Update Sept 2014

I am no longer using gitlab, it stopped working and I didn't have the energy to fix it. Details here.

Original article

As I've talked about before, I'm currently trying to put some of the principles of indieweb into practice. I started by hosting my own blog content, and then threw up a quick [pastebin clone][artifice] to host my own pastebin data. I decided that next up on my list of things to try to homestead would be my code.

I use git for my version control, and currently host all of my repos on github. Indieweb journey notwithstanding, I have many reasons lately to reconsider that.

Of course, with github you still can own your data, git is a decentralized version control system so you have a complete copy of everything even on your local clone. The things github provides (that are also the data you do not control) are things like issues. Things that are the real 'community' part of your project. As my friend @baldwin said to me earlier today, "It's interesting that github seems to have re-centralized git."

I actually don't know how easy gitlab makes it to do these things. If you have a relatively small project, and thus community, it's a lot to ask a person to create an account on your own little private gitlab instance just to contribute. As I write this I have no idea if it's easy to submit issues or merge requests from outside your local gitlab ecosystem. In theory it should be possible since git is decentralized to send merge requests between systems. Identity could also be handled by oauth (or even better persona) so that participating in someone's project doesn't require a dedicated account in their ecosystem. I'm hoping that these things are either already easy to do, if not they appear to be crucial to making the community portion of version control as open as git itself is.

Installation

I knew that I wanted to be able to use docker to run gitlab. I was already using it if you'll recall from my previous posts. Fortunately there is a gitlab-endorsed docker config. Unfortunately it doesn't work out of the box (the firstrun.sh file tries to build assets before mysql is running) and parts are super confusing (ssh port forwarding for instance is completely hand-wavy). It is also out of date and uses mysql. So like the bad-decision-making person I am, I forked it to get it on the latest versions of things, use postgresql, and most importantly actually work. You are welcome to try your luck w/ the original. Examples here will be using my fork.

The first step is to tell docker about the image:

$ cd /var/local
$ git clone https://github.com/wraithgar/gitlab-docker.git gitlab
$ cd gitlab
$ docker build -t gitlab .

This part takes awhile so maybe go read a book while you wait. Might I suggest Something Greater than Artifice? It may help you decide after all that silos are real.

Configuration

Now it's time to go into your newly cloned gitlab-docker repo and change the settings. in config/gitlab.yml just change the host: config under gitlab: to whatever hostname you are going to want to run gitlab on (I used code.danger.computer). pick a port you want to use on your host machine for git ssh, 222 is a common alternative. Uncomment and set the ssh_port under Advanced settings to this number. Unfortunately this is not something you can configure in docker so you'll have to pick a port number, set it in the config file, and remember that port number later when you forward it to this image. in config/nginx.conf change YOUR_SERVER_FQDN to the same hostname as you put in config/gitlab.yml in config/nginx.conf change PATH_TO_GITLAB_DOCKER to whatever folder you cloned the gitlab-docker repo into (heads up it's in there several times, change them all)

There are a lot of things to configure in config/gitlab.yml not the least of which could be omniauth settings. These settings are not trivial if you are unfamiliar w/ rails and gems. That kind of thing feels like a "future" post instead of trying to work it into this one. If you are feeling adventurous try this post. I hope to revisit this file in a separate post.

I won't be adding omniauth to my initial run of this image because I think config items like that should be changeable after the fact, so I want to try changing them and seeing where the pain points are.

Moving on, the next config item is setting passwords for the gitlab user. Set that in firstrun.sh (and of course pick a good password, c'mon now).

Running

In dockerland, running an image is referred to as 'making a container'. This is when your code starts to run and is where you enter the last bit of configuration items (which other than environment variables sadly all appear to be CLI only).

If you've set everything up right, you should be able to run your image in a new container. However there's one more thing missing from the instructions for gitlab-docker. Remember the port number you configured in config/gitlab.yml that I said to remember? You're going to need to tell docker to forward that from the host machine to the container. In this example I've used port 222. Note that -name is depricated and my example uses --name (the cd into your gitlab-docker folder in the instructions also appears to be superfluous)

$ docker run -d -v /var/local/gitlab:/srv/gitlab:rw -p 222:22 gitlab

Wrapping up

All that's left is for you to let nginx know how to serve gitlab. Copy your edited config/nginx.conf file to /etc/nginx/conf.d/gitlab.conf and restart nginx. If everything worked well (fingers crossed) you should be able to go to the hostname you set up and log in as the predefined user admin@local.host with password 5iveL!fe. You'll be prompted to change that password of course.

You can check out the fruit of my labor at code.danger.computer

The Future

Up next I will actually have to run gitlab and try to get my code into it, including using git over ssh. After that, it's likely making auth happen in a distributed way, and other configuration tweaks.

A small nitpick is that gitlab prompts for login by default rather than redirecting to /public. I will see if that can be changed.

Also I know you can publish docker images but I just didn't have the energy to figure that out after finally getting things working. If I get that working I'll update the readme and this post.

Finally, there is a docker file for the gitlab-ci service. The ci portion of gitlab looks like it will be very useful and I can't wait to dive into that eventually.

After this experience it is apparent that neither gitlab nor docker is really ready for primetime. You can get it to work, eventually but it took me the hobby time of a better part of a week to get things even running for the first time. Hopefully my efforts can be built upon now, with the end goal being even more people being able to host their own code.

A note about swapfiles

In some of the documentation for gitlab I was reading, it was mentioned that if you don't have a lot of memory on your system (say, for instance you went with the small 512MB of ram for your droplet) you may have problems running gitlab, especially the first time. Following the basics in this howto I added a 512MB swapfile to my droplet. The only difference between that howto and what I did was that I set count=512k instead of count=256k in the dd command that created the swapfile. Your environment may not need this but if you're copying what I am doing then it's good to know that I took this step locally.

Update:

After only a few days of running my droplet ran out of memory and I couldn't even publish to this blog w/o dokku crashing. I would definitely go for a slice w/ at least 1GB. I will be upgrading my own shortly.