Due to the recent influx in demand for the creation of WordPress sites, TycloudDC was faced with the need for its automation.
Our solution: the WPO (WordPress Orchestrator)
The WPO is a self-created tool that orchestrates other self-created and third party tools to successfully deploy, launch, manage, and replicate docker containers attached to persistent, WordPress data. WPO is a script that consists of 5 modules, each module being a separate script that completes a specific function in parallel to streamline container deployment. Using Ansible Automation Platform (AAP) as the frontend of the deployment, developers never require or ever have access to the backend servers and are also limited in actions executable against the server. Simply stated, the WPO is a tool that creates a WordPress site on-premises, duplicates it into the cloud, and keeps changes synced between the two.

Simply stated, the WPO is a tool that creates a WordPress site on-premises, duplicates it into the cloud, and keeps changes synced between the two.
TL:DR
The WPO logic is as follows:
- The admin inserts values into the AAP UI to specify website name, URL, and optionally DNS TTL.
- AAP passes these values to the WordPress Orchestrator tool.
- The WPO creates a docker-compose file (IaC) as well as creates a parameter file containing attributes of the newly created container
- Using this parameter file, the WPO creates DNS records, NGINX reverse proxy, and requests SSL certs if needed.
- After container is successfully created, parameter file and docker-compose file is uploaded into AWS S3.
- The WPO is notified that on-prem container creation finished and replicated the WordPress site in AWS for failover. Parameter file continues to map cloud failover site to corresponding on-prem resource.
- When changes are made to the WordPress site on-prem, the changes are evaluated against the cloud failover and only the differences are pushed into the cloud.
To see how the WPO architecture fits in the grand architecture of TycloudDC networking, please check out our network diagram here.
Deeper Dive
1) Deploying Parameters into the WordPress Orchestrator (WPO)

2) Ansible Automation Platform (AAP) passes user input into the WPO to create the skeleton of parameter file.

3a.) WPO creates a docker-compose.yml template to deploy container using supplied values:
version: "3"
services:
db:
image: mysql:5.7
container image from Docker Hub used in this installation.
restart: always
environment:
MYSQL_ROOT_PASSWORD: [redacted]
MYSQL_DATABASE: database
MYSQL_USER: user
MYSQL_PASSWORD: [redacted]
wordpress:
depends_on:
- db
image: wordpress:latest
restart: always
ports:
- "8050:80"
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: user
WORDPRESS_DB_PASSWORD: [redacted]
WORDPRESS_DB_NAME: user
volumes:
- 'mysqldb:/var/lib/mysql'
volumes:
mysqldb: {}
3b.) Example of created parameter file after successful WordPress deployment on prem:
{
"customer_info": {
"name": "NameHere"
},
"site_info": {
"name": "WebsiteName",
"short_name": "websitename",
"ssl_cert_needed": "false",
"ssl_email": "ssl@tycloud.us",
"wp_container_name": "tycloud-wordpress",
"db_container_name": "tycloud-db",
"db_volume": "800",
"occupied_port": "8050",
"route53_zone_name": "tycloud.us",
"route53_zone_pretty_name": "",
"route53_zone_id": "",
"ttl": "69",
"website_url": "exampletest.tycloud.us",
"unique_id": "1234567"
},
"on_prem": {
"db_vol_location": "/path/to/volumes/data",
"wp_vol_location": "path/to/volumes/data"
},
"aws_info": {
"aws_db_vol_location": "",
"aws_wp_vol_location": ""
}
}
4.) The WPO then takes these values above to interact with AWS Route53 to setup DNS records, NGINX reverse proxy, as well as generate SSL certificates.
5-6.) Parameter file uploaded and AWS Replicator module deploys infrastructure in AWS.
7.) Missing values within parameter file are filled (attributes of AWS containers)