让我们使用此docker-compose.yml
:
version: '2'
services:
db:
image: mysql:5.7
volumes:
- ./mysql:/var/lib/mysql # <- important
restart: always
environment:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:latest
volumes:
- ./wp:/var/www/html # <- important
ports:
- "8000:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
我注意到:
做事
mkdir wp
docker-compose up
# create a basic Wordpress website from the browser
# stop the containers from the command-line with CTRL+C
然后,./wp/
(最初为空)被新的Wordpress文件(**)填充。这是正常的。
那我们就做
docker rm wordpress_1 db_1 # remove the existing containers but keep
# ./wp/ as it has been created in the previous step (**)
docker-compose up
在重新创建容器期间,./wp/
不会被新的Wordpress文件覆盖,而是保留了上一步(**)中的先前文件!为什么?
如何神奇地知道应该不写入 new Wordpress文件,而应该保留以前的文件? < / p>
问题:docker
如何决定/hostdir/:/containerdir/
中列出的volumes:
是否应覆盖原始Docker映像中已经存在的文件?
答案 0 :(得分:2)
使用该语法始终进行的绑定安装会覆盖映像中存在的文件。这与普通的Linux mount (8)命令的作用方式相同:如果在源目录的一部分上装载USB盘之类的东西,则所装载设备的内容将隐藏文件系统中的原始内容。 ,并且所有读写操作都使用已安装的设备。
当容器启动时,这意味着它可以查看其数据目录是否为空,如果是,则在其中安装一些初始数据。您引用了GDK docs; Docker Hub wordpress
image带有明确的支票
51
if [ ! -e index.php ] && [ ! -e wp-includes/version.php ]; then
echo >&2 "WordPress not found in $PWD - copying now..."
# ... some code that creates sourceTarArgs and targetTarArgs ...
tar "${sourceTarArgs[@]}" . | tar "${targetTarArgs[@]}"
echo >&2 "Complete! WordPress has been successfully copied to $PWD"
fi
图像具有类似的检查,以查看其数据目录是否为空。如果是,它将进行首次初始化,包括处理mysql
目录;如果不是,则假定那里已有数据,并完全跳过初始化步骤。
通常,您应该尝试为实际数据保留绑定装载和类似的卷,而不是在此处复制代码。在/docker-entrypoint-initdb.d
映像的情况下,由于它在卷中复制了应用程序,因此,如果您尝试升级基础映像,将会发生什么并不十分明显:该卷具有优先级,并且升级可能被忽略
命名Docker卷(与绑定安装不同)将从底层映像复制内容,但如果是命名卷而不是其他类型的安装,则仅 >在Docker上正确(在Kubernetes中不是),并且如果卷完全为空,则为 (这是您第一次运行容器)。避免依赖此行为,因为它不是特别可移植,并且会忽略基础映像中的更新。