WordPress – Betriebs­dokumentation

Überblick

WordPress läuft auf einem Single-Node-K3s-Cluster auf AlmaLinux 9. Die gesamte Infrastruktur wird mit einem Ansible-Playbook (blog.yml) aufgebaut und verwaltet. Das Playbook ist idempotent – es kann jederzeit neu ausgeführt werden, ohne Daten zu verändern oder Dienste unnötig zu unterbrechen.

Architektur

Gesamtüberblick

Warum dieser Ansatz?

WordPress-Pod im Detail

Speicher & Daten

Warum sind App und Datenbank getrennte Volumes?

• Datenbankdaten (/srv/wordpress-db) können unabhängig gesichert werden
• WordPress-Dateien werden bei einem Update durch das neue Image ergänzt (der Entrypoint aktualisiert Core-Dateien in-place)
• Beide Volumes überleben einen Pod-Neustart oder ein Image-Update unbeschädigt

Ownership und Berechtigungen

WordPress-FPM läuft als www-data (UID 33 im Container). Das HostPath-Verzeichnis muss für diesen Benutzer schreibbar sein:

# Ownership für WordPress-Dateien setzen (vom Host):
chown -R 33:33 /srv/wordpress-www

# Datenbankdaten gehören root (MariaDB im Container nutzt root intern):
ls -la /srv/wordpress-db

Netzwerk & TLS

IP-Adressbereiche

Benötigte DNS-Einträge

Vor dem ersten Playbook-Lauf muss der DNS-Eintrag beim Domain-Registrar angelegt sein. cert-manager benötigt ihn für den Let's Encrypt HTTP-01-Challenge – ohne gültigen Eintrag schlägt die Zertifikatsausstellung fehl.

TLS und Proxy-Kette

Internet
  → nginx-ingress F5 (Port 443, TLS terminiert, setzt X-Forwarded-For / -Proto)
    → nginx-Sidecar (Port 80, plain HTTP)
      → PHP-FPM (Port 9000, FastCGI)

nginx-ingress leitet Anfragen aus seinem Pod-Namespace (10.42.x.x) weiter. Der nginx-Sidecar ist so konfiguriert, dass er die echte Client-IP aus dem X-Forwarded-For-Header liest:

# nginx-ConfigMap (nginx-cm.yml.j2):
set_real_ip_from 10.42.0.0/16;   # Pod-CIDR – dort kommen ingress-Pakete her
real_ip_header   X-Forwarded-For;
real_ip_recursive on;

Rate-Limiting und Sicherheit am Ingress

Schutzmaßnahmen sind direkt im Ingress über nginx.org/-Annotations definiert:

Wichtige Dateien im Repository

Inventory & Variablen

Ansible-Rollen (WordPress-spezifisch)

Templates (erzeugen die K8s-Manifeste)

Variablen & Secrets

Wo Credentials liegen

Alle Passwörter stehen in inventory/host_vars/www.apt-upgrade.me/vault.yml, verschlüsselt mit Ansible Vault. Diese Datei darf niemals unverschlüsselt in git committed werden.

# Verschlüsseln vor dem Commit:
ansible-vault encrypt inventory/host_vars/www.apt-upgrade.me/vault.yml

# Direkt im Editor öffnen (bevorzugt):
ansible-vault edit inventory/host_vars/www.apt-upgrade.me/vault.yml

Typischer Inhalt vault.yml

blog_db_root_pass: "..."       # MariaDB root-Passwort
blog_db_pass:      "..."       # WordPress DB-Benutzer-Passwort
blog_admin_pass:   "..."       # WordPress Admin-Passwort
mail_smtppass:     "..."       # SMTP-Passwort für Mail-Versand
grafana_admin_pass: "..."      # Grafana Admin-Passwort

Secrets im K8s-Cluster

Die Vault-Variablen fließen beim Playbook-Run in das K8s-Secret wordpress-secrets im Namespace wordpress.

# Secret anzeigen (dekodiert):
k3s kubectl get secret wordpress-secrets -n wordpress \
  -o jsonpath='{.data}' | python3 -c \
  "import sys,json,base64; [print(k,base64.b64decode(v).decode()) \
   for k,v in json.load(sys.stdin).items()]"

Container-Images & Versionen

Alle Image-Tags sind in inventory/group_vars/all.yml zentral definiert. K3s zieht automatisch ein neues Image nur dann, wenn der Tag im Manifest geändert wurde (imagePullPolicy: IfNotPresent).

# inventory/group_vars/all.yml
blog_image_wordpress: "wordpress:6.9-fpm"   # WordPress PHP-FPM
blog_image_mariadb:   "mariadb:10.11"       # MariaDB LTS
blog_image_nginx:     "nginx:1.30-alpine"   # nginx Sidecar

Tag-Strategie

Neue Versionen prüfen

crictl pull docker.io/library/wordpress:6.9-fpm
k3s kubectl rollout restart deployment/wordpress -n wordpress

WordPress-Konfiguration

wp-config.php

Die wp-config.php wird beim ersten Start vom WordPress-Docker-Entrypoint automatisch aus den Umgebungsvariablen erzeugt. Wichtige generierte Einträge:

define('DB_HOST',     'mariadb');          // K8s Service-Name im Namespace
define('DB_NAME',     'wordpress_db');
define('DB_USER',     'wordpress');
define('DB_PASSWORD', '...');              // aus K8s Secret

// WordPress-eigener Cron ist deaktiviert (K8s CronJob übernimmt):
define('DISABLE_WP_CRON', true);

// URL-Einstellungen (von Ansible gesetzt):
define('WP_HOME',    'https://www.apt-upgrade.me');
define('WP_SITEURL', 'https://www.apt-upgrade.me');

Plugins (via Ansible verwaltet)

Plugins werden in inventory/host_vars/www.apt-upgrade.me/vars.yml als Liste definiert und vom blog_wordpress-Playbook automatisch installiert und aktiviert:

blog_wordpress_plugins:
  - all-in-one-wp-migration       # Import/Export für Backups
  - classic-editor                # Klassischer Editor statt Gutenberg
  - limit-login-attempts-reloaded # Zusätzlicher Brute-Force-Schutz

Datenbank direkt abfragen

# Im MariaDB-Pod (kein Root-Passwort nötig, da socket auth):
k3s kubectl exec -n wordpress deployment/mariadb -- \
  mysql -u wordpress -p wordpress_db

# Oder mit explizitem Passwort:
k3s kubectl exec -n wordpress deployment/mariadb -- \
  mysql -u wordpress -p'<passwort>' wordpress_db -e "SHOW TABLES;"

Playbook ausführen

Vollständiger Erstlauf (neue Server-Installation)

1. SSH-Port auf 22 setzen in inventory/host_vars/www.apt-upgrade.me/vars.yml: ansible_port: 22
2. Vault-Passwörter in vault.yml eintragen und verschlüsseln
3. Collections installieren: ansible-galaxy collection install -r requirements.yml
4. Playbook ausführen:

   ansible-playbook blog.yml --limit www.apt-upgrade.me --ask-vault-pass

5. SSH-Port in vars.yml auf 10022 ändern (nach SSH-Hardening durch common_ssh)

Idempotente Wiederholung (z.B. nach Konfig-Änderung)

ansible-playbook blog.yml --limit www.apt-upgrade.me --ask-vault-pass

Nur bestimmte Rollen ausführen

# Nur K8s-Deployments aktualisieren
ansible-playbook blog.yml --limit www.apt-upgrade.me --tags blog_k3s_deploy --ask-vault-pass

# Nur WordPress-Konfiguration (Plugins, Admin, Einstellungen)
ansible-playbook blog.yml --limit www.apt-upgrade.me --tags blog_wordpress --ask-vault-pass

Wichtige Betriebsbefehle

Pod-Status

# Alle Pods im wordpress-Namespace
k3s kubectl get pods -n wordpress

# Detaillierter Status
k3s kubectl describe pod -l app=wordpress -n wordpress

# Logs WordPress-FPM
k3s kubectl logs deployment/wordpress -c wordpress-fpm -n wordpress --tail=50

# Logs nginx-Sidecar
k3s kubectl logs deployment/wordpress -c nginx -n wordpress --tail=50

# Logs MariaDB
k3s kubectl logs deployment/mariadb -n wordpress --tail=50

WP-CLI-Befehle

# Prefix für alle WP-CLI-Befehle:
k3s kubectl exec -n wordpress deployment/wordpress -c wordpress-fpm -- \
  wp --allow-root <BEFEHL>

# Beispiele:
... wp core version
... wp core check-update
... wp plugin list
... wp plugin update --all
... wp theme list
... wp cache flush
... wp cron event list
... wp user list
... wp db check
... wp search-replace 'http://www.apt-upgrade.me' 'https://www.apt-upgrade.me' --dry-run

Pod neustarten

# WordPress
k3s kubectl rollout restart deployment/wordpress -n wordpress
k3s kubectl rollout status  deployment/wordpress -n wordpress --timeout=300s

# MariaDB (Achtung: kurze DB-Downtime!)
k3s kubectl rollout restart deployment/mariadb -n wordpress

Namespace-Übersicht

k3s kubectl get all -n wordpress

Ingress und Zertifikat prüfen

# Ingress-Ressource
k3s kubectl get ingress -n wordpress
k3s kubectl describe ingress wordpress -n wordpress

# TLS-Zertifikat
k3s kubectl get certificate -n wordpress
k3s kubectl describe certificate wordpress-tls -n wordpress

Monitoring

Der Monitoring-Stack (Prometheus + Grafana + Node Exporter + mysqld_exporter + php-fpm_exporter) läuft teils als Host-Dienste, teils als Sidecar-Container in K3s-Pods. Grafana ist über den Ingress am Blog-Hostname unter /grafana/ erreichbar.

MariaDB Slow Query Log

Der MariaDB-Pod schreibt langsame Queries (≥ 1 Sekunde) nach /var/lib/mysql/slow.log – das liegt im HostPath-Volume und ist auf dem Host unter /srv/wordpress-db/slow.log lesbar. (Hintergrund: /dev/stderr ist im MariaDB-Container unter K3s nicht beschreibbar – der mysql-Prozess erhält uid 999 und hat keinen Zugriff auf den fd.)

# Slow Queries auf dem Host lesen
tail -f /srv/wordpress-db/slow.log

# Oder im Pod direkt
k3s kubectl exec -n wordpress deployment/mariadb -c mariadb -- \
  tail -f /var/lib/mysql/slow.log

Konfiguration: MariaDB-Pod-Args --slow-query-log=1 --slow-query-log-file=/var/lib/mysql/slow.log --long-query-time=1

PHP-FPM Slow Log

PHP-FPM loggt Requests, die länger als 5 Sekunden dauern, nach /proc/1/fd/2 (entspricht stderr des Pod-Hauptprozesses). Da ptrace in Containern nicht verfügbar ist, werden keine Stack-Traces geschrieben – nur der Request-Zeitstempel und die Ausführungszeit.

# Slow FPM Requests verfolgen
k3s kubectl logs -n wordpress deployment/wordpress -c wordpress-fpm -f | grep -i "slow"

Konfiguration: ConfigMap wordpress-fpm-pool-config → pm.status_path = /fpm-status, slowlog = /proc/1/fd/2, request_slowlog_timeout = 5s

Grafana Dashboards

Node Exporter Full (ID 1860) – Host-Metriken

Zeigt den Gesundheitszustand des gesamten Servers in Echtzeit.

MySQL Overview (ID 7362) – MariaDB-Datenbankmetriken

Zeigt die Performance der WordPress-Datenbank (MariaDB-Sidecar im K3s-Pod, NodePort 30104).

PHP-FPM (ID 4912) – PHP-Prozesspool

Zeigt wie gut PHP-FPM die WordPress-Anfragen verarbeitet (K3s-Pod, NodePort 30253).

mysqld_exporter – Konfigurationshinweis

Prometheus Scrape-Ziele

# Aktive Scrape-Ziele prüfen (im Browser oder curl)
curl -s http://127.0.0.1:9090/api/v1/targets | python3 -m json.tool | grep -E '"job"|"state"|"scrapeUrl"'

WP-Cron

WordPress benötigt einen regelmäßigen Cron-Aufruf für geplante Aufgaben: Plugin-Updates, E-Mail-Versand, Veröffentlichung geplanter Beiträge etc. In diesem Setup übernimmt ein Kubernetes CronJob diese Aufgabe.

CronJob-Status prüfen

# Status und letzter Lauf
k3s kubectl get cronjob wordpress-cron -n wordpress

# Die letzten 5 Jobs (abgeschlossene Pods)
k3s kubectl get jobs -n wordpress --sort-by=.metadata.creationTimestamp | tail -5

# Logs eines CronJob-Pods (ID aus vorherigem Befehl):
k3s kubectl logs -n wordpress -l job-name=wordpress-cron-<id>

Manuelle Ausführung (für Tests)

k3s kubectl exec -n wordpress deployment/wordpress -c wordpress-fpm -- \
  php /var/www/html/wp-cron.php

Updates

Betriebssystem (AlmaLinux 9)

Security-Updates werden durch dnf-automatic täglich automatisch eingespielt. Für ein vollständiges System-Update:

1. ssh -p 10022 root@217.154.101.78
   dnf upgrade -y

2. Prüfen ob ein Reboot nötig ist:

   needs-restarting -r

3. Bei Bedarf: Server rebooten. K3s startet automatisch, alle Pods kommen selbst wieder hoch.

   reboot
   # Danach prüfen:
   k3s kubectl get pods -n wordpress

WordPress-Update: Patch innerhalb desselben Tags

Wenn Docker Hub wordpress:6.9-fpm auf 6.9.1 aktualisiert und der Tag im Ansible unverändert bleibt:

1. Neues Image manuell pullen:

   crictl pull docker.io/library/wordpress:6.9-fpm

2. Pod neu starten:

   k3s kubectl rollout restart deployment/wordpress -n wordpress
   k3s kubectl rollout status  deployment/wordpress -n wordpress --timeout=300s

WordPress-Update: Minor-Versionssprung (z.B. 6.9 → 7.0)

1. Tag in inventory/group_vars/all.yml ändern:

   blog_image_wordpress: "wordpress:7.0-fpm"

2. Playbook ausführen – K3s zieht das neue Image und rollt den Pod durch:

   ansible-playbook blog.yml --limit www.apt-upgrade.me --ask-vault-pass

3. WordPress-DB-Update prüfen (bei Major-Versionen manchmal nötig):

   k3s kubectl exec -n wordpress deployment/wordpress -c wordpress-fpm -- \
     wp --allow-root core update-db

MariaDB-Update

Patch-Updates innerhalb von 10.11:

crictl pull docker.io/library/mariadb:10.11
k3s kubectl rollout restart deployment/mariadb -n wordpress

Backup & Restore

Was gesichert wird

Backup ausführen

Das Backup-Skript hat kein Umgebungs-Argument – es sichert immer www.apt-upgrade.me nach /data/wordpress/www.apt-upgrade.me/.

# Aus dem Repository-Verzeichnis aufrufen:
cd ~/www_k3s
./scripts/wordpress-backup.sh

# Ablauf:
# 1. WP-CLI maintenance-mode activate  (im wordpress-fpm Container)
# 2. kubectl exec → mysqldump          (im mariadb-Container, Passwort aus K8s-Secret)
# 3. rsync /srv/wordpress-www/         → /data/wordpress/www.apt-upgrade.me/wordpress/
# 4. WP-CLI maintenance-mode deactivate

Restore-Workflow

1. Server neu aufsetzen (Infrastructure):

   ansible-playbook blog.yml --limit www.apt-upgrade.me --ask-vault-pass

2. Restore-Skript ausführen:

   cd ~/www_k3s
   ./scripts/wordpress-restore.sh

   Ablauf: Maintenance an → WordPress + MariaDB stoppen → rsync WordPress-Dateien → MariaDB-Daten-Dir leeren → MariaDB starten (Neu-Initialisierung aus K8s-Secret) → SQL-Dump importieren → Ownership fix → WordPress starten → Maintenance aus

3. Ansible erneut ausführen (stellt Plugin-Liste und WP-Config sicher):

   ansible-playbook blog.yml --limit www.apt-upgrade.me --ask-vault-pass

Manuelle Einzel-Befehle (Referenz)

# mysqldump aus dem MariaDB-Pod (MARIADB_ROOT_PASSWORD aus K8s-Secret)
k3s kubectl exec -n wordpress deployment/mariadb -c mariadb -- \
  sh -c 'mysqldump --single-transaction wordpress_db \
    -u root -p"$MARIADB_ROOT_PASSWORD"'

# SQL-Dump in laufenden MariaDB-Pod importieren
k3s kubectl exec -n wordpress deployment/mariadb -c mariadb -- \
  sh -c 'mysql wordpress_db -u root -p"$MARIADB_ROOT_PASSWORD" < /tmp/dump.sql'

# WP-CLI Maintenance
k3s kubectl exec -n wordpress deployment/wordpress -c wordpress-fpm -- \
  php /var/www/html/wp-cli.phar maintenance-mode activate --path=/var/www/html --allow-root

Troubleshooting

WordPress-Pod startet nicht / CrashLoopBackOff

k3s kubectl describe pod -l app=wordpress -n wordpress
k3s kubectl logs deployment/wordpress -c wordpress-fpm -n wordpress --previous

Typische Ursachen:

• Datenbank nicht erreichbar: MariaDB-Pod läuft nicht. k3s kubectl get pods -n wordpress prüfen.
• Falsches DB-Passwort: Secret wordpress-secrets stimmt nicht mit dem MariaDB-Benutzer überein. Playbook neu ausführen.
• Volume-Berechtigungen: chown -R 33:33 /srv/wordpress-www und Pod neu starten.

MariaDB-Pod startet nicht

k3s kubectl logs deployment/mariadb -n wordpress --previous

• Datenbankdateien beschädigt: MariaDB versucht eine Recovery. Im schlimmsten Fall müssen die Daten aus dem Backup wiederhergestellt werden.
• Volume-Berechtigungen: MariaDB erwartet, dass /srv/wordpress-db für den internen mysql-User (UID 999) schreibbar ist. Ansible setzt die Berechtigungen automatisch.

WordPress-Seite zeigt 502 Bad Gateway

nginx-Sidecar kann PHP-FPM nicht erreichen. Prüfen:

# Läuft PHP-FPM?
k3s kubectl logs deployment/wordpress -c wordpress-fpm -n wordpress --tail=20

# Sind beide Container im Pod Ready?
k3s kubectl get pod -l app=wordpress -n wordpress

WordPress-Admin-Backend: "Es sind Datenbankaktualisierungen erforderlich"

k3s kubectl exec -n wordpress deployment/wordpress -c wordpress-fpm -- \
  wp --allow-root core update-db

Zertifikat wird nicht ausgestellt

# cert-manager Logs:
k3s kubectl logs -n cert-manager deployment/cert-manager --tail=50

# Certificate-Objekt:
k3s kubectl describe certificate wordpress-tls -n wordpress

# ClusterIssuer-Status:
k3s kubectl describe clusterissuer letsencrypt-prod

Häufige Ursache: Port 80 ist durch iptables oder den Provider blockiert. cert-manager benötigt Port 80 für den HTTP-01-Challenge (auch wenn die Site nur über HTTPS erreichbar sein soll).

Rate-Limiting greift zu aggressiv (eigene IP gesperrt)

# Ingress-Logs prüfen (nginx-ingress-Controller):
k3s kubectl logs -n ingress-nginx daemonset/ingress-nginx-nginx-ingress-controller --tail=50

# Temporär: Ingress ohne Rate-Limit neu deployen (für Notfälle):
# → nginx.org/server-snippets Annotation im Ingress entfernen und Playbook ausführen

WP-Cron läuft nicht

# CronJob-Status:
k3s kubectl get cronjob wordpress-cron -n wordpress

# Letzter Job-Pod (sollte "Completed" sein):
k3s kubectl get pods -n wordpress --sort-by=.metadata.creationTimestamp | tail -5

# Manuell auslösen (für Test):
k3s kubectl exec -n wordpress deployment/wordpress -c wordpress-fpm -- \
  php /var/www/html/wp-cron.php

Sicherheit

Mehrschichtige Schutzstrategie

Firewall im Detail

Das Skript /root/fw/fw_ipv4.sh (aus common_firewall) wird per @reboot-Cronjob nach jedem Neustart angewendet. K3s fügt danach seine eigenen KUBE-*-Chains oben in die INPUT/OUTPUT-Chains ein.

# Geblockte Pakete live verfolgen
journalctl -k -f --grep "IPTables-Dropped"

# Portscan-Blockliste anzeigen
cat /proc/net/xt_recent/portscan | awk '{print $1}'

# Firewall-Regeln neu laden (nach Reboot passiert das automatisch)
/root/fw/fw_ipv4.sh && /root/fw/fw_ipv6.sh

Wichtige Sicherheitshinweise