azionelab-v2/docs/operations.md

Operations

Routine commands

docker compose up --build -d
docker compose ps
docker compose logs -f proxy wordpress wp-cron db certbot
./scripts/prepare-host-volumes.sh
docker compose --profile tools run --rm wp-cli -c 'wp core version'
docker compose --profile tools run --rm wp-cli -c 'wp cron event list'
docker compose down

The proxy healthcheck reaches WordPress, and WordPress health reaches its login route. MariaDB uses its official readiness check. WordPress access logs are disabled while PHP warnings/errors remain visible. NGINX is the request audit trail; apply an explicit retention policy because it contains client metadata.

Updates

WordPress, PHP, MariaDB, NGINX, Certbot, and Playwright use explicit image versions. Review security releases routinely, update pins in a task branch, rebuild, run the full test suite, and deploy. Production disables WordPress web-based file modifications, so image rebuilds are the update path.

The default wp-cli service is attached only to the internal data network. When a maintenance command must download from the internet, use docker-compose.maintenance.yml explicitly:

docker compose -f docker-compose.yml -f docker-compose.maintenance.yml --profile tools run --rm wp-cli -c 'wp core update --version=7.0.2 --force'
docker compose -f docker-compose.yml -f docker-compose.maintenance.yml --profile tools run --rm wp-cli -c 'wp core update-db'
docker compose --profile tools run --rm wp-cli -c 'wp core version'
docker compose restart wordpress proxy

Do not use the maintenance override for routine bootstrap or inspection commands that do not need outbound network access.

External wp-cron.php requests are blocked to reduce public attack surface. The default wp-cron service runs due scheduled events internally through WP-CLI every WP_CRON_INTERVAL_SECONDS seconds, defaults to 300, and joins only the internal data network. If a scheduled job is late, inspect docker compose logs wp-cron wordpress db and run docker compose --profile tools run --rm wp-cli -c 'wp cron event list'.

Backup and restore

Create database and WordPress file backups in one maintenance window. The default host paths are ./runtime/db, ./runtime/wordpress, ./runtime/letsencrypt, and ./runtime/certbot/www, unless overridden in .env. Backups contain credentials, accounts, contact information, and uploaded media; encrypt them, restrict access, set retention, and store copies off-host.

A restore is destructive. Validate it on isolated volumes, then stop WordPress, restore the database and file volume together, restart, and verify the homepage, media, /wp-admin/, and user accounts.

Known risks

• Local host directories are not backups.
• A host-based volume may be unreadable by the application if created with the wrong owner or mode; run ./scripts/prepare-host-volumes.sh after changing paths or image user IDs.
• SMTP is not configured; WordPress password-reset email needs an external mail service.
• WordPress cron is not publicly triggerable; scheduled jobs depend on the internal wp-cron runner being healthy.
• Admin MFA and network allowlisting are deployment concerns and are not bundled.
• WordPress plugins expand the attack surface; install only reviewed, maintained, necessary plugins.