A way to override/customize configuration files? about docker-gitlab

[sameersbn]

The main idea of this image was to make if easy for anyone to tryout/use gitlab without having to deal with setting up the system or gitlab configuration files etc. Like a plug and play kinda thing.

Over a period of time I started adding all these configuration options so that users could customize their instance without having to directly deal with the configuration files.

Scalability wise I don't see any issues here. In fact its simple to start multiple instances of the image when you need to do load balancing stuff.

Having said that, I do like your idea of being able to pick up the configuration from a config directory so that more advanced users can customize the configuration to their liking. This could be implemented as an alternate configuration method such that if such a configuration is present, it will override all environment variable settings.

Currently all of gitlab data is mounted at /home/git/data, so we can look for a config directory within this path and pick the configurations for gitlabhq and gitlab-shell from this directory. I think this could work well and not interfere with users who are already using this image in its current form.

Let me know your thoughts.

Since you mentioned that you are new to docker, I advise you to take a look at:

• http://crosbymichael.com/dockerfile-best-practices.html
• https://github.com/paulczar/docker-wordpress

Regards
~Sameer

[mauvm]

Thank you for responding so quickly and for elaborating on the matter. I'd have to say I agree with you in full. Command-line parameters are easy to use, handy for multiple instances and newb-friendly - although I have to say well documented configuration files are not that hard to use either. :)

Besides keeping this image backwards compatible, I also think allowing to override individual configuration files will be a good approach. In this way you can - for example - fully configure NGinx, but let the rest of the configuration be generated automatically by the command-line parameters.

The implementation of this feature will be quite easy I believe:

• Adding a default configuration setup archive to this repository. The default configuration is pretty well documented already (https://github.com/gitlabhq/gitlabhq/tree/master/config);
• Writing file existance checks around each configuration file generation (if exists: copy existing, else: generate);
• Updating documentation accordingly.
  • Mentioning overridable configuration files (when placed in /opt/gitlab/data/config);
  • Add override setup script, something like: curl -L https://raw.github.com/sameersbn/docker-gitlab/master/resources/setup/gitlab-config-1.8.0.tar.gz -s -o - | tar -xzf --directory /opt/gitlab/data -

You'd agree?

Though, what if you specify a command-line parameter, but have a configuration file in place? Wouldn't it then be better to use the existing file as a base, and replace the given options in the local copy?

PS: Thanks for the advice! Appreciate it.

[sameersbn]

What do you mean by "Add override setup script". Are you saying that

• the image should pull the default configuration when its run?
• or do you mean informing users (in the documentation) where to get the sample configs from if case they prefer editing the configs by hand.

By "command-line parameter" you mean something like 'docker run sameersbn/gitlab app:start --db_host "192.168.1.100" --db_port="10000"' and so on right? So basically instead of env variables we do getopt parsing.

Actually, I had started off with this image the same way. Can't remember why I ditched it though. However it would still not fix your original request, unless all possible configurable parameters are tunable this way.

[mauvm]

With "Add override setup script" I mean adding an archive (for example resources/setup/gitlab-config-6.4.3.tar.gz) which contains the default configuration files (something equivalent to this folder: https://github.com/crashsystems/gitlab-docker/tree/master/config) and inform the users in the documentation. In this way it can be retrieved/installed with curl/wget without having to pull the entire repository (like the crashsystems/gitlab-docker does require you to do).

By "command-line parameter" I basically mean passing something along with a terminal command. In this case the environment variables of docker run, but getopt parsing is an option too. Although the latter is a cleaner way in my opinion, it's not my preferred choice. Mainly because of the backwards compatible issue.

If we'll ingore backwards compatibility though, I'd advise to remove the env variables entirely. For several reasons:

• A bit higher learning curve, but just one straightforward way of configuring the GitLab instance;
• I'd apply the 80-20 rule to the multiple instance case, where a copy of the configuration will be an option too;
• No trouble with adding given env variables into the given configuration files, which will be painfully bug-sensitive.

Ignoring the env variables when configuration files are present would be an option too, except the given env variables can then be misleading. Also if you have a partial selection of the configuration files available and allow this tool to generate the rest (according to the given env variables), I think it will become a mess and also less newb-friendly.

In conclusion, the easy way would be to only allow the configuration files and make them mandatory.

[mauvm]

@sameersbn Any other thoughts on this?

[sameersbn]

Will be working on this soon. Just a little caught up with work.
This feature should be implemented before the next gitlab release.

[mauvm]

I understand. Please let me know if there's anything I can help with.

[sameersbn]

@mauvm Hi and sorry for leaving this request open ended for so long. I finally got to it and the changes have been committed to the master. Have yet to get to updating the README. Here is a short version

Extract https://github.com/sameersbn/docker-gitlab/blob/master/resources/setup/config.tar.bz2 to your data directory and edit the logs as per your liking (be careful though).

The variables that are surrounded by the {{}} markers are the ones that are updated at runtime. You can edit this to hold the final value and omit passing the values as environment variable parameters. For example if you are using an external mysql server connection at 192.168.1.100, you can change {{DB_HOST}} in gitlabhq/gitlab.yml to the ip address and so on.

Other configuration parameters can be edited as per your liking.

Make sure you do not change any path variables, you are destined to be doomed if you do.
Let me know if you run into any issues.

[sameersbn]

P.S. If all works fine, please close this request. Then I will officially document this feature.

[mauvm]

Thanks! Will try it out.