Docker容器修改内部配置文件
内网搭建的wordpress会对文件上传有限制，想要突破限制的方法有多种。但进入docker容器内部大部分情况只能做临时修改，那么应该如何做到非临时docker内部修改
再次明确：在 Docker 容器内直接修改配置文件（比如 PHP 的 php.ini 或其它配置文件），这是临时修改，容器停止或重启后，这些修改都会丢失，因为 Docker 容器的文件系统是临时的（非持久化），默认情况下容器重启会恢复到镜像初始
那么，如何进行持久化修改？
打开docker-compose.yml的配置文件：
wordpress:
image: wordpress:latest
depends_on:
- db
- redis
restart: always
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpressuser
WORDPRESS_DB_PASSWORD: wordpresspassword
WORDPRESS_DB_NAME: wordpressdb
WORDPRESS_URL: http://10.10.1.70:80
WORDPRESS_REDIS_HOST: redis
volumes:
- wordpress_data:/var/www/html
- /home/yxwa/wordpress-compose/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini– wordpress_data:/var/www/html
这是一个 命名卷（named volume），挂载到容器的 /var/www/html 目录。该目录对应 WordPress 网站的代码和上传文件等内容。这个卷是持久化数据存储，不会随着容器删除而丢失。所以对 /var/www/html 中文件的任何修改都会保存在这个卷中，即使容器重建（命令：docker compose down&docker compose up -d），数据依然存在
– /home/yxwa/wordpress-compose/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
这是一个 文件挂载（bind mount），将宿主机的 uploads.ini 文件挂载到容器的 PHP 配置目录下。PHP 上传大小限制配置通过这个挂载文件生效。容器启动时会加载这个配置文件，修改宿主机上的这个文件，容器重启后生效。
例如：对于绿色，进入容器后会默认在/var/www/html目录下操作
创建一个测试文件test.php，不用写任何内容
touch test.php
然后再退出容器、删除容器、重启容器、进入容器内部查看
很明显的看到创建的test.php成功地挂载在容器中，同时再次证明：
– wordpress_data:/var/www/html：这是一个 命名卷（named volume），挂载到容器的 /var/www/html 目录。该目录对应 WordPress 网站的代码和上传文件等内容。这个卷是持久化数据存储，不会随着容器删除而丢失。所以对 /var/www/html 中文件的任何修改都会保存在这个卷中，即使容器重建（命令：docker compose down&docker compose up -d），数据依然存在
那么就产生了一个新问题：如果想在其它路径下面修改文件呢？
其实通过– wordpress_data:/var/www/html这一挂载的原理，可以明白一点：
在docker-compose.yml中，如果宿主机的一个A路径可以挂载到容器里面的一个B路径当中去，那么可以通过修改宿主机A路径里面的文件来“映射”到容器里面的B路径
听不懂？上实践！
以- /home/yxwa/wordpress-compose/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini为例：
- /home/yxwa/wordpress-compose/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
修改为：
- /home/yxwa/wordpress-compose/test-php-conf:/usr/local/etc/php/conf.d/test
##test-php-conf和test都是文件夹，里面都是空的
在/home/yxwa/wordpress-compose/test-php-conf路径下创建test.php后删除重建容器，重新进入容器内部查看/usr/local/etc/php/conf.d/test路径下是否存在test.php
存在test.php，说明挂载成功
后续可能会出现的问题
一、文件上传失败
Docker 部署 WordPress 上传图片失败的排查与解决全记录（php8.2-fpm-alpine 版）
问题现象
出现类似于：8ca6ce00209c5eab64d45e7ec899b0b9.jpg无法将上传的文件移动至 wp-content/uploads/****/**** 的报错，优先检查是否为权限不统一导致的
先查看博客文件目录下的ID和权限
id查看容器内部uploads文件夹下的各个媒体文件的权限
docker exec -it wp_trojan_app bash -c "ls -la /var/www/html/wp-content/uploads/****/****"如果各个媒体文件报出包括且不仅限于1000:1000、82:82、32:32的id，说明就是当前文件夹下的各个文件所有者相当混乱，需要重新统一。
问题原因
1、镜像用户差异
wordpress:php8.2-fpm-alpine镜像中，PHP-FPM 以 www-data 用户运行，UID/GID 为 82:82。- 之前可能切换过
wordpress:apache（Debian 版，UID 为 33:33），遗留了老权限。
2、volume权限混乱
- 如果在宿主机的主文件夹下出现和容器内部相同属性的媒体文件，也会导致部分文件属于1000:1000
- wp_data下的文件所有者和容器内部运行的用户不一致，导致PHP-FPM无法写入
3、非bind mount——使用的是docker默认配置的docker managed volume(/etc/lib/docker/volume/wp_*****/wp_data/_data)，无法直接在宿主机修改
解决方案
快速维修方案：
#在宿主机操作容器内部，直接一次性修复权限
docker exec -u root wp_trojan_app sh -c '
chown -R www-data:www-data /var/www/html/wp-content &&
find /var/www/html/wp-content -type d -exec chmod 755 {} \; &&
find /var/www/html/wp-content -type f -exec chmod 644 {} \;
'
#验证权限和修复结果
docker exec -it wp_trojan_app ls -la /var/www/html/wp-content/uploads/*****/***** #记得修改后缀文件路径
#持久化解决
在compose.yml文件内添加一行
YAML
wordpress:
image: wordpress:php8.2-fpm-alpine
container_name: wp_trojan_app
user: "82:82" # 关键：强制使用容器内正确的 www-data 用户
restart: always
...
#重启容器
docker compose down&docker compose up -d重新进入博客后台，上传一张图片再次尝试
问题总结：
- 使用 php-fpm-alpine 镜像时，必须关注 UID 82，不要和 Debian 版的 33 混用。
- 尽量避免在宿主机直接操作 WordPress 文件，尤其是使用 Named Volume 时。
- 推荐在 docker-compose.yml 中显式指定 user: “82:82″，可彻底避免权限反复出现问题。
- 如果会手动上传文件，建议统一使用 user: “$(id -u):$(id -g)” 并配合宿主机用户一致的方案。
评论