Beyond the Basics: Architecting Highly Available and Scalable WordPress Headless with Docker, AWS ECS, and RDS Aurora

Dockerizing WordPress and its Dependencies

To achieve a robust and scalable WordPress deployment, we’ll leverage Docker. This allows for consistent environments and simplified management. Our core components will be the WordPress application itself, an Nginx web server for serving static assets and proxying requests, and a MySQL-compatible database. For this example, we’ll use the official WordPress image, Nginx, and a standard MySQL image, though we’ll later discuss migrating to RDS Aurora.

Here’s a foundational docker-compose.yml file:

version: '3.8'

services:
  wordpress:
    image: wordpress:latest
    container_name: wordpress_app
    restart: unless-stopped
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpressuser
      WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
      WORDPRESS_DB_NAME: wordpressdb
    volumes:
      - wordpress_data:/var/www/html
    depends_on:
      - db
    networks:
      - wordpress_network

  db:
    image: mysql:8.0
    container_name: wordpress_db
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: wordpressdb
      MYSQL_USER: wordpressuser
      MYSQL_PASSWORD: ${WORDPRESS_DB_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql
    networks:
      - wordpress_network

  nginx:
    image: nginx:latest
    container_name: wordpress_nginx
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - wordpress_data:/var/www/html:ro # Mount WordPress files read-only
    depends_on:
      - wordpress
    networks:
      - wordpress_network

volumes:
  wordpress_data:
  db_data:

networks:
  wordpress_network:
    driver: bridge

You’ll need to create a .env file in the same directory to store sensitive credentials:

WORDPRESS_DB_PASSWORD=your_strong_db_password
MYSQL_ROOT_PASSWORD=your_strong_root_password

The Nginx configuration (nginx.conf) will be crucial for routing and performance. Here’s a basic setup:

user nginx;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";

    include /etc/nginx/conf.d/*.conf;
}

And a specific server block for WordPress (e.g., conf.d/wordpress.conf):

server {
    listen 80;
    server_name your_domain.com www.your_domain.com;

    location / {
        proxy_pass http://wordpress_app:9000; # Assuming PHP-FPM is running on port 9000 inside the wordpress container
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Serve static files directly from Nginx for performance
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2|ttf|eot)$ {
        root /var/www/html;
        expires 30d;
        access_log off;
        add_header Cache-Control "public, max-age=2592000";
    }

    # Deny access to sensitive files
    location ~ /\. {
        deny all;
    }
}

Note: The default WordPress Docker image uses PHP-FPM. The Nginx configuration above assumes PHP-FPM is listening on port 9000 within the `wordpress_app` container. If you’re using a different WordPress image or setup, adjust the `proxy_pass` directive accordingly. For a headless setup, you’d typically have a separate API service that the `wordpress` container communicates with, or the WordPress container itself would expose an API endpoint.

AWS ECS for Orchestration and Scalability

AWS Elastic Container Service (ECS) is our chosen orchestrator. It provides a highly available, scalable, and secure way to run Docker containers on AWS. We’ll define Task Definitions and Services to manage our WordPress stack.

First, we need to push our Docker images to Amazon Elastic Container Registry (ECR). You can build your images locally and then tag and push them:

# Login to ECR
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin YOUR_AWS_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com

# Create ECR repositories (if they don't exist)
aws ecr create-repository --repository-name wordpress-app --region us-east-1
aws ecr create-repository --repository-name wordpress-nginx --region us-east-1
aws ecr create-repository --repository-name wordpress-db --region us-east-1

# Build and tag your images (assuming you have Dockerfiles for nginx and potentially a custom wordpress image)
# For simplicity, we'll use official images and push them to ECR if needed, or reference them directly if available in ECR Public.
# If you have a custom Dockerfile for Nginx:
# docker build -t wordpress-nginx . -f Dockerfile.nginx
# docker tag wordpress-nginx:latest YOUR_AWS_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/wordpress-nginx:latest
# docker push YOUR_AWS_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/wordpress-nginx:latest

# For official images, you can often reference them directly in ECS, or pull and re-tag if specific versions are required.
# Example: Using official images directly in ECS Task Definition is more common.

Next, we define our ECS Task Definitions. These describe the containers that will run as part of our application. We’ll create separate task definitions for WordPress, Nginx, and potentially a database if not using RDS.

WordPress Task Definition (Simplified JSON):

{
    "family": "wordpress-app-task",
    "networkMode": "awsvpc",
    "requiresCompatibilities": ["FARGATE"],
    "cpu": "1024",
    "memory": "2048",
    "executionRoleArn": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/ecsTaskExecutionRole",
    "taskRoleArn": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/ecsTaskRole",
    "containerDefinitions": [
        {
            "name": "wordpress",
            "image": "wordpress:latest",
            "essential": true,
            "portMappings": [
                {
                    "containerPort": 9000,
                    "protocol": "tcp"
                }
            ],
            "environment": [
                {
                    "name": "WORDPRESS_DB_HOST",
                    "value": "your-rds-endpoint.rds.amazonaws.com:3306"
                },
                {
                    "name": "WORDPRESS_DB_USER",
                    "value": "wordpressuser"
                },
                {
                    "name": "WORDPRESS_DB_PASSWORD",
                    "valueFrom": "arn:aws:secretsmanager:us-east-1:YOUR_AWS_ACCOUNT_ID:secret:your-wordpress-db-secret-XXXXXX:password::"
                },
                {
                    "name": "WORDPRESS_DB_NAME",
                    "value": "wordpressdb"
                }
            ],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "/ecs/wordpress-app",
                    "awslogs-region": "us-east-1",
                    "awslogs-stream-prefix": "ecs"
                }
            },
            "mountPoints": [
                {
                    "sourceVolume": "wordpress-data",
                    "containerPath": "/var/www/html"
                }
            ]
        }
    ],
    "volumes": [
        {
            "name": "wordpress-data",
            "efsVolumeConfiguration": {
                "fileSystemId": "fs-xxxxxxxxxxxxxxxxx",
                "rootDirectoryPath": "/"
            }
        }
    ]
}

Nginx Task Definition (Simplified JSON):

{
    "family": "wordpress-nginx-task",
    "networkMode": "awsvpc",
    "requiresCompatibilities": ["FARGATE"],
    "cpu": "512",
    "memory": "1024",
    "executionRoleArn": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/ecsTaskExecutionRole",
    "containerDefinitions": [
        {
            "name": "nginx",
            "image": "nginx:latest",
            "essential": true,
            "portMappings": [
                {
                    "containerPort": 80,
                    "protocol": "tcp"
                },
                {
                    "containerPort": 443,
                    "protocol": "tcp"
                }
            ],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "/ecs/wordpress-nginx",
                    "awslogs-region": "us-east-1",
                    "awslogs-stream-prefix": "ecs"
                }
            },
            "mountPoints": [
                {
                    "sourceVolume": "wordpress-data",
                    "containerPath": "/var/www/html",
                    "readOnly": true
                },
                {
                    "sourceVolume": "nginx-config",
                    "containerPath": "/etc/nginx/nginx.conf",
                    "readOnly": true
                }
            ]
        }
    ],
    "volumes": [
        {
            "name": "wordpress-data",
            "efsVolumeConfiguration": {
                "fileSystemId": "fs-xxxxxxxxxxxxxxxxx",
                "rootDirectoryPath": "/"
            }
        },
        {
            "name": "nginx-config",
            "host": {
                "sourcePath": "/path/to/your/nginx.conf"
            }
        }
    ]
}

Important Considerations for ECS:**

# AWS CLI Example (simplified)
aws ecs create-service \
    --cluster your-ecs-cluster \
    --service-name wordpress-nginx-service \
    --task-definition wordpress-nginx-task:1 \
    --desired-count 2 \
    --load-balancers targetGroupArn=your-alb-target-group-arn,containerName=nginx,containerPort=80 \
    --network-configuration "awsvpcConfiguration={subnets=[subnet-xxxxxxxx,subnet-yyyyyyyy],securityGroups=[sg-zzzzzzzz],assignPublicIp=DISABLED}" \
    --service-registries registry-arn=your-service-discovery-registry-arn \
    --auto-scaling '{"targetTrackingConfiguration": {"targetValue": 70.0, "predefinedMetricSpecification": {"predefinedMetricType": "ALBRequestCountPerTarget"}, "scaleInCooldown": 300, "scaleOutCooldown": 300}}'