Container & DevOps: Wie Container in DevOps-Lieferpipelines passen

Container fügen sich in DevOps-Lieferpipelines ein, indem sie Anwendungscode und alle seine Abhängigkeiten in einer einzigen portablen Einheit packen und so den Umgebungskonfigurationsaufwand in jeder Pipeline-Phase eliminieren. In Kombination mit einer CI/CD-Pipeline vereinfacht die Containerisierung die Bereitstellung von der Entwicklung bis zur Produktion und integriert sich natürlich in Orchestrierungsplattformen wie Kubernetes. Das Ergebnis ist ein schnellerer, konsistenterer DevOps-Lieferprozess mit weniger umgebungsbezogenen Fehlern und weniger manuellem Eingriff.

DevOps wurde bekannt, um der stetig wachsenden Markt- und Verbrauchernachfrage nach Technologieanwendungen gerecht zu werden. Ziel ist es, eine schnellere Entwicklungsumgebung zu schaffen, ohne die Qualität der Software zu beeinträchtigen. DevOps konzentriert sich außerdem darauf, die Gesamtqualität von Software in einem schnellen Entwicklungszyklus zu verbessern. Es setzt auf eine Kombination verschiedener Technologien, Plattformen und Werkzeuge, um all diese Ziele zu erreichen.

Containerisierung ist eine Technologie, die die Art und Weise, wie wir Anwendungen entwickeln, bereitstellen und verwalten, revolutioniert hat. In diesem Beitrag betrachten wir, wie Container in die DevOps-Welt passen und welche Vor- oder Nachteile eine containerbasierte DevOps-Lieferpipeline bietet.

Was ist eine containerisierte Anwendung?

Eine containerisierte Anwendung ist ein Softwarepaket, das den Anwendungscode und alle erforderlichen Abhängigkeiten in einer einzigen tragbaren Einheit, einem sogenannten Container, bündelt. Container teilen sich den Kernel des Host-Betriebssystems, wodurch sie leichter als virtuelle Maschinen sind und dennoch auf jeder unterstützten Infrastruktur mit minimaler Konfiguration einsetzbar bleiben.

Die Virtualisierung half den Nutzern, virtuelle Umgebungen zu schaffen, die Hardwareressourcen teilen. Die Containerisierung geht noch einen Schritt weiter , indem sie den Betriebssystemkernel teilt.

Dies führt zu leichtgewichtigen und von Natur aus portablen Objekten (Containern), die den Softwarecode und alle erforderlichen Abhängigkeiten bündeln. Diese Container können dann auf jeder unterstützten Infrastruktur mit minimalen oder keinen externen Konfigurationen bereitgestellt werden.

Einer der komplexesten Teile einer traditionellen Bereitstellung ist die Konfiguration der Bereitstellungsumgebung mit allen Abhängigkeiten und Konfigurationen. Containerisierte Anwendungen eliminieren diese Konfigurationsanforderungen, weil der Container alles, was die Anwendung benötigt, im Container selbst verpackt.

Darüber hinaus benötigen Container weniger Ressourcen und lassen sich im Vergleich zu virtuellen Maschinen leichter verwalten. Containerisierung führt zu stark vereinfachten Deployment-Strategien, die leicht automatisiert und in DevOps-Lieferpipelines integriert werden können. In Kombination mit einer Orchestrierungsplattform wie Kubernetes oder Rancher können Nutzer:

• Nutzen Sie die Stärken dieser Plattformen, um die Anwendung während ihres gesamten Lebenszyklus zu verwalten
• Bieten Sie größere Verfügbarkeit, Skalierbarkeit, Leistung und Sicherheit

Was ist eine kontinuierliche Lieferpipeline?

Eine Continuous Delivery-Pipeline ist eine automatisierte Abfolge von Schritten, die Software von der Entwicklung über das Testen bis hin zur Produktion auf konsistente, wiederholbare Weise führt. In DevOps werden Continuous Delivery-Pipelines typischerweise mit kontinuierlicher Integration kombiniert, um CI/CD-Pipelines zu bilden, die den gesamten Softwareentwicklungs- und Release-Prozess automatisieren.

DevOps basiert auf Continuous Delivery (CD) als Kernprozess zur Verwaltung der Softwarelieferung. Continuous Delivery ermöglicht es Softwareentwicklungsteams, Software häufiger bereitzustellen und gleichzeitig die Stabilität und Zuverlässigkeit der Systeme zu gewährleisten.

Continuous Delivery nutzt einen Stack von Tools wie CI/CD-Plattformen, Testwerkzeuge und Automatisierung, um häufige Softwarelieferungen zu ermöglichen. Automatisierung spielt eine wichtige Rolle in diesen Continuous Delivery-Pipelines, indem sie alle möglichen Aufgaben der Pipeline automatisiert – von Tests, Infrastrukturbereitstellung bis hin zu Deployments.

In den meisten Fällen wird Continuous Delivery mit Continuous Integration kombiniert, um robustere Delivery-Pipelines zu schaffen, die CI/CD-Pipelines genannt werden. CI/CD-Pipelines ermöglichen es Organisationen, den gesamten Softwareentwicklungsprozess in eine DevOps-Pipeline zu integrieren:

• Continuous Integration stellt sicher, dass alle Codeänderungen in die Lieferpipeline integriert werden.
• Continuous Delivery stellt sicher, dass neue Änderungen ordnungsgemäß getestet und letztlich in der Produktion implementiert werden.

Beide sind entscheidend für eine erfolgreiche DevOps-Lieferpipeline.

(Lerne, wie man eine CI/CD-Pipeline einrichtet.)

Wie fügt sich das alles zusammen?

Containerisierung und CI/CD-Pipelines arbeiten zusammen, indem sie umgebungsspezifische Konfigurationsschritte durch einen einzigen Container-Build ersetzen, der unverändert durch jede Pipeline-Phase – von der Entwicklung über das Staging bis zur Produktion – reist. Die entscheidende Veränderung besteht darin, dass Teams den Container einmal bauen und ihn überall einsetzen, anstatt Umgebungen in jeder Phase bereitzustellen und zu konfigurieren.

Traditionelle DevOps-Pipeline

In einer traditionellen Lieferpipeline sind folgende Schritte typisch:

• Software entwickeln und neue Änderungen in ein zentrales Repository integrieren (Versionskontrolltools kommen hier ins Spiel).
• Code überprüfen und validieren sowie Änderungen zusammenführen
• Baue die Anwendung mit den neuen Codeänderungen
• Stellen Sie die Testumgebung mit allen Konfigurationen und Abhängigkeiten bereit und bereiten Sie die Anwendung bereit
• Führen Sie Tests durch (sowohl automatisiert als auch manuell, je nach Anforderung)
• Die Anwendung in der Produktion bereitstellen (Ressourcenbereitstellung und Abhängigkeitskonfiguration erforderlich)

Die meisten dieser Aufgaben können mit IaC-Tools wie Terraform und CloudFormation automatisiert werden, und die Bereitstellung kann mit Plattformen wie AWS Elastic Beanstalk und Azure App Service vereinfacht werden. Diese automatisierten Aufgaben erfordern jedoch weiterhin sorgfältige Konfiguration und Verwaltung, und die Nutzung anbieterspezifischer Tools schafft ein Vendor-Lock-in-Risiko .

Containerisierte Lieferpipeline

Eine containerisierte Pipeline vereinfacht denselben Workflow mit deutlich geringerem Verwaltungsaufwand:

• Entwicklung und Integration von Änderungen mit einem Versionskontrollsystem
• Codeänderungen überprüfen, validieren und zusammenführen
• Baue den Container (das Code-Repository enthält den Anwendungscode plus alle Konfigurationsdateien und Abhängigkeiten, die zum Erstellen des Containers benötigt werden)
• Deploye den Container in der Staging-Umgebung
• Durchführung von Anwendungstests
• Setze denselben Container in die Produktionsumgebung ein

Containerisierte Pipelines eliminieren effektiv die meisten regulären Anforderungen an Infrastruktur und Umgebungskonfiguration. Die Container-Bereitstellungsumgebung muss dennoch vorher konfiguriert werden – typischerweise bedeutet dies entweder eine Container-Orchestrierungsplattform wie Kubernetes oder Rancher oder einen plattformspezifischen Orchestrierungsdienst wie Amazon Elastic Container Service (ECS), AWS Fargate oder Azure Container Services.

Was ist der entscheidende Unterschied zwischen traditionellen und containerisierten Pipelines?

Der entscheidende Unterschied ist, was gebaut wird: In einer traditionellen Pipeline wird nur die Anwendung gebaut; in einer containerisierten Pipeline wird der komplette Container gebaut – wobei die Anwendung, alle ihre Abhängigkeiten und ihre Konfigurationen zu einer einzigen, deploybaren Einheit gebündelt werden, die in jeder unterstützten Umgebung funktioniert.

Diese Unterscheidung hat erhebliche nachgelagerte Auswirkungen auf die Lieferpipeline:

• Weniger Konfigurationsfehler: Der Container trägt alle Anwendungsabhängigkeiten und -konfigurationen, wodurch umgebungsspezifische Fehler reduziert werden
• Schnellere Umgebungsübergänge: Lieferteams können Container schnell zwischen Staging und Produktion bewegen, ohne umkonfiguriert zu werden
• Engerer Anwendungsbereich der Fehlerbehebung: Entwickler konzentrieren sich auf die Anwendung innerhalb des Containers, anstatt externe Konfigurations- oder Serviceprobleme zu verfolgen

Moderne Anwendungsarchitekturen wie microservices-basierte Architekturen eignen sich gut für die Containerisierung, da sie die Anwendungsfunktionalität von verschiedenen Diensten entkoppeln. Containerisierung ermöglicht es den Nutzern, diese Services als separate, einzelne Einheiten zu verwalten, ohne auf externe Konfigurationen angewiesen zu sein.

Container erfüllen weiterhin Anforderungen an das Infrastrukturmanagement – am auffälligsten ist das Management beider:

• Container-Orchestrierungsplattformen
• Externe Dienste wie Load Balancer und Firewalls

Die Nutzung einer Managed-Container-Orchestrierungsplattform wie Amazon Elastic Kubernetes Service (EKS) oder Azure Kubernetes Service (AKS) eliminiert jedoch die Notwendigkeit, die Orchestrierungsinfrastruktur direkt zu verwalten. Diese verwalteten Plattformen ermöglichen es Kubernetes-Nutzern, von Cloud-Skalierung ohne Lieferantenbindung zu profitieren, da beide auf dem offenen Kubernetes-Standard basieren.

(Bestimmen Sie, wann Sie ECS vs. AKS vs. EKS verwenden.)

Wie passt Container-Orchestrierung in die DevOps-Lieferpipeline?

Container-Orchestrierung verwaltet den gesamten Lebenszyklus von Containern innerhalb einer DevOps-Pipeline – und verwaltet Bereitstellung, Verfügbarkeit, Skalierung und Fehlerwiederherstellung automatisch. Ohne Orchestrierung würden containerisierte Pipelines manuelle Interventionen erfordern, um die Container zu verwalten, die CI/CD-Automatisierung liefert.

Container-Orchestrierung geht Hand in Hand mit containerisierten Anwendungen , da Containerisierung nur ein Teil der gesamten Container-Revolution ist. Kubernetes gehört zu den beliebtesten Orchestrierungsplattformen, bietet branchenweite Unterstützung und die Möglichkeit, praktisch jede Umgebung zu betreiben – von Einzelknoten-Clustern bis zu Multi-Cloud-Clustern.

Orchestrierungsplattformen beseitigen die Notwendigkeit manueller Containerverwaltung und gewährleisten gleichzeitig die Verfügbarkeit. Die Nutzung einer plattformunabhängigen Lösung wie Kubernetes verhindert Vendor-Lock-in und ermöglicht es Teams, verwaltete Lösungen zu nutzen und Multi-Cloud-Architekturen mit einer einzigen Plattform zu betreiben.

(Entdecken Sie unseren mehrteiligen Kubernetes-Leitfaden, einschließlich praktischer Tutorials.)

Sind Container geeignet für Ihre DevOps-Lieferpipeline?

Für die meisten Teams ja. Containerisierung kommt praktisch allen Anwendungsentwicklungsszenarien zugute, mit den Hauptausnahmen von zu einfachen Anwendungen oder alten, monolithischen Architekturen , die sich nicht gut für Containerisierung eignen.

Container helfen dabei, den DevOps-Lieferprozess zu vereinfachen, indem sie Teams ermöglichen, alle Vorteile der Containerisierung in ihren Lieferpipelines zu nutzen, ohne die Kernpraktiken von DevOps zu stören. Container unterstützen jede Umgebung unabhängig von Programmiersprache, Framework oder Bereitstellungsstrategie und bieten den Lieferteams mehr Flexibilität, ihre Umgebungen anzupassen, ohne den Lieferprozess selbst zu beeinträchtigen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Containerisierung und Virtualisierung in DevOps?

Virtualisierung erstellt virtuelle Maschinen, die jeweils ein vollständiges Betriebssystem enthalten, die nur die zugrunde liegende Hardware teilen. Containerisierung teilt sich den Kernel des Host-Betriebssystems, wodurch Container deutlich leichter, schneller zu starten und portabler werden. In DevOps-Lieferpipelines werden Container bevorzugt, da sie den Ressourcenaufwand reduzieren und sich sauberer mit CI/CD-Automatisierungstools integrieren.

Funktionieren Container mit CI/CD-Pipelines?

Ja. Container integrieren sich direkt mit CI/CD-Pipelines, indem sie die Bereitstellungsschritte der Umgebung durch einen einzigen Container-Build ersetzen. Sobald der Container mit seinem Anwendungscode und seinen Abhängigkeiten erstellt ist, wird dasselbe Container-Image durch Staging und Produktion ohne Neukonfiguration bereitgestellt – was CI/CD-Pipelines schneller und konsistenter macht.

Welche Container-Orchestrierungsplattformen werden am häufigsten in DevOps verwendet?

Kubernetes ist die am weitesten verbreitete Container-Orchestrierungsplattform im DevOps-Bereich und wird in öffentlichen Clouds und On-Premises-Umgebungen unterstützt. Managed Kubernetes-Dienste – wie Amazon EKS, Azure AKS und Google GKE – beseitigen den Infrastrukturmanagement-Overhead und erhalten gleichzeitig die Open-Source-Portabilität von Kubernetes. Weitere Orchestrierungsoptionen sind Amazon ECS und AWS Fargate für Teams, die hauptsächlich innerhalb von AWS arbeiten.

Was sind die Nachteile der Verwendung von Containern in DevOps?

Container eignen sich nicht gut für alte monolithische Anwendungen oder sehr einfache Workloads, bei denen die zusätzliche Komplexität der Containerisierung den Nutzen überwiegt. Container bringen auch eine Lernkurve in Bezug auf das Management der Orchestrationsplattform und die Sicherheit von Containern mit sich, einschließlich Bild-Schwachstellen-Scans und Zugriffskontrolle. Teams, die neu in Containern sind, sollten vor der Migration bestehender Pipelines auf diesen operativen Aufwand einplanen.

Wie funktionieren Microservices und Container in DevOps zusammen?

Microservices-Architekturen zerlegen Anwendungen in kleine, unabhängig deployable Services – eine Struktur, die natürlich auf Container abgebildet ist, wobei jeder Service als eigenständiger Container paketiert werden kann. Dies ermöglicht es DevOps-Teams, einzelne Services unabhängig zu bauen, zu testen, bereitzustellen und zu skalieren, ohne den Rest der Anwendung zu beeinträchtigen. Container-Orchestrationsplattformen wie Kubernetes werden häufig verwendet, um den Lebenszyklus aller Services in einer microservices-basierten Bereitstellung zu verwalten.

Verwandte Literatur

• BMC DevOps Blog
• Was ist eine Containerpipeline?
• Wie man MongoDB als Docker-Container ausführt
• Container vs. Microservices: Was ist der Unterschied?
• GitHub, GitLab, Bitbucket & Azure DevOps: Was ist der Unterschied?

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.