Die acht Praktiken für Containerized Delivery auf dem Microsoft-Stack - PRAXIS 1: Kleine, wiederverwendbare Image-Schichten

Dieser Beitrag wurde ursprünglich als Artikel im SDN Magazine am13. Oktober2017 veröffentlicht. Im vergangenen Jahr habe ich mehrere Kunden auf ihrem Weg zu Containerized Delivery auf dem Microsoft-Stack unterstützt. In dieser Blogserie möchte ich die acht Praktiken vorstellen, die ich beim Einsatz von Docker für die Containerized Delivery auf dem Microsoft-Stack gelernt habe, sowohl in einer Greenfield- als auch in einer Brownfield-Situation. Im ersten Blogpost dieser Serie möchte ich über die erste Praxis sprechen: Kleine und wiederverwendbare Image-Schichten.

PRAXIS 1: Kleine, wiederverwendbare Bildebenen

Sobald Sie mit der Containerisierung von.NET-Workloads beginnen, müssen Sie entscheiden, wie Sie Ihre Container-Images modularisieren wollen. Ein guter Ausgangspunkt ist, Ihre Architektur zu überprüfen und festzustellen, welche Teile Ihrer Anwendungslandschaft Sie selektiv skalieren oder unabhängig voneinander freigeben müssen. Jedes Container-Image, das Sie erstellen, sollte in sich geschlossen sein und muss für sich alleine laufen können. Es gibt noch einen weiteren wichtigen Aspekt, an den Sie denken müssen: die Schichtung von Container-Images. Wie Sie vielleicht wissen, sind Container-Images die Blaupause für Ihre Container. Images bestehen aus Image-Schichten. Jede Image-Schicht wird während des Docker-Erstellungsprozesses als Artefakt einer Reihe von Anweisungen (z.B. Erstellen eines Verzeichnisses, Aktivieren von Windows-Funktionen) erstellt, die in der Docker-Datei angegeben sind. Dieser Prozess ist in Abbildung 1 dargestellt.

Das Schöne an Docker ist, dass dieses Prinzip des Image-Layers wiederverwendet wird, um die Leistung und Geschwindigkeit von Docker zu optimieren. Sobald Docker feststellt, dass eine bestimmte Schicht bereits im Cache für Bildschichten auf Ihrem lokalen Rechner vorhanden ist, wird diese Schicht nicht erneut heruntergeladen, neu erstellt oder hinzugefügt. Wenn Sie beispielsweise zwei ASP.NET-Container-Images haben - eines für Website 1 und eines für Website 2 -, verwendet Docker die ASP.NET-, IIS- und OS-Schichten sowohl zur Laufzeit des Containers als auch im Cache des Container-Images wieder. Dies ist in Abbildung 2 dargestellt.

Wenn Sie Ihre Container-Image-Schichten auf intelligente Weise implementieren, werden Sie eine Steigerung der Leistung Ihrer containerisierten Arbeitslasten und der Geschwindigkeit ihrer Bereitstellung feststellen. Außerdem werden Sie feststellen, dass der Speicherbedarf für Ihre Container-Images sinkt. Die folgenden Praktiken beziehen sich auf Container-Image-Schichten:

• Abfolge der Ebenen: Versuchen Sie, die Überlagerung Ihrer Container-Bilder so anzuordnen und zu strukturieren, dass Sie die Ebenen so oft wie möglich wiederverwenden. Abbildung 3 zeigt, wie ich dies für einen meiner Kunden durch die Erstellung verschiedener Bilder erreicht habe.

• Kombinieren von Aktionen in einer einzigen Anweisung: Versuchen Sie, so oft wie möglich mehrere Aktionen (z.B. durch Aktivieren einer Windows-Funktion, Erstellen eines Dateisystemverzeichnisses usw.) in einer einzigen Docker-Anweisung zu kombinieren. Standardmäßig erstellt Docker aus jeder einzelnen Docker-Datei-Anweisung eine separate Container-Image-Ebene. Wenn Sie keine separate Bildebene für die spätere Verwendung benötigen, fassen Sie mehrere Aktionen in einer einzigen Anweisungszeile zusammen, um Overhead bei der Speicherung von Bildebenen zu vermeiden.

Zum Beispiel anstelle von: SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop';"] RUN Add-WindowsFeature NET-Framework-45-Core RUN Add-WindowsFeature NET-Framework-45-ASPNET beide Add-WindowsFeature-Aktionen in einer einzigen Anweisung kombinieren: SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop';"] RUN Add-WindowsFeature NET-Framework-45-Core,NET-Framework-45-ASPNET Ein weiteres Beispiel für die Ausführung mehrerer PowerShell-Befehle in einer Anweisung ist: RUN Invoke-WebRequest"https://aka.ms/InstallAzureCliWindows"-OutFile az.msi -UseBasicParsing; Start-Process msiexec.exe -ArgumentList '/i', 'C:az.msi', '/quiet', '/norestart' -NoNewWindow -Wait; Remove-Item az.msi; $env:PATH = $env:AZ_PATH + $env:PATH;

Interessiert an der nächsten Übung? Siehe PRAXIS 2 - Mehrstufige Bauten.

Mehr aus dieser Serie

• Übung 1 - Kleine wiederverwendbare Bildebenen
• Praxis 2 - Mehrstufige Builds
• Praxis 3 - Halten Sie Windows-Container auf dem neuesten Stand
• Praxis 4 - Gruppenverwaltete Servicekonten
• Praxis 5 - Sichere Lieferung in Containern
• Übung 6 - Der Umgang mit Geheimnissen
• Praxis 7 - Explizites Abhängigkeitsmanagement
• Praxis 8 - Umwelt als Code und Pipeline als individuelle Pipeline