Training Module
Docker & CMS: WordPress, PHP-FPM/Nginx und Datenpersistenz
In diesem 3-Stunden-Aufbaumodul containerisiert ihr eine vollständige WordPress-Infrastruktur mit
MariaDB und wp-cli und geht anschließend den Weg vom bequemen Apache-Monolithen zur
entkoppelten Microservice-Architektur mit Nginx und PHP-FPM. Ihr baut den ersten Stack per
compose.yaml auf, führt Erstinstallation und Plugin-Pflege komplett über wp-cli
statt über den Browser-Installationsassistenten durch und verinnerlicht dabei das zentrale Prinzip
der Container-Welt: Datenbankinhalte und hochgeladene Dateien gehören in benannte Docker Volumes,
niemals in den flüchtigen Container selbst. Zum Abschluss baut ihr denselben Stack in eine
Drei-Container-Architektur aus Nginx, PHP-FPM und MariaDB um und erlebt live, warum die Entkopplung
von Webserver und PHP-Laufzeit unter Last die bessere Wahl ist. 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 compose.yaml (Services, Netzwerke, Volumes) sowie grundlegendes Verständnis PHP-/MySQL-basierter Webanwendungen. 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
Vom Apache-Monolithen zur entkoppelten Architektur
Das klassische Apache-Image (wordpress:apache) führt Webserver und PHP-Interpreter im
selben Container zusammen, einfach im Aufbau, aber unter Last schlechter skalierbar. PHP-FPM
trennt die PHP-Verarbeitung vom Webserver und schafft damit unabhängige Skalierbarkeit auf Kosten
etwas höherer Konfigurationskomplexität. Beide Muster lernt ihr an echten Compose-Stacks kennen,
nicht nur als Folie.
CLI statt Klick: WordPress vollständig skriptgesteuert
Ein wordpress:cli-Service als eigener Compose-Dienst macht Erstinstallation,
Plugin-Verwaltung und Updates komplett automatisierbar, ohne den Browser-Installationsassistenten
und ohne lange, unübersichtliche docker run-Befehle im Terminal.
Das Prinzip, das jede Container-Anwendung retten muss
Container sind flüchtig (ephemeral). Datenbankinhalte und hochgeladene Dateien müssen zwingend in dedizierten Named Volumes auf dem Host liegen. Dieses Prinzip zieht sich durch beide Hands-on-Architekturen dieses Moduls und ist unabhängig von der gewählten Variante gültig.
Was Teilnehmende mitnehmen
- Apache-Modul (
mod_php, monolithisch) und PHP-FPM/Nginx (entkoppelt) als die zwei grundlegenden Architekturmuster für PHP-Webanwendungen gegenüberstellen und wissen, wann welches Muster sinnvoll ist. - Einen vollständigen WordPress-Stack aus Webserver, MariaDB und einem
wordpress:cli-Service percompose.yamlaufsetzen und starten. - WordPress komplett ohne Browser administrieren: Erstinstallation per
wp core install, Plugins auflisten und aktualisieren perwp plugin listundwp plugin update –all. - Das Prinzip der Daten-Persistenz in der Praxis anwenden: Named Volumes für
/var/www/htmlund das MariaDB-Datenverzeichnis/var/lib/mysql, weil Container selbst flüchtig sind. - Einen bestehenden Apache-basierten Stack in eine entkoppelte Drei-Container-Architektur aus Nginx, PHP-FPM und MariaDB umbauen.
- Eine eigene Nginx-Konfiguration schreiben, die statische Dateien direkt ausliefert und
.php-Aufrufe per FastCGI-Protokoll an den PHP-FPM-Container weiterreicht. - In drei vollständigen Hands-on-Übungen den kompletten Weg vom ersten Compose-Stack bis zur entkoppelten Architektur 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 PHP-basierte Webanwendungen bisher bare-metal oder per VM betreiben und jetzt auf reproduzierbare, containerisierte Umgebungen umstellen wollen
- • Alle, die vor dem ersten eigenen CMS-Rollout die CLI-Administration per
wp-cliund die entkoppelte PHP-FPM/Nginx-Architektur kennenlernen wollen, bevor sie produktiv damit arbeiten
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
Theorie: Architekturmuster & Datenpersistenz-Prinzip (25 min): Apache-Modul (monolithisch,
mod_php) vs. PHP-FPM/Nginx (entkoppelt) im Vergleich, das Prinzip der Named Volumes für flüchtige Container.Hands-on 1: WordPress + MariaDB per Compose (45 min): vollständiger Drei-Dienste-Stack (
web,db,cli) percompose.yaml, Start und Statusprüfung.Hands-on 2: Administration per wp-cli (30 min): Erstinstallation per
wp core install, Plugins auflisten und aktualisieren, komplett ohne Browser.- Pause (10 min).
Hands-on 3: Umbau auf die PHP-FPM/Nginx-Entkopplung (50 min): eigene Nginx-Konfiguration, Umbau auf eine Drei-Container-Architektur aus Nginx, PHP-FPM und MariaDB mit gemeinsam genutztem, read-only eingebundenem Anwendungs-Volume.
Zusammenfassung, Best-Practice-Checkliste & Ausblick (20 min): Einordnung in die weiteren Docker-Aufbaumodule, Ausblick auf Secrets-Management, Backup-Strategien und alternative CMS-Systeme als mögliche Folgemodule.
Hands-on Inhalte (Auszug)
Architekturmuster & Datenpersistenz-Prinzip
- Apache-Modul (
mod_php) vs. PHP-FPM (FastCGI Process Manager) als die zwei gängigsten Architekturmuster im PHP-Umfeld - Vorteil/Nachteil-Abwägung: einfacher Aufbau vs. unabhängige Skalierbarkeit und bessere Ressourcentrennung
- Container sind flüchtig (ephemeral): Datenbankinhalte und hochgeladene Dateien gehören zwingend in dedizierte Docker Volumes
Hands-on 1: WordPress + MariaDB + wp-cli
# Datei: ~/docker-projects/wordpress/compose.yaml
services:
web:
image: wordpress:7.1-php8.4-apache
restart: always
ports:
- "127.0.0.1:8080:80"
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_NAME: app_db
WORDPRESS_DB_USER: app_user
WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:?DB_PASSWORD fehlt in .env}
volumes:
- html_data:/var/www/html
depends_on:
db:
condition: service_healthy
healthcheck:
test: ["CMD", "test", "-f", "/var/www/html/wp-config.php"]
interval: 10s
timeout: 3s
retries: 5
start_period: 30s
start_interval: 2s
db:
image: mariadb:12.3
restart: always
environment:
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:?DB_ROOT_PASSWORD fehlt in .env}
MYSQL_DATABASE: app_db
MYSQL_USER: app_user
MYSQL_PASSWORD: ${DB_PASSWORD:?DB_PASSWORD fehlt in .env}
volumes:
- db_data:/var/lib/mysql
healthcheck:
test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
interval: 10s
timeout: 5s
retries: 5
start_period: 30s
start_interval: 2s
cli:
image: wordpress:cli-2.12-php8.4
profiles: ["cli"]
restart: "no"
user: "33:33"
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_NAME: app_db
WORDPRESS_DB_USER: app_user
WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:?DB_PASSWORD fehlt in .env}
volumes:
- html_data:/var/www/html
depends_on:
web:
condition: service_healthy
db:
condition: service_healthy
volumes:
html_data:
db_data:
Hands-on 2: wp-cli-Administration
docker compose run –rm cli wp core install –url=… –title=… –admin_user=… –admin_email=…statt Browser-Installationsassistent (Admin-Passwort erzeugtwp-cliselbst)docker compose run –rm cli wp plugin listundwp plugin update –allfür Plugin-Pflege komplett per CLIuser: “33:33”imcli-Service verhindert Permission-Denied-Konflikte beim Schreiben ins Webroot (Benutzerwww-data)
Hands-on 3: Entkopplung mit PHP-FPM & Nginx
# Datei: ~/docker-projects/wordpress-fpm/compose.yaml
services:
web:
image: nginx:1.30-alpine
restart: always
ports:
- "127.0.0.1:8082:80"
volumes:
- html_data:/var/www/html:ro
- ./default.conf:/etc/nginx/conf.d/default.conf:ro
depends_on:
app:
condition: service_healthy
app:
image: wordpress:7.1-php8.4-fpm
restart: always
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_NAME: app_db
WORDPRESS_DB_USER: app_user
WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:?DB_PASSWORD fehlt in .env}
volumes:
- html_data:/var/www/html
depends_on:
db:
condition: service_healthy
healthcheck:
test: ["CMD", "test", "-f", "/var/www/html/wp-config.php"]
interval: 10s
timeout: 3s
retries: 5
start_period: 30s
start_interval: 2s
db:
image: mariadb:12.3
restart: always
environment:
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:?DB_ROOT_PASSWORD fehlt in .env}
MYSQL_DATABASE: app_db
MYSQL_USER: app_user
MYSQL_PASSWORD: ${DB_PASSWORD:?DB_PASSWORD fehlt in .env}
volumes:
- db_data:/var/lib/mysql
healthcheck:
test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
interval: 10s
timeout: 5s
retries: 5
start_period: 30s
start_interval: 2s
volumes:
html_data:
db_data:
Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zum lauffähigen entkoppelten Stack, 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
- • Docker Secrets &
pwgenfür die sichere Verwaltung von Zugangsdaten: kein Bestandteil dieses Moduls, Kandidat für ein eigenständiges Folgemodul. - • Konsistente Backup-Strategien (Dateisystem-Backup per Helfer-Container, Datenbank-Dump im laufenden Betrieb): für Persistenz- und Backup/Restore-Verfahren an Datenbank-Containern siehe Docker Datenbanken: Persistenz, Backup & Betrieb.
- • Eigene Dockerfiles mit zusätzlichen PHP-Erweiterungen (z. B.
gd,intl): dieses Modul arbeitet ausschließlich mit den offiziellen WordPress-Images, kein eigener Image-Build. - • Nextcloud als containerisierter Enterprise-Cloud-Speicher, eigenständiges Thema, hier nicht behandelt.
- • Joomla als alternatives CMS-System: wird nicht geübt, das Architekturprinzip aus diesem Modul überträgt sich aber direkt.
- • Systemweite Docker-Ressourcenbereinigung (
docker system pruneund gezielte Bereinigung): kein Bestandteil dieses Moduls. - • 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