What is GitLab CI?
GitLab Continuous Integration (CI) is a system that can be leveraged to automate the build and deploy process of various types of software (apps, websites, etc) that are developed using git repos. You can find additional information here.
GitLab CI is pretty straight forward, and is activated by adding a gitlab-ci.yml to your project repo containing instructions for the GitLab runner that will perform the actions defined therein. When using a free account on gitlab.com you have access to something like 500 hours of runner time for free, IIRC. Not a bad deal, especially for small time usage like I need, as I only deploy to my sites a few times a week at most.
Upping the difficulty, as usual.
Instead of simply using the free resources provided by the gitlab.com platform, I decided to active the GitLab CI system on a self hosted instance. And on top of that, I wanted to host it entirely privately, in my tailscale network, with no public facing endpoints. The system will rsync the built sites to the production server that is running caddy and serving the static content.
This presented several challenges, as I could not rely on the automatically generated Let’s Encrypt TLS certificates that is typically used for a self-hosted GitLab instance. Ultimately, I needed to create my own certificate authority (CA), generate TLS certificates for the GitLab instance, and add the CA to the runner so that the docker containers that build the site(s) from the repos will trust the TLS served by GitLab. I couldn’t have done it without the excellent documentation provided by GitLab, and specifically the docs on Self-signed certificates or custom Certification Authorities
This is the first of many… Hopefully!
I hope that this is the first of many blog posts authored thru my DevOps CI pipeline. Time will tell I suppose. Just more to grind up my skills as I continue my job hunt. Not much movement there yet, but I have some leads that may prove fruitful. Stay tuned for more on that…