Hey, the project used in this tutorial got superseded by a new helm-based one.
You can still follow this post, just keep in mind that you do not need the tools described in usage, instead you only need helm.
For some time now, I've been really interested in devops, making development itself almost a side-hobby. And since I'm self hosting a Gitlab instance, I have a Kubernetes cluster, many containerized projects, and not enough nerves and time to always manually deploy stuff when I update them (we can go on with the reasons) I decided to look into Gitlab's integrations - more specifically, deploying apps to a k8s cluster.
Granted - since then I have learned a lot of new stuff which made this transition to using Gitlab agent much, much easier.
# The problem
So I've been playing around with this agent thing, deployed one for a private project of mine and it was just great - until I learned that, when using the easy way of installing it on your cluster, the manifests grant the agent cluster-wide administrative permissions! And of course I don't want that because I'm using my cluster - although this approach is an "anti-pattern" - for multiple projects, each restricted to their own namespace.
So I went to read the f*cking manual and learned that there's an alternative, advanced way of doing things. Basically constumizing the manifests to your needs which is all fine and well, but I wanted a simple, fast, environment variable-based solution - so I made gitlab-agent-namespaced.
# The solution
Using the gitlab-agent-namespaced project you can create a new namespace for your project, create the necessary role, service account and deploy the Gitlab agent - all restricted to the namespace you want.
Note that the namespace can already exist, and in case you created it imperatively you will get just a warning telling you that it already exists, it doesn't have the
last-applied-configuration annotation and that it will be now added automatically.