IBM Cloud Docs
Pipeline für kontinuierliche Integration für Infrastructure as Code

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

Kontinuierliche Integration für IaC-Phasen und -Aufgaben
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.

Parameter zum Konfigurieren des Terraform-Kontexts und der Terraform-Variablen
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
Parameter der statischen IaC Scan-Tools
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.

Zusätzliche IaC Compliance-Scans und -Prüfungen
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
IaC Compliance scannt und prüft Konfigurationsparameter
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.

Konfigurationsparameter für Buildartefakte
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.

GPG-Schlüssel für Artefakt erstellen
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

Konfigurationsparameter zur Verwendung Schematics als Bereitstellungstool
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

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.