MVHS |

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

Installation von Git

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

# Linux / macOS
kurse$ git --version
git version 2.33.0

# Windows
PS kurse> git --version
git version 2.33.0.windows.2

Wird statt einer Versionsangabe eine Fehlermeldung angezeigt, dass das git Befehl nicht gefunden wurde, muss git zuerst installiert werden.

Der Befehl “git” ist entweder falsch geschrieben oder konnte nicht gefunden werden.

Folgen Sie dazu der Installationsanleitung für Ihr Betriebssystem von der offiziellen .

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

Initialisierung eines lokalen Repositorys

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

Hinweis

Als ein Repository bei git wird ein Ordner bezeichnet, der unter Versionskontrolle von git steht.

Ordner anlegen

Als erstes legen wir einen Ordner an, den wir gleich unter die Versionsverwaltung stellen wollen. Aktuell werden wir es mit einem leeren Ordner tun, das Gleiche lässt sich auch mit einem vorhandenen Ordner erledigen, wenn Sie desen Inhalt versionieren wollen.

Wechseln Sie in den neu erzeugten Ordner.

# Linux / macOS
src$ mkdir repo_1
src$ ls -la
repo_1
src$ cd repo_1

# Windows (Power Shell Core)
PS src> New-Item repo_1 -Type Directory

 Directory: C:\Users\kurse\src

Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 15.09.2021 08:05 repo_1
PS src> cd repo_1

Repository initialisieren

Nun initialisieren wir ein git Repository mit dem init¹ Befehl von git.

# Linux / macOS
repo_1$ git init
Initialized empty Git repository in /Users/kurse/src/repo_1/.git/
$ ls -la
total 0
drwxrwxrwx 1 kurse kurse 4096 Sep 15 08:10 .
drwxrwxrwx 1 kurse kurse 4096 Sep 15 08:05 ..
drwxrwxrwx 1 kurse kurse 4096 Sep 15 08:10 .git

# Windows (Power Shell Core)
PS repo_1> git init
Initialized empty Git repository in C:/Users/kurse/src/repo_1/.git/
PS repo_1> Get-ChildItem . -Force

 Directory: C:\Users\kurse\src\repo_1

Mode LastWriteTime Length Name
---- ------------- ------ ----
d--h- 15.09.2021 08:12 .git

Dabei wird das Verzeichnis unter Versionskontrolle gestellt. Das ist an dem versteckten Ordner .git gut zu sehen. In diesem werden alle Informationen zu den Versionen gespeichert.

Prüfen des aktuellen Zustandes von Repository

Den aktuellen Zustand des Ordners, aus Sicht von git, können wir mit dem Befehl status² abrufen. Dieser zeigt, ob neue Dateien zu der Versionsverwaltung hinzugefügt werden können, ob geänderte Dateien vorliegen usw.

# Linux / macOS
repo_1$ git status
On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

# Windows
PS repo_1> git status
On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Bei einem neu angelegten Repository ist der Status sauber. Es sind ja keine Dateien versioniert und es liegen keine zum Versionieren vor.

↩︎
↩︎

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

Eine Datei versionieren

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

Legen wir eine neue Text-Datei an, die wir versionieren möchten.

# Linux / macOS
repo_1$ touch kapitel_1.txt

# Windows
PS repo_1> New-Item kapitel_1.txt

 Directory: C:\Users\kurs\src\repo_1

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 21.09.2021 07:32 0 kapitel_1.txt

Wenn wir nun den Status des Repositorys aufrufen, erhalten wir eine ganz andere Meldung.

repo_1$ git status
On branch main

No commits yet

Untracked files:
 (use "git add <file>..." to include in what will be committed)
 kapitel_1.txt

nothing added to commit but untracked files present (use "git add" to track)

Datei zum Staging-Bereich hinzufügen

Die Meldung besagt, dass in unserem Ordner eine neue, noch nicht versionierte (untracked) Datei liegt. Git gibt zugleich auch den Tipp, wie diese Datei unter Versionskontrolle genommen werden kann. Wir folgen einfach dem Tipp und nutzen den add¹ Befehl. Mit status prüfen wir wieder, welche Auswirkung das auf unser Repository hat.

repo_1$ git add kapitel_1.txt
repo_1$ git status
On branch main

No commits yet

Changes to be committed:
 (use "git rm --cached <file>..." to unstage)
 new file: kapitel_1.txt

Nun besagt die Meldung, dass wir Änderungen haben, die auf ein Commit warten.

Änderungen festschreiben

Hinweis

Commit bei git ist eine Aktion, mit der der aktuelle Stand als Version gespeichert wird. Zu einem Commit müssen die betroffenen Dateien vorgemerkt werden. Dieses Vormerken wird auch Staging genannt.

Nun schreiben wir die Version mit einen commit² endgültig fest. Dabei ist es bei git auch immer notwendig eine Nachricht mitzugeben (Parameter -m), die die aktuelle Version beschreibt. Eine gute Dokumentation, wie eine Commit-Nachricht aussehen könnte, finden Sie unter .

Wird die Nachricht (Message) nicht direkt mit angegeben, startet git automatisch vorkonfigurierten Text-Editor, um die Nachricht in diesem einzugeben. Das ist sehr praktisch, wenn man mehrzeilige Nachrichten an die Version anhängen möchte.

repo_1$ git commit -m "feat: Start des ersten Kapitels"

*** Please tell me who you are.

Run

 git config --global user.email "you@example.com"
 git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for <kurse@pc.localdomain>) not allowed

Benutzer in git einrichten

Warnung

Nutzten Sie git zum ersten Mal, erscheint eine Fehlermeldung, dass git uns noch nicht kennt. Git benötigt immer den Namen und die E-Mail-Adresse des Benutzers, um diese in der Versionshistorie zu nutzen. In der Fehlermeldung steht auch, wie der Fehler korrigiert werden kann.

repo_1$ git config --global user.email "kurse@richter.consulting"
repo_1$ git config --global user.name "Eugen [WebDucer] Richter"
repo_1$ git commit -m "feat: Start des ersten Kapitels"
[main (root-commit) e12fb6d] feat: Start des ersten Kapitels
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 kapitel_1.txt

Jetzt haben wir unseren ersten Commit mit git erstellt. Mit git status kann nachgeprüft werden, ob das Repository nun wieder in einen sauberen Zustand ist.

Allgemeiner Ablauf

Der allgemeine Ablauf beim Arbeiten mit git sieht damit wie folgt aus:

Anlegen oder ändern der Dateien, die versioniert werden sollen.
Hinzufügen der neuen oder geänderten Dateien über git add dateiA dateiB.
Festschreiben der neuen Version mit git commit -m "Warum wurde etwas geändert".

↩︎
↩︎

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

Historie anzeigen lassen

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

Die Historie eines Repositorys kann über den Befehl log¹ angesehen werden. Dieser gibt eine sehr ausführliche Information über alle gemachten Commits. Der Befehl hat viele Parameter und kann sehr gut angepasst werden (was wir später noch nutzen werden).

repo_1$ git log
commit e12fb6dc6e0b69af839d95efff837ecebf7e443f (HEAD -> main)
Author: Eugen [WebDucer] Richter <kurse@richter.consulting>
Date: Tue Sep 21 08:06:48 2021 +0200

 feat: Start des ersten Kapitels

Verkürzte Anzeige der Historie

Wenn die Anzahl der Commits steigt, wird die ausführliche Ausgabe der Historie sehr unübersichtlich. Mit dem Parameter --pretty=oneline² kann die Ausgabe pro Commit auf eine Zeile reduziert werden.

repo_1$ git log --pretty=oneline
e12fb6dc6e0b69af839d95efff837ecebf7e443f (HEAD -> main) feat: Start des ersten Kapitels

Mit den Parametern --oneline --decorate wird die Ausgabe noch kürzer. Dabei wird der Commit-Hash auf 7 Zeichen gekürzt (statt 32). Die Kürzung ist für die meisten Repositorys unproblematisch und weiterhin eindeutig.

repo_1$ git log --oneline --decorate
e12fb6d (HEAD -> main) feat: Start des ersten Kapitels

Aliases

Da man die langen Befehle mit vielen Parametern nicht jedes Mal aus dem Gedächtnis herauskramen will, bietet git die Möglichkeit, diese mit einem Alias (alternativen Namen) zu versehen. Wir vergeben für unsere Log-Anzeige ein Alias³ pl (für pretty log).

repo_1$ git config --global alias.pl 'log --graph --oneline --decorate --all'

Das Alias wir dabei in der globalen (--global) Konfiguration von git gespeichert.

log: git Befehl, in unserem Fall log
--graph: Darstellung des Logs als Graph (dazu später mehr, wenn wir mehr als ein branch haben)
--oneline: Einzeilige Darstellung
--decorate: Hübsche Darstellung der Zeile
--all: Alle Branches anzeigen, nicht nur das aktuelle (später mehr dazu)

Nun können wir mit dem einfachen git pl das Log mit vielen Parametern einfach aufrufen.

repo_1$ git pl
* e12fb6d (HEAD -> main) feat: Start des ersten Kapitels

↩︎
↩︎
↩︎

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

Ausnahmen für Versionierung

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

Es kommt oft vor, das in dem Ordner nicht nur Dateien liegen, die versioniert werden sollen, sondern auch andere (eventuell temporäre) Dateien. Bei der Software-Entwicklung sind es zum Beispiel die kompilierten Binärdateien, oder auch sehr viele temporäre. Auch Office hinterlegt oft temporäre Dateien, wenn man das Original bearbeitet.

Legen wir eine temporäre Datei an, die wir nicht in der Versionsverwaltung haben wollen, zum Beispiel mit dem Namen kapitel_1.~ und kapitel_1.bak.

# Linux / macOS
repo_1$ touch kapitel_1.~ kapitel_1.bak
repo_1$ ls
kapitel_1.bak kapitel_1.txt kapitel_1.~

# Windows
PS repo_1> New-Item -ItemType File -Path "kapitel_1.~", "kapitel_1.bak"

 Directory: C:\Users\kurs\src\repo_1

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 28.10.2021 08:50 0 kapitel_1.~
-a--- 28.10.2021 08:50 0 kapitel_1.bak

Wenn wir jetzt git status aufrufen, sehen wir zwei noch nicht versionierte Dateien. Das wollen wir eigentlich nicht sehen, da diese Dateien uns nicht interessieren.

repo_1$ git status
On branch main
Untracked files:
 (use "git add <file>..." to include in what will be committed)
 kapitel_1.bak
 kapitel_1.~

nothing added to commit but untracked files present (use "git add" to track)

Globale Ausnahmen (Betriebssystem)

Git bietet für solche Dateien zwei Orte, in denen die Ausnahmen definiert werden können. Wir können die Ausnahmen global (auf Benutzerebene) definieren, oder pro Repository.

Um eine neue Ausnahmedatei für den Benutzer anzulegen, geben Sie Folgendes ein:

# Linux / macOS
repo_1$ git config --global core.excludesfile ~/.gitignore_global
repo_1$ touch ~/.gitignore_global

# Winfows
PS repo_1> git config --global core.excludesfile "$env:USERPROFILE\.gitignore_global"
PS repo_1> New-Item "$env:USERPROFILE\.gitignore_global"

 Directory: C:\Users\kurs

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 11.11.2021 19:47 0 .gitignore_global

Nun kann in die betreffende Datei .gitignore_global¹ die Liste der globalen Ausnahmen gepflegt werden. Fügen Sie in unserem Fall einfach Folgendes als erste Zeilen in die Datei ein:

# Ignore global backup files
*.bak

Die Zeilen, die mit # Anfangen, werden als Kommentare ausgewertet.

Eine sehr gute Übersicht über übliche Ausnahmen liefert die Seite . Im Verzeichnis Global sind dabei die globalen Ausnahmen für unterschiedliche Betriebssysteme (z.B. bei macOS ist es üblich die Datei .DS_Store auszufiltern, oder unter Windows Thumbs.db).

Pro Zeile in der Datei wird eine Ausnahme definiert, die auch Globings (Platzhalter) erlaubt.

*: Beliebiges Zeichen, beliebige Anzahl
**: Beliebige Unterverzeichnisse
?: Ein Zeichen
[Aa]: Regex für kleines/großes A
!abc: Mit ! kann die Ausnahme umgekehrt werden (zum Beispiel alles im Ordner XYZ nicht versionieren, aber die Datei abc.md)

Nach dem Hinzufügen der oberen Ausnahme können wir wieder mit git status unsere Bemühungen überprüfen.

repo_1$ git status
On branch main
Untracked files:
 (use "git add <file>..." to include in what will be committed)
 kapitel_1.~

nothing added to commit but untracked files present (use "git add" to track)

Nun wir die Datei kapitel_1.bak nicht mehr angezeigt.

Ausnahmen im Repository

Die Ausnahmen für ein konkretes Repository werden in der Datei .gitignore² definiert. Meistens wird diese Datei in die Versionsverwaltung aufgenommen, da diese Ausnahmen das konkrete Projekt betreffen und für alle Beteiligten relevant sind.

Die Datei .gitignore gilt dabei für das aktuelle Verzeichnis und alle Unterverzeichnisse. Unterverzeichnisse können dabei eigene Ausnahmen in eigenen .gitignore Dateien definieren, die die Ausnahmen aus den übergeordneten Verzeichnissen ergänzen.

Legen Sie nun die .gitignore Datei im Wurzelverzeichnis von unserem Repository.

# Linux / macOS
repo_1$ touch .gitignore

# Windows
PS repo_1> New-Item .gitignore

 Directory: C:\Users\kurs\src\repo_1

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 11.11.2021 19:53 0 .gitignore

Fügen Sie in die neue Ausnahmedatei folgende Zeilen, um unsere .~ Datei von der Versionsverwaltung auszuschließen.

# Exclude temporal files
*.~

Mit git status sehen wir nun, dass auch die .~ Datei in der Auflistung nicht mehr auftaucht, dafür aber unsere neue .gitignore Ausnahmedatei. Diese sollen wir versionieren.

repo_1$ git status
On branch main
Untracked files:
 (use "git add <file>..." to include in what will be committed)
 .gitignore

nothing added to commit but untracked files present (use "git add" to track)

repo_1$ git add .gitignore
repo_1$ git commit -m "Add repo ignore file for temp files"
[main c3b4e8b] Add repo ignore file for temp files
 1 file changed, 1 insertion(+)
 create mode 100644 .gitignore

Auf der bereits erwähnten finden Sie eine Sammlung von Ausnahmedateien für unterschiedliche Projekte (Programmiersprachen / Tools). Sie müssen damit die Ausnahmelisten nicht selbst erstellen, sondern von dieser Seite die vorhandenen als Ausgangsbasis für eigene Projekte nutzen.

↩︎
↩︎

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

Änderungen zwischen Version anzeigen

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

Wenn man mit der Zeit eine Versionshistorie aufgebaut hat, kommt der Zeitpunkt, wenn man zwei Versionen einer Datei miteinander vergleichen möchte. Dazu bietet git den Befehl diff¹ an, der mit einigen Parametern gesteuert werden kann.

Legen wir zuerst ein paar Commits mit Änderungen an, damit etwas zum Anschauen haben. Aktuell ist unsere Datei kapitel_1.txt leer.

Commit 1
- Inhalt
```
# Kapitel 1
Es war ein Mal...
```
- Message: Kapitel 1 der Geschichte starten
Commit 2
- Inhalt
```
Viele Jahre später ...
```
- Message: Fortsetzung in vielen Jahren

Commit 3

Inhalt

Nach 20 Jahren treffen sich die Freunde wieder.
Das Kaffee, dass damals an diesem Platz stand, existiert nicht mehr.

Message: Treffen nach 20 Jahren

Am Ende sollte der Inhalt der Datei wie folgt aussehen.

# Kapitel 1
Es war ein Mal...
Viele Jahre später ...
Nach 20 Jahren treffen sich die Freunde wieder.
Das Kaffee, dass damals an diesem Platz stand, existiert nicht mehr.

Und die Historie mit unserem Alias pl sollte in etwa wie folgt aussehen (die Hashwerte sind bei Ihnen natürlich ganz anders).

repo_1$ git pl
* e4c2672 (HEAD -> main) Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

Aktuelle Änderungen zeigen

Ruft man den Befehl git diff <Dateiname> ohne weitere Parameter auf, zeigt dieses die aktuellen Änderungen an, also was sich seit dem letzTen Commit in der Datei geändert hat. Rufen Sie es mit einer Datei, die keine Änderungen hat, gibt der Befehl nichts aus.

Ohne einen Dateinamen werden die Änderungen vom kompletten Repository angezeigt. Die Anzeige erfolgt dabei im DIFF Format. Die neuen Zeilen werden über ein + vor der Zeile angezeigt, entferne mit einem -.

Ändern Sie nun unsere Datei kapitel_1.txt wie folgt, ohne die Änderungen in die Versionsverwaltung festzuschreiben:

Entfernen Sie die Zeile 3 (Viele Jahre später ...)

Fügen Sie nach der Zeile 3 folgendes ein

Sie verabredeten sich in ihrem alten Kaffee zu treffen,
dass sie immer nach der Schule besucht haben.

Der text sollte nun wie folgt aussehen:

# Kapitel 1
Es war ein Mal...
Nach 20 Jahren treffen sich die Freunde wieder.
Sie verabredeten sich in ihrem alten Kaffee zu treffen,
dass sie immer nach der Schule besucht haben.
Das Kaffee, dass damals an diesem Platz stand, existiert nicht mehr.

Rufen Sie nun den Befehl git diff auf (mit oder ohne den Dateinamen).

repo_1$ git diff kapitel_1.txt
diff --git a/kapitel_1.txt b/kapitel_1.txt
index 20f47a6..8cc2eca 100644
--- a/kapitel_1.txt
+++ b/kapitel_1.txt
@@ -1,5 +1,6 @@
 # Kapitel 1
 Es war ein Mal...
-Viele Jahre später ...
 Nach 20 Jahren treffen sich die Freunde wieder.
+Sie verabredeten sich in ihrem alten Kaffee zu treffen,
+dass sie immer nach der Schule besucht haben.
 Das Kaffee, dass damals an diesem Platz stand, existiert nicht mehr.
\ No newline at end of file

Wir sehen hier in DIFF Format, dass eine Zeile (nach “Es war ein Mal…”) entfernt wurde, und zwei Zeilen (zwischen “Nach 20 Jahren treffen sich die Freunde wieder.” und “Das Kaffee, dass damals an diesem Platz stand, existiert nicht mehr.”) dazu gekommen sind.

Diese Anzeige zeigt den Unterschied zwischen dem letzten Commit und der aktuellen Arbeitsversion.

Unterschiede zwischen zwei Commits

Wollen wir die Datei zwischen zwei bestimmten Versionen (Commits) vergleichen, müssen wird das diff Commando mit wenigen Parametern erweitern. Die sehr umfangreiche Liste der möglichen Parameter kann mit git diff --help aufgerufen werden. Uns interessieren aktuell nur die zwei gängigsten, bei denen die zwei Anker mit angegeben werden. Ein Anker kann dabei ein Commit, ein Branch oder ein Tag sein.

Als Erstes können wir explizit zwei Commit angeben, die wir miteinander vergleichen wollen. Die Commit-Hashes können wir sehr einfach mit unserem git pl Alias anzeigen lassen.

repo_1$ git pl
* e4c2672 (HEAD -> main) Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels
repo_1$ git diff c3b4e8b bd4b2df
diff --git a/kapitel_1.txt b/kapitel_1.txt
index e69de29..61a6fe5 100644
--- a/kapitel_1.txt
+++ b/kapitel_1.txt
@@ -0,0 +1,3 @@
+# Kapitel 1^M
+Es war ein Mal...^M
+Viele Jahre später ...
\ No newline at end of file

`HEAD` Anker für `diff` nutzen

Wenn Sie in der Historie nur wenige Commits zurückgehen wollen, lässt sich das auch mit dem HEAD Zeiger erledigen. HEAD steht immer auf dem letzten Commit. Mit der ^ und ~x Syntax kann man vom HEAD aus 1 oder x Commits zurückgehen. Das obere Ergebnis erreichen wir also auch mit dem folgenden Befehl (ohne die Commit-Hashes zu kennen).

repo_1$ git diff HEAD~3 HEAD^ kapitel_1.txt
diff --git a/kapitel_1.txt b/kapitel_1.txt
index e69de29..61a6fe5 100644
--- a/kapitel_1.txt
+++ b/kapitel_1.txt
@@ -0,0 +1,3 @@
+# Kapitel 1^M
+Es war ein Mal...^M
+Viele Jahre später ...
\ No newline at end of file

Reihenfolge ist wichtig

Passen Sie auf die Reihenfolge auf. Im Normalfall interessiert Sie, was seit einem bestimmten Commit passiert ist, die Reihenfolge der Parameter ist also älterer Commit und dann neuerer. Wenn Sie die Parameter vertauschen, erhalten Sie die Ansicht, was müsste gemacht werden, um den ursprünglichen Zustand wieder zu erhalten.

repo_1$ git diff HEAD^ HEAD~3 kapitel_1.txt
diff --git a/kapitel_1.txt b/kapitel_1.txt
index 61a6fe5..e69de29 100644
--- a/kapitel_1.txt
+++ b/kapitel_1.txt
@@ -1,3 +0,0 @@
-# Kapitel 1
-Es war ein Mal...
-Viele Jahre später ...
\ No newline at end of file

Schreiben Sie nun die letzte, noch nicht festgeschriebene Änderung an unserer Datei fest.

Hinweis

Damit wir nicht jedes Mal zwei Befehle ausführen müssen (add + commit), können wir beides kombinieren. Dabei werden alle geänderten / gelöschten Dateien in das Stating-Bereich übernommen und in den Commit aufgenommen. Neue Dateien (die noch nicht unter Versionsverwaltung stehen) werden dabei nicht berücksichtigt. Diese müssen zuerst mit git add hinzugefügt werden.

/repo_1$ git commit -a -m "Korrekturen am Kapitel 1"
[main 027c2f3] Korrekturen am Kapitel 1
 1 file changed, 2 insertions(+), 1 deletion(-)

Der Parameter -a (oder auch in der Langschreibweise --all) führt zu der gewollten Aktion.

↩︎

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

Verzweigungen (Branches) anlegen

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

Früher oder später braucht man mehr als nur eine lineare Entwicklung auf einen einzigen Zweig. Der einfachste Ansatz dazu, ist mit main und develop Zweigen zu arbeiten. Dabei erfolgt auf dem develop Zweig die eigentliche Entwicklung. Auf dem main Zweig landen dann die auslieferungsfähige Versionen, die oft auch benannt werden (Tags - siehe übernächstes Kapitel).

Branches anzeigen

Verschafen wir uns zuerst die Übersicht über die aktuell im Repository vorhandenen Zweige (Branches).

repo_1$ git branch
* main

Wir haben aktuell also nur den Branch main. Mit dem * wird bei mehreren Branches immer das aktuell aktive markiert.

Hinweis

Eventuell sehen Sie statt main einen master als Brnachnamen. Das hängt davon ab, wann Sie git auf Ihrem System installiert haben. Falls Sie eine ältere Installation haben, können Sie die globale Konfiguration mit folgender Zeile umstellen:

git config --global init.defaultBranch main

Den vorhandenen master Branch können Sie auch jederzeit auf neue Konvention umstellen.

git branch -m master main

Branches anlegen

Nun legen wir einen neuen Brnach an, den wir develop nennen. Dazu wird der Befehl branch <neuer_name>¹ genutzt.

repo_1$ git branch develop
repo_1$ git branch
 develop
* main

Zum Branch wechseln

Um nun auf den neuen Branch arbeiten zu können, wecheln wir zu diesem mit dem checkout² Befehl.

repo_1$ git checkout develop
Switched to branch 'develop'
repo_1$ git branch
* develop
 main

Nun können wir auf diesem Zweig unsere Änderungen durchführen und festschreiben. Führen Sie für den nächsten Schritt nun folgende Schritte durch:

Legen Sie eine neue die Datei kapitel_2.txt an
Versionieren Sie diese

Fügen Sie folgenden Text zu der Datei:

# Kapitel 2
Nach einer durchzechten Nacht ...

Schreiben Sie die Änderung in der Historie fest
Legen Sie eine neue Datei kapitel_3.txt an, ohne diese unter Versionsverwaltung zu stellen.

Am Ende sollte die Historie (und Status) in etwa wie folgt aussehen:

repo_1$ git pl
* aac4d8b (HEAD -> develop) Nachtszene
* e6b896a Ideen zum zweiten Kapitel
* 027c2f3 (main) Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels
repo_1$ git status
On branch develop
Untracked files:
 (use "git add <file>..." to include in what will be committed)
 kapitel_3.txt

nothing added to commit but untracked files present (use "git add" to track)

Branch Verhalten

Jetzt haben wir zwei neue Dateien im Branch develop erstellt. Dabei haben wir eine davon unter die Versionsverwaltung (kapitel_2.txt). In dem Ordner liegen aktuell drei Dateien (+2 aus der Ausnahmeliste).

repo_1$ ls
kapitel_1.bak kapitel_1.txt kapitel_1.~ kapitel_2.txt kapitel_3.txt

Was passiert nun, wenn wir zurück zu main wechseln? Wie wird der Ordner danach aussehen? Versuchen Sie es aus.

repo_1$ git checkout main
Switched to branch 'main'
repo_1$ ls
kapitel_1.bak kapitel_1.txt kapitel_1.~ kapitel_3.txt

Sie haben wahrscheinlich erwartet, dass sowohl kapitel_2.txt als auch kapitel_3.txt nicht mehr da sind, da diese ja nicht in main erstellt wurden. Tatsächlich ist nur die Datei kapitel_2.txt nicht mehr da.

Das ist sehr einfach zu erklären. Git kümmert sich nur um Dateien, die unter seiner Kontrolle stehen (versioniert sind). Alle anderen Dateien werden einfach ignoriert. Genau das passiert mit kapitel_3.txt. Diese Datei steht noch nicht unter Versionskontrolle, weshalb diese von git unangetastet bleibt. Bei kapitel_2.txt ist der Fall anders. Diese steht unter Versionskontrolle. Damit weiß git, dass diese zwar im Zweig develop vorhanden ist, aber nicht in main. Aus diesem grund wird diese beim Wechsel gelöscht (oder angelegt beim Wechsel zurück).

Hinweis

Nicht versionierte Dateien sind für git unsichtbar und werden von diesem nicht angefasst.

Paralleles Arbeiten

Nun simulieren wir, dass auf beiden Branches nun gearbeitet wurde. Dazu versionieren wir die Datei kapitel_3.txt und fügen ein wenig Text hinzu.

# Kapitel 3
Nach zwei Monaten in der Versenkung ...

Das wird unsere Basis für den nächsten Kapitel, in dem wir versuchen die Branches zusammenzuführen. Am Ende sollte die Versionshistorie in etwa wie folgt aussehen:

repo_1$ git pl
* 663ea5a (HEAD -> main) Versenkung
* 63bb3f0 Kapitel 3 Plot
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

↩︎
↩︎

Änderungen eines Zweiges in ein Anderes übernehmen

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

Nach getaner Arbeit sollen die unterschiedlichen Stände der Arbeit wieder zusammengeführt werden. Dabei kann es zu 3 Konstellationen kommen:

Fast-Merge: Es wurden nur Änderungen auf neuen Branch gemacht, aber nicht auf main. Damit kann git einfach den Zeiger für main Branch auf den neuen Stand setzen. In diesem Fall spricht man von “Fast Merge”. Es wird dabei kein extra Commit erzeugt.
Merge: Beim Zusammenführen sind keine Probleme augetreten. In diesem Fall wir ein sogenannter “Merge”-Commit erstellt. Im Gegensatz zu einem normalen Commit, hat dieser Informationen zu den beiden Branches, statt nur einen.
Conflict: Beim Zusammenführen kommt es zu einem Konflikt, den git nicht selbst lösen kann. Wir müssen alle Konflikte beseitigen und das Zusammenführen abzuschließen.

Wir werden hier alle 3 Möglichkeiten durchspielen.

Fast Merge¹

Wechseln Sie zuerst auf den main-Branch, wenn noch nicht geschehen. Erstellen Sie einen neuen Branch feat_kap_4 und wechseln Sie zu diesem.

Hinweis

Da man meistens beim Erzeugen eines neuen Branches auch gleich zu diesem wechseln möchte, gibt es eine Abkürzung. Statt git branch <neuer_branch_name> und git checkout <neuer_branch_name> eingeben zu müssen, kann man auch kürzer den -b Flag nutzen: git checkout -b <neuer_branch_name> eingeben.

repo_1$ git checkout main
Already on 'main'
repo_1$ git checkout -b feat_kap_4
Switched to a new branch 'feat_kap_4'

Nun legen wir eine neue Datei an, mit Inhalt, den wir auch mehrere Commits verteilen.

# Kapitel 4
Im vierten Jahr stand der Weizen ...

Darauf folgte eine dreijährige Düre...

Am Ende sollte die Historie wie folgt aussehen:

repo_1$ git pl
* 10eabc1 (HEAD -> feat_kap_4) Die Düre-Jahre
* 054db53 Vierter Kapitel über...
* 663ea5a (main) Versenkung
* 63bb3f0 Kapitel 3 plot
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

Wenn man den Pfad folgt, sieht man hier sehr gut, dass main eigentlich auf demselben Pfad liegt, wie unser neuer Branch feat_kap_4. Das ist die Voraussetzung für einen “Fast-Merge”.

Wechseln wir nun zurück zu main. Anschließen führen wir die Beiden Zweige zusammen. Dazu muss man immer auf dem Branch drauf sein, in dem man den anderen Zweig integrieren will. Die Integration wird mit git merge <branch_name> durchgeführt. In der Ausgabe sollte nun sichtbar sein, dass ein “Fast-Merge” durchgeführt wurde.

repo_1$ git checkout main
Switched to branch 'main'
repo_1$ git merge feat_kap_4
Updating 663ea5a..10eabc1
Fast-forward
 kapitel_4.txt | 4 ++++
 1 file changed, 4 insertions(+)
 create mode 100644 kapitel_4.txt

Auch an dem Log ist es sichtbar, dass ein “Fast-Merge” erstellt wurde:

Es sind genauso viele Commits da, wie vorher.
Letzter Commit hat denselben Hash. D.h. dieser wurde nicht geändert.
Beide Branches, main und feat_kap_4 zeigen auf denselben Commit.

repo_1$ git pl
* 10eabc1 (HEAD -> main, feat_kap_4) Die Düre-Jahre
* 054db53 Vierter Kapitel über...
* 663ea5a Versenkung
* 63bb3f0 Kapitel 3 plot
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

Da die Zusammenführung erfolgreich war, können wir den nicht mehr benötigten Branch feat_kap_4 mit git branch -d <branch_name> löschen.

repo_1$ git branch -d feat_kap_4
Deleted branch feat_kap_4 (was 10eabc1).

Merge²

Für eine “normale” Zusammenführung haben wir auch bereits alles vorbereitet. Wir haben zwei Branches, auf denen parallel gearbeitet wurde, main und develop. Nun können wir wieder auf main wechsel, falls noch nicht der Fall ist, und develop integrieren.

repo_1$ git checkout main
Already on 'main'
repo_1$ git merge develop
Merge made by the 'ort' strategy.
 kapitel_2.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 kapitel_2.txt
repo_1$ git pl
* e779542 (HEAD -> main) Merge branch 'develop'
|\
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
* | 10eabc1 Die Düre-Jahre
* | 054db53 Vierter Kapitel über...
* | 663ea5a Versenkung
* | 63bb3f0 Kapitel 3 plot
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

An dem Log können wir sehr gut sehen, dass es dieses Mal ein neuer Commit (e779542) erzeugt wurde, der mit zwei anderen Commits (aac4d8b und 10eabc1) verbunden ist.

↩︎
↩︎

Konflikte beim Zusammenführen lösen

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

Erstellen wir für einen Konflikt zuerst einen neuen Branch.

repo_1$ git checkout -b feat_kap_5
Switched to a new branch 'feat_kap_5'

Erstellen Sie nun eine neue Datei kapitel_5.txt mit dem folgenden Inhalt und fügen Sie diese Datei zur Versionsverwaltung.

# Kapitel 5
Nach 8 stünddiger Fahrt ...

_repo_1> git commit -m "Fahrt im Zug"
[feat_kap_5 1b28574] Fahrt im Zug
 1 file changed, 2 insertions(+)
 create mode 100644 kapitel_5.txt

Jetzt ändern wir bereits vorhandene Dateien, um einige Konflikte zu provozieren. Ändern Sie die Datei kapitel_1.txt wie folgt (+-neuer Inhalt, --gelöschter Inhalt).

Es war ein Mal...
- Nach 20 Jahren treffen sich die Freunde wieder.
+ Nach langen 19 Jahren trafen sich die Freunde wieder,
+ um neue Pläne zu schmieden.
Sie verabredeten sich in ihrem alten Kaffee zu treffen,

Ändern Sie noch die Datei kapitel_4.txt wie folgt.

Im vierten Jahr stand der Weizen ...

- Darauf folgte eine dreijährige Düre...
+ Nach 3 Jahren der sehr guten Ernten kam nun die Dürre,
+ die die nächsten 8 Jahre andauern sollte.

Das Log sollte in etwa wie unten aussehen.

repo_1$ git pl
* 408a803 (HEAD -> feat_kap_5) Kapitel 4 überarbeitet
* 47c1c6d Kapitel 1 überarbeitet
* 1b28574 Fahrt im Zug
* e779542 (main) Merge branch 'develop'
|\
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
* | 10eabc1 Die Düre-Jahre
* | 054db53 Vierter Kapitel über...
* | 663ea5a Versenkung
* | 63bb3f0 Kapitel 3 plot
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

Wechseln wir nun auf den main Branch und machen mit den Änderungen weiter.

repo_1$ git checkout main
Switched to branch 'main'

Auch hier ändern wird die beiden Dateien kapitel_1.txt und kapitel_4.txt an denselben Zeilen. Zusätzlich legen wir auch einen neuen Kapitel 6 an.

- Nach 20 Jahren treffen sich die Freunde wieder.
+ Nach nicht ganz 20 Jahren treffen sich die Freunde wieder.

- Darauf folgte eine dreijährige Düre...
+ Darauf folgte eine achtjährige Dürre...

Vor dem Zusammenführena sollte das Log nun wie folgt aussehen.

repo_1$ git pl
* 618450e (HEAD -> main) Kapitel 6 gestartet
* 54a8d9a Kapitel 4 überarbeitet
* 0b1ad44 Kapitel 1 ausgearbeitet
| * 408a803 (feat_kap_5) Kapitel 4 überarbeitet
| * 47c1c6d Kapitel 1 überarbeitet
| * 1b28574 Fahrt im Zug
|/
* e779542 Merge branch 'develop'
|\
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
* | 10eabc1 Die Düre-Jahre
* | 054db53 Vierter Kapitel über...
* | 663ea5a Versenkung
* | 63bb3f0 Kapitel 3 plot
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

Versuchen Sie nun die Zusammenführung. Diese sollte nun scheitern, da git nicht in der Lage ist, die Konflikte zu lösen. Die Änderungen sind auf beiden Branches in denselben Zeilen. Wir müssen die Konflikte manuell lösen.

repo_1$ git merge feat_kap_5
Auto-merging kapitel_1.txt
CONFLICT (content): Merge conflict in kapitel_1.txt
Auto-merging kapitel_4.txt
CONFLICT (content): Merge conflict in kapitel_4.txt
Automatic merge failed; fix conflicts and then commit the result.

Übernahme einer der Versionen¹

Der main Brnach befindet sich wegen dem Konflikt nun in einem “Merge” Status. Mit git status können wir immer den aktuellen Stand bei Konfliktlösung sehen.

repo_1$ git status
On branch main
You have unmerged paths.
 (fix conflicts and run "git commit")
 (use "git merge --abort" to abort the merge)

Changes to be committed:
 new file: kapitel_5.txt

Unmerged paths:
 (use "git add <file>..." to mark resolution)
 both modified: kapitel_1.txt
 both modified: kapitel_4.txt

Bei dem Konflikt im Kapitel 1 möchten wir einfach die Änderungen aus dem Branch feat_kap_4 übernehmen. Dazu nutzen wir den checkout Befehl mit dem --theirs oder --ours Parameter und dem Dateinamen.

--theirs: Es wird die Version aus dem anderen Branch genommen. Da wir auf main sind, ist es die Version aus Branch feat_kap_5.
--ours: Es wird unsere Version genommen, also aus dem main Branch.

Nach dem Auschecken der gewollten Version muss die Lösung des Konfliktes mit git add, beendet werden.

repo_1$ git checkout --theirs -- kapitel_1.txt
repo_1$ git add kapitel_1.txt
repo_1$ git status
On branch main
You have unmerged paths.
 (fix conflicts and run "git commit")
 (use "git merge --abort" to abort the merge)

Changes to be committed:
 modified: kapitel_1.txt
 new file: kapitel_5.txt

Unmerged paths:
 (use "git add <file>..." to mark resolution)
 both modified: kapitel_4.txt

Manuelle Korrekturen

Nun haben wir noch ein Konflikt, in der Datei kapitel_4.txt. Diesen Konflikt möchten wir manuell lösen, da wir Änderungen aus beiden Branches kombinieren möchten. Aktuell sieht die Datei wie folgt aus:

# Kapitel 4
Im vierten Jahr stand der Weizen ...

<<<<<<< HEAD
Darauf folgte eine achtjährige Düre...
=======
Nach 3 Jahren der sehr guten Ernten, kam nun die Dürre,
die die nächsten 8 Jahre andauern sollte.
>>>>>>> feat_kap_5

<<<<<<< HEAD: Markierung für den Start des Bereiches mit den Änderungen aus dem aktuellen Branch.
=======: Markierung zur Trennung zwischen den Änderungen aus den beiden Brnaches.
>>>>>>> feat_kap_5: Markierung zum Ende der Änderungen aus dem anderen Branch.

Die Datei können wir nun manuell bearbeiten und in den Zustand bringen, den wir haben möchten. Die Markierungen sollen am Ende alle entfernt werden.

# Kapitel 4
Im vierten Jahr stand der Weizen ...

Darauf folgte eine achtjährige Dürre...
Die die nächsten 8 Jahre andauern sollte.

Auch die Lösung von diesem Konflikt muss mit git add beendet werden. Der gesammte Merge wird dann über ein git commit abgeschlossen.

repo_1$ git add kapitel_4.txt
repo_1$ git status
On branch main
All conflicts fixed but you are still merging.
 (use "git commit" to conclude merge)

Changes to be committed:
 modified: kapitel_1.txt
 modified: kapitel_4.txt
 new file: kapitel_5.txt
repo_1$ git commit -m "Merge branch 'feat_kap_5'"
[main 7a000b4] Merge branch 'feat_kap_5'

Die Historie sollte nun unsere erfolgreiche Zusammenführung anzeigen.

repo_1$ git pl
* 7a000b4 (HEAD -> main) Merge branch 'feat_kap_5'
|\
| * 408a803 (feat_kap_5) Kapitel 4 überarbeitet
| * 47c1c6d Kapitel 1 überarbeitet
| * 1b28574 Fahrt im Zug
* | 618450e Kapitel 6 gestartet
* | 54a8d9a Kapitel 4 überarbeitet
* | 0b1ad44 Kapitel 1 ausgearbeitet
|/
* e779542 Merge branch 'develop'
|\
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
* | 10eabc1 Die Düre-Jahre
* | 054db53 Vierter Kapitel über...
* | 663ea5a Versenkung
* | 63bb3f0 Kapitel 3 plot
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

↩︎

Rebase: Verzweigung auf neue Basis setzen

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

Als Alternative für ein merge, kann auch ein rebase¹ gemacht werden. Die Unterschiede schauen wir uns jetzt an.

Was ist ein `rebase`?

Git Rebase ist eine Methode, um die Commit-Historie zu verändern und zu bereinigen. Im Gegensatz zu git merge, der zwei Branches zusammenführt und einen neuen Merge-Commit erstellt, sortiert git rebase die Commits neu und wendet sie in linearer Folge an, was eine sauberere Projekthistorie erzeugt.

Ablauf bei einem `rebase`

Bei einem Rebase nimmt Git alle Commits aus deinem aktuellen Branch (z.B. feature-branch) und wendet sie erneut auf einen anderen Branch (z.B. main) an. Dies geschieht wie folgt:

Git identifiziert den gemeinsamen Vorfahren-Commit beider Branches
Git speichert temporäre Kopien der Änderungen jedes Commits im Feature-Branch
Der Feature-Branch wird auf den Ziel-Branch (main) zurückgesetzt
Die gespeicherten Änderungen werden einzeln als neue Commits auf den Ziel-Branch angewendet (die Historie ändert sich damit)

Graph für git merge

Git Graph vor dem Rebase

Git Graph nach dem Rebase

Einen `rebase` durchführen

Um en rebase zu erstellen, sollten wir vorher Änderungen auf zwei Verzweigungen erstellen, so dass ein merge nicht mehr durch ein “fast forward” durchgeführt werden kann.

Erstellen wir für Rebase zuerst einen neuen Branch.

repo_1$ git checkout -b feat_kap_7
Switched to a new branch 'feat_kap_7'

Erstellen Sie nun eine neue Daten kapitel_7.txt mit folgenden Inhalt und fügen Sie diese Datei zur Versionsverwaltung hinzu.

Fügen Sie folgenden Inhalt der Datei hinzu und schreiben Sie die Version fest.

# Kapitel 7
Der Ausgang der Geschichte wird angepasst ...

Wechseln Sie nun zurück zu dem main Branch, um auch hier einige Änderungen vorzunehmen.

repo_1$ git checkout main
Switched to branch 'main'

Machen Sie nun folgende Änderungen in der Datei kapitel_6.txt.

# Kapitel 6
Und es wurde endlich besser...

Die Historie sieht nun wie folgt aus (gekürzt):

repo_1$ git pl
* cf10f7f (HEAD -> main) Besser
| * 67f77fa (feat_kap_7) Neue Geschichte
| * 9a14335 Start mit Kapitel 7
|/
* 4a8d01e Merge branch 'feat_kap_5'
|\ 
| * 654fae0 Kapitel 4 überarbeitet
| * a7d8ad7 Kapitel 1 überarbeitet
| * 602f965 Fahrt im Zug
* | a915c82 Kapitel 6 gestartet
* | 4893d66 Kapitel 4 überarbeitet
* | 401162d Kapitel 1 ausgearbeitet
|/
* ae2918a Merge branch 'develop'

An den Graphen sehen wir, dass hier ein Merge zu keinem “Fast Merge” führen würde (keine lineare Historie), sondern einen “Merge”-Commit (wie bei der Zusammenführung des feat_kap_5 Branches). Das können wir nun mit einen Rebase verhindern. Wechseln Sie zuerst auf den feat_kap_7 branch. Dieser soll nun neue “Basis” bekommen.

repo_1$ git checkout feat_kap_7
Switched to branch 'feat_kap_7'

Nun führen wir ein Rebase auf diesem Branch durch. D.h. der Branch bekommt eine neue Basis. Aktuell liegt diese auf dem Commit Merge branch 'feat_kap_5'.

git rebase main
Successfully rebased and updated refs/heads/feat_kap_7.

In dem Graphen sehen wir nun, dass die Basis sich von Merge branch 'feat_kap_5' zu Besser verschoben hat.

repo_1$ git pl
* 874e90c (HEAD -> feat_kap_7) Neue Geschichte
* 71c03a0 Start mit Kapitel 7
* cf10f7f (main) Besser
* 4a8d01e (origin/main) Merge branch 'feat_kap_5'
|\ 
| * 654fae0 Kapitel 4 überarbeitet
| * a7d8ad7 Kapitel 1 überarbeitet
| * 602f965 Fahrt im Zug
* | a915c82 Kapitel 6 gestartet
* | 4893d66 Kapitel 4 überarbeitet
* | 401162d Kapitel 1 ausgearbeitet
|/
* ae2918a Merge branch 'develop'

Mit diesen Graphen können wir den Branch feat_kap_7 relativ einfach über einen “Fast Merge” in unser main Branch integrieren.

repo_1$ git checkout main
Switched to branch 'main'
repo_1$ git merge feat_kap_7
Updating cf10f7f..874e90c
Fast-forward
 kapitel_7.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 kapitel_7.txt
repo_1$ git branch -d feat_kap_7
Deleted branch feat_kap_7 (was 874e90c).

Konflikte beim `rebase` lösen

Genau wie beim merge kann es auch bei rebase zu Konflikten führen, die gelöst werden müssen. Im Gegensatz zu merge können die Konflikte mehrmals vorkommen, praktisch bei jeder “Wiedergabe” (replay) eines Commits auf die neue Basis. Dabei stoppt das Rebase und erlaubt uns die Konflikte zu lösen (ähnlich wie bei merge).

Mit git add markieren wir eine Datei mit dem Konflikt, dass der Konflikt beseitigt ist.
Mit git rebase --continue setzen wir das Rebase fort (wiedergeben den nächsten Commit auf die neue Basis).
Mit git rebase --abort können wir das Rebase abbrechen (ähnlich wie beim merge während eines Konfliktes).

Warnung

Da ein rebase die Historie verändert, sollte dieser nur auf den Commits durchgeführt werden, die noch nicht zu einem Zentralen git-Server synchronisiert wurden (oder nur auf Branches auf denen man allein arbeitet).

↩︎

Squash: Commits zusammenführen

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

Was ist `squash`¹?

Ein Git Squash ermöglicht es, mehrere Commits zu einem einzelnen Commit zusammenzufassen. Dies ist besonders nützlich, um die Commit-Historie sauber zu halten. Dabei kan man squash sowohl mit rebase (aktueller Branch) als auch mit merge nutzen.

Anwendung mit `rebase`

Ein rebase kann in einen interaktiven Modus durchgeführt werden (Parameter -i oder --interactive). Dabei werden alle betroffenen Commits, die “wiedergegeben” werden, in dem Texteditor angezeigt und können angepasst werden.

Für squash mit rebase geben wir die Anzahl der Commits, die zusammengefasst werden sollen mit HEAD-<n> an (die selbe Syntax, die wir bereits mit diff gesehen haben, um Commits relativ anzusprechen). Wir wollen nun die letzten Beiden Commits unserer Historie zusammenfassen.

repo_1$ git pl
* 874e90c (HEAD -> main) Neue Geschichte
* 71c03a0 Start mit Kapitel 7
* cf10f7f Besser
* 4a8d01e (origin/main) Merge branch 'feat_kap_5'
...

Dazu führen wir das interaktive rebase für die letzten 2 Commits durch.

repo_1$ git rebase -i HEAD~2

Darauf erscheint im Texteditor die Auflistung der betroffenen Commits (und ein Wenig Dokumentation dazu - mit # auskommentiert):

pick 71c03a0 Start mit Kapitel 7
pick 874e90c Neue Geschichte

# Rebase cf10f7f..874e90c onto cf10f7f (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
# commit's log message, unless -C is used, in which case
# keep only this commit's message; -c is same as -C but
# opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# create a merge commit using the original merge commit's
# message (or the oneline, if no original merge commit was
# specified); use -c <commit> to reword the commit message
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
# to this position in the new commits. The <ref> is

Relevant sind nur die ersten beiden Zeilen. Jede Zeile (Commit), die mit pick beginnt, wird im Original übernommen - wird also wieder zu einem Commit. Ändern Sie die Commits, die Zusammengefasst werden sollen von pick zu squash (in unserem Beispiel also den zweiten Commit).

pick 71c03a0 Start mit Kapitel 7
squash 874e90c Neue Geschichte

Unter Linux/macOS können Sie den “vi(m)"-Editor mit Esc-Taste und dann mit :wq (write and quit) verlassen.

Nun können Sie auch das finale Commit bearbeiten, wenn Sie es möchten:

# This is a combination of 2 commits.
# This is the 1st commit message:

Start mit Kapitel 7

# This is the commit message #2:

Neue Geschichte

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Mon Apr 7 08:01:30 2025 +0200
#
# interactive rebase in progress; onto cf10f7f
# Last commands done (2 commands done):
# pick 71c03a0 Start mit Kapitel 7
# squash 874e90c Neue Geschichte
# No commands remaining.
# You are currently rebasing branch 'main' on 'cf10f7f'.
#
# Changes to be committed:
# new file: kapitel_7.txt
#

Mit dem Verlassen des Commit-Message Editors, wird die Historie umgeschrieben.

repo_1$ git rebase -i HEAD~2
[detached HEAD a93f4f8] Start mit Kapitel 7
 Date: Mon Apr 7 08:01:30 2025 +0200
 1 file changed, 2 insertions(+)
 create mode 100644 kapitel_7.txt
Successfully rebased and updated refs/heads/main.
repo_1$ git pl
* a93f4f8 (HEAD -> main) Start mit Kapitel 7
* cf10f7f Besser
* 4a8d01e (origin/main) Merge branch 'feat_kap_5'

Letzten Commit anpassen

Sollten nur die letzten Änderungen (bereits mit git add in das Staging-Bereich hinzugefügt, aber noch kein Commit erstellt) in das letzte Commit reinfließen, geht es noch ein wenig einfacher. Dazu kann das --amend² Parameter vom commit-Command genutzt werden.

Machen Sie folgende Änderung in kapitel_7.txt.

# Kapitel 7
Der Ausgang der Geschichte wird angepasst ...
Und manchmal zusammengeführt...

Fügen Sie die Änderung zum Staging Bereich mit git add.

repo_1$ git add kapitel_7.txt

Nun können wir mit --amend diese Änderung zum letzten Commit hinzufügen. Wenn wir die Message des letzten Commits nicht ändern wollen, können wird den Parameter --no-edit anhängen, oder mit -m eine neue Message angeben.

repo_1$ git commit --amend -m "Kapitel 7 fängt an"
[main 28087f7] Kapitel 7 fängt an
 Date: Mon Apr 7 08:01:30 2025 +0200
 1 file changed, 3 insertions(+)
 create mode 100644 kapitel_7.txt

Mit dem Status sehen wir nun, dass keine Änderungen mehr vorliegen und and der Historie den geänderten letzten Commit (anderer Hash-Wert und Message).

repo_1$ git status
On branch main
Your branch is ahead of 'origin/main' by 2 commits.
 (use "git push" to publish your local commits)

nothing to commit, working tree clean
repo_1$ git pl
* 28087f7 (HEAD -> main) Kapitel 7 fängt an
* cf10f7f Besser
* 4a8d01e (origin/main) Merge branch 'feat_kap_5'
...

Warnung

Da sowohl rebase -i als auch commit --amend die Historie verändert, sollte dieser nur auf den Commits durchgeführt werden, die noch nicht zu einem Zentralen git-Server synchronisiert wurden (oder nur auf Branches auf denen man allein arbeitet).

↩︎
↩︎

Benannte Versionen mit Tags

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

Wir Menschen sind nicht dazu geeignet Hash-Werte zu merken. Das ist aber manchmal notwendig, um zu einem bestimmten Stand in der Geschichte zurückkehren zu können. Hier helfen und sogenannte Tags, die an ein Commit angehängt werden können. Wir können diese als eine kleine Notiz an einem Commit vorstellen.

Git unterstützt dabei zwei Arten von Tags.

Leichtgewichtige Tags, die nur aus dem Tag selbst bestehen. Es ist am Ende ein einfacher Zeiger auf den Commit, wie bei Branches, der sich aber nicht bewegt.
Annotierte Tags, die neben dem Tag selbst noch weitere Informationen tragen, wie eine zusätzliche Nachricht.

Leichtgewichtiger Tag

Legen wir zuerst einen leichtgewichtigen Tag an, der auf den letzten Commit zeigt. Dazu nutzen wir das git tag Befehl mit dem Namen des Tags.

repo_1$ git tag 'kap-05'
repo_1$ git pl
* 7a000b4 (HEAD -> main, tag: kap-05) Merge branch 'feat_kap_5'
|\
| * 408a803 (feat_kap_5) Kapitel 4 überarbeitet
...
repo_1$ git tag
kap-05

Mit git tag können wir alle Tags der Repositories auflisten lassen. Mit git show können wir die Informationen zu einem Commit, oder Tag aufrufen. Bei leichtgewichtigen erscheinen dabei keine zusätzlichen Informationen.

repo_1$ git show kap-05
commit 7a000b46cdd307aea91cc0e151fa6b7ff7daad78 (HEAD -> main, tag: kap-05)
Merge: 618450e 408a803
Author: Eugen [WebDucer] Richter <github@webducer.de>
Date: Mon May 2 06:56:58 2022 +0200

 Merge branch 'feat_kap_5'

diff --cc kapitel_4.txt
...

Annotierter Tag

Nun legen wir einen annotierten Tag an, der neben der Nachricht, auch auf einen bestimmten Commit angehängt wird, nicht den aktuellen. Dazu wird der Parameter -a (für annotiert) und -m (für Message) genutzt. Der Commit auf den wir uns beziehen, wird als Hash (oder HEAD-Relative-Referenz, wie bei diff) mit angegeben.

repo_1$ git tag -a 'kap-04' e779542 -m "Kapitel 4 über Tag"
repo_1$ git pl
* 7a000b4 (HEAD -> main, tag: kap-05) Merge branch 'feat_kap_5'
|\
| * 408a803 (feat_kap_5) Kapitel 4 überarbeitet
| * 47c1c6d Kapitel 1 überarbeitet
| * 1b28574 Fahrt im Zug
* | 618450e Kapitel 6 gestartet
* | 54a8d9a Kapitel 2 überarbeitet
* | 0b1ad44 Kapitel 1 ausgearbeitet
|/
* e779542 (tag: kap-04) Merge branch 'develop'
...
_repo_1$ git show kap-04
tag kap-04
Tagger: Eugen [WebDucer] Richter <github@webducer.de>
Date: Mon May 2 07:13:57 2022 +0200

Kapitel 4 über Tag

commit e7795427bf9235f54e8fc3cc73b0fa4f43678373 (tag: kap-04)
Merge: 10eabc1 aac4d8b
Author: Eugen [WebDucer] Richter <github@webducer.de>
Date: Mon May 2 05:46:44 2022 +0200
...

Bei git show sehen wir nun neben den Informationen zu dem Commit selbst (fängt mit commit e7794 an) auch die Informationen zu dem Tag (es können auch mehrere sein) oberhalb von diesem. Hier werden neben der Nachricht auch die Informationen zu dem Ersteller des Tags angezeigt.

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

Links

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

Allgemein

Bücher

Blogs / Tutorials

Software (git Clients)

Hinweis

Die meisten heutigen IDEs und Editoren verfügen über direkte Integration mit einer Versionsverwaltung, vor allem auch mit git.

Visual Studio Code
Android Studio
JetBrains InteliJ, Rider, PyCharm und weitere
Visuals Studio
XCode
und viele weitere

Git Hoster

Alle Hoster bieten ein kostenkoses Konto an. Mit diesem ist es meistens möglich mit bis zu 5 Mitstreitern kostenlos zusammenzuarbeiten und unbegrenzte Anzahl an privaten Repositories zu haben. Viele bieten auch ein kostenloses Zeitkontingent für die integrierte CI/CD Pipeline.

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

Git - Versionsverwaltung für Dokumente, Dokumentationen, Code und mehr

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

Arbeiten Sie in einer Gruppe an einem Dokument oder programmieren Sie gerne? Wollen Sie wissen, was Sie oder Andere zuletzt am Dokument geändert haben?

Erfahren Sie mehr dazu

Lernen Sie, wie eine Version (von einem oder mehreren Dokumenten) mit Git auf dem Rechner gesichert, verglichen, mit anderen geteilt, zusammengeführt und wiederhergestellt werden kann. Erstellen Sie mehrere Bearbeitungszweige, um an mehreren Dokumentversionen parallel arbeiten zu können.

Kursinhalt: Grundlagen Versionierung; Geschichte; aktuelle Systeme; Strategien; lokaler Einsatz von Git; Git mit Server-Einsatz; Arbeiten an mehreren Zweigen.

Nächster Termin an der MVHS

2x, 18.11.2026 - 25.11.2026
1. Mi. 18.11.2026, 18:00 – 21:00 Uhr
2. Mi. 25.11.2026, 18:00 – 21:00 Uhr

Jetzt lerne ich mein Android-Smartphone kennen

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

Entdecken Sie die Welt von Android, dem führenden Betriebssystem für Smartphones und Tablets. In diesem Kurs werden Ihnen neben grundlegenden Funktionen auch nützliche Tipps zur optimalen Nutzung Ihres Gerätes aufgezeigt.

Kursinhalte:

Vorstellung einzelner Android-Versionen und einfache Anpassungen
Einrichten von WLAN-Zugang
Telefonieren und fotografieren
Abspielen von Musik und Videos
Nutzung von Gmail oder E-Mail
Surfen im Internet
Sicherheitsaspekte und hilfreiche Tipps

Erfahrungen im Umgang mit einem Touchscreen werden vorausgesetzt. Die Grundfunktionen werden an einem Android-Gerät exemplarisch demonstriert.

Hinweis

Bitte bringen Sie ein Android-Smartphone inkl. Ladegerät mit.

Termine

2x, 28.11.2026 - 29.11.2026
1. Sa. 28.11.2026, 10:00 - 13:00
2. So. 29.11.2026, 10:00 - 13:00

MacOS: das Apple-Betriebssystem besser kennenlernen

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

Sie haben bereits Erfahrungen im Umgang mit Ihrem MacBook und möchten jetzt weitere Anwendungs- und Wartungsprogramme sowie Konfigurationsmöglichkeiten von macOS kennenlernen?

Erfahren Sie mehr zu:

Hardwarekomponenten und -erweiterungen
Systemeinstellungen, -optimierung und -sicherung
Tipps und Tricks im Umgang mit dem Finder
Einrichten von Internet und Netzwerk
Nutzen der Cloud-Dienste

Hinweis

Bitte bringen Sie ein MacBook inkl. Ladegerät mit.

Nächster Termin an der MVHS

2x, 27.02.2027 - 28.02.2027
1. Sa. 27.02.2027, 09:15 – 16:00 Uhr
2. So. 28.02.2027, 09:15 – 16: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

Der geht doch noch! Ältere Computer und Laptops sicher weiterverwenden

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

Die Sicherheitsupdates von Windows 10 werden im Oktober eingestellt – und nun? In diesem Überblicksworkshop erfahren Sie, wie Sie Ihren älteren PC sicher und sinnvoll weiter nutzen können: mit Updates, Optimierungen oder passenden Alternativen. So bleibt Ihr Gerät ein zuverlässiger Begleiter – auch über 2025 hinaus. Warum das Support-Ende ein Problem und Risiko darstellen kann, erklärt dieser Artikel des WDR:

Am Ende des Kurses wissen Sie, welche Optionen Ihnen zur Verfügung stehen, um Ihr Gerät weiterhin sicher und effizient zu nutzen.

Tipp

Wer direkt den nächsten Schritt machen möchte, kann im passenden Folgekurs (Sa. 27.06.2026, 10–15 Uhr) die Installation und erste Schritte mit einem neuen Betriebssystem erlernen!

Jetzt lerne ich mein Android-Smartphone kennen

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

Kursinhalte:

Vorstellung einzelner Android-Versionen und einfache Anpassungen
Einrichten von WLAN-Zugang
Telefonieren und fotografieren
Abspielen von Musik und Videos
Nutzung von Gmail oder E-Mail
Surfen im Internet
Sicherheitsaspekte und hilfreiche Tipps

Erfahrungen im Umgang mit einem Touchscreen werden vorausgesetzt. Die Grundfunktionen werden an einem Android-Gerät exemplarisch demonstriert.

Hinweis

Bitte bringen Sie ein Android-Smartphone inkl. Ladegerät mit.

Termine

2x, 20.06.2026 - 21.06.2026
1. Sa. 20.06.2026, 10:00 - 13:00
2. So. 21.06.2026, 10:00 - 13:00

Linux leicht gemacht: Der einfache Einstieg für Anfänger (mit Installation)

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

Sie verwenden einen älteren Computer und möchten ihn sicher weiter nutzen? Oder suchen Sie eine Alternative zu Windows, die zuverlässig und kostenlos ist? Linux ist eine bewährte Alternative: Es ist sicher, läuft stabil und eignet sich besonders für ältere Geräte. Zudem machen Sie sich unabhängig von kostenpflichtigen Updates oder neuen Windows-Versionen. Hintergrund ist, dass Microsoft die kostenlosen Sicherheitsupdates für Windows 10 am 14. Oktober 2025 beendet.

Viele Programme und Abläufe in Linux ähneln Windows, sodass der Umstieg leichter ist als gedacht. In diesem Workshop lernen Sie Schritt für Schritt, wie Sie Linux auf Ihrem Computer installieren und erste wichtige Einstellungen vornehmen. Wir zeigen Ihnen, welche Linux-Variante sich für Ihre Bedürfnisse eignet, wie Sie Programme installieren und welche grundlegenden Funktionen Ihnen den Einstieg erleichtern. Alles in verständlicher Sprache und mit praktischen Übungen. Nach Kursende nehmen Sie einen voll einsatzbereiten Linux-Rechner mit nach Hause – bereit für einen sicheren und effizienten Einsatz!

Wichtig: Bitte bringen Sie ein eigenes Endgerät sowie einen USB-Stick (mindestens 8 GB, idealerweise USB 3.0) mit. Damit können Sie das neue System direkt ausprobieren und individuell einrichten.

Hinweis

Dieser Kurs eignet sich besonders gut als praktische Ergänzung zum Überblicks-Workshop (261-32004), in dem Sie erfahren, wann und warum ein Umstieg sinnvoll sein kann.

MacOS: das Apple-Betriebssystem besser kennenlernen

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

Sie haben bereits Erfahrungen im Umgang mit Ihrem MacBook und möchten jetzt weitere Anwendungs- und Wartungsprogramme sowie Konfigurationsmöglichkeiten von macOS kennenlernen?

Erfahren Sie mehr zu:

Hardwarekomponenten und -erweiterungen
Systemeinstellungen, -optimierung und -sicherung
Tipps und Tricks im Umgang mit dem Finder
Einrichten von Internet und Netzwerk
Nutzen der Cloud-Dienste

Hinweis

Bitte bringen Sie ein MacBook inkl. Ladegerät mit.

Nächster Termin an der MVHS

2x, 25.07.2026 - 26.07.2026
1. Sa. 25.07.2026, 09:15 – 16:00 Uhr
2. So. 26.07.2026, 09:15 – 16:00 Uhr

MVHS |

Installation von Docker Desktop

Docker Desktop installieren

Prüfen der Installation

In Terminal / PowerShell

Docker Desktop UI starten

Docker Desktop Dashboard

Installation von Git

Ersten Container ausführen

nginx Webserver ausführen

Container liefert Web-Inhalt

Container stoppen und löschen

nginx mit eigenen Inhalt ausführen

Eigene Web-Site mit nginx

Initialisierung eines lokalen Repositorys

Ordner anlegen

Repository initialisieren

Prüfen des aktuellen Zustandes von Repository

Erster Container für Entwicklung

Starten der Applikation

Start der Postgres Datenbank

Kategorisierung in Docker Hub

Aussuchen der notwendigen Parameter

Postgres Container in Docker Desktop

Starten der Applikation mit laufender Datenbank

Blazor App mit DB Verbindung

Eine Datei versionieren

Datei zum Staging-Bereich hinzufügen

Änderungen festschreiben

Benutzer in git einrichten

Allgemeiner Ablauf

Orchestrierung mit Docker Compose

Orchestrierung mit Docker Compose

Starten der Orchestrierten Container

Gestarteten Container über Compose

Postgres Admin Web-UI

Anpassung der Orchestrierung an die Applikation

pgAdmin ohne Anmeldung mit Serverkonfiguration

Historie anzeigen lassen

Verkürzte Anzeige der Historie

Aliases

Eigene App in Container verpacken

Anpassbarkeit des Images

Auswahl des Basis-Images

Dockerfile

Kopieren des Projektes

Bauen des Projektes

Konfiguration des Ports und Datenbankverbindung

Standard port in SDK image

Starten der Anwendung

Image bauen

Finale Version

Unser Image in Docker Desktop

Ausnahmen für Versionierung

Globale Ausnahmen (Betriebssystem)

Ausnahmen im Repository

Multi Stage Builds

Ursachen für große Images

Größe des Basisimages

Daten im Image

Ursachen beseitigen

Weitere Optimierungen

Vorteil von Alpine Linux

14 Schwachstellen in SDK Image

2 Schwachstellen in SDK Image

Änderungen zwischen Version anzeigen

Aktuelle Änderungen zeigen

Unterschiede zwischen zwei Commits

HEAD Anker für diff nutzen

Reihenfolge ist wichtig

Eigenes Image veröffentlichen

Container Registry

Docker Hub

Personal Access Token Erstellen

Vorbereiten des Images

Push command Hilfestellung auf der Repository Seite

Veröffentlichen

Repository nach Veröffentlichung

Details des Images

Verzweigungen (Branches) anlegen

`HEAD` Anker für `diff` nutzen

Fast Merge¹

Merge²

Übernahme einer der Versionen¹

Was ist ein `rebase`?

Ablauf bei einem `rebase`

Einen `rebase` durchführen

Konflikte beim `rebase` lösen

Was ist `squash`¹?

Anwendung mit `rebase`

`docker run`

`docker start`

`docker stop`