Informationen zu DevSecOps-Pipelines
Die verschiedenen Pipelines, die in den Referenz-Toolchains für kontinuierliche Integration und kontinuierliches Deployment bereitgestellt werden, basieren auf der Unterstützung von Continuous Delivery für Tekton Pipelines. Weitere Informationen zu Tekton-Pipelines finden Sie unter Mit Tekton-Pipelines arbeiten.
Sie müssen kein Tekton-Experte sein, um die Referenzpipelines zu nutzen. Referenzpipelines sind mit einer Grundstruktur vordefiniert, die Platzhalter für benutzerdefinierte Skripte für Schritte wie Builds, automatische Tests und Bereitstellung enthält. Benutzer können ihre angepassten Scripts für ihre eigenen Pipelines deklarieren und Werte für verschiedene Umgebungseigenschaften für eine bestimmte Pipeline festlegen.
Pipeline-Statustypen
Es ist wichtig, die Fehler- oder Ausfallbedingungen für eine Referenzpipeline an bestimmten Punkten zu verstehen. Konzeptionell ergeben sich aus einer Task, die in einer Konformitätspipeline ausgeführt wird, zwei verschiedene Typen von Statusdaten:
- Konformitätsstatus: Der Status 'pass' oder 'fail' bei einer Prüfung des Typs
some(einige) oder bei einer Gruppe von Prüfungen. - Pipelinestatus: Der Erfolgs- oder Fehlerstatus einer Taskausführung selbst.
Wenn ein Test, ein Scan oder eine Prüfung fehlschlägt, führt dies nicht dazu, dass die Pipeline selbst fehlschlägt oder gestoppt wird; die Task, die den Test ausführt, wird als grün markiert.
Aus Konformitätssicht wirkt sich das Ergebnis des Komponententests nicht auf die Bereitstellung aus. Sie können Artefakte mit fehlgeschlagenen Prüfungen bereitstellen, jedoch bewahrt der Prozess einen Nachweis zu dieser Aktivität auf. Der Konformitätsablauf
hindert Sie nicht daran, bei einem Ausfall einen Fix freizugeben. Beispiel: Eine grün markierte Ausführung für eine Komponententesttask, bei der fehlgeschlagene Tests festgestellt wurden, bedeutet, dass The task ran successfully and found the following issues.
Wenn eine Task mit einem roten Status fehlschlägt, tritt dieser auf, weil die Pipeline nicht fortfahren kann oder nicht fortgesetzt werden sollte. Zu den Beispielbedingungen einen solches Fehlschlagen gehören:
- Fehler in einer Task oder in der Pipeline.
- Vorkommnisse, die darauf hinweist, dass es keinen Sinn macht, die Pipeline weiterhin auszuführen.
Wenn zum Beispiel ein Artefaktbuild in der kontinuierlichen Integration fehlschlägt, untergräbt dies den Zweck des eigentlichen kontinuierlichen Intergrationsprozesses.
Damit der abschließende Pipelinestatus und die Konformitätsergebnisse synchron sind, überprüft eine Task am Ende der Pipeline die Konformitätsergebnisse und legt den Status der Pipeline auf red oder green fest.
Pipeline für Pull-Anforderungen
Die Pipeline für Pull-Anforderungen führt vordefinierte Konformitätsstatusprüfungen für eine Pull-Anforderung für das angegebene Anwendungsrepository (App-Repo) aus. Diese Statusüberprüfungen könnten Sie daran hindern, die Pull-Anfrage in den
standardmäßig aktiven Zweig, normalerweise master, zusammenzuführen, wenn die Überprüfungen nicht erfolgreich sind. Öffnen oder aktualisieren Sie eine Pull-Anfrage für den standardmäßig aktiven Zweig, um den Pull-Anfrage-Pipeline-Lauf
auszulösen. Benutzer können eine eigene Konfiguration für die Pipeline und Tests in angepassten Stages ausführen. Weitere Informationen zur Pipeline für Pull-Anforderungen finden Sie im Abschnitt zur Pipeline für Pull-Anforderungen.
Pipeline für kontinuierliche Integration (Continuous Integration)
Pipeline für kontinuierliche Integration (Continuous Integration) erstellt die bereitstellungsfähigen Artefakte aus den Repositorys (Repos) der Anwendung (App). 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. Erstellte Artefakte werden auch auf Sicherheitslücken gescannt und in der Pipeline signiert, bevor sie im Bestand als release- und bereitstellungsfähig gekennzeichnet werden. 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. Weitere Informationen zur Pipeline für kontinuierliche Integration finden Sie im Abschnitt zur Pipeline für kontinuierliche Integration.
Pipeline für kontinuierliche Bereitstellung
Die Continuous-Deployment-Pipeline generiert alle Nachweise und Zusammenfassungen der Änderungsanforderungen. Die Pipeline stellt die Buildartefakte in einer bestimmten Umgebung, z. B. Staging oder Produktion, bereit und erfasst, erstellt und lädt dann alle vorhandenen Protokolldateien, Nachweise und Artefakte in das Nachweisschließfach hoch. Weitere Informationen zur Continuous-Deployment-Pipeline finden Sie unter Continuous-Deployment-Pipeline.
Kontinuierliche Compliance-Pipeline
Die kontinuierliche Compliance-Pipeline scannt die bereitgestellten Artefakte und ihre Quellenrepositorys regelmäßig auf neuere Schwachstellen, seit die Artefakte in der Produktion bereitgestellt wurden. Die Pipeline hilft auch bei der automatischen Verfolgung von Abweichungen mit Fälligkeitsdatum und bietet Anwendungsbewusstsein. Weitere Informationen finden Sie unter Kontinuierliche Compliance-Pipeline.
Bestandsworkflow
Siehe Nachweis.
Siehe Bestand.
Kontinuierliche Integration schreibt in Bestand
Das Inventar enthält mehrere Zweige, darunter den Standardzweig. Diese Verzweigungen können Bereitstellungsstages, Umgebungen oder Regionen oder eine Kombination dieser Optionen in Abhängigkeit von der Konfiguration und der Verwendung darstellen.
Der Standardzweig wird aus den Builds der kontinuierlichen Integration gespeist. Die letzte Festschreibung im Ziel, wie z. B. staging, enthält einen Tag, der darauf hinweist, dass es sich um die letzte abgeschlossene Bereitstellung
handelt.
Wenn der Standardzweig für die Inventarisierung auf einen anderen Zweig umgestellt wird, müssen Sie die Commits aus dem vorherigen Standardzweig in den neuen Standardzweig umbinden, damit der Git Commit-Verlauf linear wird.
Umstufung
Um eine Zielverzweigung umzustufen, erstellen Sie eine Pull-Anforderung. Der Inhalt der Pull-Anforderung füllt die Felder der Änderungsanforderung. Nach der Überprüfung können Sie die Pull-Anforderung für die Umstufung zusammenführen.
Delta und Bereitstellung
Nach dem Zusammenführen der Pull-Anforderung für die Umstufung kann die Bereitstellungspipeline gestartet werden. Das Bereitstellungsdelta ergibt sich aus dem Unterschied zwischen dem Inhalt der zuletzt abgeschlossenen Bereitstellung und der aktuellen Bereitstellung. Im Bereitstellungsdelta werden die Bestandselemente aufgelistet, die bereitgestellt werden.
Abschluss
Bei Beendigung der Bereitstellung wird der Tag latest nach vorne verschoben.
Während des Auslösers 'dev-mode' werden die Tags nicht erweitert. Der Zweck des Auslösers 'dev-mode' ist nur das Testen der CD-Pipeline und es wird nicht empfohlen, sie in der Produktionsumgebung zu verwenden.
Auf andere Umgebungen umstufen
Die Umstufung und Bereitstellung kann von jeder Verzweigung zu einer anderen erfolgen.
Bestandslandschaft
Der aktuelle Bereitstellungsstatus (deployed) enthält den Inhalt für die Bereitstellung in einer Umgebung. Jede umgestufte Festschreibung in den Zielverzweigungen enthält die entsprechende Ausführungs-ID der Pipeline und die ID der Änderungsanforderung als Tag. Einige Festschreibungen können mehrere Tags haben, z. B., wenn eine fehlgeschlagene Bereitstellung erneut ausgeführt wird. Der Bestand enthält alle Informationen, die für die Wiederholung der Bereitstellungen erforderlich sind.
Konfiguration für ein einzelnes Ziel mit mehreren Regionen
Bei der Konfiguration für ein einzelnes Ziel mit mehreren Regionen handelt es sich um eine Iteration für dieses Modell, bei der mehrere latest Tags für eine einzelne Zielumgebung eingeführt werden. Dieses Modell ermöglicht es,
mehrere kontinuierliche Pipelines für dasselbe Ziel für verschiedene Typen von Anwendungsfällen einzusetzen.
Sie können beispielsweise dieselbe Zielumgebung für mehrere Regionen (z. B. us-south und eu-de) in der Produktionszielumgebung und in der Bestandsverzweigung verwenden.
Verwenden Sie den Parameter region, um die Bereitstellungsregion durch die kontinuierliche Bereitstellungspipeline anzugeben. Weitere Informationen zu diesem Parameter finden Sie unter Continuous deployment Pipeline parameters.
Die Teams müssen nicht für jede Region eine eigene Zweigstelle einrichten, wie z. B. us-south-prod und eu-de-prod, und die Werbung redundant durchführen. Stattdessen geben Sie diese zusätzlichen Ziele für dieselbe
Bestandsverzweigung an und verwenden Sie dann als Git-Tags.
In dieser Konfiguration hat der prod-Zweig mehrere latest-Tags auf demselben Zweig, z. B. us-south_prod_latest und eu-de_prod_latest, und jede Continuous-Deployment-Pipeline, die für die einzelnen Regionen
zuständig ist, kann diese Tags zur Bereitstellung verwenden.
Beispielszenario
Eine Gruppe von Änderungen, die letztendlich überall implementiert werden kann, könnte zuerst in einer einzelnen Region freigegeben werden. Sie können diese Änderungen dann nach und nach in anderen Regionen bereitstellen, indem Sie kontinuierliche Bereitstellungspipelines verwenden, die auf diese Regionen ausgerichtet sind.