一尘不染

为什么docker-compose使用user:group 999:999创建目录/文件?

docker

我用docker-compose up以下docker-compose.yml

version: '3.5'
services:
 mysql-server:
  image: mysql:5.7
  environment:
    - MYSQL_ROOT_PASSWORD=root_pwd
  volumes:
   - ./var/lib/mysql:/var/lib/mysql:rw

该目录./var/lib/mysql最初不存在。

运行后docker-compose up..

ls -al ./var/lib/mysql命令显示所有带有的文件user:group 999:999

999在系统中找不到用户或组。

为什么* docker-compose选择使用 不存在的uid:gid 创建文件*

就我而言,除非更改所有权,否则无法提交特定目录。但是,即使我这样做,在下次运行时也会docker-compose up将所有权再次更新为999:999

以上问题的解决方法是什么?例如,是否有一种方法可以指示docker-compose使用特定的uid:gid对映射主机中的文件?

主持人:ubuntu-18.04
docker-compose:1.22.0


阅读 2981

收藏
2020-06-17

共1个答案

一尘不染

Docker mysql使用映像所使用的用户创建并填充目录。该用户当然uid在容器内。这uid恰好是999。

具有该用户的用户uid在容器中,但在您的主机中不存在。

在容器上,文件夹如下所示:

root@f86ffddac96c:/var/lib# ls -l
total 32
...
drwxr-xr-x 5 mysql mysql 4096 Mar 19 13:06 mysql
...

在主机上看起来像这样

root@machine:/home/username/mysql/var/lib# ls -l
total 4
drwxr-xr-x 5 999 docker 4096 Mar 19 15:06 mysql

这仅表示用户mysqluid999个。在创建从容器到主机的绑定卷时,该卷中的所有文件都必须对同一uids
具有相同的权限。在我的测试机上,docker的guid值为999,这就是为什么它在主机端显示为999的原因。

至于“修复”,您可以使用uiddockerfile中已知的(主机级)代替默认文件,也可以忽略它,因为它按预期工作,除非有特定原因需要它uid在您的主机系统中显示特定名称。

2020-06-17