finalize docker-compose.yml for v2

[sameersbn]

No description provided.

[sameersbn]

Ideally I would have liked to use a volumes section to define named volumes. but unfortunately the local volume driver does not allow specifying a host path for the volume.

I have also applied the :Z volume label, but haven't tested it on a selinux based distro like redhat or centos. It would be great if someone could test this.

[solidnerd]

This would possible if you use a volume plugin like local-persist

[sameersbn]

Thanks for linking to local-persist. Good to know 😄
For the sample docker-compose.yml file we need to stick with what docker provides as the default.

[solidnerd]

@sameersbn. I put my test results in here as you mentioned me in #658 . I guess it will provide a litte bit more clarity.
First of all everything is working for me now. Thanks for the work. But i got some barriers.

1. If you don't have the latest redis image you get an error message that the command does not work.
   To fix it. You to pull the latest redis image.
2. Maintenance has been changed. The way of restoring a backup is different to the old way, because your gitlab container must be in the same network and you should provide the enviroment variables to ensure that the gitlab_container finds the database.
   To fix it i use the following command:

docker run --name gitlab -it --rm --net="gitlab_gitlab_backend" -v /srv/gitlab/gitlab:/home/git/data --env-file=gitlab.env sameersbn/gitlab:8.6.4 app:rake gitlab:backup:restore BACKUP=1460347212

I used the env variables from the compose file. In that case we sould use env_file to define them once. Lets rethink about #600.

[sameersbn]

If you don't have the latest redis image you get an error message that the command does not work. To fix it. You to pull the latest redis image.

I guess the redis client version in the gitlab image may not be compatible.

Maintenance has been changed. The way of restoring a backup is different to the old way, because your gitlab container must be in the same network and you should provide the enviroment variables to ensure that the gitlab_container finds the database. To fix it i use the following command:

Wouldn't you use docker-compose to launch the rake task?

create a backup

docker-compose run --rm gitlab app:rake gitlab:backup:create

restore a backup

docker-compose run --rm gitlab app:rake gitlab:backup:restore BACKUP=1460905799

Lets rethink about #600.

I have commented on the issue #600 (comment)

[solidnerd]

I mean sameersbn/redis:latest image. I needed to pull that than everything works at docker-compose up.

Next time i will try to use docker-compose to run the rake tasks. It will make my work a lot of easier. 😅

[sameersbn]

I mean sameersbn/redis:latest image. I needed to pull that than everything works at docker-compose up.

Yes. I meant the redis-cli version in the gitlab image was probably not compatible with the redis-server from sameersbn/redis:latest

Next time i will try to use docker-compose to run the rake tasks. It will make my work a lot of easier. 😅

With docker-compose v2 I think this might be the only valid way of doing things correctly because of all the networking bits.

[solidnerd]

The networks key isn't needed because docker-compose will create an own network by default. So this could be remove @sameersbn.

[sameersbn]

Yep, its not "required".
Not sure if we should keep it or remove it. Guess we can remove it for now and add it later as we see fit?

[jgsqware]

Hello, any idea when you will merge it?

[sameersbn]

@jgsqware can you try it out and let us know it works for you? will merge it on the weekend after doing some tests to check if backup/restore operations work without issues.