sameersbn / docker-gitlab

Dockerized GitLab
http://www.damagehead.com/docker-gitlab/
MIT License
7.9k stars 2.14k forks source link

"docker run --name=gitlab ..." does not work with docker v1.5.0 within the same instance #277

Closed qwc closed 9 years ago

qwc commented 9 years ago

Hi,

please excuse, I'm a very fresh docker noob. I'm just trying docker for the very first time, setting up a gitlab instance on my server. Specs:

Images: all yours. ;)

Following your instructions I get an error everytime I try to run a "docker run --name=gitlab ...." So for example:

$ docker run -it --name=gitlab -d [options] sameersbn/gitlab:7.8.4 app:rake gitlab:env:info
FATA[0000] Error response from daemon: Conflict. The name "gitlab" is already in use by container
e5d00fa523b2. You have to delete (or rename) that container to be able to reuse that name.

So are you really creating a new container everytime you run a command to show some information or do backups? Shouldn't all rake tasks be run in the very single container, where it is first set up? The correct command would be docker exec -it e5d00fa523b2 app:rake ..., wouldn't it? But this doesn't work as well.

Am I doing something completely wrong here? If so, please correct me. If I'm correct, please fix the documentation and the image so that it's possible to run the rake tasks.

(It's possible with going into the container with docker exec -it <name> bash and cd into /home/git/gitlab and executing the standard commands like bundle exec rake gitlab:check RAILS_ENV=production)

sameersbn commented 9 years ago

@qwc You need to stop and remove the running container and execute the backup command. Alternately you can run the backup command with a different name for the container. You can also exec into the running container and execute the rake command manually as you have listed above.

As long as the docker image is configured to mount a volume for the data store, all your gitlab data is safe and the running container can be stopped/removed/recreated with the same configuration without any loss of data.

qwc commented 9 years ago

Of course my data is safe in the volume and the image or newly created containers are working with that volume, still I somehow can't accept, that this 'creating a container for every command' isn't too much overhead for this simple commands. And additional, if I define always a different name for the one-command-container I get a lot of containers which are just useless, and I have to remove them one-by-one. :/

sameersbn commented 9 years ago

Of course my data is safe in the volume and the image or newly created containers are working with that volume, still I somehow can't accept, that this 'creating a container for every command' isn't too much overhead for this simple commands.

Technically there is not much overhead. Yes there are multiple steps involved, but you can setup automatic backups, and that way you don't have to worry about taking backups. The container will do that for you. Basically the current setup makes the process simple for new users. I do agree that, taking backups using docker exec is a simpler solution. Its just that the backups mechanism/instructions were added way before docker added the exec option. Apart from the fact that I am much more comfortable taking the gitlab instance down before taking a backup for obvious reasons, after all its a maintenance task. Maybe, I will revisit this and also provide the option of using docker exec.

And additional, if I define always a different name for the one-command-container I get a lot of containers which are just useless, and I have to remove them one-by-one. :/

You can get around this my using the --rm flag to the docker command. i.e. docker run --it --rm.

qwc commented 9 years ago

Well, the kinda obvious and only advantage of using docker exec is the fact that you don't have to supply the complete configuration on every docker run call, your container is completely configured.

But I accept the fact, that the current maintainance commands are defined like this, and I have to use them as stated, because the docker exec variant I tried myself does not always work flawlessly.

Looks like writing some shell scripts which do the configuration part for me on every call. :)

sameersbn commented 9 years ago

@qwc I think the docker exec did not work is probably because you are not in the right working directory, i.e. /home/git/gitlab. Basically, I think adding the WORKDIR statement in the docker file should resolve this. Next, the rake command would have to be launched as the git user, i.e. docker exec -it gitlab sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production.

These are minor changes that need to be done. I just got my laptop back from the service center. I will make these changes once I done setting it up.

sameersbn commented 9 years ago

@qwc You can now run rake tasks using docker exec. Please refer https://github.com/sameersbn/docker-gitlab#rake-tasks for basic information.

qwc commented 9 years ago

Great!!! Thanks, for your fantastic work! :) :+1: