Training Module

Docker & Webserver: Apache, Nginx Reverse Proxy & HAProxy Load Balancing

In diesem 3-Stunden-Aufbaumodul baut ihr die Schicht, die in den bisherigen Docker-Kursen bewusst ausgespart blieb: die Multi-Tier-Architektur vor der eigentlichen Anwendung. Ihr baut ein eigenes Apache-Image auf Debian-Basis mit eigener VirtualHost-Konfiguration, richtet Nginx als Reverse Proxy vor einer Node.js-API ein und verteilt Anfragen per HAProxy im Round-Robin-Verfahren auf zwei Backend-Webserver – inklusive des Fixes für die Race-Condition beim Container-Start, die dabei in der Praxis fast immer zuerst auffällt. Zum Abschluss ordnet ihr Traefik als moderne, label-gesteuerte Alternative konzeptionell ein. Die komplette Session – auch alle drei Hands-on-Übungen – läuft vollständig lokal auf eurem eigenen Rechner (macOS/Apple Silicon geeignet), ohne Cloud-Account, ohne öffentliche Domain und ohne Kostenwirkung.

Format

3 Stunden, live (remote oder vor Ort), Input & drei vollständige Hands-on-Blöcke

Teilnehmende

Absolvent:innen von “Docker Grundlagen” und “Docker Fortgeschritten” oder gleichwertige Vorkenntnisse in Docker Compose

Voraussetzungen

Sicherer Umgang mit docker run, docker build und Bind Mounts sowie Docker-Compose-Basiswissen (services/networks). Eine lauffähige Docker-Umgebung, idealerweise macOS/Apple Silicon. Keine Cloud-/AWS-Kostenwirkung, keine öffentliche Domain – alles läuft lokal.

Warum dieses Training für deine Organisation wirkt

Die Schicht vor der Anwendung

Alle bisherigen Docker-Kurse haben Anwendungs- und Datenbank-Container behandelt, aber nie die Schicht davor: Wer nimmt Anfragen entgegen, wer terminiert TLS, wer verteilt Last auf mehrere Instanzen? Dieses Modul schließt genau diese Lücke mit einer Technologie-Matrix und einer klaren Abgrenzung Forward- vs. Reverse-Proxy.

Vom offiziellen Image zum eigenen Betrieb

Der Bogen läuft vom offiziellen Apache-Image mit Bind Mount bis zum selbst gebauten Image mit eigener VirtualHost-Konfiguration, aktivierten Modulen und bewusst gesetzten Sicherheits-Direktiven – der Unterschied zwischen “es läuft” und “es ist absichtlich so konfiguriert” wird an echtem Code sichtbar.

Der Fehler, der in der Praxis zuerst auffällt

Ein Load Balancer, der beim Compose-Start schneller hochfährt als seine Backends, scheitert an einem DNS-Lookup-Fehler – ein Klassiker, an dem viele erste HAProxy-Setups scheitern. Ihr baut den Fix aktiv selbst ein, statt nur davon zu lesen.

Was Teilnehmende mitnehmen

  • Eine Multi-Tier-Architektur und die Technologie-Matrix (Apache, Nginx, Caddy, Node/Express, HAProxy, Traefik) im Überblick einordnen – wer wofür die richtige Wahl ist.
  • Forward- vs. Reverse-Proxy und das Grundprinzip der TLS-Termination als Konzept sicher erklären können.
  • Ein eigenes Apache-Image auf debian:trixie-Basis mit eigener VirtualHost-Konfiguration bauen, inklusive a2enmod rewrite headers und bewusst gehärteten Directory-Direktiven (Options -Indexes, AllowOverride).
  • Nginx als Webserver UND als Reverse Proxy vor einer Node.js/Express-API einsetzen, mit sauberer Pfad-Aufteilung / (Frontend) und /api/ (Backend) über ein internes Compose-Netzwerk.
  • HAProxy als Load Balancer im Round-Robin-Verfahren vor zwei unterschiedlichen Webservern (Apache und Nginx) betreiben – inklusive des Fixes für die typische Race-Condition/DNS-Lookup-Fehler beim gleichzeitigen Containerstart.
  • Traefiks Docker-Label-Discovery, Architektur und automatische Let’s-Encrypt-Integration konzeptionell einordnen und wissen, in welchen Kursen der praktische Betrieb bereits vorkommt.
  • In drei vollständigen Hands-on-Übungen den kompletten Weg vom eigenen Webserver-Image bis zum lastverteilten Setup selbst gehen und gegen eine Musterlösung abgleichen.

Für wen dieses Modul ideal ist

  • • Absolvent:innen von “Docker Grundlagen” und “Docker Fortgeschritten” oder Entwickler:innen mit gleichwertigen Compose-Vorkenntnissen
  • • Teams, die bisher nur Anwendungs- oder Datenbank-Container betrieben haben und jetzt die vorgelagerte Webserver-/Proxy-Schicht selbst verstehen und konfigurieren wollen
  • • Alle, die vor dem ersten eigenen Reverse-Proxy- oder Load-Balancer-Setup den typischen Startup-Race zwischen Proxy und Backend kennenlernen wollen, bevor er im Ernstfall auftritt

Rahmendaten

  • • Dauer: 3 Stunden live (remote oder vor Ort)
  • • Format: Input, Live-Demo, drei vollständige Hands-on-Übungen mit Musterlösungs-Abgleich
  • • Voraussetzungen: abgeschlossene Module “Docker Grundlagen” und “Docker Fortgeschritten” oder gleichwertige Vorkenntnisse, lauffähige Docker-Umgebung (macOS/Apple Silicon geeignet), keine Cloud-Kostenwirkung, keine öffentliche Domain

Modulaufbau & Agenda

  1. Theorie: Multi-Tier-Architektur, Technologie-Matrix & Reverse-Proxy-Grundprinzip (20 min): Forward- vs. Reverse-Proxy, TLS-Termination als Konzept, Apache/Nginx/Caddy/Node+Express/HAProxy/Traefik im Überblick.

  2. Apache HTTP Server (40 min): offizielles Image mit Bind Mount, danach ein eigenes Image auf Debian-Basis mit eigenem Dockerfile, VirtualHost und a2enmod.

  3. Hands-on 1: eigenes Apache-Image (in Modul 2 enthalten): eigenes Dockerfile, eigene VirtualHost-Konfiguration, gehärtete Directory-Direktiven.

  4. Nginx als Webserver & Reverse Proxy (55 min): eigene Nginx-Konfiguration, danach Hands-on 2: Reverse-Proxy-Setup vor einer Node.js-API per Compose.

  5. HAProxy als Load Balancer (40 min): Round-Robin vor Apache und Nginx, Hands-on 3 inklusive Race-Condition-/DNS-Lookup-Fix beim Containerstart.

  6. Traefik – nur Konzept (20 min): Docker-Label-Discovery, Architektur, automatische Let’s-Encrypt-Integration, Verweis auf “Docker Betrieb” und “GitLab & Container-Registry selbst hosten mit Docker”, wo Traefik bereits operativ läuft.

  7. Fazit & Ausblick (5 min): Zusammenfassung, Einordnung in die weiteren Docker-Aufbaumodule.

Hands-on Inhalte (Auszug)

Technologie-Matrix & Reverse-Proxy-Grundprinzip

  • Apache, Nginx, Caddy, Node/Express, HAProxy, Traefik anhand von Einsatzzweck, Konfigurationsmodell und Discovery-Mechanismus gegenübergestellt
  • Forward-Proxy (verdeckt den Client) vs. Reverse-Proxy (verdeckt die Backends) als klare Abgrenzung
  • TLS-Termination als Konzept: wo das Zertifikat liegt, was intern unverschlüsselt weiterläuft

Hands-on 1: eigenes Apache-Image

  • Dockerfile auf debian:trixie-Basis, eigene default.conf mit VirtualHost/DocumentRoot/Directory
  • a2enmod rewrite headers aktivieren, bevor Apache startet
  • Options -Indexes und AllowOverride bewusst als Sicherheits-Lernpunkt gesetzt, nicht aus dem Default übernommen
  • Läuft als Non-root-User www-data auf Port 8080 statt als root auf Port 80 – kein Container-Prozess mit mehr Rechten im Netzwerk-Stack als nötig

Hands-on 2: Nginx Reverse Proxy vor Node.js-API

  • Drei Compose-Services (Proxy, Frontend, Node/Express-API) in einem internen app-net-Netzwerk
  • Proxy extern auf Port 8080 erreichbar, / routet zum Frontend, /api/ zur API
  • Nur der Proxy-Container veröffentlicht einen Host-Port – Frontend und API bleiben intern

Hands-on 3: HAProxy Round-Robin

  • Ein HAProxy-Frontend verteilt Anfragen abwechselnd auf den Apache- und den Nginx-Container aus Modul 2/3
  • Fix für die Race-Condition/den DNS-Lookup-Fehler beim gleichzeitigen Containerstart über die resolvers-Direktive
  • Beweis per wiederholtem curl: die Antwort wechselt sichtbar zwischen beiden Backends

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zum lauffähigen Load-Balancer-Setup, Ergebnis der drei Hands-on-Übungen) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Explizit nicht Teil dieses Kurses

  • Caddy als eigenständiger Webserver/Reverse Proxy – wird in der Technologie-Matrix nur benannt, nicht praktisch geübt.
  • Node/Express als eigenständiges Webserver-Kapitel – die API in Hands-on 2 ist reines Backend hinter dem Nginx-Reverse-Proxy, kein Thema für sich.
  • Apache mod_status und Log-Auswertung per sed – kein Bestandteil dieses Moduls.
  • Traefik als Hands-on – wird ausschließlich konzeptionell behandelt (Docker-Label-Discovery, Architektur, Let’s-Encrypt-Automatisierung). Der praktische Betrieb ist bereits Teil von Docker Betrieb und GitLab & Container-Registry selbst hosten mit Docker.
  • Let’s-Encrypt-Produktivbetrieb mit echter, öffentlicher Domain und echtem Zertifikat – diese Session läuft vollständig lokal, ohne öffentliche Domain.
  • Compose- und Netzwerk-Grundlagen (compose.yaml-Grundstruktur, Service Discovery, Bind Mounts) – vorausgesetzt aus Docker Grundlagen und Docker Fortgeschritten und hier nicht wiederholt.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übungen auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen