generated from bisco/codex-bootstrap
bisco
69 lines
3.1 KiB
Markdown
69 lines
3.1 KiB
Markdown
# Operations
|
|
|
|
## Routine commands
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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.
|