This is one of a series of posts on “Demystifying the Magical World of DevOps”
As of last time, we finally have a Hyper-V server with a copy of Ubuntu server on it. Now let’s actually make it in to something useful. We’re going to install a copy of GitLab Enterprise Edition on it, and do some basic configuration. Stepping back for a moment, however, why GitLab EE?
Well, as a starting point, let’s talk about why chose to self-host. We need to comply with ITAR regulations, which severely limits the cloud hosted options available to us, and those services that do exist generally have a rather high per-user cost. Going with a self-hosted solution gives us much greater control over our data storage, and also allows us to avoid the monthly bills.
Now, that’s not to say that this is the best option for you. If you aren’t at least somewhat comfortable with a Linux command line, and willing to take on the responsibility of monitoring for updates, keeping your server up-to-date, and handling your own back up responsibilities, it’s a terrible idea. I want to stress that last point again: If you’re not willing to handle your own redundant data storage, don’t do this. I can’t think of anything more terrifying than a hard drive failure on a standalone source code control server.
Why GitLab EE though? Well, for one, I had seen GitLab used by various people in the LabVIEW community, so it was clearly functional for our workflows. i was also already familiar with it thanks to several presentations I had seen in the past year or so. Finally, I saw a good webinar by Sam Taggart a while back that demonstrated exactly how the cloud hosted version could be used to automate our workflows.
The only piece of the puzzle remaining was whether or not GitLab EE had all (or enough of) the features of the cloud hosted version. Further investigation revealed it does. The complete list of features can be viewed here. After evaluating it, our organization is actually well served by Core level; as we grow further, there are some paid features we may consider upgrading to.
The install process
Now that we have established why we chose GitLab, let’s talk about how to install and configure it. Fortunately, most of it is well-documented on the GitLab page itself. There are a few differences from their recommendations, however, if you don’t intend for your server to be publicly accessible from the web. For the sake of completeness, I’ll go ahead and walk through all of it below.
Worth noting, the GitLab documentation assumes you’ll be using postfix. In our case, we want to use an SMTP server, so we’ll set that up later. There is a pretty good walkthrough you can follow after things are set up otherwise.
A basic configuration looks like the following:
sudo apt update
sudo apt-get install -y curl openssh-server ca-certificates
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo EXTERNAL_URL="http://myserver.mycommpany.net" apt-get install gitlab-ee
Note that “EXTERNAL_URL” represents the URL you will be using to access your GitLab server. This might be myserver.mycompany.net or just an IP address. At this point you could browse to the EXTERNAL_URL and start configuring your server, but let’s look a little more at this URL first.
The last line is a slight departure from the installation docs. They recommend you use HTTPS (and so do I), but by default GitLab tries to use “Let’sEncrypt” if you select HTTPS. In our case, since we aren’t publicly accessible from the web, that won’t work. Instead, we will be using a custom certificate. The rough procedure for doing so is outlined in the GitLab docs but if you want to use a self-signed certificate, there are a few caveats. (Note: Self-signed certs are great for testing, but there are security implications if using them for deployment. NEVER use them for a public-facing server and use caution if you use them for an internal deployment.)
First, you’ll need to create the certificate. I found the answer by vog on this StackOverflow post very useful. In short, it all boils down to one command:
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout example.key -out example.crt -subj /CN=example.com \
-addext subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1 This will result in the appropriate .key and .crt files. (Notice that there’s no ‘e’ in that last one… you’ll chase your tail for a while. Not that I know from experience or anything…) You can use those files with the GitLab documents listed above to configure the server. Specifically, you’ll need to edit /etc/gitlab/gitlab.rb to have https in the entry for ‘external url’ as follows:
external_url "https://myserver.mycompany.net"You’ll also need to add the following to gitlab.rb:
letsencrypt['enable'] = falseThen create a directory called /etc/gitlab/ssl and copy the key and certificate over. That can be done with the following:
sudo mkdir -p /etc/gitlab/ssl
sudo chmod 700 /etc/gitlab/ssl
sudo cp myserver.mycompany.net.key myserver.mycompany.net.crt /etc/gitlab/ssl/OK, finally, reconfigure GitLab:
sudo gitlab-ctl reconfigureNow, you’ll be greeted by this pleasant screen when you browse to your GitLab URL:
The joys of self-signed certificates! To get around this, you’ll need to install the relevant certificate as trusted on any machine that you wish to access the server from. For this, you’ll need a .pem file, which is easy to generate. Simply run the following command in the directory containing your .crt and .key files:
cat server.crt server.key > cert.pemNow, install the resulting .pem file on to your development machine by double-clicking and walking through the menus. Those screens are fairly self explanatory, but a bit of googling should resolve any questions that come up. (Note that you will need to do this for every machine you want to access the DevOps server from. That root-ca signed key is looking pretty nice now, huh?)
Check it out!
Now that you have successfully done basic configuration of your GitLab server, go check it out! Browse the the external URL and have some fun!
For those interested, the full setup documentation can be found here, but next time we’ll talk about setting up Active Directory (LDAP) integration and configuring the SMTP server integration.