Docker für ASP.NET Core Anwendungen - Best Practices von der Entwicklung bis zur Produktion - DWX 2026

Talk auf der DWX 2026

Abstract:
Entdecken Sie das volle Spektrum von Docker für Ihre ASP.NET Core-Anwendungen! Diese Session bietet einen umfassenden Leitfaden zur Nutzung von Docker-Containern während des gesamten Anwendungslebenszyklus, von der Entwicklung bis zur Produktion. Entdecken Sie, wie Sie Ihre Entwicklungs- und Testprozesse optimieren, Ihre Container absichern und effizient in Produktionsumgebungen einsetzen können. Wir behandeln wichtige Tools, erweiterte Sicherheitspraktiken und Optimierungstechniken, damit Sie das volle Potential von einer containerbasierten Anwendung voll ausschöpfen können.

Transcript

1. DOCKER FÜR ASP.NET CORE ANWENDUNGEN Best Practices von der Entwicklung bis zur Produktion
2. ABOUT ME Daniel Lindemann Begeisterter .NET-Entwickler und Berater mit einer seltsamen Vorliebe für die Optimierung, Automatisierung und Containerisierung von Anwendungen. Was ich so mache: ▪ Microsoft Azure ▪ Cloud-native & Container Technologien ▪ Developer Technologies ▪ Generative AI ▪ DevOps - Dev in der Nacht, Ops am Tag E-Mail: d.lindemann@abtis.de Web: https://www.dlindemann.de LinkedIn: https://linkedin.com/in/daniel-lindemann
3. AGENDA ▪ .NET-Apps für Container vorbereiten ▪ Container Images erstellen ▪ Container Security & Compliance ▪ Multi-architecture Images
4. .NET-Apps für Container vorbereiten
5. APPLIKATION OPTIMIEREN Know the source Erstellen von guten Container-Anwendungen startet mit dem optimieren der Applikation
6. APPLIKATION OPTIMIEREN 12 factor app - Configuration Konfigurationen können je nach Umgebung variieren
7. https://12factor.net
8. .NET APPLIKATIONEN KONFIGURIEREN 12 Factor App - Konfiguration ▪ App-Konfigurationen variieren je nach Umgebung (Development, Staging, Production) ▪ Connections zu Datenbanken ▪ Connections zu Backing Services ▪ Credentials für den Zugriff auf externe Dienste ▪ Keine hard-coded Konfigurationen ▪ Ermöglicht die Trennung von Code und Konfiguration ▪ Verhindern, dass sensible Informationen in das Versionskontrollsystem übertragen werden ▪ Umgebungsvariablen zur Konfiguration der Anwendung benutzen ▪ Erlauben das Überschreiben von Default-Konfigurationen ▪ Programmiersprachen- und Betriebssystem-agnostisch ▪ Es ist in Ordnung eine große Anzahl von Konfigurationsparametern zu haben
9. .NET APPLIKATIONEN KONFIGURIEREN 12 Factor App - Konfiguration in ASP.NET ▪ Anwendung über appsettings.json konfigurieren ▪ Basis-Konfiguration der Anwendung ▪ Konfigurationswerte können einfach über OptionsBuilder und IOptions validiert und abgerufen werden ▪ Ermöglicht umgebungsspezifische Konfigurationen ▪ Während der Entwicklung User Secrets zum Speichern sensibler Informationen verwenden ▪ Speichert Informationen nur auf dem lokalen Rechner ▪ Keine Änderungen an appsettings.json erforderlich ▪ HostBuilder liest Umgebungsvariablen ▪ App-Einstellungen über Umgebungsvariablen überschreiben ▪ WebApplication.CreateBuilder() lädt Konfigurationen aus verschiedenen Ressourcen (HostApplicationBuilder Constructor (Microsoft.Extensions.Hosting) | Microsoft Learn)
10. APPLIKATION OPTIMIEREN 12 Factor App - Port Binding Die App ist self-contained und an einen Port gebunden
11. .NET APPLIKATIONEN KONFIGURIEREN 12 Factor App - Port Binding ▪ Die App ist komplett self-contained → Ziel Container ▪ Die Anwendung bindet an einen Port und kann Anfragen empfangen ▪ Port-Binding kann konfiguriert werden Beispiel: ▪ Während der Entwicklung auf lokalem System erfolgt der Zugriff über http://localhost:1234 ▪ In Production-Umgebung könnte das Hosting der Anwendung neu konfiguriert werden ▪ Vielleicht wird Port 1234 bereits verwendet ▪ Vielleicht läuft die App hinter einem Load Balancer oder Reverse Proxy
12. .NET APPLIKATIONEN KONFIGURIEREN 12 factor app - Port Binding ASP.NET ▪ ASP.NET nutzt Kestrel als Webserver ▪ Kestrel ist Teil von .NET ▪ Kestrel kann über die Kestrel-Options konfiguriert werden ▪ Einstellungen können über appsettings.json gesetzt werden ▪ Konfiguration via Code auch möglich ▪ Configure options for the ASP.NET Core Kestrel web server | Microsoft Learn ▪ Externe Konfiguration von Kestrel durch Umgebungsvariablen ▪ Festlegen der URL Bindings über ASPNETCORE_URLS ▪ SSL/TLS Zertifikate über Kestrel__Certificates__Default__Path und Kestrel__Certificates__Default__Password binden
13. APPLICATION OPTIMIZATION 12 Factor App - Logging Die Applikation generiert Logs als kontinuierlichen, zeitlich geordneten Stream und versucht nicht, diese zu verwalten oder weiterzuleiten
14. .NET APPLIKATIONEN KONFIGURIEREN 12 Factor App - Logs ▪ ASP.NET erlaubt die Konfiguration der Logging-Einstellungen ▪ .NET enthält vorkonfigurierte Logging-Bibliotheken (.NET Standard Logging) ▪ Konfiguration über Logging-Eigenschaft in appsettings.json ▪ Log-Einstellungen können über Umgebungsvariablen konfiguriert werden ▪ Logging Best Practices für Container ▪ Immer in die Konsole loggen (STDOUT) ▪ JSON-Format für Production-Umgebungen benutzen ▪ Alternativen zu .NET-Logging sind bspw. Serilog und log4net
15. CONTAINER IMAGES ERSTELLEN
16. CONTAINER Unterschied VM und Container Virtualisierung Containerisierung Typ 1 Hardware Hypervisor 1 VM VM VM Hardware Typ 2 Host OS Hypervisor 2 VM VM VM VM Gast OS Abhängigkeiten Applikation XYZ Hardware Host OS Docker Engine Abhängigkeit 1 Abhängigkeit 2 C C C C C Container App-Abhängigkeiten Applikation XYZ
17. VORAUSSETZUNG Docker & Entwicklungsumgebung ▪ Docker ist das defacto Standardtool für Container Development ▪ Installation ▪ Docker Desktop und Docker CLI einfach zu installieren ▪ Unterstützte System: Windows, MacOS, Linux ▪ Windows Abhängigkeit: WSL ▪ Andere Container Tools möglich ▪ Rancher Desktop ▪ Orbstack (MacOS) ▪ Podman
18. VORAUSSETZUNG Docker Support zu Projekt hinzufügen Visual Studio Code Visual Studio
19. DOCKERFILE ASP.NET Default Image
20. CONTAINER Build
21. IMAGE SIZE ASP.NET Default Image The default image is based on Ubuntu 24.04 LTS (Noble Numbat)
22. CONTAINER Run
23. OPTIMIEREN DES IMAGES Warum sollten Images klein sein? ▪ Performance und Effizienz ▪ Kleine Images können schneller bewegt werden (pull/push) ▪ Verbesserte Geschwindigkeit bei Build und Deployment ▪ Sicherheit ▪ Kleinere Images haben weniger Bibliotheken und Tools ▪ Verringerung der Angriffsfläche ▪ Wartbarkeit ▪ Installation von Abhängigkeiten in kleine Images erhöht die Kontrolle über die Abhängigkeiten ▪ Änderungen von Abhängigkeiten wird vereinfacht
24. OPTIMIEREN DES IMAGES Image-Größe verkleinern – Alpine Basis Image benutzen ▪ Alpine ist eine sehr kleine Distribution ▪ Tools und Bibliotheken könnten nicht vorhanden sein ▪ Eine einfache Änderung in der Dockerfile FROM mcr.microsoft.com/dotnet/aspnet:10.0-alpine AS base
25. OPTIMIEREN DES IMAGES Image-Größe verkleinern – Distroless Container Images ▪ Distroless Images = Minimalistische Container-Images ohne klassische Betriebssystem-Komponenten ▪ Features ▪ Minimal set of packages required for .NET applications ▪ Non-root user by default ▪ No package manager ▪ No shell ▪ .NET Distroless Images ▪ Chiseled Ubuntu ▪ Azure Linux 3.0 ▪ Eine einfache Änderung in der Dockerfile FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled AS base
26. OPTIMIEREN DES IMAGES Image-Größe verkleinern – Self-containing .NET Applikation ▪ Trimmen von Applikationsabhängigkeiten auf eine Teilmenge des Frameworks ▪ Ermöglicht die Applikation als „Single-File“ bereitzustellen ▪ Best effort: Alpine oder Distroless Basis-Image ▪ Komplexe Änderungen in Dockerfile
27. BEST PRACTICES Linting ▪ Linter für fertige Container-Image ▪ Fokus auf Security-Misconfigs ▪ Linter für Dockerfiles ▪ Fokussiert auf Best Practices und Fehler im Dockerfile selbst Hadolint ▪ Images gegen well-etablierter Best Practices analysieren ▪ Vermeidet die Verwendung von Anti Pattern ▪ Security Best Practices durchsetzen
28. BASE IMAGES Know the source Verwende vertrauenswürdige Images
29. DEMO Konfiguration der Applikation Docker Images erstellen Image Best Practices
30. Container Security & Compliance
31. CONTAINER SECURITY Angriffsflächen von Container-Anwendungen ▪ Container Host ▪ Base Image ▪ Application Image ▪ Application ▪ OWASP Sicherheitslücken ▪ Veraltete oder anfällige Abhängigkeiten
32. SECURITY OPTIMIERUNG Entfernen von ungenutzten Tools und Bibliotheken ▪ Benutzt kleine Images ▪ Tools sind bereits reduziert ▪ Minimierung der Angriffsfläche ▪ Die meisten Tool werden nicht zum ausführen der Applikation genutzt ▪ Alpine & Distroless FTW!
33. SECURITY OPTIMIERUNG Applikationen als Non-Root ausführen ▪ Ausführen der Anwendung auf einen bestimmten Non-Root-Benutzer beschränken ▪ Nicht berechtigt Tools zu installieren (z.B. via apt-get) ▪ Nicht berechtigt privilegierte Skripte auszuführen ▪ Keine Erlaubnis zum Ändern von Berechtigungen ▪ Keine Erlaubnis priviligierte Ports zu binden ▪ Non-Root-Benutzer unterliegt Einschränkungen, auch wenn der Container selbst über erweiterte Rechte verfügt (priviledged container) ▪ Applilation als spezifischer Benutzer ausführen; z.B. Ubuntu RUN adduser -u 5678 --disabled-password --gecos "" appuser && chown -R appuser /app USER appuser ▪ app-Benutzer ist bereits Teil der .NET Base Images
34. RUNTIME SECURITY Production Tip: Schreibgeschütztes Dateisystem ▪ Änderungen am Dateisystem sind nicht zulässig ▪ Angreifern das Herunterladen von Skripten (z. B. mit curl) untersagen ▪ Konfiguration: ▪ Docker: Container mit Option --read-only starten ▪ Kubernetes: readOnlyRootFilesystem: true in yaml-Manifest ▪ Achtung: Manche Anwendungen oder Abhängigkeiten müssen in das Dateisystem schreiben ▪ z.B. temp-Dateien, lock-Dateien ▪ Lösung: Verwenden eines temporären Dateisystems (tmpfs, Docker) oder kurzlebigen Volumes (emptyDir, Kubernetes)
35. SCHWACHSTELLEN SCAN Auf schwachstellen prüfen ▪ Risk Mitigation: Sicherheitsrisiken vor der Bereitstellung in Production identifizieren ▪ Early Detection: Sicherheitslücken bereits in der (frühen) Entwicklungsphase erkennen ▪ Third-Party Component Analysis: Einblicke in die Sicherheit von Abhängigkeiten ▪ Improved Security Hygiene: Fördern einer Kultur des Sicherheitsbewusstseins ▪ Tools ▪ Trivy (aquasecurity/trivy: Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and mor (github.com)) ▪ Clair (quay/clair: Vulnerability Static Analysis for Container (github.com)) ▪ Snyk (Container vulnerability management | Container Security Tools | Kubernetes Security Solutions | Snyk) ▪ Docker Scout (Software Supply Chain Management for Developers | Docker Scout)
36. ▪ Targets ▪ Container Images ▪ Dateisystem ▪ Kubernetes ▪ und viele mehr … ▪ Scanners ▪ OS-Pakete und genutzte Software-Abhängigkeiten ▪ Bekannte Sicherheitslücken (CVEs) ▪ IaC-Probleme und –Fehlkonfigurationen ▪ Vertrauliche Informationen und Secrets ▪ Software-Lizenzen SCHWACHSTELLEN SCAN Trivy
37. SCHWACHSTELLEN SCAN Sicherheitslücken in Images beheben ▪ Basis Image auf Updates prüfen ▪ Basis Image mit weniger Abhängigkeiten, Tools und Bibliotheken nutzen ▪ Sicherheiteslücken mit Copacetic patchen ▪ project-copacetic/copacetic: CLI tool for directly patching container images! ▪ Gewonnenes Wissen nutzen, um Lücken zu schließen ▪ Applikationsabhängigkeiten entfernen ▪ Infrastruktur Update (z.B. Port 22 in Firewall schließen) ▪ Sicherheitsüberprüfungen regelmäßig durchführen ▪ Image Prüfung während CI/CD process ▪ Hyperscaler haben integrierte Tools zum Scannen von Sicherheitslücken (z.B. Microsoft Defender for Cloud)
38. SECURITY & COMPLIANCE Software Bill of Materials ▪ Tools ▪ Trivy ▪ microsoft/sbom-tool: The SBOM tool is a highly scalable and enterprise ready tool to create SPDX 2.2 compatible SBOMs for any variety of artifacts ▪ Formate ▪ CycloneDX ▪ SPDX ▪ Liste der genutzten Software, Bibliotheken und Lizenzen ▪ Hilft Risiko, Kosten und Compliance zu steuern ▪ Vorteile für ISV ▪ Besseres Schwachstellenmanagement ▪ Transparenz über die Lieferkette (Supply Chain) ▪ Lizenz- und Compliance-Sicherheit ▪ Vorteile für Kunden ▪ Erhöhtes Vertrauen und Transparenz ▪ Ermöglicht schnellere Reaktion auf Sicherheitsvorfälle ▪ Unterstützung bei eigenen Audits (z.B. ISO 27001, NIS2)
39. IMAGES SIGNIEREN Warum Container Images signieren? ▪ Integrität: Heruntergeladenes und gebautes Image sind identisch ▪ Non-Repudiation: Der Ersteller des Images ist eindeutig nachweisbar ▪ Tools ▪ Notation CLI (notaryproject/notation: A CLI tool to sign and verify artifacts) ▪ Sigstore Cosign (sigstore/cosign: Code signing and transparency for containers and binaries) ▪ Achtung: Docker Content Trust (DCT) ist mittlerweile veraltet und sollte nicht mehr genutzt werden ▪ Abschaltung am 08.12.2026 (Docker Content Trust: Retirement and Migration Guidance | Docker) ▪ Validierung von Images ▪ CLI Tools ▪ Policy Agents für Kubenetes (Gatekeeper, Ratify)
40. IMAGES SIGNIEREN Notation ▪ Notation CLI: Signieren und Verifizieren von Container-Images und OCI-Artefakten ▪ Easy to use ▪ Integration in CI/CD Pipelines ▪ Plugin system ▪ Azure Key Vault (Azure/notation-azure-kv: Azure Provider for Notation CLI (github.com)) ▪ AWS (Prerequisites for signing container images - AWS Signer (amazon.com))
41. IMAGES SIGNIEREN Signing-Prozess Announcing Notation Azure Key Vault plugin v1.0 for signing container images (microsoft.com) Dev Ops
42. DEMO Applikation als Non-Root Benutzer ausführen Sicherheitslücken Scan Image Patching Images signieren
43. Multi-architecture Images
44. MULTI-ARCHITECTURE IMAGES Vorteile von Multi-Architecture Images ▪ Entwickler arbeiten auf unterschiedlichen OS-Plattformen und CPU-Architekturen ▪ ARM-Architektur gewinnt an Bedeutung ▪ Bessere Performance pro Watt als x64 ▪ Deutlich geringerer Energieverbrauch ▪ Cloud-Anbieter stellen Container-Umgebungen für x64- und ARM-Architekturen bereit ▪ Azure Kubernetes Services ▪ AWS Elastic Kubernetes Services
45. MULTI-ARCHITECTURE IMAGES Container Workloads ausführen x64 arm x64 arm docker buildx
46. MULTI-ARCHITECTURE IMAGES Multi-Architecture Image Manifest Beispiel: mcr.microsoft.com/dotnet/aspnet:10.0 architecture: amd64 os: linux architecture: arm os: linux variant: v7 architecture: arm64 os: linux
47. MULTI-ARCHITECTURE IMAGES Build with Docker Buildx ▪ Docker Buildx = Werkzeug zur Erstellung von Multi-Architecture Images ▪ Released in 2019 (Bestandteil von Docker seit Version 19.03) ▪ Nutzt BuildKit zur Image-Erzeugung ▪ Stell es dir so vor: Ein einzelnes Container-Image enthält mehrere Versionen deiner Anwendung, jeweils für ein bestimmtes Betriebssystem und eine spezifische Architektur.
48. MULTI-ARCHITECTURE IMAGES Buildx konfigurieren ▪ Neuen Builder erstellen docker buildx create --name mybuilder --platform linux/amd64,linux/arm64 --use ▪ Aktuellen Builder überprüfen docker buildx inspect ▪ Multi-Architecture Images erstellen docker buildx build --platform linux/amd64,linux/arm64 --load -t sample-app:1.0.0 . ▪ Prüfen von Multi-Architecture Images docker buildx imagetools inspect sample-app:1.0.0
49. MULTI-ARCHITECTURE IMAGES .NET Applikation Dockerfile erweitern ▪ Nutze die automatischen Plattform-Parameter von Docker, um Plattform- und Architektur-Einstellungen zu konfigurieren ▪ Dockerfile reference - Automatic platform ARGs in the global scope | Docker Docs ▪ Build-Plattform setzen FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0 AS build ▪ Zielarchitektur angeben ARG TARGETARCH ▪ Architektur an .NET Build- und Publish-Befehl weitergeben RUN dotnet build „MyProject.csproj" -c Release \ -a $TARGETARCH
50. DEMO Multi-Architektur Images erstellen
51. ZUKUNFT – WSL CONTAINERS Native Linux Container unter Windows ▪ Mit WSL-Containern lassen sich Linux-Container künftig direkt unter Windows erstellen ▪ Ohne zusätzliche Container-Stacks dazwischen (Docker) ▪ Basierend auf WSL ▪ Ankündigung auf der Build 2026 (WSL container is now available for public preview - Windows Command Line) ▪ Tooling ▪ wslc.exe (mit alias container) ▪ WSL-Container-API + NuGet-Pakete ▪ Docker damit obsolet? ▪ Nein ▪ Stand 06.26 keine Info zu Integration der von Docker und Microsoft https://www.youtube.com/watch?v=c78ZMB7SgHM
52. FRAGEN?
53. LINK ZU SLIDES & DEMOS https://dlmn.link/dwx-2026-docker-aspnet-apps
54. www.abtis.de +49 7231 4431 - 100 vertrieb@abtis.de © 2026 Alle Rechte vorbehalten. Dieses Dokument ist urheberrechtlich geschützt. Sämtliche Inhalte dienen der Dokumentation. Jede andere Nutzung, insbesondere die Weitergabe an Dritte, die Verbreitung oder die Bearbeitung, auch in Teilen, ist ohne schriftliche Einwilligung der abtis GmbH untersagt. Die verwendeten Firmen-, Marken- und Produktnamen und Warenzeichen sind eingetragene Markenzeichen oder Warenzeichen der jeweiligen Inhaber und werden hiermit anerkannt. Die abtis Gruppe führt als IT-Dienstleister den Mittelstand mit strategischer Beratung, effizienten Projekten und maßgeschneiderten Managed Services sicher in die digitale Zukunft. Die Gruppe verfügt über mehr als 20 Jahre Erfahrung in der Planung, der Umsetzung und dem Betrieb von Microsoft-Plattformen. Sie betreut bereits mehr als 250.000 Anwender der Cloud-Plattformen Microsoft 365 und Azure. Die abtis Gruppe ist Mitglied der Microsoft Intelligent Security Association (MISA), Fokuspartner von Microsoft für den Mittelstand und Gewinner des Microsoft Accelerate Innovation Awards 2023 und des Microsoft Act to Accelerate Digital Resilience Awards 2025. Dabei deckt abtis alle Lösungsbereiche von Microsoft ab: von Modern Work über Security, Business Applications, Infrastructure (Azure), Digital & App Innovation (Azure) bis hin zu Data & AI (Azure).