Container |

Installation von Docker Desktop

Sat, 07 Dec 2024 00:00:00 +0000

Die Firma Docker Inc. liefert für Entwickler ein einfaches Tool, um mit Containern starten zu können. Für die private Nutzung (und kleine Firmen) ist das Tool komplett kostenlos.

Docker Desktop installieren

Laden Sie die Installationsdatei von der offiziellen Seite herunter (Windows / macOS) oder installieren Sie diese über den Paket-Manager Ihrer Wahl.

Download:
macOS Homebrew
```
brew install --cask docker
```
Windows WinGet
```
winget install Docker.DockerDesktop
```

Prüfen der Installation

Nach der Installation und Start von Docker Desktop, sollte dieser in erster Linie in der Statusleiste als Icon angezeigt werden. Wenn dies nicht der Fall ist, sollten Sie die Installation überprüfen.

In Terminal / PowerShell

docker version
Client:
 Version: 29.1.2
 API version: 1.52
 Go version: go1.25.5
 Git commit: 890dcca
 Built: Tue Dec 2 21:54:24 2025
 OS/Arch: darwin/arm64
 Context: desktop-linux

Server: Docker Desktop 4.54.0 (212467)
 Engine:
 Version: 29.1.2
 API version: 1.52 (minimum version 1.44)
 Go version: go1.25.5
 Git commit: de45c2a
 Built: Tue Dec 2 21:55:52 2025
 OS/Arch: linux/arm64
 Experimental: false
 containerd:
 Version: v2.2.0
 GitCommit: 1c4457e00facac03ce1d75f7b6777a7a851e5c41
 runc:
 Version: 1.3.4
 GitCommit: v1.3.4-0-gd6d73eb8
 docker-init:
 Version: 0.19.0
 GitCommit: de40ad0

Docker Desktop UI starten

Nachdem das Docker-Desktop-Symbol in der Statusleiste angezeigt wurde, können Sie das Docker Desktop Dashboard starten. Dies ist entweder über das Startmenü oder durch Klicken auf das Symbol in der Statusleiste möglich.

Docker Desktop Dashboard

Ersten Container ausführen

Sat, 07 Dec 2024 00:00:00 +0000

Nachdem Docker Desktop auf unserem System läuft, können wir nun ein erstes Container auf unserem Rechner ausführen. Dazu werden wir die das mitinstallierte Docker CLI nutzen.

nginx Webserver ausführen

docker run --name mein-server \
 -p 1080:80 \
 -d nginx:alpine

docker run --name mein-server -p 1080:80 -d nginx:alpine

Unable to find image 'nginx:alpine' locally
alpine: Pulling from library/nginx
e1779b8a5a13: Download complete
81eecc9295df: Download complete
9afea992cb63: Pull complete
e6b7df06dc76: Pull complete
223f9efb3159: Pull complete
0bd713040ebb: Pull complete
d85e26d0c84d: Pull complete
2422bf732277: Pull complete
e350a0f963e3: Pull complete
29b7c987abf6: Pull complete
Digest: sha256:289decab414250121a93c3f1b8316b9c69906de3a4993757c424cb964169ad42
Status: Downloaded newer image for nginx:alpine
76c073965f57bc7351a7259b6e71b70a990cb42bcc4cda7ee41c6f38bb11963d

docker run startet ein neues Container
--name <eingener_container_name> gibt dem Container den Namen mein-server. Dies ist optional. Wird kein Name angegeben, “würfelt” Decker einen aus.
-p 1080:80 Durchreichen eines Ports aus dem Container (hier Port 80 des nginx Servers) zu dem Host-Port (hier 1080)
-d Starten Container als “Detached” (Hintergrundprozess), so dass die Kommandozeile weiter genutzt werden kann.
nginx:alpine ist der Image, das wir verwenden. nginx ist dabei der Name des Images (Repository). alpine ist ein Tag (Version).

In der Ausgabe sehen wir, dass Docker am Anfang das Image nicht hat (Unable to find image 'nginx:alpine' locally). Aus diesem Grund stößt dieser an, das Image aus dem Docker Hub herunterzuladen. Dies kann einige Zeit dauern, abhängig von der Internetverbindung und der Größe des Images. In unserem Fall ist das Image sehr klein (ca. 20MB).

Nun können wir über http://localhost:1080 auf unseren neuen Webserver zugreifen.

Container liefert Web-Inhalt

Container stoppen und löschen

docker stop mein-server

docker rm mein-server

nginx mit eigenen Inhalt ausführen

Statt der langweiligen Standardseite von nginx können wir auch diesen dazu bewegen, unsere eigen statische Seite auszuliefern. Dazu erstellen wir zuerst einen Ordner und legen da eine einfache HTML Seite ab.

Hinweis

Beispiel Seite finden Sie in dem verlinkten im Ordner nginx-site

docker run --name mein-server \
 -p 1080:80 \
 -v ./nginx-site:/usr/share/nginx/html:ro \
 -d nginx:alpine

-v <ordner/pfad/auf/dem/host>:/usr/share/nginx/html:ro Mapping für Speicher (Volume)
- der 2. Teil nach dem : ist der Ordner innerhalb vom Container, das auf unseren lokalen Ordner gemappt werden soll. nginx erwartet Web-Inhalt in dem Ordner /usr/share/nginx/html
- ro am Ende steht für read only. D.h. der Container kann nur lesend auf unseren lokalen Ordner zugreifen.

Eigene Web-Site mit nginx

Erster Container für Entwicklung

Sat, 07 Dec 2024 00:00:00 +0000

Für die erste Nutzung als Entwickler, werden wir ein vorhandenes Beispielprojekt aus dem nehmen. Es liegt im Unterordner blazor-postgres.

Wie der Name schon andeutet, handelt es sich um eine Web-Anwendung mit Blazor. Die Anwendung nutzt zur Datenspeicherung die Datenbank Postgres. Die Datenbank wollen wir als Container ausführen. Das bietet folgende Vorteile:

Keine großen Administrator Vorkenntnisse zu Postgres Datenbank notwendig
Wir können jederzeit entscheiden, welche Version der Datenbank wir nutzen wollen (z.B. kann eine ältere Version der Applikation eine ältere DB Version erfordern - für Fehlerkorrekturen)
Wir können sehr schnell einen “sauberen” Zustand der Datenbank erzeugen.

Starten der Applikation

Hinweis

Falls noch nicht geschehen, müssen Sie die für Ihr Betriebssystem installieren.

Öffnen Sie den Projektordner in dem Editor Ihrer Wahl. Ich nutze dafür VS Code mit der installierten Erweiterung “C# DevKit”.

Versuchen Sie die App nur zu starten, ohne dass wir aktuell eine passende Datenbank dazu haben.

dotnet run

Da die Anwendung bereits beim Start eine Verbindung zur Datenbank erfordert, scheitert der Start mit einer Fehlermeldung.

dotnet run
Die Starteinstellungen von /Users/eugen/src/container-kurs/blazor-postgres/Properties/launchSettings.json werden verwendet…
Buildvorgang wird ausgeführt...
fail: Microsoft.EntityFrameworkCore.Database.Connection[20004]
 An error occurred using the connection to database 'devdb' on server 'tcp://localhost:5432'.
Unhandled exception. Npgsql.NpgsqlException (0x80004005): Failed to connect to 127.0.0.1:5432
 ---> System.Net.Sockets.SocketException (61): Connection refused
 at Npgsql.Internal.NpgsqlConnector.Connect(NpgsqlTimeout timeout)
 at Npgsql.Internal.NpgsqlConnector.Connect(NpgsqlTimeout timeout)
 at Npgsql.Internal.NpgsqlConnector.RawOpen(NpgsqlTimeout timeout, Boolean async, CancellationToken cancellationToken)
 at Npgsql.Internal.NpgsqlConnector.<Open>g__OpenCore|209_0(NpgsqlConnector conn, String username, SslMode sslMode, GssEncryptionMode gssEncMode, NpgsqlTimeout timeout, Boolean async, CancellationToken cancellationToken)
 at Npgsql.Internal.NpgsqlConnector.Open(NpgsqlTimeout timeout, Boolean async, CancellationToken cancellationToken)
 at Npgsql.PoolingDataSource.OpenNewConnector(NpgsqlConnection conn, NpgsqlTimeout timeout, Boolean async, CancellationToken cancellationToken)
 at Npgsql.PoolingDataSource.<Get>g__RentAsync|33_0(NpgsqlConnection conn, NpgsqlTimeout timeout, Boolean async, CancellationToken cancellationToken)
 at Npgsql.NpgsqlConnection.<Open>g__OpenAsync|42_0(Boolean async, CancellationToken cancellationToken)
 at Npgsql.NpgsqlConnection.Open()
 at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenDbConnection(Boolean errorsExpected)
 at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenInternal(Boolean errorsExpected)
 at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.Open(Boolean errorsExpected)
 at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteReader(RelationalCommandParameterObject parameterObject)
 at Microsoft.EntityFrameworkCore.Migrations.HistoryRepository.GetAppliedMigrations()
 at Npgsql.EntityFrameworkCore.PostgreSQL.Migrations.Internal.NpgsqlHistoryRepository.GetAppliedMigrations()
 at Microsoft.EntityFrameworkCore.RelationalDatabaseFacadeExtensions.GetAppliedMigrations(DatabaseFacade databaseFacade)
 at Microsoft.EntityFrameworkCore.RelationalDatabaseFacadeExtensions.GetPendingMigrations(DatabaseFacade databaseFacade)
 at BlazorWebAppMovies.Data.SeedData.Initialize(IServiceProvider serviceProvider) in /Users/eugen/src/container-kurs/blazor-postgres/Data/SeedData.cs:line 20
 at Program.<Main>$(String[] args) in /Users/eugen/src/container-kurs/blazor-postgres/Program.cs:line 23

Start der Postgres Datenbank

Damit die Anwendung starten können, müssen wir die Postgres Datenbank starten. Dazu suchen wir auf dem größten Repository für Container Images, dem von Docker Inc., nach Postgres.

Kategorisierung in Docker Hub

Die Suche gibt uns sehr viele Ergebnisse zu Postgres, da jeder auf diesem Hub Images veröffentlichen kann. Docker Hub hilft uns ein wenig dabei, das richtige Image herauszufinden, in dem es die Image-Repositories kategorisiert.

Es gibt sogenannte “offizielle” Image, die direkt von den Entwicklern der jeweiligen Software zur Verfügung gestellt werden. Nach der Verifizierung, bekommen diese ein Siegel “Docker Official Image”. Damit sind solche Images am vertrauenswürdigsten. Man erkenn solche Images relativ einfach, an den Namen.

Die Namen von den offiziellen Images, haben keinen Präfix. Das haben wir bereits bei nginx gesehen. Auch da bestand der Image-Name nur aus dem Namen der Software. Bei Postgres heißt das Image auch einfach postgres.

Eine weitere Kategorie sind die “Verified Publisher”. Dabei handelt es sich zwar nicht um die “Ersteller” der jeweiligen Software, aber um Firmen, die von Docker Inc. validiert und für vertrauenswürdig befunden worden. Es sind of Firmen, die selbst Ihr Geld mit Containern verdienen und optimierte Images für bestimmte Bereiche liefern. Zu den “Verified Publisher” gehören zum Beispiel

CircleCI: Ein CI/CD as a Service Anbieter
Microsoft
Ubuntu
Bitnami: Anbieter von VM Images / Container Images

Aussuchen der notwendigen Parameter

Wir nutzen für unseren Zweck das offizielle Image von Postgres. Wenn wir in der Suche diesen auswählen, erscheint die Detail-Seite des . Hier finden wir die Beschreibung, wie das vorhandene Container-Image beim Starten mit Parametern angepasst werden kann. Oft stehen auch Informationen, welche Version, Basis-Images und Architekturen unterstützt werden.

Das Postgres Repository hat zum Beispiel Images für:

Postgres-Versions: 18, 17, 16, 15, 14, 13, 12
Architekturen: amd64, arm32v5, arm32v6, arm32v7, arm64v8, i386, mips64le, ppc64le, riscv64, s390x
Basis-Images
- alpine: Basiert auf Alpine-Linux
- bullseye: Basiert auf Debian Trixie (13)
- bookworm: Basiert auf Debian Bookworm (12)

Um auf die Datenbank in unserer Anwendung zugreifen zu können, müssen wir folgende Einstellungen für die Datenbank wissen / setzen:

Benutzername
- Kann im offiziellen Image über Umgebungsvariable POSTGRES_USER gesetzt werden (Standardwert ist postgres)
Passwort
- Muss im offiziellen Image über Umgebungsvariable POSTGRES_PASSWORD gesetzt werden
Datenbankname
- Kann im offiziellen Image über Umgebungsvariable POSTGRES_DB gesetzt werden (Standardwert entspricht dem Benutzernamen)

Die Umgebungsvariablen werden an Docker Runtime mit dem Parameter -e übergeben (kann auch mehrmals verwendet werden).

Aus den gesammelten Informationen, können wir nun den geforderten (kürzesten) Aufruf ableiten:

docker run -e POSTGRES_USER=devuser \
 -e POSTGRES_PASSWORD=devpassword \
 -e POSTGRES_DB=devdb \
 -p 5432:5432 -d postgres:18-alpine

-e POSTGRES_USER=devuser: setzt den Benutzernamen auf devuser
-e POSTGRES_PASSWORD=devpassword: setzt das Passwort auf devpassword
-e POSTGRES_DB=devdb: setzt die Datenbankname auf devdb
-p 5432:5432: ordnet den Standard Port von Postgres zu demselben Port auf unserem Host zu
postgres:18-alpine: startet den Postgres Container mit der Version 18 und dem Alpine-Basis-Image

Postgres Container in Docker Desktop

Starten der Applikation mit laufender Datenbank

Nun läuft die Postgres Datenbank im Hintergrund (in der Version 18), so dass die App auf diese Zugreifen kann. Da wir einige Einstellungen nicht angegeben haben, werden dabei Standardwerte genutzt.

--name: Wir haben dem Container keinen expliziten Namen gegeben. Aus diesem Fall wird dieser durch die Runtime “gewürfelt”. Bei meinem ersten Start war der Name funny_austin.

Wenn wir jetzt die Applikation starten. In der Ausgabe wird auch die URL Angezeigt, unter der die Applikation erreichbar ist.

dotnet run

Using launch settings from /Users/eugen/src/container-kurs/blazor-postgres/Properties/launchSettings.json...
Building...
fail: Microsoft.EntityFrameworkCore.Database.Command[20102]
 Failed executing DbCommand (10ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
 SELECT "MigrationId", "ProductVersion"
 FROM "__EFMigrationsHistory"
 ORDER BY "MigrationId";
fail: Microsoft.EntityFrameworkCore.Database.Command[20102]
 Failed executing DbCommand (1ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
 SELECT "MigrationId", "ProductVersion"
 FROM "__EFMigrationsHistory"
 ORDER BY "MigrationId";
info: Microsoft.EntityFrameworkCore.Migrations[20411]
 Acquiring an exclusive lock for migration application. See https://aka.ms/efcore-docs-migrations-lock for more information if this takes too long.
info: Microsoft.EntityFrameworkCore.Migrations[20402]
 Applying migration '20241206073458_Init'.
info: Microsoft.Hosting.Lifetime[14]
 Now listening on: http://localhost:5216
info: Microsoft.Hosting.Lifetime[0]
 Application started. Press Ctrl+C to shut down.

Öffnen Sie die Applikation nun unter der ausgegebenen Adresse http://localhost:5216.

Blazor App mit DB Verbindung

Orchestrierung mit Docker Compose

Sat, 07 Dec 2024 00:00:00 +0000

Bereits in unserem kleinen Beispiel bräuchten wir normalerweise mehr als einen Container. Es wäre schön, wenn wir neben der Datenbank, auch eine Web-basierte UI für die Verwaltung der Datenbank zur Hand hätten (gibt es ja fast für alle Datenbanken). Damit müssten wir nicht für jede Datenbank auch noch ein Tool installieren, mit dem man die Daten anschauen kann.

Aber bereits 2 Container bringen eine gewisse Komplexität. Zum Beispiel müssen wir die UI für die Datenbank erst starten, wenn die Datenbank bereits hochgefahren und verfügbar ist. Mit mehr Containern (z.B. Redis für Caching, Prometheus für Monitoring, Logging und Tracing, Grafana für Visualisierung dieser Daten, usw.). Alle haben eigene Voraussetzungen, Abhängigkeiten usw.

Wäre es nicht schön, so eine “Laufzeitumgebung” ein Mal zu definieren und immer wieder (sauber) ausführen zu können? Eventuell diese Konfiguration direkt mit dem Projekt auch mit den Kollegen teilen?

So eine Orchestrierung von unterschiedlichen Containern können wir mit “Docker Compose” umsetzten. Das ist praktisch ein kleiner Bruder von Kubernetes, das für die professionelle, hoch skalierbare, Orchestrierungen gedacht ist.

Orchestrierung mit Docker Compose

Die Container, die mit “Docker Compose” orchestriert werden sollen, werden in einer YAML Datei definiert und konfiguriert. Die CLI dafür wird mit “Docker Desktop” mitgeliefert. Ist diese auf Ihrem System nicht installiert, können Sie den Installationsanweisungen von der offiziellen folgen.

Die Datei wird standardmäßig docker-compose.yml genannt und befindet sich in dem gleichen Verzeichnis wie das Projekt. Hier ist der Grundaufbau der Datei:

 1# Liste der Services / Container
 2services:
 3 # Datenbank Container
 4 db:
 5 # Container image
 6 image: postgres:18-alpine
 7 # Umgebungsvariablen
 8 environment:
 9 POSTGRES_PASSWORD: super-secret-password
10 # Port Mapping
11 ports:
12 - "5432:5432"
13 dbAdmin:
14 # Container image
15 image: dpage/pgadmin4
16 # Umgebungsvariablen
17 environment:
18 PGADMIN_DEFAULT_EMAIL: admin@example.com
19 PGADMIN_DEFAULT_PASSWORD: super-secret-password
20 # Port Mapping
21 ports:
22 - "8080:80"

Die Konfiguration enthält min. ein Service (Container) das gestartet werden soll.

In der Zeile 4 starten wir die Konfiguration von Postgres Datenbank. Der Service enthält den Namen db.
Zeile 6 definiert das Image, das verwendet wird (Postgres in diesem Fall).
In der Zeile 8 definieren wir die Umgebungsvariablen, die beim Starten des Containers gesetzt werden sollen. In diesem Fall POSTGRES_PASSWORD wird auf super-secret-password gesetzt.
Zeile 10 definiert das Port Mapping, mit dem Containerport 5432 mit dem Hostport 5432 verbunden wird.

Der zweite Service ist eine Admin-UI für Postgres. Sie wird mit dem Namen dbAdmin gestartet und verwendet die Image dpage/pgadmin4. Die Umgebungsvariablen werden ebenfalls gesetzt, um den Benutzername und das Passwort für die Admin-UI zu definieren.

Da bei der Definition des Images for dbAdmin keine Version angegeben wird (kein :tagName am Ende), wird der Tag automatisch auf latest gesetzt (Docker Konvention).

Starten der Orchestrierten Container

Um nun alle konfigurierten Services zu starten, nutzen wir die “Docker Compose” CLI. Die Aufrufe müssen in dem Ordner erfolgen, in dem die docker-compose.yml Datei liegt.

docker compose up -d

Gestarteten Container über Compose

Unter http://localhost:8080 können Sie sich nun mit den Zugangsdaten (aus der Konfiguration) anmelden und eine Verbindung zur Datenbank herstellen (Hostname db, wie der Service Name).

Postgres Admin Web-UI

Anpassung der Orchestrierung an die Applikation

Damit passt die aktuelle minimalistische Konfiguration aber noch nicht zu unseren Anforderungen der App.

Wir haben vorgegebene Anmeldedaten für die Datenbank
Wir haben einem, vom Standard abweichenden Datenbanknamen
Es wäre gut, wenn pgAdmin bereits die Verbindung zu unseren Datenbank hätte, ohne dass wir es jedes Mal nach Neustart eingeben müssten
pgAdmin sollte erst starten, wenn die Datenbank einsatzbereit ist (“health check”)

Die Konfiguration der Datenbank können wir leicht anpassen. Die entsprechenden Umgebungsvariablen-Werte kennen wir bereits aus dem direkten Start mit Docker.

services:
 db:
 environment:
 POSTGRES_USER: devuser
 POSTGRES_PASSWORD: devpassword
 POSTGRES_DB: devdb

Für die Prüfung, ob der Container wirklich einsatzbereit ist, müssen wir einen “health check” umsetzen. Dieser ist immer abhängig vom Service. Für unsere Postgres Datenbank könnte dieser wie folgt aussehen.

1services:
2 db:
3 healthcheck:
4 test: ["CMD-SHELL", "pg_isready -U devuser -d devdb"]
5 interval: 2s
6 retries: 10
7 start_period: 5s
8 timeout: 30s

Zeile 3 startet die Definition für “health check” ( )
Zeile 4 beschreibt den Befehl, mit dem die “Bereitschaft” geprüft werden kann. Bei Postgres können wir dazu pg_isready Tool nutzen. ( )
Zeile 5 gibt an, in welchen Zeitabständen der Check durchgeführt wird, nach dem Ablauf der start_period
Zeile 6 gibt an die Anzahl der Versuche, bis der Start als fehlerhaft markiert wird
Zeile 7 gibt die üblich Startzeit an. In dieser Zeit wir der Container zwar getestet, die Fehler zählen in dieser Zeit aber nicht zu Wiederholungen.
Zeile 8 gibt an, wie lange ein Check max. dauern soll, bis der als fehlerhaft erkannt wird

In pgAdmin können wir nun die Datenbank als Abhängigkeit eintragen, so dass der Container erst dann startet, wenn die (auf Verbindungsversuche antwortet) ist.

services:
 db:
 ...
 dbAdmin:
 depends_on:
 db:
 condition: service_healthy

Nun fehlt uns nur noch die Konfiguration von pgAdmin, so dass unsere Datenbank da bereits “hinterlegt” ist. Dazu müssen wir (leider) die von pgAdmin genauer ansehen.

Damit wir uns nicht jedes Mal anmelden müssen (wir sind ja auf unseren eigenen Rechner und betreiben keinen Server), können wir pgAdmin ich einen “nicht” Server Modus starten

services:
 dbAdmin:
 environment:
 PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED: 'False'
 PGADMIN_CONFIG_SERVER_MODE: 'False'

PGADMIN_CONFIG_SERVER_MODE schaltet pgAdmin in single User Mode, so dass wir uns nicht mehr anmelden müssen
PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED erlaubt uns im nächsten Schritt die Konfiguration des Servers durchzureichen

Im letzten Schritt legen wir eine Konfigurationsdatei für die Serverkonfiguration, die wir an pgAdmin durchreichen werden. Diese können wir indirekt für uns erstellen lassen, in dem wir den Server zuerst in pgAdmin konfigurieren und diese Konfiguration dann als JSON-Datei exportieren. Die exportierte Datei muss dann über Docker Desktop aus dem Container exportiert werden.

 1{
 2 "Servers": {
 3 "1": {
 4 "Name": "DB",
 5 "Group": "Servers",
 6 "Host": "db",
 7 "Port": 5432,
 8 "MaintenanceDB": "devdb",
 9 "Username": "devuser",
10 "PasswordExecCommand": "echo \u0027devpassword\u0027"
11 }
12 }
13}

In Zeile 10 übergeben wir das Passwort über ein echo Befehl, da die Konfiguration die Speicherung von unverschlüsselten Passwörtern nicht erlaubt.

1services:
2 dbAdmin:
3 # Datei und Orner Mappings
4 volumes:
5 - ./db_server.json:/pgadmin4/servers.json

In Zeile 5 Mappen wir unsere Konfigurationsdatei servers.json in den Container hinein. pgAdmin erwartet die Serverkonfiguration im Ordner /pgadmin4 mit dem Dateinamen servers.json.

Nun können wir unsere Konfiguration starten. In der Kommandozeile sehen wir auch, dass pgAdmin erst starten, wenn Postgres in den “healthy” Status wechselt. Wenn wir nun die pgAdmin Web-Oberfläche öffnen, gelangen wir direkt, ohne Anmeldung, hinein. Auch der Postgres Server ist für uns bereits konfiguriert.

docker compose up -d

dotnet run

pgAdmin ohne Anmeldung mit Serverkonfiguration

Eigene App in Container verpacken

Sun, 08 Dec 2024 00:00:00 +0000

Wenn man eine Zeit lang die Container für sich arbeiten lässt und diese nutzt, kommt irgendwann der Gedanke, auch eigene Applikation in einen Container zu verpacken und auszuliefern. Das wollen wir am Beispiel unser Blazor Beispielprojektes ein Mal durchspielen.

Um ein Image zu erstellen, benötigen wir eine Bauanleitung. Diese wird in Form eines sogenannten Docker-Files definiert. Die Datei beschreibt Schritt für Schritt, was wir am Basissystem machen müssen, um unsere Applikation zu veröffentlichen. Dazu kommen noch einige Konfigurationsangaben, wie Port oder verfügbare Umgebungsvariablen.

Anpassbarkeit des Images

Als erstes müssen wir überlegen, welche Möglichkeiten wir dem “Nutzer” des Images zur Verfügung stellen müssen (und wollen). Da es sich um eine Web-Anwendung handelt, sollten wir mindestens den Port für den Web-Server freigeben, so dass die Anwendung auch von Außen ansprechbar ist.

Da unsere Anwendung eine Datenbankverbindung benötigt, sollten wir erlauben diese zu konfigurieren. Hier könnten wir entweder direkt den kompletten “Connection String” empfangen, oder diesen in Teilen konfigurierbar machen.

Auswahl des Basis-Images

Unsere Anwendung basiert auf der .Net Laufzeitumgebung und benötigt das ASP .Net Core Framework. Im ersten Schritt wollen wir auch, dass die App in dem Container (einfachheitshalber) direkt gebaut wird. Die Applikation nutzt .Net 10 als Version der Laufzeitumgebung. Eine Liste mit verfügbaren (offiziellen) Repositories für .Net finden wir .

Für unsere Zwecke werden wir das “sdk” Basis-Image nutzen.

Dockerfile

Die Datei ist eine einfache Textdatei, die einem Schema folgt. Jede neue Zeile (Anweisung) erzeugt dabei eine neue Schicht im Dateisystem des fertigen Images. Die Datei fängt immer mit einer Anweisung, gefolgt von dem Basis-Image, auf dem wir unsere Applikation aufbauen.

# Basis-Image .Net 10 SDK
FROM mcr.microsoft.com/dotnet/sdk:10.0

Kopieren des Projektes

Im nächsten Schritt (nächste Zeile) legen wir das Verzeichnis ( ) an, in dem wir “arbeiten” wollen. Und kopieren ( ) den aktuellen Inhalt des Projektes in dieses Verzeichnis.

FROM mcr.microsoft.com/dotnet/sdk:10.0
# Verzeichnis für die App
WORKDIR /build
# Kopiere das Projekt in das Arbeitsverzeichnis
COPY . ./

Bauen des Projektes

Nun folgen die Standardschritte von dotnet um eine Applikation für die Veröffentlichung zu bauen. Dieser Schritt ist spezifisch für die jeweilige Sprache / Framework (und unabhängig von Docker / Containern). Die Befehle werden durch die Anweisung ausgeführt. Jede Zeile erzeugt, wie erwähnt, eine neue Schicht im Dateisystem.

FROM mcr.microsoft.com/dotnet/sdk:10.0
...
# Wiederherstellen der Abhängigkeiten
RUN dotnet resore
# Veröffentlichen der App in das Verzeichnis /app
RUN dotnet publish BlazorWebAppMovies.csproj -c Release -o /app

Konfiguration des Ports und Datenbankverbindung

Da wir eine Web-Anwendung haben, die eine Datenbank benötigt, sollen wir diese parametrisieren. Für das Arbeiten einer Web-Anwendung im Container ist es wichtig, dass wir ein Port zur Verfügung stellen, über den die Applikation erreichbar ist. In dem SDK Package ist das Port für Webanwendungen auf 8080 gesetzt (kann über die Umgebungsvariable ASPNETCORE_HTTP_PORTS angepasst werden).

Standard port in SDK image

Der Port wird über die Anweisung angegeben und kann neben dem Port selbst auch dar Protokoll enthalten.

Unsere Applikation ist auch von einer Datenbank abhängig. Wir müssen den “Connection String” mit übergeben, damit der Container sich mit der Datenbank verbinden kann. In .Net werden die Einstellungen in appsettings.json Datei (JSON Format) gespeichert. Will man diese Einstellungen mit Umgebungsvariablen überschreiben, werden die Verschachtlungen über ein __ (doppeltes Unterstrich) abgebildet. Aus aktuell { "ConnectionStrings": { "BlazorWebAppMoviesContext": "" } } wird so ConnectionStrings__BlazorWebAppMoviesContext. Da Umgebungsvariablen oft in Großbuchstaben geschrieben werden (und für .Net Konfigurationen es irrelevant ist), werden wir es als CONNECTIONSTRINGS__BLAZORWEBAPPMOVIESCONTEXT schreiben.

Die Umgebungsvariablen werden in Dockerfile mit der Anweisung definiert. Schlüssel und Wert werden über = getrennt.

FROM mcr.microsoft.com/dotnet/sdk:10.0
...
# Neues Arbeitsverzeichnis
WORKDIR /app
# Datenbank Connection string
ENV CONNECTIONSTRINGS__BLAZORWEBAPPMOVIESCONTEXT=""
# Port für Webserver
EXPOSE 8080

Starten der Anwendung

Der letzte Schritt ist nun die Anweisung, um die Anwendung in dem Container zu startet. Da wir die Applikation nicht manuell innerhalb des Containers starten wollen, sollte dies direkt beim “Instanziieren” des Containers geschehen.

Die Anwendung selbst wird über die Anweisung ausgeführt. Die Anweisung nimmt eine Liste an Parametern entgegen. Die Applikationen in .Net startet man mit dem dotnet Befehl und dem Applikationsnamen (entspricht dem Projektnamen).

FROM mcr.microsoft.com/dotnet/sdk:10.0
...
# Start der .Net Anwendung
ENTRYPOINT ["dotnet", "BlazorWebAppMovies.dll"]

Image bauen

Im letzten Schritt können wir nun die “Bauanleitung” dazu nutzen unser erstes Image mit unserer Anwendung zu bauen. Dazu dient der Befehl .

docker build -t blazor-movies:from-sdk .

-t: Tag des Images, also der Image-Name + Version. In unserem Fall vergeben wir den Namen blazor-movies. Da wir einige Images bauen werden und diese miteinander vergleichen möchten, vergeben wir eine sprechenden Versionsnamen. Aktuelle Buildanleitung basiert auf dem SDK-Image. Der Versionsname ist bei uns deshalb from-sdk.
.: Das . hinter dem Tab bestimmt den (Pfad). Der Build-Context steht beim Bauen zur Verfügung (wie bei uns der Quellcode der Anwendung). . bedeutet dabei, der aktuelle Ordner.

Hinweis

Sie können die Datei der Bauanleitung auch anders benennen als Dockerfile, müssen dann aber beim Bauen den Dateinamen als Parameter (-f) mit übergeben. Wenn Sie zum Beispiel die Datei Dockerfile.dev nennen würden, würde der Baubefehl wie folgt aussehen:

docker build -t blazor-movies:dev -f Dockerfile.dev .

Finale Version

FROM mcr.microsoft.com/dotnet/sdk:10.0
# Verzeichnis für die App
WORKDIR /build
# Kopiere das Projekt in das Arbeitsverzeichnis
COPY . ./
# Wiederherstellen der Abhängigkeiten
RUN dotnet restore
# Veröffentlichen der App in das Verzeichnis /app
RUN dotnet publish BlazorWebAppMovies.csproj -c Release -o /app
# Arbeitsverzeichnis für Ausführung
WORKDIR /app
# Datenbank Connection string
ENV CONNECTIONSTRINGS__BLAZORWEBAPPMOVIESCONTEXT=""
# Port für Webserver
EXPOSE 8080
# Start der .Net Anwendung
ENTRYPOINT ["dotnet", "BlazorWebAppMovies.dll"]

Unser Image in Docker Desktop

Multi Stage Builds

Sun, 08 Dec 2024 00:00:00 +0000

Wenn wir die Größe unseres Images in Docker Desktop anschauen (oder mit dem Docker-Befehl auf der Kommandozeile), sehen wir, dass die Größe gewaltig ist. Auf meinem Rechner ist das Image 2.6 GB groß. Warum ist es so?

docker image ls

IMAGE ID DISK USAGE CONTENT SIZE
blazor-movies:from-sdk e561bfaae17f 2.55GB 758MB
mcr.microsoft.com/dotnet/sdk:10.0 d1823fecac36 1.29GB 318MB

Ursachen für große Images

Schauen wir uns die Ursachen für die Größe an.

Größe des Basisimages

Einen großen Einfluss auf die endgültige Größe hat natürlich das Basisimage. Unsere App kommt ja immer “on Top” von diesem Basisimage. Aktuell nutzen wir SDK-Image als Basis, das alleine bereits 1.3 GB groß ist. Das SDK-Image bringt alles mit, was notwendig ist, um eine dotnet Applikation ausführen, aber auch bauen zu können.

Daten im Image

Da wir die Applikation in dem Image selbst bauen, hat dieser nicht nur die fertige App, sondern auch noch:

Quellcode, den wir kopiert haben, um die Applikation bauen zu können
Eventuelle “Zwischen-Dateien”, die bei einem Build-Prozess entstehen, aber nicht in die finale App reinfließen (bei dotnet z.B. die obj und bin Ordner)
Eventuelle “Kompilate”, die auf unserem PC bereits da sind, da wir die App ja bereits local gebaut uns ausgeführt haben

Ursachen beseitigen

Beide Probleme können wir mit sogenannten “multi stage builds” lösen. Dabei werden unterschiedliche Images für das Erstellen der App (Kompilieren) und für finale Image genutzt. Dabei bekommt das finale Image nur die fertig kompilierte App.

Dafür müssen wir nur wenige Änderungen an unserem Bauplan durchführen.

# Image für Build
- FROM mcr.microsoft.com/dotnet/sdk:10.0
+ FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
# Verzeichnis für das Build

Mit AS <name> vergeben wir diesen ersten Schritt (Stage) einen Namen, so dass wir später uns auf diesen beziehen können.

Für den zweiten Schritt benötigen wir ein schlankeres Basis-Image. Da wir am Ende die Applikation nur ausführen möchten, ist SDK überdimensioniert. Uns reicht für unsere Zwecke die runtime (Ausführung) Version. Das Image dazu bei Microsoft heißt mcr.microsoft.com/dotnet/aspnet:9.0.

Alle Schritte in der Bauanleitung (Dockerfile), die mit dem finalen Image zu tun haben, werden auf dem “runtime” Basis-Image ausgeführt.

 1RUN dotnet publish BlazorWebAppMovies.csproj -c Release -o /app
 2+
 3+ # Image für Runtime
 4+ FROM mcr.microsoft.com/dotnet/aspnet:10.0
 5# Verzeichnis für die App
 6WORKDIR /app
 7+ # Kopieren des aus dem Build zu Runtime Image
 8+ COPY --from=build /app .
 9# Datenbank Connection string
10ENV CONNECTIONSTRINGS__BLAZORWEBAPPMOVIESCONTEXT=""

In der Zeile 4 definieren wir das Image, das als Basis für unser eigenes Image dienen soll (hier aspnet).
In der Zeile 8 kopieren wir die fertig kompilierte Applikation aus dem SDK-Schritt (´from=build´) und Ordner /app in den aktuellen Arbeitsordner. Damit enthält das fertige Image weder den Quellcode, noch die “Zwischen-Dateien”, die beim Kompilieren entstehen.

Bauen wir nun unser Image mit der aktuellen Version von Dockerfile und vergeben die Version from-aspnet an das Image.

# Image für Build
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
# Verzeichnis für das Build
WORKDIR /build
# Kopiere das Projekt in das Arbeitsverzeichnis
COPY . ./
# Wiederherstellen der Abhängigkeiten
RUN dotnet restore
# Veröffentlichen der App in das Verzeichnis /app
RUN dotnet publish BlazorWebAppMovies.csproj -c Release -o /app

# Image für Runtime
FROM mcr.microsoft.com/dotnet/aspnet:10.0
# Verzeichnis für die App
WORKDIR /app
# Kopieren des aus dem Build zu Runtime Image
COPY --from=build /app .
# Datenbank Connection string
ENV CONNECTIONSTRINGS__BLAZORWEBAPPMOVIESCONTEXT=""
# Port für Webserver
EXPOSE 8080
# App in Container starten
ENTRYPOINT ["dotnet", "BlazorWebAppMovies.dll"]

docker build -t blazor-movies:from-runtime .

Unser Image ist nun deutlich kleiner geworden. Auf meinem MacBook Air ist das Image nun 462 MB, also 2.0 GB kleiner als unser erster Versuch.

docker image ls

IMAGE ID DISK USAGE CONTENT SIZE
blazor-movies:from-runtime 42c8d3bed245 462MB 116MB
blazor-movies:from-sdk e561bfaae17f 2.55GB 758MB
mcr.microsoft.com/dotnet/aspnet:10.0 eaa79205c3ad 369MB 92.4MB
mcr.microsoft.com/dotnet/sdk:10.0 d1823fecac36 1.29GB 318MB

Ein großer Teil kommt vom kleineren Basis-Image. Diese Änderung bringt bereits über 920 MB Ersparnis (von 1.3 GB runter auf 369 MB). Der Rest kommt durch das Weglassen des Quellcodes und der temporären Dateien, die beim Kompilieren entstehen.

Weitere Optimierungen

Wir können unser Image noch weiter Optimieren. Die Standard-Images von Microsoft basieren normalerweise auf Debian, zwar einer sehr schlanken Version davon, aber immer noch mit einen vollwertigen Linux als Basis. Wir kennen bereits ein minimalistisches Linux, das selbst nur 20MG groß ist, alpine Linux.

Microsoft liefert alle eigene Basis-Images auch in der Alpine-Version.

# Image für Build
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
# Verzeichnis für das Build
WORKDIR /build
# Kopiere das Projekt in das Arbeitsverzeichnis
COPY . ./
# Wiederherstellen der Abhängigkeiten
RUN dotnet restore
# Veröffentlichen der App in das Verzeichnis /app
RUN dotnet publish BlazorWebAppMovies.csproj -c Release -o /app

# Image für Runtime
FROM mcr.microsoft.com/dotnet/aspnet:10.0-alpine
# Verzeichnis für die App
WORKDIR /app
# Kopieren des aus dem Build zu Runtime Image
COPY --from=build /app .
# Datenbank Connection string
ENV CONNECTIONSTRINGS__BLAZORWEBAPPMOVIESCONTEXT=""
# Port für Webserver
EXPOSE 8080
# App in Container starten
ENTRYPOINT ["dotnet", "BlazorWebAppMovies.dll"]

 docker build -t blazor-moviews:from-alpine .

Nun sieht unser Image noch kleiner aus. Das Basis-Image ist von 369 MB runter auf 183 MB. Und unser eigener Image ist nun von 462 MB runter auf 276 MB. Das ist 11% von unseren Ausgangspunkt.

docker image ls

IMAGE ID DISK USAGE CONTENT SIZE
blazor-movies:from-alpine bb332d7cf91c 276MB 76MB
blazor-movies:from-runtime 42c8d3bed245 462MB 116MB
blazor-movies:from-sdk e561bfaae17f 2.55GB 758MB
mcr.microsoft.com/dotnet/aspnet:10.0 eaa79205c3ad 369MB 92.4MB
mcr.microsoft.com/dotnet/aspnet:10.0-alpine 1be14b20e4ec 183MB 51.9MB
mcr.microsoft.com/dotnet/sdk:10.0 d1823fecac36 1.29GB 318MB

Abhängig von der Programmiersprache und deren Fähigkeiten, lässt sich die finale Applikation noch weiter verkleinern (und somit auch das Image). Das erfordert aber sehr oft deutlich mehr aufwand. Mit Asp.Net wäre es möglich bei einigen Applikationen AOT (Ahead of Time) Kompilierung durchzuführen, so dass gar keine Runtime mehr benötigt wird. Mit Trimming (Abschneiden der nicht genutzten Fähigkeiten) kann die kompilierte Applikation noch weiter verkleinert werden.

Mit den einfachen Mitteln haben wir aber bereits ein sehr kleines Image erstellt, das für die meisten Anforderungen gut genug ist.

Vorteil von Alpine Linux

Der größte Vorteil von Alpine Linux ist nicht die Größe, sondern die Sicherheit. Da dieses Linux fast nichts hat, kann es weniger kompromittiert werden. Das ist direkt sichtbar in Docker Desktop. Für SDK Image liegen aktuell 14 bekannte Schwachstellen (7 in Debian und 7 in SDK selbst), Runtime hat immer noch 8, Alpine hat nur 2 (mit niedriger Wertung).

Hinweis

Das Bild der Schwachstellen ist eine Momentaufnahme und wird bei Ihnen anders aussehen. Allgemeines Bild, dass Alpine-Images deutlich weniger Schwachstellen aufweisen, wird aber bleiben.

14 Schwachstellen in SDK Image

2 Schwachstellen in SDK Image

Eigenes Image veröffentlichen

Sun, 08 Dec 2024 00:00:00 +0000

Nun haben wir das Image erstellt. Aktuell befindet sich dieses aber nur auf unserem eigenen Rechner. D.h. keiner, außer uns, kann dieses Image nutzen. Damit auch andere unser Image nutzen können, müssen wir dieses veröffentlichen. Dazu benötigen wir als erstes eine Container-Registry.

Container Registry

Container Registry ist ein zentraler Speicherort für die fertig gebauten Images. Es gibt einige Anbieter dafür, sowohl öffentlich zugängliche als auch solche, die private Images verwalten.

Die bekannteste Registry ist von der Firma Docker selbst und heißt . Diese erlaubt ein kostenloses privates Repository und unbegrenzt für Open Source Projekte.

Daneben bietet fast jeder größerer Cloud-Anbieter eine Container-Registry in deren Cloud-Umgebung:

und viele weitere.

Docker Hub

Hier werden wir Docker Hub als Beispiel nutzen. Das Vorgehen mit anderen Anbietern ist oft ähnlich. Für alle können dieselben Docker-Befehle genutzt werden.

Legen Sie als erstes ein Konto bei an, falls Sie noch keinen haben.
Erstellen Sie ein neues Repository (Speicherort für Images einer Anwendung) an, z.B. blazor-movies
Erstellen Sie ein “Personal Access Token”, um auf den Docker Hub einfacher zugreifen zu können (und sicherer - insbesondere in CI/CD Umgebungen).

Personal Access Token Erstellen

Klicken Sie auf Ihren Avatar oben rechts, um zu den “Account Settings” zu gelangen.
Öffnen Sie nun im Bereich “Settings” die Einstellungen für “Personal access tokens”
Klicken Sie auf “Generate new token”, um einen neuen Token zu erstellen. Wählen Sie hier einen sprechenden Namen, die max. Gültigkeit des Tokens und dessen Berechtigung. Zum Veröffentlichen benötigen Sie min. Schreibrechte. Bei anderen Anbietern kann die Granularität der Berechtigungen deutlich granulärer sein.

Vorbereiten des Images

Bevor das Image hochgeladen werden kann, muss dieser zuerst angepasst werden. Der Name kann nicht mehr so einfach sein, wie in unserem Fall vorher (balazor-moview). Wie wir bereits gelernt haben, sind die “einfachen” Image-Namen für offizielle Images reserviert.

Unsere Images müssen im Namen folgende Bestandteile enthalten <registry>/<vendor>/<repository>:<tag>. Hier am Beispiel unseres Basis-Images mcr.microsoft.com/dotnet/aspnet:10.0-alpine:

Registry: Bei Docker-Hub fällt dieser Teil weg. Bei anderen Registrys muss der Name der Registry angegeben werden (z.B. bei unserem Basis-Image ist es mcr.microsoft.com).
Vendor: Normalerweise Hersteller der Software oder Benutzer, der die Repositories pflegt (z.B. bei unserem Basis-Image ist es dotnet). Bei offiziellen Images auf Docker Hub entfällt auch dieser Teil.
Repository: Speichername für die Images einer Anwendung (z.B. bei unserem Basis-Image ist es aspnet). Dieser Teil ist immer notwendig
Tag: Version der Anwendung (z.B. bei unserem Basis-Image ist es 10.0-alpine). Dieser Teil ist wieder optional. Wird Tag nicht angegeben, vergibt Docker automatisch den Tag latest.

Wir müssen unser Image, das wir veröffentlichen wollen, zuerst nach der obigen Konvention umbenennen. Aus dem aktuellen Namen blazor-movies:from-alpine muss webducer/blazor-moviews:alpine werden (ersetzen Sie Benutzer- und Repository-Namen mit Ihren Werten).

Auf Docker Hub erhalten Sie einen Hinweis, wie das Image heißen soll in Form des “push” Befehls auf der Repository Startseite.

Push command Hilfestellung auf der Repository Seite

Die Umbenennung des Images erfolgt durch das erneute Taggen des vorhandenen Images mit dem Befehl.

docker image tag blazor-movies:from-alpine webducer/blazor-movies:alpine

Veröffentlichen

Vor der Veröffentlichung müssen wir uns zuerst bei der Registry einloggen. Bei Docker Hub entfällt die Angabe der Registry. Bei allen anderen muss diese immer explizit mit angegeben werden. Das Anmelden erfolgt über den Befehl (docker login <server-name> bei nicht Docker Hub Registrys). Folgen Sie dabei den Anweisungen.

docker login

Nun können wie unser Image veröffentlichen. Das erfolgt durch den Befehl und der Eingabe des Image-Namens.

docker push webducer/blazor-movies:alpine

Das Veröffentlichen kann einige Zeit dauern, abhängig von der Größe des Images und Ihrer Internetverbindung. Beim push wird normalerweise nicht das ganze Image übertragen, sondern nur die “unbekannten” Schichten. Da meistens das Basis-Image bereits in Registry bekannt ist, müssen nur die Schichten oberhalb von diesen Basis-Image übertragen werden.

Repository nach Veröffentlichung

Details des Images

Oft benötigte Commands

Sat, 07 Dec 2024 00:00:00 +0000

`docker run`

Startet ein neues Container basierend auf den übergebenen Image. Abhängign von den Fähigkeiten des Images, können zusätliche Parameter übergeben / genutzt werden.

docker run nginx

Wichtige Parameter

--name Name des Containers. Wenn dieser nicht mitgegeben wird, wir der Name von der Runtime vergeben.
-d oder --detach Detatched. D.h. die Runtime startet den Container im Hintergrund, so dass das Terminal für weitere Eingaben zur Verfügung steht.
-e oder --env Setzen der Umgebungsvariablen innnerhalb des Containers (kann auch mehrfach genutzt werden, um mehrere Umgebungsvariablen zu setzen).
-p oder --publish Port Publishing. Gibt an welcher Container-Port zu welchen Host-Port umgeleitet werden soll.
-v oder --volume Mapping für Speicher (Dateien oder Orner)
-rm Starte einen neuen Container. Somald dieser beendet wird, wird dieser auch gleich gelöscht (praktsich für “ein Mal ausführen” Container).
-it Kombination aus -i (--interactive) und -t (--tty) und erlaubt interaktiv in den Container “reinzugehen”, um dessen Inhalt zum Beispiel zu untersuchen

docker run --name my-homepage \ 
 -p 1080:8080 \ 
 -e NGINX_PORT="8080" \ 
 -e NGINX_HOST="my-homepage.io" \ 
 -v /www/website:/usr/share/nginx/html:ro \ 
 - d

`docker start`

Starten einen bereits vorhandenen Container. Als Parameter wird der Name oder die ID des Containers akzeptiert.

docker start my-homepage

`docker stop`

Stopt einen bereits vorhandenen und laufenden Container. Als Parameter wird der Name oder die ID des Containers akzeptiert.

docker stop my-homepage

Glossar

Sat, 07 Dec 2024 00:00:00 +0000

Container

Ein Container ist eine Laufzeitinstanz eines .

Ein Docker-Container besteht aus

Einem Docker-Abbild
einer Ausführungsumgebung
Einem Standardsatz von Anweisungen

Das Konzept ist von den Schiffscontainern abgeleitet, die einen Standard für den weltweiten Versand von Waren definieren. OCI definiert einen Standard für den Versand von Software.

Image / Container-Image

Container-Images sind die Grundlage von Containern. Ein Image ist eine geordnete Sammlung von Dateisystemänderungen und den Ausführungsparametern zur Verwendung innerhalb einer Container-Laufzeit. Ein Image enthält in der Regel eine Vereinigung von übereinander gestapelten Dateisystemen.

Container Registry

Container Registry ist ein zentraler Speicherort für die fertig gebauten Images.

Repository

Ein Repository ist ein Satz von Container-Images (meist derselben Software). Ein Repository kann freigegeben werden, indem es auf einen Registry-Server gepusht wird. Die verschiedenen Images im Repository können mit Tags (Versionen) gekennzeichnet werden.

Weiterführende Links und Ressourcen

Mon, 01 Jan 0001 00:00:00 +0000

Projektressourcen

Weiterführende Ressourcen

Container / Docker für Einsteiger*innen am eigenen Laptop

Tue, 02 Jun 2026 07:00:00 +0100

Die eigene Software ist oft von externen Services abhängig. Diese können auf dem Entwicklungsrechner installiert werden. Noch einfacher, sicherer und schneller geht es aber mit den Containern. Lernen Sie in diesem Kurs die Grundlagen von Docker, Container, Images, Orchestrierung, Docker Compose, die Sie für Ihren eigenen Entwickleralltag benötigen.

Voraussetzung:

sicherer Umgang mit einem PC sowie
grundlegende Programmierkenntnisse.

Hinweis

Bitte bringen Sie Ihren Laptop oder MacGerät inkl. Ladegerät mit.

Nächster Termin an der MVHS

2x, 12.12.2026 - 13.12.2026
1. Sa. 12.12.2026, 10:00 – 15:00 Uhr
2. So. 13.12.2026, 10:00 – 15:00 Uhr

Container / Docker für Einsteiger*innen am eigenen Laptop

Sun, 01 Feb 2026 07:00:00 +0100

Voraussetzung:

sicherer Umgang mit einem PC sowie
grundlegende Programmierkenntnisse.

Hinweis

Bitte bringen Sie Ihren Laptop oder MacGerät inkl. Ladegerät mit.

Nächster Termin an der MVHS

2x, 13.06.2026 - 14.06.2026
1. Sa. 13.06.2026, 10:00 – 15:00 Uhr
2. So. 14.06.2026, 10:00 – 15:00 Uhr

Workshop: Container / Docker für Einsteiger*innen

Sat, 07 Dec 2024 00:00:00 +0000

Programmierenn Sie gerne? Nervt es Sie immer wieder, die notwendigen Services (wie Datenbanken) auf Ihrem System immer in der richtigen Version pflegen zu müssen? Sind Sie es leid, dass diese Services die Ressourcen Ihres Rechners belegen, auch wenn Sie diese gar nicht benötigen?

Lernen Sie, wie Sie mit Containern diese Probleme auf eine einfache Art lösen können. Starten Sie die notwendigen Services als Container wann Sie diese benötigen (in der geforderten Version) und stoppen diese zu jeder Zeit.

Hinweis

Die Code-Beispiele werden für Linux/macOS in Bash und unter Windows in PowerShell (Core) abgebildet. Sind die erforderlichen Befehle gleich, werden diese nur in Bash angezeigt. Die Anweisungen können 1:1 in PowerShell eingegeben werden.

Die sind Blazor Server Projekte, um unterschiedliche Szenarien repräsentieren zu können. Ich nutze diesen Technologie-Stack vor allem, weil ich mich hier am wohlsten fühle. .Net ist keine Voraussetzung, um Container nutzen zu können. Zum Ausführen von diesen Projekten ist installiertes erforderlich.

Installation von Docker Desktop

Container / Docker für Einsteiger*innen

Sat, 07 Dec 2024 00:00:00 +0000

Container / Docker für Einsteiger*innen

Dipl. Ing. (FH) Eugen Richter

Themen

Container vs. VM vs. Bare Metall

Container / Image

Orchestrierung

Container Hubs / Registries

Docker Geschichte

Weiterführende Themen

Workshop

Container vs. VM vs. Bare Metall

Bare Metall

Pro
- Alle Ressourcen der Hardware nutzbar
- Wiederverwendung von Abhängigkeiten
- Schnelle App Startzeiten
Kontra
- Auslastung der Hardware mit einer Applikation
- HW-Größe basierend am max. Auslastung
- App Abhängigkeiten
- Skalierung (neu HW + Installation)

Virtualisierung

Pro
- Abhängigkeiten können in der VM isoliert werden
- Unterschiedliche Betriebssysteme pro VM möglich
- Vorlagen / Images möglich (für Skalierung)
Kontra
- Höher Ressourcenverbrauch pro VM (eigenständiges Betriebssystem)
- Lange Startzeiten (Hochfahren der VM)

Containerisierung

Pro
- Sehr schnelle Startzeit
- Kein Verbrauch “unnötiger” Ressourcen
- Isolierung der Abhängigkeiten pro Container
- Skalierung
Kontra
- Nur Betriebssystem des Host
- Nicht alle “Features” der HW können direkt genutzt werden

Container / Images

Image

Bauplan für einen Container
Beschreibt die Software und ihre Abhängigkeiten
Ist ein Schichten-Dateisystem
Jede Schicht entspricht einer Änderung an der vorherigen Schicht

Container

Instanz, die aus einem Image erstellt wurde
Letzter Layer im Dateisystem ist beschreibbar
“Die” laufende Applikation
Kann beim Start parametrisiert werden

Orchestrierung

Problem

Abhängigkeiten zwischen Containern

Startreihenfolge

Lösung

Orchestrierung

Docker Compose

Kubernetes

Hubs / Registries

Speicherorte für veröffentlichte Images mit Versionen und meistens einer Beschreibung, wie das Image zu nutzen ist.

Bekannteste Anbieter von Container Repositories

Docker Hub - hub.docker.com

Quay.io - quay.io

GitHub Container Registry

Azure Container Registry

Google Container Registry

Amazon Elastic Container Registry

Docker - Geschichte

2008: cgroup kommen in Linux an

2008: Gründung als dotCloud

2013: Ankündigung von Docker (mit RedHat)

2014: Partnerschaft mit Microsoft

2015: OCI Projekt

2015: Kubernetes 1.0

2018: GKS, AKS, EKS (Managed Kubernetes)

2021: Änderung der Linzenzierung

Weiterführende Themen

Kubernetes (Orchestrierung)

OCI - Open Container Initiative

CNCF - Cloud Native Computing Foundation

Alpine Linux

UNRAID (NAS auf Container Basis)

WebAssembly

Workshop

Installation

Starten von vorhandenen Images

Nutzung als Entwickler (Beispiel Applikation)

Docker Compose (Orchestrierung)

Nutzung als Entwickler (Beispiel Applikation)

Eigenen Code als Image verpacken

Multi Step Builds

Veröffentlichung der Images

Dev / Test Container