绑定挂载容器时构建文件丢失问题及解决方案咨询

Hey there! Let's tackle your questions one by one— I totally get the frustration when bind mounts override your carefully built container content.

First: A Quick Recap of Your test.txt Issue #

Just to align with what you already figured out: Bind mounts mount your host directory on top of the container's /var/www/html at runtime. So even though you created test.txt during the build phase, the host's directory (empty or pre-existing) replaces that container path, hiding your build-time files entirely.

1. How to Sync Latest Code with Bind Mounts for Persistence #

The core fix here is separating your build-time code from the runtime mounted directory. The most reliable approach is:

• Store your base WordPress code + custom files in a non-mounted "source" directory inside the image
• Sync this source directory to the bind-mounted path when the container starts (without overwriting existing persistent data)

2. Runtime Script Implementation #

Let's build a custom entrypoint script to handle the sync logic. Here's a step-by-step setup:

Step 1: Update Your Dockerfile

We'll move our build-time content to a safe, non-mounted directory, then add the entrypoint script:

FROM wordpress

# Copy WordPress core and our custom files to a protected base directory
WORKDIR /usr/src/wordpress-base
COPY --from=wordpress /var/www/html .
RUN touch test.txt  # Your build-time file lives here now

# Create and make our entrypoint script executable
COPY entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/entrypoint.sh

# Set working directory back to the mounted path
WORKDIR /var/www/html

ENTRYPOINT ["entrypoint.sh"]
CMD ["apache2-foreground"]

Step 2: Create the entrypoint.sh Script

This script syncs the base code to the bind mount only on the first run (to avoid overwriting existing persistent data like uploads or wp-config.php):

#!/bin/bash
set -e

# Sync base files to the persistent directory if it's empty (first launch)
if [ -z "$(ls -A /var/www/html)" ]; then
    echo "Syncing base WordPress files to persistent directory..."
    rsync -av --exclude='wp-config.php' /usr/src/wordpress-base/ /var/www/html/
fi

# Copy sample config if it doesn't exist (adjust to your needs)
if [ ! -f /var/www/html/wp-config.php ]; then
    cp /usr/src/wordpress-base/wp-config-sample.php /var/www/html/wp-config.php
fi

# Run the original WordPress entrypoint/command
exec "$@"

Step 3: Update docker-compose.yml

No major changes here—keep your bind mount as configured:

web:
  build: ./code
  ports:
    - "80:80"
  volumes:
    - ./mount:/var/www/html

On first run, the script copies all base files (including test.txt) to your bind mount. On subsequent launches, it leaves your existing persistent data (uploads, custom config) untouched.

3. Alternative Persistence Methods for AWS ECS #

Since AWS ECS restricts you to host directory bind mounts, here are practical workarounds:

• AWS EFS Volumes: ECS supports mounting Elastic File System (EFS) directly to containers. EFS is a managed network file system that preserves data across task restarts and doesn't override your image's content. Configure it as a volume in your ECS task definition for persistent, shared storage.
• Init Containers: Add an init container to your ECS task that runs before your main WordPress container. The init container can sync code from your image's base directory to the bind-mounted host path, or pull the latest code from a Git repository. Once sync completes, the main container starts with up-to-date files.
• S3 + Startup Script: Store static code/assets in an S3 bucket, then add a startup script to your container that downloads the latest files from S3 to the bind-mounted directory on each run. This works best for static content, not dynamic WordPress files.

内容的提问来源于stack exchange，提问作者Anand Naik B