Dockerizing and Orchestrating Legacy WooCommerce Systems on Modern AWS Infrastructure
Deconstructing the Legacy Monolith: Initial Containerization Strategy
The primary challenge with legacy WooCommerce installations is their monolithic nature, often tightly coupled with specific PHP versions, Apache configurations, and a single MySQL instance. Our goal is to break this monolith into manageable, independently scalable services within Docker containers, targeting a modern AWS infrastructure. This begins with isolating the core WooCommerce application and its dependencies.
We’ll start by creating a Dockerfile for the WooCommerce application itself. This will include the web server (Apache is common for legacy setups, but Nginx can be used for better performance), PHP, and the necessary PHP extensions. We’ll also need to handle Composer dependencies and potentially WordPress core files if they aren’t managed externally.
Dockerfile for WooCommerce Application
This Dockerfile assumes a base Ubuntu image, Apache, and PHP 7.4 (a common version for many legacy WooCommerce sites). Adjust PHP version and extensions as per your specific installation.
# Use an official Apache image as the base
FROM php:7.4-apache
# Install necessary PHP extensions and system packages
RUN apt-get update && apt-get install -y \
libzip-dev \
unzip \
git \
libpng-dev \
libjpeg-dev \
libfreetype6-dev \
libwebp-dev \
libssl-dev \
libicu-dev \
libxslt1-dev \
libonig-dev \
libxml2-dev \
&& docker-php-ext-configure gd --with-freetype --with-webp \
&& docker-php-ext-install -j$(nproc) gd \
&& docker-php-ext-install -j$(nproc) zip \
&& docker-php-ext-install -j$(nproc) pdo \
&& docker-php-ext-install -j$(nproc) pdo_mysql \
&& docker-php-ext-install -j$(nproc) mbstring \
&& docker-php-ext-install -j$(nproc) exif \
&& docker-php-ext-install -j$(nproc) pcntl \
&& docker-php-ext-install -j$(nproc) bcmath \
&& docker-php-ext-install -j$(nproc) opcache \
&& a2enmod rewrite \
&& apt-get clean && rm -rf /var/lib/apt/lists/*
# Copy WordPress and WooCommerce files
# Assuming your WordPress root is in a 'wordpress' directory next to the Dockerfile
COPY ./wordpress/ /var/www/html/
# Install Composer
COPY --from=composer:latest /usr/bin/composer /usr/local/bin/composer
# Set working directory
WORKDIR /var/www/html/
# Install Composer dependencies for WooCommerce and any plugins
RUN composer install --no-dev --prefer-dist --optimize-autoloader
# Configure Apache virtual host
COPY ./apache-config/woocommerce.conf /etc/apache2/sites-available/000-default.conf
# Ensure correct permissions for Apache user
RUN chown -R www-data:www-data /var/www/html/ \
&& chmod -R 755 /var/www/html/ \
&& find /var/www/html/wp-content/uploads -type d -exec chmod 755 {} \; \
&& find /var/www/html/wp-content/uploads -type f -exec chmod 644 {} \;
# Expose port 80
EXPOSE 80
# Start Apache in foreground
CMD ["apache2-foreground"]
Apache Virtual Host Configuration
Create a file named woocommerce.conf in an apache-config directory next to your Dockerfile. This ensures Apache is configured correctly for WordPress and WooCommerce.
<VirtualHost *:80>
DocumentRoot /var/www/html
<Directory /var/www/html>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
DirectoryIndex index.php index.html
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Database Containerization: MySQL/MariaDB
The database is a critical component. For legacy systems, it’s often a single, large MySQL instance. We’ll containerize this using the official MySQL or MariaDB images. Persistent storage is paramount here, so we’ll leverage AWS Elastic File System (EFS) or AWS Elastic Block Store (EBS) volumes.
For simplicity in this example, we’ll use Docker Compose to define the database service and its volume. In a production AWS environment, you’d likely opt for Amazon RDS for managed database services, but for direct containerization, this approach is valid.
Docker Compose for Multi-Container Setup
A docker-compose.yml file orchestrates the application and database containers. This is a foundational step before moving to more advanced orchestration like ECS or EKS.
version: '3.8'
services:
woocommerce_app:
build:
context: .
dockerfile: Dockerfile
ports:
- "8080:80" # Map host port 8080 to container port 80
volumes:
- woocommerce_data:/var/www/html # For persistent application files if needed
- ./wp-content/uploads:/var/www/html/wp-content/uploads # Ensure uploads are persistent
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wordpress_user
WORDPRESS_DB_PASSWORD: your_strong_password
WORDPRESS_DB_NAME: wordpress_db
depends_on:
- db
networks:
- woocommerce_network
db:
image: mysql:5.7 # Or mariadb:10.5
volumes:
- db_data:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: your_root_password
MYSQL_DATABASE: wordpress_db
MYSQL_USER: wordpress_user
MYSQL_PASSWORD: your_strong_password
networks:
- woocommerce_network
volumes:
woocommerce_data:
driver: local # For local development; in AWS, consider EFS
db_data:
driver: local # For local development; in AWS, consider EBS or RDS
networks:
woocommerce_network:
driver: bridge
To run this locally, ensure you have Docker and Docker Compose installed. Navigate to the directory containing your Dockerfile, docker-compose.yml, and the wordpress directory, then execute:
docker-compose up -d
This will build the application image, start the WooCommerce and database containers, and map port 8080 on your host machine to the WooCommerce application. You can then access your WooCommerce site at http://localhost:8080.
Optimizing for AWS: Moving Beyond Docker Compose
While Docker Compose is excellent for local development and simple deployments, AWS offers more robust orchestration services. For containerizing legacy WooCommerce, Amazon Elastic Container Service (ECS) or Amazon Elastic Kubernetes Service (EKS) are prime candidates.
ECS Fargate Deployment Strategy
ECS with Fargate abstracts away the underlying EC2 instances, simplifying management. We’ll define Task Definitions and Services.
First, build your Docker image and push it to Amazon Elastic Container Registry (ECR).
# Build the Docker image docker build -t your-ecr-repo-name:latest . # Authenticate Docker to your ECR registry aws ecr get-login-password --region your-aws-region | docker login --username AWS --password-stdin your-aws-account-id.dkr.ecr.your-aws-region.amazonaws.com # Tag the image docker tag your-ecr-repo-name:latest your-aws-account-id.dkr.dkr.ecr.your-aws-region.amazonaws.com/your-ecr-repo-name:latest # Push the image to ECR docker push your-aws-account-id.dkr.ecr.your-aws-region.amazonaws.com/your-ecr-repo-name:latest
ECS Task Definition
A Task Definition describes how your application containers should run. This is typically defined in JSON.
{
"family": "woocommerce-task",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "1024",
"memory": "2048",
"executionRoleArn": "arn:aws:iam::YOUR_ACCOUNT_ID:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"name": "woocommerce-app",
"image": "YOUR_ACCOUNT_ID.dkr.ecr.YOUR_AWS_REGION.amazonaws.com/your-ecr-repo-name:latest",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
],
"environment": [
{
"name": "WORDPRESS_DB_HOST",
"value": "your-rds-endpoint.rds.amazonaws.com"
},
{
"name": "WORDPRESS_DB_USER",
"value": "wordpress_user"
},
{
"name": "WORDPRESS_DB_PASSWORD",
"value": "your_strong_password"
},
{
"name": "WORDPRESS_DB_NAME",
"value": "wordpress_db"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/woocommerce-task",
"awslogs-region": "your-aws-region",
"awslogs-stream-prefix": "ecs"
}
}
}
]
}
Note: Replace placeholders like YOUR_ACCOUNT_ID, your-aws-region, your-rds-endpoint.rds.amazonaws.com, and credentials. You’ll need an RDS instance provisioned separately. The ecsTaskExecutionRole is crucial for ECS to pull images and send logs.
ECS Service Configuration
The ECS Service manages the desired count of tasks and their deployment. This is configured via the AWS Console or AWS CLI.
Key configurations for the ECS Service:
- Cluster: Create or select an existing ECS cluster.
- Task Definition: Select the Task Definition created above.
- Service Name: e.g.,
woocommerce-service. - Desired Tasks: Start with 1, scale as needed.
- Networking: Use a VPC, subnets, and security groups. Ensure the security group allows inbound traffic on port 80 from your load balancer.
- Load Balancing: Integrate with an Application Load Balancer (ALB). The ALB will distribute traffic to your container instances. Configure a listener on port 80 and a target group pointing to your container port 80.
- Auto Scaling: Configure scaling policies based on CPU utilization, memory, or custom metrics.
Persistent Storage for WooCommerce Uploads
WooCommerce relies heavily on the wp-content/uploads directory for media. In a containerized, ephemeral environment, this data must be persisted. AWS EFS is an excellent choice for shared file storage accessible by multiple container instances.
When setting up your ECS Task Definition or Task Definition revision, you’ll configure a volume mount:
"volumes": [
{
"name": "efs-uploads",
"efsVolumeConfiguration": {
"fileSystemId": "fs-xxxxxxxxxxxxxxxxx",
"rootDirectoryPath": "/",
"transitEncryption": "ENABLED"
}
}
],
"mountPoints": [
{
"sourceVolume": "efs-uploads",
"containerPath": "/var/www/html/wp-content/uploads",
"readOnly": false
}
]
Ensure your ECS Task Definition’s execution role has permissions to access EFS, and your VPC’s security groups allow traffic between your ECS tasks and the EFS mount targets.
Database Management: RDS Integration
For production workloads, running MySQL/MariaDB within ECS is generally not recommended due to the complexities of stateful applications in container orchestrators. Amazon RDS is the standard AWS solution.
When provisioning your RDS instance:
- Choose a suitable instance class (e.g.,
db.t3.mediumor larger depending on load). - Configure Multi-AZ for high availability.
- Set up read replicas for read-heavy workloads.
- Ensure the RDS instance is in the same VPC as your ECS tasks.
- Configure the RDS security group to allow inbound traffic on port 3306 from your ECS task’s security group.
- Use AWS Secrets Manager or AWS Systems Manager Parameter Store to securely manage database credentials instead of hardcoding them in the Task Definition.
Caching and Performance Enhancements
Legacy WooCommerce sites often suffer from performance bottlenecks. Containerization provides opportunities to introduce robust caching layers.
Object Caching: Integrate Redis or Memcached. You can run these as separate services within ECS or use AWS ElastiCache.
// Example using a WordPress plugin for Redis object cache define( 'WP_REDIS_CLIENT', 'phpredis' ); define( 'WP_REDIS_HOST', 'your-elasticache-redis-endpoint.cache.amazonaws.com' ); define( 'WP_REDIS_PORT', 6379 ); define( 'WP_REDIS_PASSWORD', 'your-redis-password' ); // If password protected
Page Caching: Utilize a WordPress caching plugin (e.g., W3 Total Cache, WP Super Cache) configured to leverage object caching or serve static HTML files. For advanced scenarios, consider a CDN like Amazon CloudFront in front of your ALB.
Monitoring and Logging
Effective monitoring and logging are critical for maintaining production systems. AWS CloudWatch is the native solution.
Ensure your ECS Task Definition is configured with awslogs as the log driver. This streams container logs to CloudWatch Logs. You can then create CloudWatch Alarms based on log patterns (e.g., PHP errors, Apache errors) or metrics (CPU, memory).
For deeper insights, consider integrating Application Performance Monitoring (APM) tools like Datadog, New Relic, or AWS X-Ray. These often require agents to be installed within your container or configured at the infrastructure level.
CI/CD Pipeline for Containerized WooCommerce
Automating the build, test, and deployment process is essential. AWS CodePipeline, CodeBuild, and CodeDeploy can be orchestrated to manage this.
A typical pipeline would involve:
- Source Stage: Triggered by commits to a Git repository (e.g., AWS CodeCommit, GitHub).
- Build Stage (CodeBuild): Builds the Docker image, pushes it to ECR, and runs unit/integration tests.
- Deploy Stage (CodeDeploy/ECS): Updates the ECS Service with the new task definition, potentially using rolling updates or blue/green deployments to minimize downtime.
This ensures that updates to your legacy WooCommerce system can be deployed reliably and with minimal risk.