Docker: owner not changed recursively when switching container (update use case)
Hi,
I tried updating GitLab from a Docker container on version N to a container on version N+1, following the procedure documented here.
- I built 2 images, one for version 7.10.0, one for version 7.12.2 (but the version does not really matter here, this is a Chef-related issue)
- I ran the 7.10.0 container that created its own users and groups using , and missing directories on the mounted data volumes, such as log files and directories
- I stopped and removed the 7.10.0 container and ran a 7.12.2 container
- The new 7.12.2 container creates its own users and groups, with different uid/gid
- The Chef recipes changes ownership to directories, but Chef does not apply it recursively (by choice, see here)
The effect of wrong ownership will prevent GitLab to work, with different effects, among them:
- Unicorn won't start, keeping complaining about the log file permissions
2015-07-17_13:25:47.28913 starting new unicorn master
2015-07-17_13:25:48.54988 /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:732:in `initialize': Permission denied @ rb_sysopen - /var/log/gitlab/unicorn/unicorn_stderr.log (Errno::EACCES)
2015-07-17_13:25:48.54994 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:732:in `open'
2015-07-17_13:25:48.54996 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:732:in `redirect_io'
2015-07-17_13:25:48.54997 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:177:in `stderr_path='
2015-07-17_13:25:48.54997 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/unicorn-4.6.3/lib/unicorn/configurator.rb:111:in `block in commit!'
2015-07-17_13:25:48.54998 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/unicorn-4.6.3/lib/unicorn/configurator.rb:108:in `each'
2015-07-17_13:25:48.54998 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/unicorn-4.6.3/lib/unicorn/configurator.rb:108:in `commit!'
2015-07-17_13:25:48.54999 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:121:in `initialize'
2015-07-17_13:25:48.54999 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/unicorn-4.6.3/bin/unicorn:126:in `new'
2015-07-17_13:25:48.55000 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/unicorn-4.6.3/bin/unicorn:126:in `<top (required)>'
2015-07-17_13:25:48.55000 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/bin/unicorn:23:in `load'
2015-07-17_13:25:48.55001 from /opt/gitlab/embedded/service/gem/ruby/2.1.0/bin/unicorn:23:in `<main>'
2015-07-17_13:25:48.57039 master failed to start, check stderr log for details
2015-07-17_13:25:49.57991 failed to start a new unicorn master- GitLab users won't be able to access their repositories.
I see this issue as a serious one, as it is then impossible to upgrade a GitLab instance hosted as a Docker container. Did I miss something important, to avoid this from happening? I found 2 solutions here :
- Nailing created users and groups ids to defined values, to avoid this switch between different containers. This is how this Docker file managed it.
- Or recursively change ownership to the container users using a Chef "execute command" directive as proposed here.
Thanks for your consideration on this topic!