Monday, February 5, 2018

PART 1: Gitlab:latest and docker

I've been exercising with Digital Ocean and my need to get gitlab running in such a way that I can publish or register container instances. Sure I could use the public FREE version but I really want to integrate with my own CI/CD and so on.

So there is a lot going on... launch gitlab as a container:

docker run --detach \
    --hostname git.example.com \
    --publish 443:443 --publish 80:80 --publish 2222:22 \
    --name gitlab \
    --restart always \
    --volume /srv/gitlab/config:/etc/gitlab \
    --volume /srv/gitlab/logs:/var/log/gitlab \
    --volume /srv/gitlab/data:/var/opt/gitlab \
    gitlab/gitlab-ce:latest

This is going to launch the container for you, however, one important point is that there is no SSL here and it's quite complicated so to start this is the wrong way to start the container... instead this is preferred:

docker run --detach \
    --hostname git.example.com \
    --publish 10443:443 --publish 10080:80 --publish 10022:22 \
    --name gitlab \
    --restart always \
    --volume /srv/gitlab/config:/etc/gitlab \
    --volume /srv/gitlab/logs:/var/log/gitlab \
    --volume /srv/gitlab/data:/var/opt/gitlab \
    gitlab/gitlab-ce:latest

* one nasty side effect of storing all of the snippets in gitlab is trying to locate them when you need them to restart the service.

Mounting a host volume feels better than mounting a container. There are certain advantages including container HA and some functions that do not exist yet but there are serious problems when cleaning stale containers... you could delete all your data.  I recently survived a system crash only because the files were mounted on the host.

It's not great but it's better. What this means is that git is going to be accessible:

http://1.2.3.4:10080

This is not terrible be it also means you're using the host's IP address and not the ephemeral IP. Think in terms of Kubernetes the public IP is not stitched in.

At this point we have a running gitlab. The next step is setting up the smtp email relay. My preference is to deploy using mailgun so you'll need an account there. It's free until you get to scale.

Next configure gitlab to use mailgun by editing the file on the host volume:

vi /srv/gitlab/config/gitlab.rb

And you'll want to get these fields from the mailgun config(docs):

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.mailgun.org"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_authentication'] = "plain"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_user_name'] = "postmaster@mg.example.com"
gitlab_rails['smtp_password'] = "password here"
gitlab_rails['smtp_domain'] = "mg.example.com"

Now you'll need to reload the config by first shelling into the running container

docker exec -it gitlab /bin/sh

And then tell gitlab to reconfigure

gitlab-ctl reconfigure

UPDATE: I forgot to add the gitlab runner

docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

The actual registration info is here. Essentially with a running runner... do this:

docker exec -it gitlab-runner gitlab-runner register

and answer the questions with info in gitlab

NEXT: In Part 2 I'll document the certbot configuration and Part 3 will be haproxy.

another bad day for open source

One of the hallmarks of a good open source project is just how complicated it is to install, configure and maintain. Happily gitlab and the ...