Introduction
As discussed in the previous guide, we used Let’s Encrypt to get legitimate SSL certificates for valid, external domains, and then mapped all of it internally to our own locally-hosted services via DNS. And of course, everything that needs to be maintained periodically is completely automated — a well-oiled machine.
Next up, we’re going to use those keys to enable two capabilities on a self-hosted GitLab (CE, 9.x) server:
These two go hand-in-hand with the latter enabling some great continuous integration capabilities. Let’s get right to it then!
Pre-flight
In this guide, we assume you installed GitLab from the omnibus packages (e.g., you ran apt-get install gitlab-ce). We also assume that you’re synchronizing your keys (fullchain.pem and privkey.pem) to the GitLab server over in /etc/gitlab/ssl/HOST.FQDN, with the understanding when we say HOST and FQDN, we’re saying:
| Variable | Value |
|---|---|
| HOST | One of your subdomains you plan to uniquely identify the gitlab server (e.g., gitlab.local.us.com) |
| FQDN | The top-level registered subdomain that points back to your external IP (e.g., local.us.com) |
Note: In both cases, the examples are referring to the example in the other guide.
Naturally, you could be storing the keys in a different directory as it makes really no difference at all. But if you’re comparing notes with GitLab’s own documentation, this will look familiar.
Upgrades
Now, make a backup of /etc/gitlab/gitlab.rb. If you’re feeling anxious, run a backup for your entire GitLab installation.
Enable HTTPS
Enabling HTTPS and the redirect from HTTP to HTTPS is very easy and is an essential piece of getting these two features running. Edit /etc/gitlab/gitlab.rb to uncomment (or add, if necessary) these keys:
external_url 'https://HOST.FQDN'
...
nginx['redirect_http_to_https'] = true
...
nginx['ssl_certificate'] = "/etc/gitlab/ssl/HOST.FQDN/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/HOST.FQDN/privkey.pem"
...
Feel free to reconfigure now if you just want to test this change.
Note: It may be necessary at this point to open a new tab or re-open your web browser when navigating to your GitLab server.
With the redirects in place in DNS and the server, navigating to the host name of the GitLab server via HTTP should automatically redirect your browser up to the external HOST.FQDN, and you should also now see an indication that your session is secure.
And not once did you have to accept the key, because it is validated by a trusted Certificate Authority: Let’s Encrypt. Great!
Container Repository
The internal GitLab Container Repository is a fully-integrated Docker Image repository. It’s a great feature for continuous integration since you can use it as a local build cache between jobs in the pipeline. Now, unless you want to disable/ignore some security related checks, it requires a valid (trusted) SSL certificate. That is the main reason why we did this. 🙂
Edit your /etc/gitlab/gitlab.rb script for these keys:
registry_external_url 'https://HOST.FQDN:4567'
...
nginx['ssl_certificate'] = "/etc/gitlab/ssl/HOST.FQDN/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/HOST.FQDN/privkey.pem"
Note: If sequential numbers damage your calm, feel free to pick a different (unused) port for your container repository than 4567. The current commented default for omnibus is 4567, so we’ve shown it here.
Then, reconfigure the server.
Once GitLab is finished reconfiguring, you should be able to log into it as you would DockerHub, for example:
$ docker login HOST.FQDN:4567
It should prompt you for your login credentials which are the same as you would normally login.
If you’re familiar with pushing images to DockerHub, this is exactly the same. Your image must be tagged with the full name to the project in question, for example:
docker push HOST.FQDN:4567/some_group/some_repo:feature
Q: Thomas: you’re saying rather than having a concise tag like ourstuff/image:feature, I have to do a long HOST.FQDN:4567/some/long_path/repository:feature. Come on!!
A: That’s not a question. (It’ll be okay.)
The GitLab folks have seen fit to give you a number of CI_... environment variables for handling all of this in your Pipelines. So really, within a given runner configuration you aren’t going to have to worry about maintaining those long tag names as you move and fork repositories so long as you use those variables in your pipeline definition.
But we’ll cover that in our next article about setting up and running CI.
Conclusion
Between the previous post and this one, you now have an internally-hosted GitLab server with some really excellent new features that came from adding SSL. Next time, we’ll take you through configuring continuous integration (CI) pipelines that use the Container Repository by adding a GitLab runner (or two) and go through a detailed example of a configuration script.
Reconfigure GitLab
To reconfigure / update the running configuration of GitLab, execute the following:
# gitlab-ctl reconfigure
The process should complete without any errors.
The GitLab logo is the property of GitLab.
