Volume trouble with GitLab docker image on Windows

Question

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 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

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.

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

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

And got this error on container:

# 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 [[email protected], [email protected], [email protected]]
[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?

Answer 1

I think I have a solution for running Gitlab from Docker on Windows 10; it appears to be working for me thus far.

For all of the Powershell, you'll need an elevated prompt.

Init

This first part gets the folders/volumes setup, then creates and starts the Gitlab container. (Remember that you have to have the Docker Desktop running and tell it to make the C drive shared.)

mkdir c:\GitlabConfig
mkdir c:\GitlabConfig\backups

docker volume create gitlab-logs
docker volume create gitlab-data 
docker run --detach `
    --name gitlab `
    --restart always `
    --hostname gitlab.local `
    --publish 4443:443 --publish 4480:80 --publish 8222:22 `
    --volume C:\GitlabConfig:/etc/gitlab `
    --volume gitlab-logs:/var/log/gitlab `
    --volume gitlab-data:/var/opt/gitlab `
    gitlab/gitlab-ce

Wait a few minutes for Gitlab to finish initializing; just keep refreshing "localhost:4480/" in a browser until the web page comes up.

You can now use Gitlab however you were planning.

Backups

Edit the c:\GitlabConfig\gitlab.rb file. Find the 2 settings indicated, uncomment, and set them like so (this is what you'll end up with):

gitlab_rails['manage_backup_path'] = false

gitlab_rails['backup_path'] = "/etc/gitlab/backups"

Note that the "backups" folder is the same one created on the host back at the beginning, just how it's known inside the container.

Next, restart the container.

docker restart gitlab

Now you can backup Gitlab and it'll show up on the Windows host

docker exec -it gitlab gitlab-rake gitlab:backup:create

You will see a c:\GitlabConfig\backups\{prefix}_gitlab_backup.tar file in Windows after the process completes.

Restores

Once everything's ready for a restore, you can just run

gitlab gitlab-rake gitlab:backup:restore BACKUP={prefix}

Where {prefix} is everything that comes before the "_gitlab_backup.tar" of the filename you want to use for the restore. The restore functionality looks in the folder you configured earlier in the gitlab.rb file.

With this approach, I've been able to setup a running Gitlab container on Windows 10. I can just backup that main "c:\GitlabConfig" folder using any method I like.

Additionally, you can nuke the container and the 2 docker-volumes and start from scratch with just that folder's contents. If you start the new container by pointing it to your saved config folder, it'll have most of your stuff right out of the gate. But after it's done booting up, you can restore a backup and you'll be right back where you were. The docs presently indicate that there's problems with restoring when Gitlab is running in a container, but I didn't have any. If the restore runs into trouble, it should tell you what you need to fix before trying again

Answer 2

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' ]

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

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.

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.

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.