azionelab-v2/docs/operations.md

Operations

Routine commands

docker compose up --build -d
docker compose ps
docker compose logs -f proxy wordpress db certbot
./scripts/prepare-host-volumes.sh
docker compose --profile tools run --rm wp-cli -c 'wp core version'
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. If future content scheduling, maintenance jobs, or plugin features require WordPress cron, run it from a controlled host/container cron against the private WordPress service instead of leaving the public trigger enabled.

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 need an operator-managed cron runner if that feature becomes necessary.
• Admin MFA and network allowlisting are deployment concerns and are not bundled.
• WordPress plugins expand the attack surface; install only reviewed, maintained, necessary plugins.