Windows 上 GitLab docker 映像的体积问题 [英] Volume trouble with GitLab docker image on Windows

问题描述

我正在尝试通过 docker 在我的 Windows 10 上运行官方映像 gitlab/gitlab-ce:latest.
首先我尝试像下面这样运行它，它成功了.

I'm trying to run official image gitlab/gitlab-ce:latest by docker on my Windows 10.
First I tried to run it like below and it worked.

docker 运行 --detach
--hostname gitlab.example.com
--publish 443:443 --publish 8080:80 --publish 22:22
--name gitlab
--总是重启
--volume/srv/gitlab/config:/etc/gitlab
--volume/srv/gitlab/logs:/var/log/gitlab
--volume/srv/gitlab/data:/var/opt/gitlab
 gitlab/gitlab-ce:最新的

docker run --detach
--hostname gitlab.example.com
--publish 443:443 --publish 8080:80 --publish 22:22
--name gitlab
--restart always
--volume /srv/gitlab/config:/etc/gitlab
--volume /srv/gitlab/logs:/var/log/gitlab
--volume /srv/gitlab/data:/var/opt/gitlab
  gitlab/gitlab-ce:latest

但问题是容器中的更改没有保存.我发现这东西是成卷的.此附加仅适用于 Boot2Docker VM.好的，我在 docker 设置(桌面应用程序)中成功地从主机(窗口)共享了我的磁盘 C:/并对其进行了测试.Window 的文件夹共享，我可以看到测试容器中的文件.

But the problem was that changes in container were not saving. I found that the thing is in volumes. This attaching works only for Boot2Docker VM. Ok, I successfully shared my disk C:/ from host(Window) in docker settings(desktop application) and test it. Window's folder shared and I can see files in test container.

现在我正在尝试像这样运行 gitlab 图像:

Now I'm trying ti run gitlab image like this:

docker 运行 --detach
--hostname gitlab.example.com
--publish 443:443 --publish 8080:80 --publish 22:22
--name gitlab
--总是重启
--volume C:UsersPublicGitlabconfig:/etc/gitlab
--volume C:UsersPublicGitlablogs:/var/log/gitlab
--volume C:UsersPublicGitlabdata:/var/opt/gitlab
 gitlab/gitlab-ce:最新的

docker run --detach
--hostname gitlab.example.com
--publish 443:443 --publish 8080:80 --publish 22:22
--name gitlab
--restart always
--volume C:UsersPublicGitlabconfig:/etc/gitlab
--volume C:UsersPublicGitlablogs:/var/log/gitlab
--volume C:UsersPublicGitlabdata:/var/opt/gitlab
  gitlab/gitlab-ce:latest

在容器上得到这个错误:

# Logfile created on 2017-06-21 16:33:44 +0000 by logger.rb/56438
[2017-06-21T16:33:45+00:00] INFO: Started chef-zero at chefzero://localhost:8889 with repository at /opt/gitlab/embedded
  One version per cookbook

[2017-06-21T16:33:45+00:00] INFO: Forking chef instance to converge...
[2017-06-21T16:33:45+00:00] INFO: *** Chef 12.12.15 ***
[2017-06-21T16:33:45+00:00] INFO: Platform: x86_64-linux
[2017-06-21T16:33:45+00:00] INFO: Chef-client pid: 26
[2017-06-21T16:33:45+00:00] WARN: unable to detect ipaddress
[2017-06-21T16:33:46+00:00] INFO: HTTP Request Returned 404 Not Found: Object not found: chefzero://localhost:8889/nodes/9ca249ba6250
[2017-06-21T16:33:46+00:00] INFO: Setting the run_list to ["recipe[gitlab]"] from CLI options
[2017-06-21T16:33:46+00:00] INFO: Run List is [recipe[gitlab]]
[2017-06-21T16:33:46+00:00] INFO: Run List expands to [gitlab]
[2017-06-21T16:33:46+00:00] INFO: Starting Chef Run for 9ca249ba6250
[2017-06-21T16:33:46+00:00] INFO: Running start handlers
[2017-06-21T16:33:46+00:00] INFO: Start handlers complete.
[2017-06-21T16:33:46+00:00] INFO: HTTP Request Returned 404 Not Found: Object not found: 
[2017-06-21T16:33:47+00:00] INFO: Loading cookbooks [gitlab@0.0.1, runit@0.14.2, package@0.0.0]
[2017-06-21T16:33:47+00:00] INFO: directory[/etc/gitlab] mode changed to 775
[2017-06-21T16:33:47+00:00] WARN: Skipped selecting an init system because it looks like we are running in a container
[2017-06-21T16:33:48+00:00] INFO: template[/var/opt/gitlab/.gitconfig] owner changed to 998
[2017-06-21T16:33:48+00:00] INFO: template[/var/opt/gitlab/.gitconfig] group changed to 998
[2017-06-21T16:33:48+00:00] INFO: template[/var/opt/gitlab/.gitconfig] mode changed to 644
[2017-06-21T16:33:48+00:00] INFO: Running queued delayed notifications before re-raising exception
[2017-06-21T16:33:48+00:00] ERROR: Running exception handlers
[2017-06-21T16:33:48+00:00] ERROR: Exception handlers complete
[2017-06-21T16:33:48+00:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/chef-stacktrace.out
[2017-06-21T16:33:48+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2017-06-21T16:33:48+00:00] ERROR: ruby_block[directory resource: /var/opt/gitlab/git-data] (gitlab::gitlab-shell line 26) had an error: Mixlib::ShellOut::ShellCommandFailed: Failed asserting that ownership of "/var/opt/gitlab/git-data" was git
---- Begin output of set -x && [ "$(stat --printf='%U' $(readlink -f /var/opt/gitlab/git-data))" = 'git' ] ----
STDOUT: 
STDERR: + readlink -f /var/opt/gitlab/git-data
+ stat --printf=%U /var/opt/gitlab/git-data
+ [ root = git ]
---- End output of set -x && [ "$(stat --printf='%U' $(readlink -f /var/opt/gitlab/git-data))" = 'git' ] ----
Ran set -x && [ "$(stat --printf='%U' $(readlink -f /var/opt/gitlab/git-data))" = 'git' ] returned 1
[2017-06-21T16:33:48+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

请帮忙，我做错了什么?

Please help, what did I do wrong?

推荐答案

hyperv文件共享机制不支持unix风格的文件权限.因此，当应用程序尝试断言所有权是它所期望的时，它会遇到错误.我猜它会尝试执行chown"，然后是您的输出中描述的以下 shell 行:

The hyperv filesharing mechanism does not support unix style file permissions. Because of this, the application encounters an error when it tries to assert that ownership is what it expects. I would guess that it tries to do a 'chown', followed by the following shell line that is described in your output:

[ "$(stat --printf='%U' $(readlink -f /var/opt/gitlab/git-data))" = 'git' ]

错误消息表明它期望所有者是'git'，但它却得到了'root'.

Error message indicates that it is expecting the owner to be 'git', but it gets 'root' instead.

你有两个主要的可能性.您可以尝试配置/更改在容器内运行的进程以处理这种情况.这可能就像更改配置一样简单，以便它需要root"而不是git".它最终可能会比这更多地参与.您的里程可能会有所不同.

You have two major possibilities. You could try to configure/change the process running inside your container to handle the situation. That might be as simple as changing the configuration so that it expects 'root' instead of 'git'. It may end up being much more involved than that. Your mileage may vary.

您的另一个选择是使用正确支持 unix 样式权限和所有权的文件系统.这意味着您应该切换到使用命名卷，或者切换回使用 Docker For Windows 设置的 hyperv vm 中的主机卷.无论哪种方式，您的文件都将驻留在虚拟机中，而不是主机的文件系统中.

Your other option is to use a file system that does properly support unix style permissions and ownership. This would mean that you should switch to using a named volume, or switch back to using a host volume within the hyperv vm that Docker For Windows sets up. Either way, your files will reside in the VM instead of on your host's file system.

我建议在这种情况下使用命名卷.请记住，如果您重置 Docker For Windows VM，命名卷中的任何数据也将被重置.

I would recommend using a named volume in this situation. Just keep in mind that if you reset your Docker For Windows VM, any data in a named volume will be reset as well.

这篇关于Windows 上 GitLab docker 映像的体积问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！