Die acht Praktiken für Containerized Delivery auf dem Microsoft-Stack - PRAXIS 2: Mehrstufige Builds

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 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 zweiten Blogpost dieser Serie möchte ich über Folgendes sprechen Mehrstufige Builds.

PRAXIS 2: Mehrstufige Bauten

Neu seit Docker 17.05 ist das Konzept der mehrstufigen Builds. Wie in der vorangegangenen Übung beschrieben, können Container-Images aufgrund einer großen Anzahl von Image-Ebenen ziemlich groß sein. Mehrstufige Builds helfen Ihnen, die Größe Ihrer Images auf einfache Weise zu reduzieren. Anstelle eines Images, das alle dazwischen liegenden Image-Schichten enthält, ermöglicht es die Multi-Stage-Build-Implementierung, den resultierenden Image-Inhalt eines bestimmten Images in ein anderes, von Ihnen definiertes Image zu kopieren. Ein weiterer großer Vorteil des Multi-Stage-Builds ist, dass er Ihre Angriffsfläche minimiert, indem er alle dazwischen liegenden Schichten und Installationen entfernt. Und nicht zuletzt ermöglichen mehrstufige Builds die einfache Erstellung von Debug- und Test-Images aus Ihren Produktions-Images, indem der resultierende Inhalt Ihres Produktions-Images in ein Standard-Debug- und Test-Image eingefügt wird. Vor Docker 17.05 konnte dies auch durch die Verwendung des Docker-Builder-Patterns erreicht werden. Bei der neuen mehrstufigen Lösung können wir einfach eine zweite FROM-Anweisung zu unserer bestehenden Docker-Datei hinzufügen und dieses Image anweisen, den Inhalt der früheren Stufe in das Image dieser zweiten Stufe zu kopieren, indem wir das Argument -from innerhalb der COPY-Anweisung verwenden. Wie im folgenden Beispiel gezeigt, wird der Inhalt der ersten Image-Definition (genannt temp) in die zweite Image-Definition (genannt final) kopiert. Das Ergebnis ist, dass die Bildgröße des endgültigen Bildes 315 MB kleiner ist als die des ursprünglichen temp-Bildes! Wenn wir die Anzahl der Bildebenen betrachten, sehen wir eine Reduzierung um 15 von 20 Bildebenen! ## First Stage – Install WebDeploy, create disk structure, deploy MVCMusicStore website FROM microsoft/aspnet AS temp RUN mkdir c:install c:MvcMusicstore ADD WebDeploy_2_10_amd64_en-US.msi /install/WebDeploy_2_10_amd64_en-US.msi WORKDIR /install RUN msiexec.exe /i c:installWebDeploy_2_10_amd64_en-US.msi /qn WORKDIR /MvcMusicStore ADD fixAcls.ps1 /MvcMusicStore/fixAcls.ps1 ADD MvcMusicstore.zip /MvcMusicStore/MvcMusicStore.zip ADD MvcMusicStore.deploy.cmd /MvcMusicStore/MvcMusicStore.deploy.cmd ADD MvcMusicStore.SetParameters.xml /MvcMusicStore/MvcMusicStore.SetParameters.xml RUN powershell.exe -executionpolicy bypass .fixAcls.ps1 RUN MvcMusicStore.deploy.cmd, /Y ## Second Stage - Creates final image FROM microsoft/aspnet AS final COPY --from=temp c:/inetpub/wwwroot c:/inetpub/wwwroot EXPOSE 80

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