My deployment of GitTea from an earlier post is still going strong, but I wanted to try something a little more robust, and I wanted to try to get it deployed with Ansible. GitLab is a “DevOps software package that combines the ability to develop, secure, and operate software in a single application”. Although I won’t be using all of its features in my self-hosted environment, it will make a great SCM for me and it has some truly impressive features, such as the web-ide, and web-terminal that I don’t have available in GitTea.

To get started, I instantiated a new RHEL8.6 VM on my KVM hypervisor using the RHEL8.6 KVM guest image. It’s a great light-weight RHEL distro that I’ll cover in my next post. After giving it a static IP address, a hostname of simply gitlab, creating a DNS record for it, and getting it subscribed to the RHN I headed over to galaxy.ansible.com to look for a pre-built role to help me out. As luck would have it, Jeff Geerling, a prolific Ansible Galaxy contributor, had already committed exactly what I needed to get started in his GitLab role.

Back on my Ansible management workstation, I ran the following to install the role:

ansible-galaxy install geerlingguy.gitlab

This went ahead and installed the role in my home directory in ~/.ansible/roles. This I confirmed with:

ansible-galaxy list

Next, I needed to closely review the included README.md file to know which inbuilt variables I would need to override to account for my site-specifics. Geerling’s README.md is very thorough, and well written and after reading carefully it I had a pretty good idea of how to write a playbook that would call his role. Here’s what I came up with:

---
- name: Use geerlinguy.gitlab role
  hosts: gitlab
  vars:
    gitlab_external_url: "https://gitlab"
    gitlab_self_signed_cert_subj: "/C=US/ST=<my state>/L=<my town>/O=IT/CN={{ gitlab_domain }}"
    gitlab_letsencrypt_enable: true
  roles:
    - geerlingguy.gitlab

I sanity-checked my own site playbook with:

ansible-playbook use_geerlingguy.gitlab.yml --syntax-check

And once confirmed sane, I ran it without –syntax-check appended to the end of the line. When the playbook had completed without error I ran nmap against my gitlab host and found out that there were now services listening on ports 80 and 443. A request to http://gitlab:80 redirects to https://gitlab:443 thanks to Geerling’s configuration.

I launched a browser and tried https://gitlab and was presented with a login page. I could not, however, get logged in with the default root password provided in Geerling’s README.md. This was not a big deal, because resetting the GitLab root password is as easy as running the following:

sudo gitlab-rake 'gitlab:password:reset[root]'

and following the prompts. Note that this command does take some time to execute all the way up to the point where it provides you with a prompt to enter a new password. After doing this I was able to log into the WebUI and begin looking around. I opened another browser in private-mode and used the Register Now link to create a normal user, and then switched back to the original browser to approve the new user creation under Menu> Admin> Users> Pending Approval. With this taken care of, I logged back in as myself and created my first git repo on this new server.

I was able to clone this new repo on my local box, but there is something to note about the Ansible Role’s creation of a self-signed cert for this deployment, that I noticed when attempting to push back updates. Git does not like to negotiate with self-signed certs. This is not a deal-breaker in my self-hosted environment, and easily worked-around. But in an enterprise environment you’d want to be sure to use a legitimate, non-self-signed CA issued certificate. To find a workaround I reviewed the project’s troubleshooting page and found my solution under the heading, Unable to perform Git operations due to an internal or self-signed certificate. The solution is to simply use SSH rather than HTTP for git operations, which I was able to begin doing after copying my SSH public key over to GitLab at User Preferences> SSH Keys, in the WebUI. A more permanent solution could be to copy the self-signed cert over to the client and sourcing it with:

git config --global http.sslCAInfo ~/.ssl/gitlab.domain.tld.crt

But, since it’ll only be me using it, I can just remember to always use SSH and dispense with the difficulty of having to do this on every client i intend to use GitLab from.