Warum sind Container wichtig?
In dieser Lektion folgen Sie dem Tailspin-Team, das einige dringend benötigte Verbesserungen an seinem DevOps-Prozess diskutiert. In diesem Szenario verwendet das Team Docker zum Containerisieren der Webanwendung. Das Team aktualisiert dann seine CI/CD-Pipeline, um dies zu unterstützen.
Harte Wochen liegen hinter dem Team
Die letzten Wochen waren eine herausfordernde Zeit bei Tailspin. Die Teams haben aus verschiedenen Gründen Schwierigkeiten, Termine einzuhalten, und im gesamten Unternehmen gibt es Bedenken hinsichtlich der Produktivität. Andy hat einige wichtige Projektbeteiligte aus dem Team der Space Game-Website zusammengerufen, um Feedback für eine bevorstehende Präsentation vor dem Management zu sammeln.
Andy: Danke fürs Vorbeischauen. Ich weiß, dass die letzten Wochen für alle hart waren, aber ich habe auch gute Nachrichten. Das Management hält morgen ein Informationsgespräch ab, um Vorschläge für Änderungen zur Verbesserung der Leistung zu hören. Ich wurde eingeladen, eine Fallstudie über unsere DevOps-Erfolge zu präsentieren, und sie sagten, sie seien auch offen für alle anderen Ideen, die wir haben könnten. Ich hatte gehofft, wir könnten dieses Treffen als Gelegenheit für ein Brainstorming nutzen. Wer fängt an?
Alle sehen Amita an. Sie war in letzter Zeit besonders frustriert.
Amita: Ich fange an. Wie Sie wissen, teste ich für mehrere Teams, und das kann eine Herausforderung sein, weil jedes Team seinen eigenen Technologie-Stack verwendet. Selbst wenn sie die gleichen zugrundeliegenden Plattformen verwenden wie etwa .NET oder Java, zielen sie oft auf unterschiedliche Versionen ab. Ich habe das Gefühl, dass ich manchmal einen halben Tag damit verbringe, Testumgebungen in einen Zustand zu versetzen, in dem sie den Code ausführen können, den ich testen muss. Wenn etwas nicht funktioniert, ist es schwer zu sagen, ob es ein Fehler im Code ist oder ob ich versehentlich Version 4.2.3 statt 4.3.2 konfiguriert habe.
Andy schreibt „Herausforderungen bei der Versionsverwaltung für QA“ auf das Whiteboard.
Tim: Ich möchte dieser Frustration Betriebsvorgänge hinzufügen. Wir haben ein paar Teams mit einzigartigen Versionsanforderungen, sodass wir ihre Apps auf eigenen virtuellen Computern veröffentlichen müssen, um sicherzustellen, dass ihre Versions- und Komponentenanforderungen nicht mit unseren anderen Apps in Konflikt geraten. Neben dem Mehraufwand, der durch die Verwaltung der zusätzlichen VMs entsteht, kostet es uns auch mehr, als wenn diese Anwendungen parallel ausgeführt werden könnten.
Andy schreibt „Mehraufwand durch Lösen der App-Isolierung mit VMs“ auf das Whiteboard.
Mara: Ich habe etwas von der Entwicklungsseite beizutragen. Vor einigen Wochen habe ich am Peer-to-Peer-Aktualisierungssystem gearbeitet, und auf meinem Computer hat alles funktioniert. Aber als ich die Lösung zur Bereitstellung übergeben habe, hat sie in der Produktion nicht funktioniert. Ich hatte vergessen, dass ich Port 315 als Teil des Diensts öffnen muss. Die Problembehandlung hat mehr als einen Tag gedauert, bis wir erkannt haben, was los ist. Nachdem wir den Port in der Produktion geöffnet haben, hat alles wie erwartet funktioniert.
Andy schreibt „Konfigurationsinkonsistenzen zwischen den Bereitstellungsstufen“ auf das Whiteboard.
Andy: Ich denke, dieses Gespräch ist ein guter Anfang. Lasst mich diese Themen recherchieren und sehen, was ich herausfinden kann. Dies sind die Probleme, die ich gehört habe:
- Herausforderungen bei der Versionsverwaltung für QA
- Mehraufwand durch Lösen der Anwendungsisolierung mit VMs
- Konfigurationsinkonsistenzen zwischen den Bereitstellungsstufen
Zusammenführung (in einem Container)
Am nächsten Morgen beruft Andy eine Besprechung ein, um dem Team eine neue Idee vorzustellen.
Andy: Ich habe gestern mit einigen Kollegen über die Herausforderungen gesprochen, vor denen wir stehen, und sie haben einige interessante Vorschläge gemacht. Der Vorschlag, den ich unbedingt ausprobieren möchte, ist Docker. Dabei handelt es sich um eine Technologie zum Verpacken ganzer Anwendungen als Container.
Amita: Was ist ein Container? So etwas wie eine ZIP-Datei?
Andy: Nicht ganz. Es handelt sich eher um einen schlanken virtuellen Computer, der direkt unter dem Hostbetriebssystem ausgeführt wird. Wenn das Projekt erstellt wird, ist die Ausgabe ein Container, der die Software zusammen mit ihren Abhängigkeiten enthält. Es handelt sich jedoch nicht um ein vollständig virtualisiertes System, so dass es in weniger als einer Sekunde gestartet werden kann.
Tim: Wie verhält es sich mit Sicherheit und Isolierung?
Andy: Sicherheit und Isolierung werden durch das Hostbetriebssystem geregelt. Wenn der Container in einem Hostprozess ausgeführt wird, ist der Container von den anderen Prozessen auf demselben Hostcomputer isoliert. Diese Isolation ermöglicht es Ihrem Container, beliebige Versionen von Komponenten zu laden, die benötigt werden, unabhängig von den anderen Containern. Das bedeutet auch, dass problemlos mehrere Container gleichzeitig auf demselben Host ausgeführt werden können.
Amita: Das klingt super für die Produktionsumgebung, aber löst es auch die Herausforderungen, die wir früher in der Pipeline haben?
Andy: Auf jeden Fall! Anstatt Quellcode oder eine Sammlung von Binärdateien auszuliefern, wird der gesamte Container zum Artefakt. Das heißt, wenn Mara entwickelt, werden ihre Debugsitzungen lokal anhand des auf ihrem Computer gehosteten Containers ausgeführt. Wenn Amita testet, testet sie mit einer Kopie desselben Containers, der bereits alle erforderlichen Versionen seiner Abhängigkeiten enthält. Wenn Tim unsere Produktionsumgebung verwaltet, sind die Container, die er überwacht, eigenständige Kopien der gleichen Container, die von Mara entwickelt und von Amita getestet wurden.
Mara: Wie schwierig ist es, eine Containeranwendung zu entwickeln? Müssen wir erhebliche Änderungen an unserem vorhandenen Code vornehmen?
Andy: Container sind eher eine Verpackungs- und Bereitstellungstechnologie. Sie wirken sich nicht auf die grundlegende Software aus, die wir schreiben. Wir können unsere Tools einfach anweisen, am Ende des Builds einen Docker-Container zu erstellen. Beim Debuggen wird die Anwendung dann nicht mehr auf unserem lokalen Webserver, sondern aus dem lokalen Container ausgeführt. Tatsächlich kannst Du mit Tools wie Visual Studio sogar zwischen Debugumgebungen wie Docker und IIS Express wechseln, um die erforderliche Flexibilität zu erreichen. Ich habe gestern Abend unser Websiteprojekt geforkt und es so konvertiert, dass es als Docker-Container erstellt wird, um den Prozess zu testen. Ich musste nur einige grundlegende Containerkonfigurationen hinzufügen. Ich musste nichts an unserem vorhandenen Code ändern.
Mara: Das ist gut zu wissen. Ich wette, wir können sogar die Releasepipeline in Azure Pipelines aus Deinem Fork aktualisieren, sodass die Docker-Version erstellt und bereitgestellt wird.
Andy: Du kannst meine Gedanken lesen.
Was ist Docker?
Docker ist eine Technologie zur Automatisierung der Verpackung und Bereitstellung von portierbaren, autarken Containern. Docker-Container können überall dort ausgeführt werden, wo ein Docker-Host vorhanden ist, egal ob auf einem Entwicklungscomputer, auf einem Abteilungsserver, in einem Unternehmensrechenzentrum oder in der Cloud. Azure bietet mehrere Möglichkeiten, containerbasierte Anwendungen auszuführen, einschließlich App Service oder als Teil von Clustern, die mit Orchestrierungstechnologien wie Kubernetes verwaltet werden.
Das Tailspin-Team hat Docker-Container für dieses Szenario ausgewählt, da diese Lösung alle Anforderungen erfüllt:
Herausforderungen bei der Versionsverwaltung für QA: Anwendungen werden als Container verpackt, welche die richtigen Versionen ihrer Abhängigkeiten ebenfalls einbinden.
Mehraufwand durch Lösen der Anwendungsisolierung mit VMs: Viele isolierte Container können auf demselben Host ausgeführt werden, mit Vorteilen gegenüber virtuellen Computern, einschließlich schnellerer Startzeiten und größerer Ressourceneffizienz.
Konfigurationsinkonsistenzen zwischen DevOps-Stufen: Container werden mit Manifesten ausgeliefert, welche die Konfigurationsanforderungen automatisieren, z. B. welche Ports verfügbar gemacht werden müssen.
Die Einführung von Docker-Containern kann ein wichtiger Schritt in Richtung einer Microservicesarchitektur sein. Wir werden später mehr darüber erfahren.