Mitglied werden – KI-Tutor mit vollen Antworten

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 per compose.yaml aufsetzen und starten.
  • WordPress komplett ohne Browser administrieren: Erstinstallation per wp core install, Plugins auflisten und aktualisieren per wp plugin list und wp plugin update –all.
  • Das Prinzip der Daten-Persistenz in der Praxis anwenden: Named Volumes für /var/www/html und 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-cli und 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

  1. 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.

  2. Hands-on 1: WordPress + MariaDB per Compose (45 min): vollständiger Drei-Dienste-Stack (web, db, cli) per compose.yaml, Start und Statusprüfung.

  3. Hands-on 2: Administration per wp-cli (30 min): Erstinstallation per wp core install, Plugins auflisten und aktualisieren, komplett ohne Browser.

  4. Pause (10 min).
  5. 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.

  6. 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 erzeugt wp-cli selbst)
  • docker compose run –rm cli wp plugin list und wp plugin update –all für Plugin-Pflege komplett per CLI
  • user: “33:33” im cli-Service verhindert Permission-Denied-Konflikte beim Schreiben ins Webroot (Benutzer www-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 & pwgen fü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 prune und 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