AWS部署可扩展WordPress：是否需迁移wp-content至共享存储？

Great question—given your Auto Scaling Group (ASG) + Jenkins/CodeDeploy setup, moving the entire wp-content directory to a shared, network-accessible storage is absolutely the right call, and here's why, plus how to approach it even if you can't do a full immediate migration:

Why you need shared storage for wp-content #

• ASG compatibility: When your ASG spins up new EC2 instances, local wp-content directories will be empty of user-uploaded media, custom theme tweaks, or plugin settings. This leads to broken images, missing content, and inconsistent user experiences across your fleet. Shared storage ensures every instance pulls the same dynamic content.
• Decouple content from core code: You're already using CI/CD to deploy core WordPress code (from your master branch) via CodeDeploy. Keeping wp-content separate means deployments won't overwrite user-generated content or customizations—you won't have to clutter your Git repo with uploads or config files that change outside your codebase.
• Centralized management: Backups, scaling storage capacity, and applying permission rules become far easier when your dynamic content lives in one place, rather than scattered across multiple EC2 instances. You already separated your database to RDS, so this completes the "stateless app" setup for your WordPress instances.

Recommended AWS shared storage options for your setup #

1. Amazon EFS (Elastic File System) #

• Fully managed NFS storage that integrates seamlessly with EC2 and ASG. You can mount EFS to the exact wp-content path on every instance, and all changes sync automatically.
• Perfect for the entire wp-content directory (themes, plugins, uploads, configs) since it supports the file system operations WordPress relies on.
• Auto-scales storage capacity, so you don't have to worry about running out of space as your content grows.

2. Amazon S3 + WP Offload Media (for media-heavy sites) #

• If most of your wp-content volume comes from images/videos, you can offload media files to S3 (with optional CloudFront CDN for faster delivery) using a plugin like WP Offload Media.
• Keep themes/plugins in EFS (or deploy them via CodeDeploy if they're part of your core codebase) and let S3 handle the bulk storage. This is more cost-effective for large media libraries.

How to migrate without immediate full downtime #

Since you can't do a direct migration right now, take this phased approach to minimize risk:

1. Provision and mount shared storage: Spin up an EFS filesystem (or configure S3 bucket permissions) and mount it to a temporary path on your existing EC2 instance (e.g., /mnt/efs/wp-content).
2. Sync existing content: Use rsync -av /var/www/html/wp-content/ /mnt/efs/wp-content/ to copy all current wp-content files to the shared storage. Run this a few times (including a final sync right before switching) to catch any new uploads.
3. Update WordPress config: Modify wp-config.php to point WordPress to the shared storage:

   define('WP_CONTENT_DIR', '/mnt/efs/wp-content');
   define('WP_CONTENT_URL', 'https://your-domain.com/wp-content'); // Or S3/CDN URL if using that
   

4. Test on existing instance: Verify that media loads, you can upload new files, and themes/plugins work as expected.
5. Update your CI/CD pipeline: Modify your CodeDeploy appspec.yml to include steps to mount the shared storage on new instances, and ensure the updated wp-config.php is deployed (or use environment variables for these paths to keep config flexible).
6. Roll out to ASG: Gradually replace old instances in your ASG with new ones using the updated configuration. Once all instances are using the shared storage, you can decommission the local wp-content directories.

Key things to watch out for #

• Permissions: Ensure your EC2 instances' IAM roles have the necessary permissions to access EFS/S3. Set file permissions on the shared storage to match the user running WordPress (usually www-data on Debian/Ubuntu).
• Caching: If using CloudFront with S3, configure cache invalidation rules so updated media files are served immediately. For EFS, consider a page cache plugin (like WP Rocket) to reduce filesystem load.
• Backups: Enable automatic backups for EFS, or turn on versioning for your S3 bucket—don't rely solely on instance-level backups anymore.

内容的提问来源于stack exchange，提问作者rkm