Mitglied werden – KI-Tutor mit vollen Antworten

Training Module

Docker-native CI/CD: eigene Pipeline mit Test-Containern bauen

In diesem 3-Stunden-45-Minuten-Aufbaumodul schreibt ihr eine vollständige CI/CD-Pipeline von Grund auf – ohne fertige Test-Images aus der Cloud. Ihr baut ein eigenes Hugo-Image, verpackt es per Multi-Stage-Build zusammen mit Nginx zu einem schlanken Webserver-Image, und baut zwei eigenständige Test-Werkzeuge als eigene Docker-Images: einen Link-Checker und einen W3C-HTML-Validator. Eine schlanke, selbstgehostete GitLab-Testumgebung per compose.yaml liefert euch dafür die Automatisierung: eine .gitlab-ci.yml mit fünf Stages (Build, SetupTest, Test, CleanupTest, Release) baut alle Images, startet den Webserver isoliert im eigenen Docker-Netzwerk und lässt beide Test-Container gegen ihn laufen. Den Beweis, dass die Pipeline tatsächlich schützt, liefert ihr euch selbst: Ihr baut bewusst einen fehlerhaften HTML-Tag ein, beobachtet, wie die Pipeline im Test-Stage rot wird und das Release blockiert, und behebt den Fehler wieder. Zum Abschluss ordnet ihr ein, wie sich isolierte Job-Container (mit dem klassischen Docker-in-Docker-Problem) von dem hier verwendeten Socket-Binding unterscheiden. Die komplette Session läuft vollständig lokal auf eurem eigenen Rechner, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an mail@mhm-dl.de

Format

3 Stunden 45 Minuten, live (remote oder vor Ort), Input & zwei Hands-on-Blöcke

Teilnehmende

Absolvent:innen von “Docker Fortgeschritten” oder gleichwertige Vorkenntnisse in Dockerfiles, Multi-Stage-Builds und Docker Compose

Voraussetzungen

Sicherer Umgang mit Dockerfile, Multi-Stage-Builds und compose.yaml aus “Docker Fortgeschritten”, Git-Grundkenntnisse, eine lauffähige Docker-Umgebung mit Docker Compose (6 bis 8 GB RAM verfügbar). Keine Cloud-/AWS-Kostenwirkung, alles läuft lokal.

Warum dieses Training für deine Organisation wirkt

Eigene Test-Container statt fertiger SaaS-Scanner

Ein Link-Checker- und ein HTML-Validator-Image selbst bauen, statt Testwerkzeuge als Blackbox aus einer fremden Registry zu ziehen – ihr versteht jede Zeile der Dockerfiles und könnt sie auf eigene Test-Anforderungen zuschneiden.

Eine Pipeline, die wirklich etwas verhindert

Der eingebaute Fehler ist der Kern dieses Trainings: Ihr seht mit eigenen Augen, wie ein fehlerhaftes HTML-Tag den Test-Stage rot werden lässt, das Release blockiert und der Cleanup trotzdem sauber durchläuft – keine Theorie, sondern ein selbst provozierter, selbst behobener Ernstfall.

Runner-Architektur verstehen, nicht nur konfigurieren

Der Vergleich Socket-Binding (Docker-out-of-Docker über den Docker-Socket) gegen isolierte Job-Container (Docker-in-Docker-Problem) erklärt, warum viele Unternehmensumgebungen andere Pipeline-Muster brauchen als eine lokale Übung.

Was Teilnehmende mitnehmen

  • Ein eigenes Hugo-Image per Dockerfile bauen und über ENTRYPOINT/WORKDIR als wiederverwendbares Build-Werkzeug einsetzen.
  • Ein Multi-Stage-Webserver-Image bauen, das im Build-Stage die Website generiert und im Laufzeit-Stage ausschließlich das fertige HTML in ein schlankes Nginx-Image kopiert.
  • Zwei eigenständige Test-Tool-Images bauen: einen Link-Checker (Debian + linkchecker, unprivilegierter Nutzer) und einen W3C-HTML-Validator (Java-Runtime + vnu.jar).
  • Eine schlanke, lokale GitLab-CE-Instanz samt Runner per compose.yaml aufsetzen, den Runner registrieren und mit dem Docker-Socket ausstatten.
  • Eine .gitlab-ci.yml mit fünf Stages (Build, SetupTest, Test, CleanupTest, Release) selbst schreiben, inklusive when: always für zuverlässiges Aufräumen und einem only: main-Release-Gate.
  • Einen bewusst eingebauten Pipeline-Fehler (ungültige HTML-Verschachtelung) live in der Validator-Log-Ausgabe analysieren, das blockierte Release nachvollziehen und den Fehler wieder beheben.
  • Socket-Binding (Docker-out-of-Docker über den Docker-Socket) und isolierte Job-Container (Docker-in-Docker-Problem, gebündeltes Test-Image, GitLab Services) konzeptionell einordnen.

Für wen dieses Modul ideal ist

  • • Docker-erfahrene Entwickler:innen/Admins, die ihre erste eigene CI/CD-Pipeline mit selbstgebauten Test-Containern statt fertiger SaaS-Scanner schreiben wollen
  • • Absolvent:innen von “Docker Fortgeschritten” oder Entwickler:innen mit gleichwertigen Dockerfile-/Multi-Stage-/Compose-Vorkenntnissen
  • • Teams, die verstehen wollen, warum eine Pipeline ein fehlerhaftes Release tatsächlich verhindert – nicht nur, dass sie es tun soll

Rahmendaten

  • • Dauer: 3 Stunden 45 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Coding, zwei Hands-on-Blöcke
  • • Voraussetzungen: abgeschlossenes Modul “Docker Fortgeschritten” oder gleichwertige Dockerfile-/Multi-Stage-/Compose-Vorkenntnisse; “Git Versionskontrolle” für Git-Basics empfohlen, aber keine Pflicht; lauffähige Docker-Umgebung mit 6 bis 8 GB RAM; keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Vorbereitung & Landkarte des Projekts (15 min): die drei Bausteine (Anwendung, Test-Werkzeuge, Automatisierung) im Überblick, plus die vier Kernprobleme vorab: Portweiterleitung/0.0.0.0, Multi-Stage-Builds, die Volumes-Rechte-Falle (-u “$(id -u):$(id -g)”), macOS-/Apple-Silicon-Hinweis.

  2. Baustein 1: Eigenes Hugo-Image bauen (20 min): Dockerfile für den Website-Generator, Image bauen, per Versionsabfrage verifizieren.

  3. Baustein 2: Multi-Stage-Webserver-Image (15 min): Build-Stage generiert die Website mit Hugo, Laufzeit-Stage kopiert ausschließlich das fertige HTML in ein schlankes, nicht als root laufendes Nginx-Image.

  4. Baustein 3: Zwei eigene Test-Tool-Images (30 min): Link-Checker-Image (Debian, unprivilegierter Nutzer) und HTML-Validator-Image (Java-Runtime + vnu.jar) bauen und lokal per Hilfeseite smoke-testen.

  5. Lokale GitLab-Testumgebung aufsetzen (25 min): compose.yaml mit GitLab CE + Runner, Hosts-Eintrag, Root-Passwort aus .env, Erst-Login, Gruppe/Projekt anlegen, Runner registrieren.

  6. Die Pipeline: .gitlab-ci.yml mit fünf Stages (30 min): Build → SetupTest → Test (parallel) → CleanupTest → Release, GitLab-Variablen ($CI_JOB_TOKEN, $CI_COMMIT_REF_NAME), when: always und only: main.

  7. Hands-on 1: die Pipeline zum ersten Mal grün bekommen (20 min): Code pushen, alle fünf Stages live im Browser verfolgen.

  8. Hands-on 2: eingebauter Fehler & Fehlersuche (30 min): bewusst ungültige HTML-Verschachtelung einbauen, Validator-Fehlermeldung lesen, blockiertes Release und sauberes Cleanup nachvollziehen, Fehler beheben.

  9. Exkurs: Socket-Binding vs. isolierte Job-Container (20 min): Docker-out-of-Docker vs. Docker-in-Docker-Problem, gebündeltes “Schweizer-Taschenmesser”-Test-Image, GitLab Services als Live-Webserver für isolierte Job-Container.

  10. Aufräumen (10 min): Container/Netzwerke stoppen, GitLab-Datenordner löschen, docker system prune -a –volumes.

  11. Abschluss/Q&A (10 min): offene Fragen, Einordnung in die weiteren Docker- und CI/CD-Aufbaumodule.

Hands-on Inhalte (Auszug)

Eigene Images bauen

  • Hugo-Image als eigenständiges Build-Werkzeug, per ENTRYPOINT [“hugo”] direkt aufrufbar
  • Multi-Stage-Webserver-Image: Hugo-Build-Stage + Nginx-Laufzeit-Stage (nginx-unprivileged, Alpine), nur das fertige HTML wandert in die zweite Stage
  • Link-Checker- und HTML-Validator-Image, jeweils mit unprivilegiertem Nutzer statt root

Hands-on 1: Pipeline grün bekommen

  • Alle drei Images per .gitlab-ci.yml automatisiert bauen und pushen (Stage build)
  • Webserver isoliert im eigenen Docker-Netzwerk starten (Stage setupTest)
  • Link-Checker und Validator parallel gegen den laufenden Webserver testen (Stage test) – Beweis: alle fünf Stages grün im Browser

Hands-on 2: eingebauter Fehler

  • Bewusst ungültige HTML-Verschachtelung (<p> in <span>) einbauen und pushen
  • Validator-Fehlermeldung im Pipeline-Log lesen, Test-Stage wird rot, Release-Stage läuft nicht
  • when: always beweisen: Cleanup räumt Test-Container und -Netzwerk trotzdem sauber auf, Fehler beheben, Pipeline wird wieder grün

Exkurs: Runner-Architektur

  • Socket-Binding: Docker-Befehle der Jobs direkt gegen den Docker-Daemon des Runner-Hosts (Docker-out-of-Docker)
  • Isolierte Job-Container: Docker-in-Docker-Problem, gelöst über ein gebündeltes Test-Image
  • GitLab Services als Muster für einen Live-Webserver ohne Docker-Socket

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zur grünen Pipeline, Ergebnis beider Hands-on-Übungen) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Explizit nicht Teil dieses Kurses

  • • Produktionsnahe, mehrdienstige GitLab-Instanz mit Traefik/externer Datenbank, Registry-Push/Pull-Tagschema, Personal Access Tokens und Backup/Restore – vertieft im Aufbaumodul GitLab & Container-Registry selbst hosten mit Docker. Die hier verwendete GitLab-Instanz ist bewusst minimal (nur GitLab + Runner, keine externe Datenbank/kein Traefik) und dient ausschließlich als Automatisierungs-Unterbau für die Pipeline selbst.
  • • Kubernetes-Deployment von GitLab und Cluster-Betrieb – Thema von GitLab auf Kubernetes betreiben.
  • • Monitoring und Log-Aggregation des Stacks – Thema von Docker Betrieb.
  • • Verteilung über mehrere Nodes – Thema von Docker Swarm Hands-on.
  • • Policy-as-Code-Gates vor dem Deployment (Kyverno-CLI/conftest) – eigenständiges Thema von CI/CD Policy Gates.
  • • Vertiefte CI/CD-Build-Theorie jenseits der hier geschriebenen Pipeline (Pipeline-Designprinzipien, Vergleich verschiedener CI-Systeme) – Thema von CI: Continuous Integration & der Build-Prozess.
  • • Bitbucket-Pipelines im Vergleich bleibt ein eigenständiges Thema – siehe Bitbucket Pipeline Grundwissen.

Bereit, das Modul zu buchen?

Wir passen die Test-Tool-Images und den eingebauten Fehler auf euren Stack und Erfahrungsstand an.

Academy Briefing anfragen