crashsystems / gitlab-docker

Thanks for the awesome dockerfile! It looks clean.

I would like to link this from the GitLab readme https://github.com/gitlabhq/gitlabhq/pull/5963/files

But before that I would like to discuss some simplifications the the readme to make this as accessible as possible.

You always need to clone the repo anyway, can you just assume that option and move Pull From Docker Index to the end or remove it completely? Have two options intertwined in the readme was confusing for me.
Can you run the image attached instead of detached (remove the -d) so people see any errors?
Can you make sure there are no error if you choose not to make any changes to the closed repo and run it straight away? (I'm getting stuff like: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2), Validation failed: Email has already been taken, Username has already been taken, Username already exist and Mysql2::Error: Can't create database 'gitlabhq_production'; database exists.

Alternatively, it would be even better to use the official GitLab Cookbook to install everything with a Chef Solo run https://gitlab.com/gitlab-org/cookbook-gitlab/blob/master/doc/production.md

This cookbook is maintained by GitLab.com so it will always be compatible with the latest version. It also allows both development and production installations. We would really love help with this https://gitlab.com/gitlab-org/cookbook-gitlab/issues/9

Is this something you are willing to consider?

👍

I'd love to have this linked to from the GitLab documentation! Let me see
if I can address some of your questions:

" You always need to clone the repo anyway, can you just assume that option
and move Pull From Docker Index to the end or remove it completely?"

For many people, pulling from the Docker index is going to be faster than
building themselves? To avoid confusion, what would you think about
splitting the build it yourself bit into a sperate file?

" Can you run the image attached instead of detached (remove the -d) so
people see any errors?"

You'd want to use -d so you could be running the container in the
background while doing other things. However docker attach can be used to
see the current output, and docker log can be used to see previous output.

" Can you make sure there are no error if you choose not to make any
changes to the closed repo and run it straight away?"

Are you talking about running it without binding to a local directory bind
via the -v param to docker run?

Regarding using the chef cookbook, I'm interested in potentially using
that. However, a significant goal of my build is to ensure that the gitlab
data exists from outside the container, so a gitlab upgrade can be achieved
be pulling a new build and binding to the same data directory. If that can
be achieved with this install method, then I may go that route.

Let me know if this answers all of your questions.
On Jan 15, 2014 12:38 AM, "Sytse Sijbrandij" notifications@github.com
wrote:

Thanks for the awesome dockerfile! It looks clean.

I would like to link this from the GitLab readme
https://github.com/gitlabhq/gitlabhq/pull/5963/files

But before that I would like to discuss some simplifications the the
readme to make this as accessible as possible.

You always need to clone the repo anyway, can you just assume that
option and move Pull From Docker Index to the end or remove it
completely? Have two options intertwined in the readme was confusing for me.

Can you run the image attached instead of detached (remove the -d) so
people see any errors?

Can you make sure there are no error if you choose not to make any
changes to the closed repo and run it straight away? (I'm getting stuff
like: Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2), Validation failed: Email has already
been taken, Username has already been taken, Username already exist and Mysql2::Error:
Can't create database 'gitlabhq_production'; database exists.

Alternatively, it would be even better to use the official GitLab Cookbook
to install everything with a Chef Solo run
https://gitlab.com/gitlab-org/cookbook-gitlab/blob/master/doc/production.md

This cookbook is maintained by GitLab.com so it will always be compatible
with the latest version. It also allows both development and production
installations. We would really love help with this
https://gitlab.com/gitlab-org/cookbook-gitlab/issues/9

Is this something you are willing to consider?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14
.

Thanks for the detailed response. My answers are inline

For many people, pulling from the Docker index is going to be faster than
building themselves? To avoid confusion, what would you think about
splitting the build it yourself bit into a separate file?
=>
I think that would be perfect.

You'd want to use -d so you could be running the container in the
background while doing other things. However docker attach can be used to
see the current output, and docker log can be used to see previous output.
=>
Would you consider these hints in the readme?

Are you talking about running it without binding to a local directory bind
via the -v param to docker run?
=>
I did the local directory bind with -v and got the errors. I have no preference for it completing without errors with -v or without -v. As long as the standard workflow that is described in the readme without any editing from the user completes without errors.

Regarding using the chef cookbook, I'm interested in potentially using
that. However, a significant goal of my build is to ensure that the gitlab
data exists from outside the container, so a gitlab upgrade can be achieved
be pulling a new build and binding to the same data directory. If that can
be achieved with this install method, then I may go that route.
=>
It is awesome to hear you are open to using the Chef cookbook. I understand the need to have the data outside the container completely. In the cookbook are configurable paths for the repositories https://gitlab.com/gitlab-org/cookbook-gitlab/blob/master/attributes/default.rb#L92 and satellites https://gitlab.com/gitlab-org/cookbook-gitlab/blob/master/attributes/default.rb#L95

You maybe want to also configure the .tmp and ssh paths that are linked in https://github.com/crashsystems/gitlab-docker/blob/master/start.sh#L25

We're open to discussing making these attributes of the cookbook too or finding another solution for that.

Let me know what you think.

Adding docker attach and log to the documentation is a good idea, and I'll
be doing that.

Regarding configurable paths via the cookbook:

The thing with -v volumes with Docker is that they are applied at docker
run, not when the image is being build. So if your build puts stuff in
/opt/foo and an outside directory or volume is applied there during docker
run, the stuff in /opt/foo from the build process disappears. This is why I
do the GItLab DB init during the first run, along with linking directory
paths.

GitLab has a really great upgrade process. However, modifying a container
in place is generally a discouraged practice with Docker. The idea is that
your deploy process is the same as your upgrade, backup restoration etc:
just rebuild and run.

Do you think the cookbook install could support something like this?
Basically, a brand new GitLab install would have to ether do DB init, or
use pre-existing data, and the build won't know until runtime.
On Jan 15, 2014 9:51 AM, "Sytse Sijbrandij" notifications@github.com
wrote:

Thanks for the detailed response. My answers are inline

For many people, pulling from the Docker index is going to be faster than
building themselves? To avoid confusion, what would you think about
splitting the build it yourself bit into a separate file?
=>
I think that would be perfect.

You'd want to use -d so you could be running the container in the
background while doing other things. However docker attach can be used to
see the current output, and docker log can be used to see previous output.
=>
Would you consider these hints in the readme?

Are you talking about running it without binding to a local directory bind
via the -v param to docker run?
=>
I did the local directory bind with -v and got the errors. I have no
preference for it completing without errors with -v or without -v. As long
as the standard workflow that is described in the readme without any
editing from the user completes without errors.

Regarding using the chef cookbook, I'm interested in potentially using
that. However, a significant goal of my build is to ensure that the gitlab
data exists from outside the container, so a gitlab upgrade can be achieved
be pulling a new build and binding to the same data directory. If that can
be achieved with this install method, then I may go that route.
=>
It is awesome to hear you are open to using the Chef cookbook. I
understand the need to have the data outside the container completely. In
the cookbook are configurable paths for the repositories
https://gitlab.com/gitlab-org/cookbook-gitlab/blob/master/attributes/default.rb#L92and satellites
https://gitlab.com/gitlab-org/cookbook-gitlab/blob/master/attributes/default.rb#L95

You maybe want to also configure the .tmp and ssh paths that are linked in
https://github.com/crashsystems/gitlab-docker/blob/master/start.sh#L25

We're open to discussing making these attributes of the cookbook too or
finding another solution for that.

Let me know what you think.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-32390240
.

Thanks for adding the attach and log commands to the readme.

Thanks for explaining the rebuild and run strategy, this makes a lot of sense. @maxlazio is currently refactoring the cookbook to support exactly this. Using the database recipe Chef solo will detect if the database exists or not. Only when it does not it inits and seeds it. See https://dev.gitlab.org/snippets/52 This will probably land in the next week. This probably means we have to do the Chef run during the first run, not the build. What do you think?

BTW From the outside directory I was missing stuff like the uploads directory and I'm not sure .ssh and /tmp have to be backed up. You might want to use the same list of directories that are backed up in https://gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/backup

Great, I'll check out the cookbook when that redactor is complete. Is there
any chance that it will detect what GitLab version the DB is from, and
automatically run migrations on the DB when needed? This would make
upgrading GitLab as simple as a docker pull followed by a docker run.
On Jan 16, 2014 12:04 AM, "Sytse Sijbrandij" notifications@github.com
wrote:

Thanks for adding the attach and log commands to the readme.

Thanks for explaining the rebuild and run strategy, this makes a lot of
sense. @maxlazio https://github.com/maxlazio is currently refactoring
the cookbook to support exactly this. Using the database recipe Chef solo
will detect if the database exists or not. Only when it does not it inits
and seeds it. See https://dev.gitlab.org/snippets/52 This will probably
land in the next week. This probably means we have to do the Chef run
during the first run, not the build. What do you think?

BTW From the outside directory I was missing stuff like the uploads
directory and I'm not sure .ssh and /tmp have to be backed up. You might
want to use the same list of directories that are backed up in
https://gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/backup

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-32448807
.

I think it automatically runs db:migrate, so that will work.

BTW, I've created this work-in-progress repo.

Its a build of GitLab with Chef Solo. However, while that build process works wonderfully outside of Docker, with a container it fails to connect to MySQL for some reason (see build errors). If I can get it to work, I'll deprecate this build in favour of the new one. Any feedback on what the problem might be would be welcome.

@crashsystems The redactions to cookbook-gitlab are complete. I like https://github.com/crashsystems/gitlab/ it looks really clean. I have no comments at this point. I hope you can fix https://gist.github.com/crashsystems/63680e567b9db199d9ba

I don't know what is causing the error, googling I found:
http://ubuntuforums.org/showthread.php?t=804021
http://stackoverflow.com/questions/11657829/error-2002-hy000-cant-connect-to-local-mysql-server-through-socket-var-run

@crashsystems What is the status for this issue?

It turns out that LDAP git push is not working with LDAP authenticated
users when GitLab is running inside the container, so I've been trying to
get that sorted out before anything else. However, I've not had much time
to work on it lately.
On Feb 11, 2014 1:16 PM, "Jeroen van Baarsen" notifications@github.com
wrote:

@crashsystems https://github.com/crashsystems What is the status for
this issue?

Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-34807929
.

@crashsystems Thanks for the feedback. Can give an indication when you will get around to this or should we close this for now?

Feel free to close it.
On Feb 11, 2014 11:20 PM, "Sytse Sijbrandij" notifications@github.com
wrote:

@crashsystems https://github.com/crashsystems Thanks for the feedback.
Can give an indication when you will get around to this or should we close
this for now?

Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-34845003
.

@crashsystems If you want to work on the docker image again I recommend the new packages we released. It should be very easy to make a docker file for them. See https://www.gitlab.com/downloads/

IIRC, aren't those not ready for production yet? I read about the new
package, and definitely want to check it out once it supports all of
GitLab's features.
On Feb 18, 2014 10:38 AM, "Sytse Sijbrandij" notifications@github.com
wrote:

@crashsystems https://github.com/crashsystems If you want to work on
the docker image again I recommend the new packages we released. It should
be very easy to make a docker file for them. See
https://www.gitlab.com/downloads/

Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-35417525
.

@crashsystems It is not but we think it is the future of GitLab

@crashsystems Thanks for checking it out, no problem to wait until it supports more features.

Simplify the readme