基于Docker搭建WordPress开发环境及镜像同步的技术咨询

Hey there, let's work through your Docker WordPress setup questions step by step—you're already halfway there with your docker-compose config, so we'll tweak it to fit all your requirements.

1. Sharing Your Custom WordPress Theme via Docker Image #

Right now, you're mounting your local wp-content directory into the WordPress container, which is great for development, but to package your theme into a shareable image, you'll want to build a custom WordPress image instead of using the official one directly. Here's how:

Create a Dockerfile in your project root:

# Start with your base WordPress image
FROM wordpress:5.1.1-php7.3-apache

# Copy your custom theme into the image's theme directory
COPY ./wp-content/themes/your-custom-theme /var/www/html/wp-content/themes/your-custom-theme

# Keep your uploads.ini config in the image too (optional, but avoids mounting it)
COPY ./uploads.ini /usr/local/etc/php/conf.d/uploads.ini

Then update your docker-compose.yml to build this custom image instead of pulling the official one:

services:
  db:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
  wordpress:
    depends_on:
      - db
    build: .  # This tells Docker to use the local Dockerfile
    ports:
      - "8001:80"  # Fixed port mapping to host:container for easy access
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
    working_dir: /var/www/html
    volumes:
      - ./wp-content:/var/www/html/wp-content
volumes:
  db_data:

Now run docker-compose build to create your custom image. You can share this with colleagues by pushing it to a container registry (like Docker Hub or a private one) or exporting it as a tar file with docker save -o wordpress-custom.tar your-project_wordpress, then sending that file over.

2. Saving Theme & WordPress/DB Changes to the Image #

First, a critical note: docker commit won't save data stored in Docker volumes (like your db_data volume for MySQL). Volumes are independent of containers, so they don't get included when you commit a container to an image. Here's the right approach for persisting changes:

For Theme/Code Changes:

Since you're mounting ./wp-content locally, any edits you make are saved on your host machine. To include these changes in your image, update the COPY command in your Dockerfile to copy the entire wp-content directory (or specific subdirs) into the image, then rebuild.

For Database Changes:

To save your database state so colleagues get the exact same setup:

1. Export a backup of your MySQL database while the db container is running:

   # Replace <db-container-name> with the actual name (run docker ps to check)
   docker exec <db-container-name> mysqldump -u wordpress -pwordpress wordpress > db-backup.sql
   

2. Add this backup to your project and update the Dockerfile to auto-import it when the database starts:

   # Add this to your existing Dockerfile
   COPY ./db-backup.sql /tmp/db-backup.sql
   RUN echo "mysql -u wordpress -pwordpress wordpress < /tmp/db-backup.sql" >> /docker-entrypoint-initdb.d/import-backup.sh
   RUN chmod +x /docker-entrypoint-initdb.d/import-backup.sh
   

   This script will run automatically the first time the MySQL container starts, loading your saved database state.

3. Colleagues Saving Changes Back to Docker & GitHub #

Forget about using docker commit for collaborative work—it creates "black box" images with no trace of what changed, which is a nightmare for version control. Instead, use this workflow:

1. Colleagues clone your GitHub repo (which includes Dockerfile, docker-compose.yml, wp-content, db-backup.sql, etc.).
2. They build the custom image with docker-compose build.
3. They run the stack with docker-compose up. Since wp-content is mounted locally, any theme/code changes they make are saved directly on their host machine—they can commit these changes to GitHub like regular code.
4. When they modify the database, they export a new backup using the same mysqldump command you used, replace the db-backup.sql in the repo, and commit that file to GitHub.
5. Next time you pull the repo, rebuild the image and restart the stack—your database will automatically load the latest backup, syncing with their changes.

Quick Clarification on docker commit #

Just to clear up your confusion: docker commit takes a running container and turns its current filesystem state into a new image. But since your MySQL data is in a volume (not the container's filesystem), it won't be included. This tool is best for one-off fixes or testing, not for collaborative development workflows—stick to Dockerfiles and GitHub for that.

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