Pipeline für kontinuierliche Integration für Infrastructure as Code
Die Pipeline für kontinuierliche Integration für Infrastructure as Code (IaC) erstellt die bereitstellbare Konfiguration aus den IaC-Repositorys (Terraform-Inhalt).
Vor der Erstellung von Artefakten prüft die Pipeline, ob der Code gescannt und getestet wird, und zwar auf dieselbe Weise, wie Pull-Anforderungen verarbeitet werden. Die erstellten Artefakte werden in der Pipeline auch auf Schwachstellen gescannt und signiert, bevor sie im Inventar als bereit für die Freigabe und Bereitstellung markiert werden. Weitere Informationen finden Sie unter Bestand. Anders als die Pipeline für Pull-Anforderungen erfasst die Pipeline für kontinuierliche Integration Angaben und Ergebnisartefakte zu jeder Stage (Phase) des Buildvorgangs, wie dem Testen, Scannen und Signieren. Diese Daten werden mit den erstellten Artefakten korreliert und können über den Bereitstellungsprozess und das Änderungsmanagement verfolgt werden.
Stages und Tasks
Task oder Stage | Kurzbeschreibung | Anpassbar in .pipeline-config.yaml |
---|---|---|
start |
Richtet die Pipeline-Umgebung ein. | Nein |
setup |
Richtet Ihre Build- und Testumgebung ein. | Ja |
test |
Führt Komponententests für die Konfiguration IaCaus | Ja |
static-scan |
Führt statischen Scan-Code für IaCaus. | Ja |
compliance-checks |
Führt Code Risk Analyzer-Scans und andere Compliance-Prüfungen für App-Repos durch. | Ja |
build-artifact |
Erstellt die Artefakte, die der Konfiguration entsprechen. | Ja |
sign-artifact |
Signiert die erstellten Artefakte. | Ja |
deploy |
Implementiert die Konfiguration mithilfe der erstellten Artefakte in der Entwicklungsumgebung. | Ja |
acceptance-test |
Führt Akzeptanz- und Integrationstests für die bereitgestellte Konfiguration in der Entwicklungsumgebung durch. | Ja |
release |
Fügt die gebauten Artefakte dem Inventar hinzu. | Ja |
finish |
Sammelt, erstellt und lädt die Protokolldateien, Artefakte und Beweise in die Asservatenkammer hoch. | Nein |
Weitere Informationen über die Anpassung von Stufen mithilfe der Datei .pipeline-config.yaml
finden Sie unter Benutzerdefinierte Skripte. e) und
Pipelineparameter.
Parameter zum Konfigurieren von Terraform-Kontext und -Variablen
Für Terraform-Definitionen, die Infrastructure-as-Code-Quelle definieren, können der Kontext und die Variablen, die sich auf Terraform und Terraform-bezogene Scans und Prüfungen beziehen, mithilfe der in Tabelle 1 beschriebenen Parameter definiert werden.
Eigenschaft | Standard | Beschreibung |
---|---|---|
tf-dir |
. |
Position oder Pfad im Quellenrepository, in dem sich main.tf befindet. |
TF_VAR_<XXXX> |
Pipeline-oder Triggereigenschaft (gesichert oder nicht gesichert), die den Wert für die Terraform-Variable <XXXX> bereitstellt. |
|
tfvars-repository |
Git-Repository für Infrastrukturquellcode. | Git-Repository, das tfavars -Dateien enthält. Das Repository muss in der Toolchain deklariert sein. |
tfvars-branch |
main |
Zweig des Git-Repositorys, das die tfvars -Dateien enthält |
tfvars-files |
Dateien, die Terraform-Variablenwerte enthalten. | |
terraform-version |
1.2.9 |
Version des Terraform-CLI-Tools, das installiert werden soll, wenn es in dem für die stages.You können auch Versionen wie 1.5.0-1bereitstellen. Dies ist die Liste der Terraform-Versionen. |
Dieselben Parameter gelten für die Scripts, die in einem IaC CD-Implementierungsprozess verwendet werden. Da der CD-Prozess mehrere Bestandseinträge verarbeiten kann, können Sie einen Parameter für einen Bestandseintrag definieren. Um Terraform-Kontext
und -Variablen für einen Bereich (Bestandseintrag) anzugeben, stellen Sie der Eigenschaft den Namen des Bestandseintrags voran, z. B. <inventory_entry>_
. Dieses Präfix gilt für die Umgebungseinträge tf-dir
,
TF_VAR_<XXXX>
, tfvars-repository
, tfvars-branch
und tfvars-files
.
Beispiel:
hello-iac-sample_TF_VAR_resource_group : Default
Scans und Prüfungen Statischer Code-Scan
Die Stage 'Static Code Scan' führt eine Reihe von Analysetools für statischen Code in den angegebenen IaC-Repositorys aus. Die durch den Befehl pipelinectl save_repo
angegebenen Repositorys und das Standard-App-Repository werden gescannt.
Sie können jede der Methoden verwenden, die für statische Code-Scans definiert sind, die für die Anwendung konfigurierbar sind, die sich auf die kontinuierliche Integrationspipeline beziehen.
Die IaC-Pipeline für kontinuierliche Integration definiert weitere Tools, die aktiviert werden, indem die opt-in-*
-Parameter aus Tabelle 2 auf 1
gesetzt werden.
Scannen oder prüfen | Beschreibung | Enablement |
---|---|---|
tflint | Läuft tflint $tflint_args --format=json von tflint, um vor veralteter Syntax, nicht verwendeten Deklarationen zu warnen und bewährte Verfahren sowie Namenskonventionen
durchzusetzen. |
opt-in-tflint auf 1 gesetzt |
fmt | Führt terraform fmt -check von fmt aus, um Terraform-Konfigurationsdateien in ein kanonisches Format und einen kanonischen Stil umzuschreiben. |
opt-in-terraform-fmtvalidate auf 1 gesetzt |
terraform-validate | Läuft ibmcloud cra terraform-validate von terraform-validate, um vor einer bestimmten Terraform-Plan-Datei zu warnen, die nicht
den im IBM Cloud® Security and Compliance Center festgelegten Regeln entspricht |
opt-in-terraform-fmtvalidate auf 1 gesetzt |
Name | Typ | Standard | Beschreibung | Erforderlich oder optional |
---|---|---|---|---|
opt-in-terraform-fmt-validate |
text | Führt die Befehle terraform fmt und terraform validate in der Stufe static-scan aus. |
optional | |
opt-in-tflint |
text | Führt den tflint -Befehl in der Stufe static-scan aus. |
optional | |
tflint-version |
text | v0.53.0 |
Geben Sie die tflint -Version an, die installiert werden soll, wenn sie nicht in dem Image angegeben ist, das für die Ausführung der static-scan -Phase verwendet wird. |
optional |
tflint-config |
text | Die Konfigurationsdatei, die für tflint verwendet werden soll. |
optional | |
tflint-args |
text | Die Befehlsargumente, die während des Toolaufrufs an tflint übergeben werden |
optional |
Scans und Prüfungen bei Compliance-Prüfungen
Konformitätsprüfungen, die für die anwendungsbezogene Pipeline für kontinuierliche Integration definiert sind, werden auch für die IaC-Pipeline für kontinuierliche Integration ausgeführt.
Die IaC-CI-Pipeline führt einige zusätzliche Prüfungen durch, die mithilfe von opt-in-
-Funktionen aktiviert werden.
Die IaC-CI-Pipeline definiert weitere Tools, die mithilfe der Parameter opt-in-
aktiviert werden, die auf 1
gesetzt sind.
Scannen oder prüfen | Beschreibung | Enablement |
---|---|---|
cra-tf |
Verwenden Sie den Befehl ibmcloud cra terraform-validate aus dem IBM Cloud-CRA-Tool, um einen Terraform-Plan auf Konformität zu analysieren. |
opt-in-cra-tf-validate auf 1 gesetzt. |
tfsec |
Verwenden Sie das Tool TFsec, um potenzielle fehlerhafte Konfigurationen zu finden und Konformitätsprobleme zu erstellen. | opt-in-tfsec festgelegt auf 1 |
checkov |
Verwenden Sie das Tool Checkov, um fehlerhafte Konfigurationen zu finden und Konformitätsprobleme zu erstellen. | opt-in-checkov festgelegt auf 1 |
Eigenschaft | Standard | Beschreibung |
---|---|---|
opt-in-cra-tf-validate |
Das Flag für die Ausführung von Konformitätsprüfungen mit dem Tool ibmcloud cra terraform-validate . |
|
cra-tf-policy-file |
Der Pfad zur Richtlinienprofildatei. Weitere Informationen finden Sie unter Optionen für Terraform-Befehle. | |
cra-tf-scc-instance-name |
Standardmäßig wird die in der Toolchain konfigurierte Security and Compliance Center-Toolintegration verwendet. | Der Name der Integration des Tools Security and Compliance Center, der zum Abrufen des Profils und des Anhangs für die Konfiguration des Befehls cra terraform validate verwendet werden soll |
cra-tf-ignore-rules |
Die durch Kommas getrennte Liste der zu ignorierenden Regeln aus dem ibmcloud cra terraform-validate -Bericht. |
|
cra-tf-ignore-rules-file |
Der Pfad zu der JSON-Datei, die die Liste der zu ignorierenden Regeln aus dem ibmcloud cra terraform-validate -Bericht enthält. Weitere Informationen zum Dateiformat finden Sie unter Format for cra-tf-ignore-rules-file. |
|
opt-in-tfsec |
Das Flag zum Ausführen von Konformitätsprüfungen mit dem Tool tfsec . |
|
tfsec-version |
Zu verwendende `v1.21.0`` | The ` tfsec-Version. |
tfsec-args |
Die tfsec -Befehlsargumente |
|
opt-in-checkov |
Das Flag für die Ausführung von Konformitätsprüfungen mit dem Tool checkov . |
|
checkov-version |
``, d.h. die neueste Version | checkov version zu installieren, wenn sie in der Umgebung nicht verfügbar ist. |
checkov-args |
Die checkov -Befehlsargumente |
Diese Skripte werden auf allen Repos ausgeführt, die der Pipeline bekannt sind. Um Repos zu diesen Scans hinzuzufügen, verwenden Sie die Schnittstelle pipelinectl
, die in Ihrer Einrichtungsphase bereitgestellt wird. Weitere Informationen
finden Sie unter pipelinectl
.
Weitere Informationen zu der erwarteten Ausgabe aus Benutzerscriptstages finden Sie in Angepasste Scripts.
Format für cra-tf-ignore-rules-file
Das erwartete Format für die Datei, die von cra-tf-ignore-rules-file format
definiert wird. Das Format ähnelt dem Format (ohne das Feld scc_parameters
) in der Beispiel-SCC-Profildatei V2 für den terraform-validate
-Befehl.
Beispielinhalt für die Datei cra-tf-ignore-rules-file
:
{
"scc_rules": [
{
"scc_rule_id": "rule-8cbd597c-7471-42bd-9c88-36b2696456e9"
},
{
"scc_rule_id": "rule-c97259ee-336d-4c5f-b436-1868107a9558"
}
]
}
Artefakt erstellen
In der Phase der Artefakterstellung können Sie Ihre eigenen Artefakte erstellen. Für die IaC-CI-Pipeline erstellt die Standardbuildfunktion eine TAR-Datei, die die Terraform-Konfiguration enthält.
Die Standardbuildfunktion kann mithilfe bestimmter Parameter aus Tabelle 5 konfiguriert werden.
Eigenschaft | Standard | Beschreibung |
---|---|---|
configuration-name |
Der "menschliche" Teil des Namens des Git-Repositorys. | Der Name der Konfiguration IaC. Wird für den Artefaktdateinamen und den Bestandseintrag verwendet, der von der IaC-CI-Pipeline erstellt wird. |
build-ignore-file |
Pfad zu einer Ignorierungslistendatei (für tar --exclude-from verwendet) |
Weitere Informationen dazu, wie Sie in Stages angepasster Scripts auf Parameter und geheime Schlüssel zugreifen, finden Sie unter Angepasste Scripts.
Artefaktsignierung
Die Stage 'Sign Artifact' stellt ein Standardverhalten für die Verwendung eines GPG-Schlüssels zum Erstellen einer freigegebenen Signaturdatei für ein oder mehrere Artefakte bereit.
Eigenschaft | Beschreibung |
---|---|
signing-key |
Wert des privaten GPG-Schlüssels, der für die ASCII-Version von freigegebenen Signaturen eines oder mehrerer Artefakte verwendet wird |
Wenn Sie einen anderen Signierprozess verwenden wollen, passen Sie diese Stufe mithilfe der .pipeline-config.yaml
-Konfiguration in Ihrem Projekt an.
In Entwicklung implementieren
Die Implementierungsphase implementiert das Konfigurationsartefakt in einer Entwicklungsumgebung. Sie können Ihre Variablen und Berechtigungsnachweise für diese Stage aus Variablen in der Pipeline-Benutzerschnittstelle und den Webhook-Nutzdaten für Pipeline-Auslöser angeben.
Die Scripts, die als Teil des Common Base Image bereitgestellt werden, können bei der Ausführung einer Implementierung mithilfe von Schemas oder der Terraform-CLI helfen. Die Parameter zum Konfigurieren der Scripts für die Implementierungsaktion werden in Tabelle 8 und Tabelle 9 beschrieben.
Konfigurationsparameter für die Verwendung von Schematics als Implementierungstool
Eigenschaft | Standard | Beschreibung |
---|---|---|
schematics-ibmcloud-api-key |
Überschreibt die ibmcloud-api-key , die für die schematics-bezogenen Aktionen verwendet wird (Abrufen/Erstellen, Planen & Anwenden des Schematics-Arbeitsbereichs). |
|
schematics-workspace-name |
<schematics-workspace-prefix><toolchain name>-<pipeline id> |
Arbeitsbereich, der verwendet oder erstellt werden soll, wenn er nicht vorhanden ist. Wenn der Arbeitsbereich vorhanden ist, muss es sich um einen Arbeitsbereich handeln, der ohne Link zu einem Git-Repository erstellt wurde. Weitere
Informationen hierzu finden Sie im Abschnitt Schematics-Arbeitsbereichserstellung. Diese Einschränkung ist darauf zurückzuführen, dass
das Script das IaC-Konfigurationsartefakt als tar -Datei mithilfe von Schematics Workspace-Upload hochlädt. |
schematics-workspace-prefix |
Präfix für die Arbeitsbereichserstellung, wenn kein Arbeitsbereich für die Implementierungsaktion angegeben ist. | |
schematics-workspace-resource-group |
Standardmäßig wird die Ressourcengruppe der Toolchain verwendet. | Ressourcengruppe, die für die Erstellung des Schematics-Arbeitsbereichs verwendet werden soll. |
schematics-workspace-region |
Standardmäßig wird die Region der Toolchain verwendet. | Für die Erstellung des Schematics-Arbeitsbereichs zu verwendende Region. |
schematics-workspace-netrc |
Aus bekannten Repositorys berechnet. | Wert für die netrc -Konfiguration des zu erstellenden Schematics-Arbeitsbereichs. Weitere Informationen finden Sie unter Unterstützung beim Herunterladen von Modulen vom privaten fernen Host. |
schematics-workspace-terraform-version |
Standardmäßig wird die mit ibmcloud schematics version --output JSON abgerufene Schematics-Terraform-Version verwendet. |
Terraform-Version, die für den zu erstellenden Schematics-Arbeitsbereich verwendet wird. Siehe Übersicht über Schematics-Images und gepackte Terraform-Provider. |
Um die Scripts im Implementierungsprozess für die IaC-CD zu konfigurieren, definieren Sie den Parameter für einen bestimmten Bestandseintrag. Wenn Sie Schematics as deployment tool
-bezogene Umgebungseigenschaften für einen bestimmten
Bereich (Bestandseintrag) angeben möchten, stellen Sie der Eigenschaft den Namen des Bestandseintrags voran. Beispiel: <inventory_entry>_
. Dieses Präfix gilt für alle schematics-bezogenen Umgebungseinträge (außer schematics-ibmcloud-api-key
).
Beispiel:
hello-iac-sample_schematics-workspace-name : workspace-for-deployment-of-hello-iac-sample
Konfiguration zur Verwendung der Terraform-CLI als Bereitstellungstool
Eigenschaft | Beschreibung |
---|---|
tf-backend-s3-bucket |
Bucketname, in dem der Status gespeichert wird. |
tf-backend-s3-key |
Name, der zum persistenten Speichern des Status verwendet werden soll. |
tf-backend-s3-region |
Region der Instanz Cloud Object Storage. |
tf-backend-s3-endpoint |
Cloud Object Storage endpunkt. |
tf-backend-s3-access_key |
Unterabschnitt HMAC access_key der Berechtigungsnachweise. |
tf-backend-s3-secret_key |
Unterabschnitt HMAC secret_key der Berechtigungsnachweise. |
Beachten Sie Folgendes:
- Weitere Informationen zur Verwendung des Endpunkts oder Buckets Cloud Object Storage zum Speichern des Terraform-Status finden Sie unter Terraform-Status in Cloud Object Storage.
- Um die Scripts im Implementierungsprozess für die IaC-CD zu konfigurieren, definieren Sie den Parameter für einen Bestandseintrag. Um
Terraform CLI as deployment tool
-bezogene Umgebungseigenschaften für einen Bereich (Bestandseintrag) anzugeben, stellen Sie der Eigenschaft den Namen des Bestandseintrags voran, z. B.<inventory_entry>_
. Dieses Präfix gilt für alle schematics-bezogenen Umgebungseinträge.
Beispiel:
hello-iac-sample_tf-backend-s3-bucket : bucket-to-store-tfstate-of-hello-iac-sample
An Bestand freigeben
Verwenden Sie die Benutzerscript-Stage für die Freigabe an den Bestand, um Artefakte mithilfe des CLI-Befehls cocoa inventory add
zum Bestand hinzuzufügen. Weitere Informationen zu cocoa inventory add
finden Sie in
Hinzufügen von Kakaobestand.
Sie können die Schnittstelle pipelinectl
verwenden, um auf Ihre Repos und Artefakte zuzugreifen, indem Sie die Befehle list_repos
, load_repo
, list_artifacts
und load_artifact
verwenden.
Weitere Informationen finden Sie unter pipelinectl.
Compliancedaten beim Buildvorgang erfassen
Wenn die Pipeline erfolgreich ausgeführt wird, können Sie Informationen zum Build erfassen.
Bei allen Kontrollen, Scans, Tests und Unterzeichnungen von Artefakten werden Beweise gesammelt und in der Asservatenkammer aufbewahrt. Die Protokolldateien der Pipeline werden zusammen mit den eigentlichen Pipelinedaten, die die Tekton-Definitionen
enthalten, ebenfalls in diesem Schließfach gespeichert. Bei diesem Schritt werden auch Compliance-Daten zu Prüfungen durch Peers erfasst. Die Pipeline verwendet pipelinectl
, um nach Repositorys mit Pull-Anforderungen zu suchen,
die seit dem letzten Buildvorgang zusammengeführt wurden. Die Pipeline prüft auch den PR-Prüfungsstatus, speichert ihn als Artefakt und erstellt auf der Grundlage des Ergebnisses Nachweise.
Beim letzten Script handelt es sich um ein Auswertungsprogramm, das den Status der Pipeline abhängig von den Nachweisstatus grün oder rot kennzeichnet. Treten Fehler auf, wird der kontinuierliche Integrationslauf als rot markiert.