Richard Bucker

PART 1: Gitlab:latest and docker

Posted at — Feb 5, 2018

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 </span>    –hostname </span>    –publish 443:443 –publish 80:80 –publish 2222:22 </span>    –name gitlab </span>    –restart always </span>    –volume /srv/gitlab/config:/etc/gitlab </span>    –volume /srv/gitlab/logs:/var/log/gitlab </span>    –volume /srv/gitlab/data:/var/opt/gitlab </span>    gitlab/gitlab-ce:latestThis 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 </span>    –hostname </span>    –publish 10443:443 –publish 10080:80 –publish 10022:22 </span>    –name gitlab </span>    –restart always </span>    –volume /srv/gitlab/config:/etc/gitlab </span>    –volume /srv/gitlab/logs:/var/log/gitlab </span>    –volume /srv/gitlab/data:/var/opt/gitlab </span>    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: 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.rbAnd you’ll want to get these fields from the mailgun config(docs):gitlab_rails[‘smtp_enable’] = truegitlab_rails[‘smtp_address’] = “”gitlab_rails[‘smtp_port’] = 587gitlab_rails[‘smtp_authentication’] = “plain”gitlab_rails[‘smtp_enable_starttls_auto’] = truegitlab_rails[‘smtp_user_name’] = “postmaster@mg.example.comgitlab_rails[‘smtp_password’] = “password here”gitlab_rails[‘smtp_domain’] = “”Now you’ll need to reload the config by first shelling into the running containerdocker exec -it gitlab /bin/shAnd then tell gitlab to reconfiguregitlab-ctl reconfigureUPDATE: I forgot to add the gitlab runnerdocker run -d –name gitlab-runner –restart always </span>  -v /srv/gitlab-runner/config:/etc/gitlab-runner </span>  -v /var/run/docker.sock:/var/run/docker.sock </span>  gitlab/gitlab-runner:latestThe actual registration info is here. Essentially with a running runner… do this:docker exec -it gitlab-runner gitlab-runner registerand answer the questions with info in gitlabNEXT: In Part 2 I’ll document the certbot configuration and Part 3 will be haproxy.