What Is a Container Pipeline?

Eine Container-Pipeline ist ein Software-Liefer-Workflow, der das Erstellen, Testen und Bereitstellen containerisierter Anwendungen in jeder Entwicklungsphase automatisiert. Container-Pipelines verbinden die Isolation und Portabilität der Containerisierung mit CI/CD-Automatisierung und ermöglichen es DevOps-Teams, Software schneller und zuverlässiger auszuliefern. Dieser Artikel behandelt, wie Container-Pipelines funktionieren, ihre vier Schlüsselphasen und Best Practices für die Implementierung in einer DevOps-Umgebung.

Warum benötigen Organisationen Container-Pipelines?

Die Containerisierung hat die Anwendungsentwicklung und -bereitstellung revolutioniert und isolierte, abhängig verwaltete und unveränderliche Softwareanwendungen hervorgebracht, die überall eingesetzt werden können. Der reduzierte Ressourcenbedarf von Containern hilft außerdem, die Betriebskosten und den Verwaltungsaufwand zu minimieren. Softwareteams müssen schnell liefern, um den Anforderungen der Endnutzer gerecht zu werden und auf sich ändernde Marktbedingungen zu reagieren. Deshalb haben sich Organisationen auf automatisierte Softwareentwicklungslebenszyklen (SDLCs) spezialisiert – strukturierte Prozesse mit ausreichender Agilität, um unerwartete Probleme zu bewältigen, ohne die Lieferung zu verlangsamen. Die wichtigste Komponente eines effektiven SDLC ist eine Lieferpipeline, die alles – Entwicklung, Test, Bereitstellung und Wartung – unter einem einzigen übergeordneten Prozess abdeckt. Container-Pipelines erweitern dieses Konzept, indem sie den Container zur zentralen Liefereinheit machen.

Was sind die Grundlagen einer SDLC-Pipeline?

Eine SDLC-Pipeline ist ein Workflow, der einen integrierten, durchgängigen Prozess schafft, der alle Phasen der Softwareentwicklung umfasst. Auf der grundlegendsten Ebene besteht eine Pipeline aus folgenden Stufen:

• Entwicklungsphase: Anwendungscode wird entwickelt und in ein Code-Repository eingebettet
• Code-Überprüfung/-Akzeptanzphase: Code wird manuell oder durch automatisierte Überprüfungen überprüft
• Build-Phase: Code wird gebaut und verpackt
• Testphase: Umfassende automatisierte und manuelle Tests werden durchgeführt
• Bereitstellungsphase: Getestete Software wird in der Produktionsumgebung bereitgestellt

Jede Phase beinhaltet integrierte Validierungen und Verifikationen, um Fehler frühzeitig zu erkennen. Wenn ein Fehler erkannt wird, werden die zuständigen Teams sofort benachrichtigt, damit Probleme vor dem Weitergehen behoben werden können. Da die meisten Aufgaben automatisiert sind, sind Rückkopplungsschleifen kürzer – aber dennoch robust genug, um alle Aspekte der Anwendung abzudecken. SDLC-Pipelines sind nicht auf Softwareentwicklung beschränkt; sie gelten auch für das Datenbankmanagement und das Infrastrukturmanagement.

Wie unterscheidet sich eine Containerpipeline von einer traditionellen Pipeline?

Container-Pipelines unterscheiden sich von traditionellen Pipelines. Container-Pipelines unterscheiden sich von traditionellen Pipelines in einem Schlüsselbereich: Container-Pipelines konzentrieren sich darauf, Container-Images zu erstellen und diese in einer Orchestrierungsplattform wie Kubernetes bereitzustellen, anstatt traditionelle Anwendungsartefakte zu packen und bereitzustellen. Alle Standard-SDLC-Stufen bleiben bestehen, aber die Bau- und Bereitstellungsstufen sind speziell um Container herum konzipiert.

Was sind die vier Stufen einer Containerpipeline?

Die Entwicklung von Container-Pipelines konzentriert sich auf vier Hauptbereiche: zentralisiertes Sourcecode-Management und -Build, Testing, CI/CD und Produktionsbereitstellung. Die Komplexität und der Umfang einer Containerpipeline hängen von der Anwendungsarchitektur, Anforderungen, der Bereitstellungsstrategie und den verwendeten Technologien ab. Da Container die zentrale Komponente sind, dreht sich der Technologiestack typischerweise um Plattformen, die für Container üblich sind: Docker, Kubernetes und Rancher.

Phase 1: Zentralisiertes Sourcecode-Management und -Build

In dieser Phase werden alle Entwickler ihren Code in ein zentrales Code-Repository eintragen, das die Entwicklungs-, Code-Review- und Build-Phasen der Pipeline umfasst. Ein Pull Request dient als Ausgangspunkt für den automatisierten Pipeline-Workflow im Code-Repository. Die erste Aufgabe ist es, eine Reihe von Tests durchzuführen, um die Funktionalität des neuen Codes sicherzustellen:

• Unit-Tests, die die Kernfunktionalität des Codes abdecken
• A/B-Tests, die die Leistung zweier Komponenten vergleichen

Diese Tests stellen optimalen, fehlerfreien Code sicher. Da dies die erste Phase der Pipeline ist, können erkannte Probleme behoben werden, bevor sie in den Container übertragen werden. Als Nächstes wird die Anwendung verpackt und ein Container-Image erstellt – alle Abhängigkeiten werden zur Containererstellung auf einem vorgegebenen Image aufgebaut. Das Image wird dann in eine interne Container-Registry zur Bereitstellung in einer Staging-Umgebung gepusht.

Phase 2. Tests

Die Testphase beginnt, sobald das Container-Image erstellt ist und die Pipeline die Anwendung in einer Staging-Umgebung bereitgestellt hat. (Diese Tests können auch in kontinuierliche Tests integriert werden.) Tests behandeln Funktionalität, Leistung und Sicherheit des Containers. Wichtige Tests in dieser Phase umfassen:

• Funktionstests, die überprüfen, ob das Anwendungsverhalten den Anforderungen entspricht
• Regressionstests, die die neue containerisierte Anwendung mit früheren Versionen vergleichen
• Stresstests, die bestimmen, wie sich der Behälter unter weniger optimalen Bedingungen verhält
• Sicherheitstests, die durch Penetrationstests und Schwachstellen-Scans nach Schwachstellen suchen

Nach Bestehen dieser Tests wechseln die Container zum Akzeptanztest. Die Flexibilität der Containerisierung erleichtert es, Endnutzer in Akzeptanztests einzubeziehen – Container werden einfach in einer Vorproduktionsumgebung bereitgestellt, ohne die Anwendung zu verändern. Für Container, die Teil eines größeren Clusters sind oder von anderen Containern abhängig sind, muss die Testphase auch Fehlertoleranztests für Clusterausfälle oder Kommunikationsprobleme enthalten. Dies stellt sicher, dass neue Containerversionen die zugrunde liegende Orchestrierungsplattform nicht beeinträchtigen.

Stufe 3: Kontinuierliche Integration und Bereitstellung (CI/CD)

Ein robustes CI/CD-Tool stellt die automatisierte Plattform bereit, die die Container-Pipeline antreibt und alle erforderlichen Pipeline-Funktionalitäten kombiniert. Die meisten CI/CD-Tools können Container-Pipelines unterstützen, darunter Jenkins, CircleCI, Travis CI und TeamCity. Cloudbasierte Optionen wie AWS CodeBuild oder Azure DevOps unterstützen ebenfalls Container-Pipelines. Jenkins X und Flux sind spezialisierte Tools mit stärkerem Schwerpunkt auf Container-Pipelines und verwenden einen GitOps-Ansatz mit direkten Integrationen für Orchestrierungsplattformen wie Kubernetes. (Lernen Sie, wie man eine CI/CD-Pipeline einrichtet.) Bei der Auswahl eines CI/CD-Tools sollten Sie die Unterstützung für die in der Pipeline verwendeten Technologien und Services überprüfen: Versionskontrollsysteme, Build-Tools und Containerplattformen. Je nativer die Unterstützung, desto besser die Integration. Zu den Hauptanforderungen einer Container-Pipeline-CI/CD-Plattform gehört die native Unterstützung für Containerisierung:

• Erstellung von containerisierten Bildern
• Interaktion mit Containerregistern
• Integration mit Orchestrierungswerkzeugen

Für einige dieser Anforderungen existieren Workarounds, erhöhen jedoch die Pipeline-Komplexität und erfordern möglicherweise manuelle Interventionen. Die Auswahl des CI/CD-Tools sollte auch die Erweiterbarkeit berücksichtigen, was besonders wichtig ist, wenn das Tool zusätzliche Konfigurationen wie Datenbank- oder Infrastrukturmanagement abdeckt. Schließlich sollte die Pipeline mehrere gleichzeitige Workflows unterstützen – essenziell, wenn mehrere Teams verschiedene Container in einer microservices-basierten Anwendung bauen. (Container und Microservices vergleichen.)

Stufe 4. Produktionseinsatz

Die Produktionsbereitstellung ist das logische Ende einer Container-Pipeline. Sobald ein Container getestet und akzeptiert wurde, wird er direkt aus der Pre-Release-Umgebung in die Produktionsumgebung bereitgestellt – nahtlos und ohne Änderungen. Die meisten containerisierten Deployments basieren auf Orchestrierungstools wie Kubernetes und Rancher. Diese Tools vereinfachen Container-Deployments, indem sie native Unterstützung für das Aktualisieren und Nacherstellen von Containern bieten, ohne die Verfügbarkeit zu beeinträchtigen. Container-Images werden in eine Container-Registry übertragen, und das Orchestrierungstool übernimmt das Update bestehender Container oder die Bereitstellung neuer. Da Orchestrierungstools plattformunabhängig sind, können Teams auf jedem unterstützten Cluster deployen und Multi-Cloud-Deployments aus einer einzigen Pipeline ausführen.

Was sind die besten Praktiken für Containerpipelines?

Best Practices für Container-Pipelines konzentrieren sich darauf, jede der vier Stufen korrekt zu konfigurieren und für jede Phase klare Workflows zu etablieren. Teams können Container-Pipelines weiter erweitern, indem sie Infrastrukturmanagement integrieren, um Staging und Produktionsinfrastruktur direkt innerhalb der Pipeline zu verwalten. Beispielsweise kann die Bereitstellung eines neuen Servers oder das Aktualisieren von Load-Balancer-Konfigurationen und Netzwerkrouting aus der Pipeline über IaC-Tools wie Terraform oder AWS CloudFormation übernommen werden. Bei diesem Ansatz ist es unerlässlich, externe Ressourcen – Firewalls, Datenspeicher und Backups – selbst in cloudbasierten verwalteten Kubernetes-Clustern korrekt zu verwalten. Die Integration des Infrastrukturmanagements in die Containerpipeline schafft einen einzigen, umfassenden Prozess, der alle Aspekte der Bereitstellung abdeckt.

Steigere Entwicklungsgeschwindigkeit und Flexibilität

Container-Pipelines sind Software-Lieferpipelines, die darauf ausgerichtet sind, Container zu bauen und bereitzustellen. Die Kombination aus Containerisierung mit automatisierten CI/CD-Tools verschafft Software-Delivery-Teams größere Flexibilität und beschleunigt den Entwicklungsprozess.

FAQ: Container-Pipelines in DevOps

Was ist eine Containerpipeline in DevOps?

Eine Containerpipeline in DevOps ist ein automatisierter Software-Lieferworkflow, der containerisierte Anwendungen in jeder Phase des SDLC erstellt, testet und bereitstellt. Containerpipelines verwenden CI/CD-Tools, um den Prozess vom Quellcode-Commit bis zur Produktionsbereitstellung zu automatisieren, wobei der Container die zentrale Liefereinheit bildet.

Was sind die vier Phasen einer Containerpipeline?

Die vier Phasen einer Containerpipeline sind: (1) zentrale Quellcodeverwaltung und -entwicklung, bei der Code eingetragen und Container-Images erstellt werden; (2) Testen, die funktionale, Regressions-, Stress- und Sicherheitstests abdecken; (3) CI/CD, bei denen automatisierte Werkzeuge jede Pipeline-Phase orchestrieren und verbinden; und (4) Produktionsbereitstellung, bei der der getestete und akzeptierte Container in die Produktionsumgebung freigegeben wird.

Wie unterscheidet sich eine Container-Pipeline von einer traditionellen Delivery-Pipeline?

Eine traditionelle Delivery-Pipeline konzentriert sich auf das Erstellen und Bereitstellen von Standard-Anwendungspaketen, während eine Container-Pipeline speziell darauf ausgelegt ist, Container-Images zu erstellen und diese über eine Orchestrierungsplattform wie Kubernetes bereitzustellen. Die Kern-SDLC-Stufen sind in beiden Phasen gleich, aber die Build- und Deployment-Phasen einer Containerpipeline basieren auf Container-Technologien und -Registries.

Welche CI/CD-Tools unterstützen Container-Pipelines?

Beliebte CI/CD-Tools, die Container-Pipelines unterstützen, sind Jenkins, CircleCI, Travis CI, TeamCity, AWS CodeBuild und Azure DevOps. Jenkins X und Flux sind speziell entwickelte Optionen mit nativer Container-Pipeline-Unterstützung und direkter Kubernetes-Integration mit einem GitOps-Ansatz.

Welche Rolle spielt Kubernetes in einer Container-Pipeline?

Kubernetes dient als Orchestrierungsplattform für die Produktionsbereitstellung in einer Container-Pipeline. Kubernetes verwaltet die Bereitstellung, Skalierung und Aktualisierung von Containern, ohne die Anwendungsverfügbarkeit zu beeinträchtigen. Da Kubernetes plattformunabhängig ist, ermöglicht es Teams, auf jeden unterstützten Cluster zu deployen und Multi-Cloud-Deployments aus einer einzigen Pipeline durchzuführen.

Verwandte Literatur

• BMC DevOps Blog
• Container-Sprawl: Was es ist und wie man es vermeidet
• Verwaltung von Containern und Code für DevOps
• Wie man MongoDB als Docker-Container ausführt
• Automatisierung in DevOps: Warum und wie man DevOps-Praktiken automatisiert
• Wie und warum man eine Softwarefabrik wird

Die in diesem Beitrag geäußerten Ansichten und Meinungen sind die des Autors und spiegeln nicht unbedingt die offizielle Position von BMC wider.

DevOps-Leitfaden

1. Was ist DevOps? Eine umfassende Einführung
2. Eine kurze Geschichte von DevOps
3. Einführung in die DevOps-Architektur
4. Automatisierung in DevOps: Warum und wie man DevOps-Praktiken automatisiert
5. Was ist CI/CD? Kontinuierliche Integration und kontinuierliche Lieferung erklärt
6. Wie man eine CI/CD-Pipeline mit Jenkins aufbaut
7. DevOps-Metriken zur Optimierung von CI/CD-Pipelines
8. Kontinuierliche Liefermetriken
9. Ist Continuous Integration in Continuous Deployment ein Fortschritt – oder nicht?
10. Unterschiede zwischen Continuous Integration (CI), Delivery (CD) und Deployment
11. Quellcode und Versionskontrolle in DevOps
12. Was ist kontinuierliche Testung?
13. Testautomatisierungs-Frameworks: Der ultimative Leitfaden
14. Release Management in DevOps
15. Erklärt: Monitoring & Telemetrie in DevOps
16. Anwendungs-Leistungsmanagement in DevOps
17. DevOps-Orchestrierung im SDLC
18. Einführung in Datenbank-DevOps
19. Die Rolle der Microservices in DevOps
20. Die Rolle der Virtualisierung in DevOps
21. Container & DevOps: Wie Container in DevOps-Lieferpipelines passen
22. Was ist eine Containerpipeline?
23. Was ist eine DevOps-Toolchain?
24. Verwaltung von Containern und Code für DevOps
25. Die Rolle von Agile in DevOps
26. Die Rolle der Cloud in DevOps
27. Was ist FinDevOps?
28. Top-DevOps-Trends im Jahr 2022
29. DevOps-Werte & Prinzipien
30. DevOps-Kennzahlen und KPIs
31. DevOps-Ratschläge für kleine, mittlere und große Organisationen
32. DevOps-Teamstruktur
33. Top-DevOps-Bücher, die man heute lesen sollte
34. Buchrezension von The Phoenix Project: DevOps For Everyone
35. DevOps-Influencer: 11 DevOps-Experten, denen Sie auf Twitter folgen können
36. GitHub, GitLab, Bitbucket & Azure DevOps: Was ist der Unterschied?
37. Best Practices: Wie man Anwendungen für Kubernetes architekt
38. Konfigurationsmanagement in DevOps
39. DevOps-Verzweigungsstrategien erklärt
40. DevOps-Jobbezeichnungen, Rollen und Verantwortlichkeiten
41. Testen in DevOps: Konzepte, Best Practices und mehr
42. Der vollständige DevOps-Zertifizierungsleitfaden für 2022
43. Was ist das Kubernetes-Operator-Muster?

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.