Self Hosting Log - 002 - Gitlab

Getting version control, CI/CD and more with Gitlab

To start my self hosting journey, I looked to taking control of my code bases. Now I don’t have a lot of code, as of writing around 160 repositories. But I still wanted to bring it in house. I did enjoy Github and Github Actions, but honestly I’ve always been suspect of the Microsoft ownership. CodeSpaces does look quite cool and I think if that went GA before this project, I may have stuck around. But, I also have self hosted alternatives for that, something for the future!

To get started, I needed some infrastructure, so, hello Endeavour! Now I wanted to work out a good deployment mechanism. I’ve done a lot of Kubernetes, but honestly at the time I was kind of on a Kubernetes detox, which I might be at the tail end of now at writing. But I also wanted some simplicity while still leveraging containers. So, I went with Docker Compose and that’s defined the deployment pattern for almost all other applications I’ve run. Below you can see the Compose file I’ve used today, with some entries omitted, but it’s very close to the stock Docker Compose that Gitlab recommend.

web:
  image: 'gitlab/gitlab-ee:latest'
  restart: always
  hostname: 'gitlab.evanwebservices.com'
  environment:
    GITLAB_OMNIBUS_CONFIG: |
      external_url 'https://gitlab.evanwebservices.com:8080'
      letsencrypt['enable'] = false
      registry_external_url 'https://registry.evanwebservices.com:5000'
      gitlab_rails['gitlab_shell_ssh_port'] = 22
      gitlab_rails['smtp_enable'] = true
      gitlab_rails['smtp_address'] = "smtp.eu.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.evanwebservices.com"
      gitlab_rails['smtp_password'] = "Snakeoil :)"
      gitlab_rails['smtp_domain'] = "mg.evanwebservices.com"
  ports:
    - '8080:8080'
    - '5000:5000'
    #- '443:443'
    - '22:22'
  volumes:
    - '/srv/gitlab/config:/etc/gitlab'
    - '/srv/gitlab/logs:/var/log/gitlab'
    - '/srv/gitlab/data:/var/opt/gitlab'
    - '/srv/gitlab/secrets:/secret/gitlab/backups'

Note that today I don’t run the Gitlab Runner on the same machine, it’s currently a T3.Small instance running on AWS. I’ve got some plans for improving this, but right now things just work so I’m keeping them as they are.

Issues I’ve had with this mainly revolved around my earlier attempts of configuring Gitlab behind CloudFlare, which I’ve since resolved by well, not using CloudFlare. When I deployed a reverse proxy, my Gitlab Registry broke since it was using 443, so I had to change that port. I also just need to get said reverse proxy in front of Gitlab, but Gitlab is a bit of a beast with a multitude of components, so it’s something I need to research. It’s definitely doable, it’s just a case of putting in the effort. I think I might stand up a bit of a phoenix environment on a local machine just to test it out, since doing it live kind of borks everything else.

Overall, Gitlab has been one of my favourite tools. I won’t lie, it’s a bit of a beast memory wise and I could probably try to separate out the services from being one. But so far I’ve not felt the need to do so. It handles my source code, my CI builds, my Docker images and my Terraform state with module support too. I’m also using some of its SAST features on my code base, but I do wish the merge request decorating wasn’t behind the “Ultimate” license. Even on the first paid tier, it would be something I’d consider upgrading for.