This is one of a series of posts on “Demystifying the Magical World of DevOps”
Alright, so, as of last time, we have our basic GitLab instance installed and working. I’m not going to go through exactly “How do I Git” or “How do I GitLab” right now, but there are lots of good resources out there. Googling is useful, but I’d start with the GitLab Basics Guide. A later post will go in to my take on those topics and more importantly, how to use Git with LabVIEW.
So for now, let’s dive in. We’re going to do a few things this time:
- Configure backups
- Enable LDAP authentication
- Configure the SMTP settings
- Configure third-party integrations
Enabling Backups
I can’t begin to stress enough how important this is. A source code control server that’s not backed up might as well not exist. Fortunately it’s pretty simple.
Now, this does require a bit of thought up front with regards to your storage scheme. At a minimum, you should have either a redundant RAID array on your server, or a network share to store your backups on. For this example we’re going to back up to a network share, but it’s worth noting our server itself has a RAID array, so to some extent we get the best of both worlds. So, how do you enable backups, you ask? For these purposes we’re going to assume your network share is hosted on a Windows machine (i.e Samba/CIFS) and requires credentials to log in.
Step 1: Map your Network Drive
Map a network drive to your local machine. Where you mount doesn’t really make a difference. The most common paths I’ve seen are in /media or /srv but it’s really just a matter of personal preference. There’s a pretty good tutorial over on the Ubuntu wiki but the general gist is as follows:
- Run the following command to ensure you have the required packages to mount a Windows share. Note you’ll be prompted to enter your root password:
sudo apt-get install cifs-utils - Now, you’ll need to lay the groundwork for logging in to the remote share. Create your credentials file:
nano ~/.smbcredentials - Put your username and password in this new file and save it:
username=windows_usernameNote: You probably want to use a service account, or account with non-expiring credentials.
password=windows_password - Now, let’s make sure your credentials are safe. This prevents unauthorized access:
chmod 600 ~/.smbcredentials - Next you’ll need to actually configure the share to be mounted. To do that, you’ll need to edit your fstab file:
sudo nano /etc/fstab - Add the following line to the bottom of the file:
//servername/sharename /media/windowsshare cifs credentials=/home/ubuntuusername/.smbcredentials,iocharset=utf8,sec=ntlm 0 0
This mounts //servename/share in the /media/windowsshare directory using the credentials you just stored. Note thatubuntuusernameshould be replaced by whatever your username is. Save and close the file. - Test your work. If the following command runs without error, you have been successful:
sudo mount -a - Finally, navigate to the directory in question. For example
cd /media/windowsshare
Worth noting, you should probably perform this step twice, pointing to two different network locations, so that you can store your data independent of your “secret” information. More on that in step 3.
Step 2: Configure GitLab
The next thing to do is configure GitLab backups. This is covered in their documentation, which also provides information on backing up to a cloud storage solution.
To enable backups, we’ll need to edit /etc/gitlab/gitlab.rb adding the following lines (at the top is fine):
gitlab_rails['backup_upload_connection'] = {
:provider => 'Local',
:local_root => '/media/windowsshare'
}
# The directory inside the mounted folder to copy backups to # Use '.' to store them in the root directory gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups'
This will tell GitLab to make it’s backups in /media/windowsshare/gitlab_backups which, per our last step, is the path we mounted our windows share at; thus they will be stored on the server.
One thing to note here, is that the backup_keep_time token referenced in the documentation does not apply when using network shares or cloud storage solutions. You’ll need to prune them manually or via a cron job.
You’ll need to reconfigure GitLab now: sudo gitlab-ctl reconfigure
Step 3: Create Your Cron Jobs
The last step in the process is to create your cron jobs. To do so, edit the crontab file: sudo nano /etc/crontab
Add the following lines:
00 2 * * * root gitlab-ctl backup-etc /media/secrets >> /var/log/gitlab-backup.log 2>&1 45 2 * * * root /opt/gitlab/bin/gitlab-backup create CRON=1 >> /var/log/gitlab-backup.log 2>&1
The first line will copy the ‘secret’ files to a network location that has been mapped to /media/secrets and pipes the results to the file /var/log/gitlab-backup.log. This will happen every day at 2:00 am. (The first several columns correspond to the following: minute, hour, day of month, month, day of week and * indicates all. To be clear, the logging ( >> and the text that follows it) is something I added beyond what is referenced in the documentation, and should be checked/cleaned out periodically. It’s necessity is arguable.
Next it will run the gitlab backup job. This happens at 2:45 and backups up your actual data to the path we defined in previous steps.
Enabling LDAP authentication
This step is optional, but for us is really handy. It means we can use our windows login information and don’t have to maintain a separate set of user accounts just for GitLab. The GitLab documentation is here, for reference, specifically the configuration section.
I’m not going to go through the process step by step, because it’s pretty straightforward. You’ll just need all of the information for your Active Directory server, such as the host name, port, dn of the user you will bind with, the user’s password, etc. Again, I recommend a service account be used for this. Also, don’t forget to reconfigure gitlab again when you’re done: sudo gitlab-ctl reconfigure
One thing I will mention is turning off non-LDAP login when you’re done. This can be done from the Admin area of your GitLab install after logging in as an administrator. You’ll need to go to Admin area -> Settings -> General -> Signup Restrictions and expand it. Then:
- Uncheck “Password authentication enabled for web interface”
- Uncheck “Password authentication enabled for Git over HTTP(S)”
- Save Changes
You should also disable new account signup:
- Admin area -> Settings -> General -> Signup Restrictions (expand)
- Uncheck “Sign-up Enabled”
- Save Changes
Another thing to note:
If you have already created a GitLab account with the e-mail address associated with your LDAP account, it will auto-merge. If it’s different, you can simply change the address of your existing GitLab account to the one associated with your LDAP account before signing in with your LDAP credentials. It will then automerge.
SMTP Integration
Again, this is pretty straightforward. GitLab has detailed instructions for nearly every e-mail provider you can think of: https://docs.gitlab.com/omnibus/settings/smtp.html
An important thing to pay attention to, however, is whether or not you have ITAR restrictions. If, so, be careful with this option as it’s possible you could end up sending sensitive information (comments, etc.) via unsecured e-mail. I believe you should be fine if you’re on a secured cloud (Amazon GovCloud or such), but I’m still researching that.
Microsoft Teams Integration (and more!)
The final point I’m going to make here is the huge number of integration options you have. I’m a big fan of Teams, and GitLab supports publishing to a channel. Be aware of the same caveat from above however, regarding ITAR restrictions. Information on configuring Teams integration can be found here and many more options can be found here.
Conclusion
So, now we should have a fully functioning, secure and robust GitLab install. Next up, we’ll talk about Continuous Integration (CI) and best practices for building and testing your code. It’s hard to contain my enthusiasm for this part, so I imagine the posts will be coming soon.