As I wrote about earlier, I now have some of my GitLab CI/CD builds running in Docker containers on the Google Cloud Platform (GCP), slowly chipping away at the US$500 credit I claimed from Google and GitLab. Getting that working was fairly easy, but not quite as easy as suggested by the videos and blog posts I read. I don’t know if the problems were due to the particular state of my GCP account, or recent changes to GitLab’s integration with Google Kubernetes Engine (GKE). In this post I’ll talk through the few places where things didn’t match the documentation.
I didn’t have a GCP project
This is expected, but glossed over in the literature I’ve read. When using the GitLab
Kubernetes page (under the
Operations menu) to create a GKE cluster, I was informed that I need to create a GCP project. GitLab conveniently provided a link to the GCP page that creates a project (see screenshot).
I followed the highlighted link to GCP, where I created an empty project. That’s done via a form with just two fields, Name and Location, and the Location field can be ignored. After I created the project, I returned to gitlab.com and the form there detected my new GCP project. It still wasn’t happy.
My GCP project did not have Billing enabled
On the same page, I was now given a new link, as shown on the right, which I followed the link to enable billing on my new GCP project. The process is painless, and Google promised not to auto-bill me, so I have reluctantly handed over my credit card details. I also activated my US$300 start-up offer. To save you some time, I’ve poked around the UI and I can confirm that you cannot cash out that credit.
So I now had a GCP project with billing enabled. A GCP project is essentially a collection of configuration information: it doesn’t “do” anything. In order to get my GitLab builds running on GCP, I needed to create a Kubernetes cluster associated with the project. Which is exactly what the gitlab.com page was going to do for me once I could get as far as the “Submit” button.
My GCP project did not have the Compute Engine API enabled
The clusters created by GitLab run entirely within a single data centre (I don’t know if they can span multiple data centres, and I didn’t need them to), so now I had to pick where my cluster would be created. Unfortunately, this too presented me with an error and a link to solve it. On navigating to the Google APIs and Services console for the project (the link is in the screenshot to the right), I just had to click on the Computer Engine API link.
That enabled the API automatically, and I returned to the gitlab.com page, which was now able to load the zones. I chose one fairly close to me (Australia isn’t exactly down the street, but it’s closer than anywhere else in the drop down).
I couldn’t create a tiny test node
The only other bother I had at this stage was that I could not create a cluster based on machine type
f1-micro, the smallest in that drop-down. Every time I tried, I was presented with an apparently unrelated error. This is a known issue. The advertised workaround, to use
g1-small, was good enough for me. I’ll probably need something larger tomorrow, this is just my minimal viable experiment. This was the last issue I had when creating the GKE cluster.
I couldn’t get my build to use my GitLab runner
As described in my earlier post, I now had a deployed GitLab runner on my new GKE cluster. To test that it was all doing what I expected, I triggered a build of my project. The build output said that it was using the usual free GitLab runner, using up some of my free 2000 monthly minutes. Not what I was hoping for, but that’s just because GitLab now has a bigger pool of runners to choose from: GitLab’s free ones, and the new one I’ve set up in GKE. A quick hunt through my project’s CI/CD settings showed a “Runners” section, which allowed me to enable and disable the GitLab and Kubernetes runners.
The same page exists on each project, so I can enable any of my projects to share the same runner, or I can create new runners for each project to enable more concurrent builds.
Once I’d disabled the shared runners, a new build showed that it was correctly using the new runner, highlighted in the console output here.
And now I have my GItLab CI builds running on my GKE cluster!