### 2023-05-03
## Introduction
GitLab is a web-based Git repository management tool that provides version control, continuous integration and deployment, and other collaborative features for software development teams. One of the standout features of GitLab is its ease of installation, which is a critical factor for teams looking to get up and running quickly.
GitLab provides a variety of installation options to cater to different needs, including self-managed, cloud-hosted, and GitLab.com instances. The self-managed option is a popular choice among organizations that want to host GitLab on their own infrastructure, allowing them to have complete control over their repositories and data.
The self-managed installation process is straightforward, with detailed installation guides available for different operating systems and deployment environments. GitLab provides packages for popular Linux distributions such as Ubuntu, Debian, and CentOS, as well as Docker images for containerized deployments. The installation process typically involves running a few simple commands, after which GitLab is ready to be configured and used.
For those who prefer a cloud-hosted solution, GitLab provides a fully managed offering that eliminates the need for self-managed infrastructure. This option provides a turnkey solution that can be set up within minutes, enabling teams to focus on their development workflows rather than infrastructure management.
Overall, GitLab's ease of installation is a key factor that has contributed to its popularity among software development teams. Whether organizations choose to self-manage or use GitLab's cloud-hosted offering, the installation process is designed to be straightforward and accessible, allowing teams to get up and running quickly and efficiently.
## Getting Real
In reality, even though Gitlab is fairly simple to install, sometimes our infrastructure plays a big role into how "straight-forward installations" play out. This was my case when deciding to deploy a Gitlab node in my HomeLab.
Some of you may know, but I am an avid supporter of the pfSense firewall platform. pfSense is a free, open-source firewall and router software that provides advanced networking capabilities and security features. It is based on the FreeBSD operating system and is designed to be highly customizable and scalable to meet the needs of small to medium-sized businesses and large enterprises alike.
pfSense offers a user-friendly web interface that enables network administrators to manage their network configurations and security policies. It provides a wide range of advanced features such as virtual private networking (VPN), traffic shaping, and intrusion detection, making it an excellent choice for network security and management.
The software is known for its flexibility and extensibility, with a large community of developers contributing to its ongoing development and maintenance. pfSense can be deployed on a variety of hardware, including dedicated firewalls, virtual machines, and cloud platforms, and supports a wide range of network interfaces and protocols.
Overall, pfSense is a powerful and versatile firewall and router software that provides advanced networking and security features to protect and manage network traffic. Its open-source nature and large community of contributors make it a cost-effective and customizable solution for organizations of all sizes. Including people like myself who are always trying out new software solutions in their HomeLabs.
## Gitlab Installation Specifications
From all the Awesome configuration options Gitlab provides, I needed (mostly) four:
- Being able to access it externally
- Hosting an artifact registry
- Be able to rotate it's own TLS certificates automatically
- Set up a data directory of my choosing (instead of using the default path)
I will be using RHEL 8.6 as the hosting VM and the latest gitlab-ee repository already configured. **These configuration details have been tested in gitlab 15.5.x**
In the gitlab-rb:
1) Line 32 of the gitlab.rb needs to have your domain. Notice how it starts with https.
```bash
## GitLab URL
##! URL on which GitLab will be reachable.
##! For more details on configuring external_url see:
##! https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab
##!
##! Note: During installation/upgrades, the value of the environment variable
##! EXTERNAL_URL will be used to populate/replace this value.
##! On AWS EC2 instances, we also attempt to fetch the public hostname/IP
##! address from AWS. For more details, see:
##! https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html
external_url 'https://<your domain here>'
## Roles for multi-instance GitLab
##! The default is to have no roles enabled, which results in GitLab running as an all-in-one instance.
##! Options:
##! redis_sentinel_role redis_master_role redis_replica_role geo_primary_role geo_secondary_role
##! postgres_role consul_role application_role monitoring_role
##! For more details on each role, see:
##! https://docs.gitlab.com/omnibus/roles/index.html#roles
##!
# roles ['redis_sentinel_role', 'redis_master_role']
```
2) To setup a different data storing directory (line 641-645):
```bash
### For setting up different data storing directory
###! Docs: https://docs.gitlab.com/omnibus/settings/configuration.html#store-git-data-in-an-alternative-directory###! **If you want to use a single non-default directory to store git data use a
###! path that doesn't contain symlinks.**
git_data_dirs({
"default" => {
"path" => "<your different directory path>"
}
})
```
3) To activate the registry (line 793, instead of using "registry" you could use something else.):
```bash
################################################################################
## Container Registry settings
##! Docs: https://docs.gitlab.com/ee/administration/packages/container_registry.html
################################################################################
registry_external_url 'https://registry.<your domain>'
```
4) Finally, for auto certificate renewal using letsencrypt (line 2504-2514):
```bash
################################################################################
# Let's Encrypt integration
################################################################################
letsencrypt['enable'] = true
# letsencrypt['contact_emails'] = [] # This should be an array of email addresses to add as contacts# letsencrypt['group'] = 'root'
# letsencrypt['key_size'] = 2048
# letsencrypt['owner'] = 'root'
# letsencrypt['wwwroot'] = '/var/opt/gitlab/nginx/www'
# See http://docs.gitlab.com/omnibus/settings/ssl.html#automatic-renewal for more on these sesttings
letsencrypt['auto_renew'] = trueletsencrypt['auto_renew_hour'] = "12"
letsencrypt['auto_renew_minute'] = "30" # Should be a number or cron expression, if specified."
letsencrypt['auto_renew_day_of_month'] = "*/4"
# letsencrypt['auto_renew_log_directory'] = '/var/log/gitlab/lets-encrypt'
```
I know there are more configuration options in the gitlab.rc, but for what I need it to do, it's more than enough.
## pfSense Configurations
Configuring GitLab is easy compared to pfSense, but totally doable. **Supposing you have the necessary DNS records in place for the registry and gitlab, both external AND internal.**
To make it work you need two pairs of rules:
### NAT
1) First rule (NAT): external 443 to gitlab's private IP:443.
2) Second rule (NAT): external 80 to gitlab's private IP:80. This is for the letsencrypt bot to renew the TLS certificates.
Should look like this:
![[Pasted image 20230503102523 1.png]]
### WAN
1) First Rule (WAN): external 443 to gitlab's private IP:443. Action needs to be "Pass", Interface "WAN".
2) Second rule (WAN): external 80 to gitlab's private IP:80. Action needs to be "Pass", Interface "WAN".
Should look like this:
![[Pasted image 20230503101006.png]]
Make sure the rules are sitting on top of any other rules you have AND are enabled. I know it's basic, but I have to say it. Also, make sure the VM's firewall rules accept 443, 80 and 22 (for admin and git ssh).
## In Conclusion
Setting up Gitlab for the first time can be a daunting task. But with a little bit of preparation and some research, its worth it. Learning how to manage an omnibus gitlab instance is essential for the growth of any DevSecOps engineer, SRE or Cloud Engineer. Trying stuff out on your own time can pay dividends at work and will make you look like a super star everywhere else. Stay curious.
**If you need any help or want to get in contact with me, Click [danvazquez.com](https://danvazquez.com) where I have my contact details.**