Ansible & tenant layout

Ansible is the implementation layer for hosting changes. The runner chooses the playbook; the job cannot supply an arbitrary executable.

Playbook map

Job	Playbook	Purpose
Apply	apply-tenant.yml	Create or converge the complete tenant
Inspect	inspect-tenant.yml	Read actual health and manifest
Suspend	suspend-tenant.yml	Make the service unavailable without deleting data
Resume	resume-tenant.yml	Restore a suspended service
Backup	backup-tenant.yml	Create and verify a service backup
Decommission	decommission-tenant.yml	Remove exactly one retained tenant

Apply role order

Roles under mivama_core/ansible/roles cover validation, identity, directory ownership, quota, resource slice, networking, secret generation, workspace container, database, WordPress stack, reverse proxy, backup, monitoring, healthcheck and manifest.

Tenant layout

A service gets a deterministic root below /srv/mivama/tenants/HOSTING-NNNNN. Inside are Compose/runtime configuration, persistent database, WordPress content, workspace/SFTP data, logs, secrets and backup metadata. Exact subpaths remain owned by the tenant identities defined by the playbooks.

Hostnames map to internal application ports and a generated Nginx vhost. Customers never share database credentials or writable WordPress volumes.

WordPress CLI safety

Running wp-cli as root is forbidden because WordPress code would execute with host authority and create root-owned files. Automation enters the WordPress container or uses sudo/container user flags so files retain the customer's tenant ownership. The root runner only orchestrates that boundary.

Decommission precision

The decommission playbook takes one validated service specification. It stops/removes that Compose project, Nginx file, directories, identities, resource slice and related runtime artifacts. Broad globs, guessed paths and workspace-root deletion are not allowed.

Changes to Ansible must remain idempotent and return structured facts expected by the runner.