Containerisierung von .NET Core Microservices – Tipps & Tricks<\/p>\n
<\/h1><\/div>
Es gibt bereits viele Artikel, in denen Sie Einzelheiten zur Containerisierung von .NET Core-Anwendung finden k\u00f6nnen. Trotzdem bin ich der Meinung, dass ein detaillierter Post helfen kann Best Practices f\u00fcr ein produktionsreifes Container-Image auf der Grundlage von Container- und .NET Core-Best Practices zu vermitteln.<\/p>\n
Zum besseren Verst\u00e4ndnis werde ich alles im Detail anhand einer kleinen ASP .NET-Core Beispiel-Webanwendung erkl\u00e4ren. Mehr Details zur Anwendung selbst finden Sie hier<\/a>. Nat\u00fcrlich sind die unten genannten Praktiken nicht auf .NET Core beschr\u00e4nkt. Sie k\u00f6nnen diese auf Ihre weiteren Projekte und Anwendungsf\u00e4lle ausweiten.<\/p>\n Es gibt unz\u00e4hlige Anwendungsf\u00e4lle, weshalb es auch keine “one fits all”-L\u00f6sung gibt. Ich m\u00f6chte Ihnen zwei verschiedene Optionen vorstellen, welche ich pers\u00f6nlich am h\u00e4ufigsten verwende. Aber lassen Sie uns erst mit einigen Grundlagen beginnen.<\/p>\n <\/p>\n\n\n Dies ist ein g\u00e4ngiges Beispiel f\u00fcr ein Dockerfile, das mir recht h\u00e4ufig begegnet: <\/p>\n\n\n\n An diesem Beispiel ist nichts falsch. Es wird funktionieren, aber es ist keineswegs optimiert. Weder f\u00fcr Performance noch f\u00fcr sicherheitsrelevante Aspekte und ist daher nicht optimal f\u00fcr eine Produktionsumgebung. Hier einige Beispiele:<\/p>\n\n\n\n Schauen wir uns ein weiteres Dockerfile-Beispiel etwas genauer an:<\/p>\n\n\n\n In diesem Beispiel wird ein containerisierter Build verwendet. Dies bedeutet, dass der Anwendungs-Build selbst in den Docker-Build-Prozess verlagert wird. Dies ist ein gutes Pattern, das es Ihnen erlaubt, in einer unver\u00e4nderlichen und isolierten Umgebung die Anwendung zu bauen. Ein Nachteil ist jedoch, dass Sie Ihr Image auf der Grundlage eines gr\u00f6\u00dferen SDK-Images erstellen m\u00fcssen. Das SDK-Image stellt die f\u00fcr die Erstellung der Anwendung erforderlichen Abh\u00e4ngigkeiten bereit, w\u00e4re aber f\u00fcr die anschlie\u00dfende Ausf\u00fchrung nicht erforderlich. Es existiert jedoch eine Pattern, das dieses Problem l\u00f6st. Multi-stage Builds.<\/p>\n\n\n\n .<\/span><\/p>\n\n\n\n Wenn Sie eine \u00e4hnliche Version der oben genannten Dockerfiles verwenden, haben Sie vielleicht noch nicht von Multi-stage Container-Builds geh\u00f6rt. Mehrstufige Builds erm\u00f6glichen es uns, unseren Image-Build-Prozess in mehrere Schritte aufzuteilen.<\/p>\n\n\n\n Die erste Stufe dient der Erstellung unserer Anwendung, f\u00fcr die wir die erforderlichen Abh\u00e4ngigkeiten bereitstellen m\u00fcssen. In der zweiten Stufe kopieren wir die Anwendungsartefakte in eine kleinere Laufzeitumgebung, die dann als unser endg\u00fcltiges Container Image verwendet wird. Ein entsprechendes Dockerfile sieht wie folgt aus:<\/p>\n\n\n\n Schauen wir uns die einzelnen Schritte n\u00e4her an:<\/p>\n\n\n\n Unser erster Schritt basiert auf dem SDK-Image, das alle Abh\u00e4ngigkeiten f\u00fcr die Erstellung unserer Anwendung bereitstellt.<\/p>\n\n\n\n Im zweiten Scrhitt definieren wir ein neues Basis-Image, das diesmal nur unsere Laufzeitabh\u00e4ngigkeiten enth\u00e4lt. Dann kopieren wir die Anwendungsartefakte aus dem ersten Image in das zweite Image.<\/p>\n\n\n\n Damit sind wir nun in der Lage, ein kleineres und sichereres Container-Image zu erstellen, da es nur die zur Ausf\u00fchrung der Anwendung erforderlichen Abh\u00e4ngigkeiten enth\u00e4lt. Es gibt aber weiterhin noch Raum f\u00fcr Verbesserungen.<\/p>\n\n\n\n Wenn Sie mehr \u00fcber die Best Practices von Dockerfile erfahren m\u00f6chten, empfehle ich Ihnen einen Blick auf diese Seite<\/a> oder die offizielle Docker Dokumentation.<\/p>\n\n\n\n .<\/span><\/p>\n\n\n\n Wie bereits erw\u00e4hnt, gibt es nicht eine L\u00f6sung f\u00fcr alles. Sie variiert von Anwendungsfall zu Anwendungsfall. Mit den nachfolgenden Beispielen erhalten Sie zwei Beispiele sowie deren Vor- und Nachteile. Diese k\u00f6nnen Sie nat\u00fcrlich nach Ihren Bed\u00fcrfnissen anpassen.<\/p>\n\n\n\n Das untenstehende Dockerfile ist eine optimierte Version des obigen Multi-Stage Beispiels und d\u00fcrfte f\u00fcr die meisten Szenarien gut geeignet sein.<\/p>\n\n\n\n Auch hier schauen wir uns die einzelnen Schritte genauer an:<\/p>\n\n\n\n Wir definieren zun\u00e4chst unser Basis Image mit Hilfe einer ARG-Anweisung. Dies hilft uns, den Tag leicht zu aktualisieren, anstatt jedesmal mehrere Zeilen zu \u00e4ndern. Wie Sie vielleicht bemerkt haben, verwenden wir ein anderes Tag. Das tag3.1-alpine3.10<\/em> besagt, dass dieses Image die ASP .NET-Version 3.1 enth\u00e4lt und auf Alpine 3.10 basiert.<\/p>\n\n\n\n Alpine Linux ist eine Linux-Distribution, die speziell f\u00fcr Anwendungsszenarien im Hinblick auf Sicherheit, Einfachheit und Ressourceneffizienz entwickelt wurde. In diesem Schritt kann Alpine Linux uns bereits dabei helfen, den Speicherbedarf unserer Build-Phase zu reduzieren.<\/p>\n\n\n\n Da wir Multi-Stage Builds verwenden, m\u00fcssen wir auch das Image definieren, das in unserem zweiten Schritt verwendet wird. Hier werden wir die Alpine basierte ASP .NET-Laufzeitumgebung als unser Basis-Image verwenden. Wie bereits gesagt, erm\u00f6glicht uns Alpine kleinere und sicherere Container-Images zu erstellen.<\/p>\n\n\n\n Anders als im oberen Beispiel teilen wir diesmal den Build-Prozess in mehrere Teile auf. Der Befehl Um die Laufzeit unserer Anwendung zu sch\u00fctzen, m\u00fcssen wir sie ohne Root-Rechte ausf\u00fchren. Aus diesem Grund legen wir einen neuen Benutzer an und \u00e4ndern den Benutzerkontext unter Verwendung der USER-Definition.<\/p>\n\n\n\n Da wir unsere Anwendung ohne jegliche Root-Privilegien ausf\u00fchren, m\u00fcssen wir diese auch auf einem Port h\u00f6her 1024 bereitstellen. In unserem Beispiel wurde 8080 gew\u00e4hlt. Mit der ENV-Definition k\u00f6nnen wir der Anwendung weitere Umgebungsvariablen mitgeben. DOTNET_RUNNING_IN_CONTAINER=true<\/em> ist eine informelle Umgebungsvariable, um einen Entwickler\/Anwendung wissen zu lassen, dass der Prozess innerhalb eines Containers l\u00e4uft. ASPNETCORE_URLS=http:\/\/+:8080<\/em> wird genutzt um den konfigurierten Port mit dem Port 8080 zu \u00fcberschreiben.<\/p>\n\n\n\n .<\/span><\/p>\n\n\n\n Wie bereits erw\u00e4hnt, d\u00fcrfte das obere Beispiel f\u00fcr die meisten der Szenarien geeignet sein. Das folgende Beispiel beschreibt eine M\u00f6glichkeit, ein m\u00f6glichst kleines Container-Image zu erstellen. Ein m\u00f6glicher Anwendungsfall k\u00f6nnte ein IoT Edge Szenario<\/a>, oder Umgebungen die eine optimierte Startzeit ben\u00f6tigen, sein. Allerdings gibt es auch einige Nachteile, auf die ich im Nachhinein noch n\u00e4her eingehen werde.<\/p>\n\n\n\n Noch einmal schauen wir uns die einzelnen Schritte genauer an:<\/p>\n\n\n\n Der gro\u00dfe Unterschied zum oberen Beispiel besteht darin, dass wir eine in sich geschlossene Anwendung bauen werden. Die Angabe des Parameters Da das fertige Image f\u00fcr die Gr\u00f6\u00dfe optimiert sein soll, definieren wir das Flag Ein zweiter Nachteil ist, dass Code-\u00c4nderungen zu einer gr\u00f6\u00dferen \u00c4nderung f\u00fchren. Dies liegt daran, dass der Code und die Laufzeit in einem einzigen Image-Layer zusammengefasst sind. Jedes Mal, wenn sich der Code \u00e4ndert, muss der gesamte Image-Layer neu erzeugt und auch neu auf die Systeme heruntergeladen werden.<\/p>\n\n\n\n Da das Anwendungsartefakt in sich geschlossen ist, brauchen wir keine Laufzeitumgebung mit dem Bild bereitzustellen. In diesem Beispiel habe ich das Runtime-deps-Image gew\u00e4hlt, das auf Alpine Linux basiert. Dieses Image ist auf die minimalen Abh\u00e4ngigkeiten reduziert, die zur Ausf\u00fchrung des Anwendungsartefakts erforderlich sind.<\/p>\n\n\n\n Eine weitere Optimierung der Image-Gr\u00f6\u00dfe ist die Verwendung des “globalization invariant” Modus. Dieser Modus ist n\u00fctzlich f\u00fcr Anwendungen, die nicht global bekannt sind und die Formatierungskonventionen, String-Vergleich und -Sortierreihenfolge der “invariant culture” verwenden k\u00f6nnen. Dieser Modus kann durch die Umgebungsvariable DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1<\/em> aktiviert werden. Wenn Ihre Anwendung eine Globalisierung erfordert, m\u00fcssen Sie die ICU library<\/a> installieren und die Umgebungsvariable entfernen. Dadurch wird die Gr\u00f6\u00dfe Ihres Container-Image um etwa 28 MB zunehmen. Weitere Einzelheiten \u00fcber den “globalization invariant” Modus finden Sie hier<\/a>.<\/p>\n\n\n\n F\u00fcr die in sich geschlossene Anwendungen m\u00fcssen wir die ENTRYPOINT-Definition \u00e4ndern, um das Artifakt selbst auszuf\u00fchren.<\/p>\n\n\n\n Die Gr\u00f6\u00dfe dieses Images wird etwa 73 MB betragen (einschlie\u00dflich der Beispielapplikation). Dies ist recht klein. Hier der Vergleich zu anderen Images:<\/p>\n\n\n\nDas g\u00e4ngige Beispiel<\/h2>\n\n\n\n
FROM mcr.microsoft.com\/dotnet\/core\/aspnet:3.1\nWORKDIR \/app\nCOPY \/app\/output .\nEXPOSE 8080\nENTRYPOINT [\"dotnet\", \"sample-mvc.dll\"]<\/code><\/pre>\n\n\n\nFROM mcr.microsoft.com\/dotnet\/core\/sdk:3.1\nWORKDIR \/app\nADD \/src .\nRUN dotnet publish \\\n -c Release \\\n -o .\/output\nEXPOSE 8080\nENTRYPOINT [\"dotnet\", \"sample-mvc.dll\"]<\/code><\/pre>\n\n\n\nMulti-stage Builds<\/h2>\n\n\n\n
FROM mcr.microsoft.com\/dotnet\/core\/sdk:3.1 AS build-env\nWORKDIR \/app\nADD \/src .\nRUN dotnet publish \\\n -c Release \\\n -o .\/output\nFROM mcr.microsoft.com\/dotnet\/core\/aspnet:3.1\nWORKDIR \/app\nCOPY --from=build-env \/app\/output .\nEXPOSE 8080\nENTRYPOINT [\"dotnet\", \"sample-mvc.dll\"]<\/code><\/pre>\n\n\n\nFROM mcr.microsoft.com\/dotnet\/core\/sdk:3.1 AS build-env\n...\nRUN dotnet publish \\\n -c Release \\\n -o .\/output\n...<\/code><\/pre>\n\n\n\n...\nFROM mcr.microsoft.com\/dotnet\/core\/aspnet:3.1\n...\nCOPY --from=build-env \/app\/output .\n...<\/code><\/pre>\n\n\n\nSie haben die Wahl<\/h2>\n\n\n\n
Die Grundlage<\/h3>\n\n\n\n
ARG VERSION=3.1-alpine3.10\nFROM mcr.microsoft.com\/dotnet\/core\/sdk:$VERSION AS build-env\nWORKDIR \/app\nADD \/src\/*.csproj .\nRUN dotnet restore\nADD \/src .\nRUN dotnet publish \\\n -c Release \\\n -o .\/output\nFROM mcr.microsoft.com\/dotnet\/core\/aspnet:$VERSION\nRUN adduser \\\n --disabled-password \\\n --home \/app \\\n --gecos '' app \\\n && chown -R app \/app\nUSER app\nWORKDIR \/app\nCOPY --from=build-env \/app\/output .\nENV DOTNET_RUNNING_IN_CONTAINER=true \\\n ASPNETCORE_URLS=http:\/\/+:8080\nEXPOSE 8080\nENTRYPOINT [\"dotnet\", \"sample-mvc.dll\"]<\/code><\/pre>\n\n\n\nARG VERSION=3.1-alpine3.10\nFROM mcr.microsoft.com\/dotnet\/core\/sdk:$VERSION AS build-env\n...<\/code><\/pre>\n\n\n\n...\nFROM mcr.microsoft.com\/dotnet\/core\/aspnet:$VERSION\n...<\/code><\/pre>\n\n\n\nADD \/src\/*.csproj .\nRUN dotnet restore\nADD \/src .\nRUN dotnet publish \\\n -c Release \\\n -o .\/output<\/code><\/pre>\n\n\n\ndotnet restore<\/code> verwendet NuGet zur Wiederherstellung von Abh\u00e4ngigkeiten sowie von projektspezifischen Tools, die in der Projektdatei angegeben sind. Das Wiederherstellen von Abh\u00e4ngigkeiten ist ebenfalls Teil des Befehls dotnet publish<\/code>, die Trennung erlaubt uns jedoch die Abh\u00e4ngigkeiten in einer separaten Image-Layer zu speichern. Dies verk\u00fcrzt die Zeit, die f\u00fcr den Aufbau des Images ben\u00f6tigt wird, und reduziert die Gr\u00f6\u00dfe des Downloads, da die Abh\u00e4ngigkeiten der Image-Layer nur dann neu aufgebaut werden, wenn die Abh\u00e4ngigkeiten ge\u00e4ndert werden.<\/p>\n\n\n\n...\nRUN adduser \\\n --disabled-password \\\n --home \/app \\\n --gecos '' app \\\n && chown -R app \/app\nUSER app\n...<\/code><\/pre>\n\n\n\n...\nENV DOTNET_RUNNING_IN_CONTAINER=true \\\n ASPNETCORE_URLS=http:\/\/+:8080\nEXPOSE 8080\n...<\/code><\/pre>\n\n\n\nKleiner, kleiner, kleiner<\/h2>\n\n\n\n
ARG VERSION=3.1-alpine3.10\nFROM mcr.microsoft.com\/dotnet\/core\/sdk:$VERSION AS build-env\nWORKDIR \/app\nADD \/src .\nRUN dotnet publish \\\n --runtime alpine-x64 \\\n --self-contained true \\\n \/p:PublishTrimmed=true \\\n \/p:PublishSingleFile=true \\\n -c Release \\\n -o .\/output\nFROM mcr.microsoft.com\/dotnet\/core\/runtime-deps:$VERSION\nRUN adduser \\\n --disabled-password \\\n --home \/app \\\n --gecos '' app \\\n && chown -R app \/app\nUSER app\nWORKDIR \/app\nCOPY --from=build-env \/app\/output .\nENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 \\\n DOTNET_RUNNING_IN_CONTAINER=true \\\n ASPNETCORE_URLS=http:\/\/+:8080\nEXPOSE 8080\nENTRYPOINT [\".\/sample-mvc\", \"--urls\", \"http:\/\/0.0.0.0:8080\"]<\/code><\/pre>\n\n\n\n...\nRUN dotnet publish \\\n --runtime alpine-x64 \\\n --self-contained true \\\n \/p:PublishTrimmed=true \\\n \/p:PublishSingleFile=true \\\n -c Release \\\n -o .\/output\n...<\/code><\/pre>\n\n\n\n--self-contained true<\/code> zwingt den Build dazu, alle Abh\u00e4ngigkeiten in das Anwendungsartefakt einzubeziehen. Das schlie\u00dft die .NET Core-Laufzeitumgebung ein. Aus diesem Grund m\u00fcssen wir auch die Laufzeitumgebung definieren, in der wir die Anwendung ausf\u00fchren m\u00f6chten. Dies geschieht mit dem Parameter --runtime alpine-x64<\/code>.<\/p>\n\n\n\n\/p:PubishTrimmed=true<\/code>, das den Build-Prozess anweist, keine unbenutzten Bibliotheken einzubinden. Das Flag \/p:PublishSingleFile=true<\/code> erlaubt es uns, den Build-Prozess selbst zu beschleunigen. Ein Nachteil ist, dass Sie dynamisch geladene Assemblys im Voraus definieren m\u00fcssen, um sicherzustellen, dass ben\u00f6tigte Bibliotheken im Image vorhanden sind. Weitere Informationen dazu finden Sie hier<\/a>.<\/p>\n\n\n\n...\nFROM mcr.microsoft.com\/dotnet\/core\/runtime-deps:$VERSION\n...<\/code><\/pre>\n\n\n\n...\nENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 \\\n DOTNET_RUNNING_IN_CONTAINER=true \\\n ASPNETCORE_URLS=http:\/\/+:8080\n...<\/code><\/pre>\n\n\n\n...\nENTRYPOINT [\".\/sample-mvc\", \"--urls\", \"http:\/\/0.0.0.0:8080\"]<\/code><\/pre>\n\n\n\n