Deploy Your Application Directly From GitLab CI to Google Kubernetes Engine (GKE)
Google Cloud Platform has a containerized application management called Google Kubernetes Engine (GKE). GKE Gives you a production-ready managed service for containerized applications allowing you to get up and running Kubernetes clusters with your applications in it.
In this blog post, we’ll create a Gitlab CI/CD pipeline that uses a Gitlab CI Runner to automate the deployment and configuration of the Google Cloud GKE cluster.
Every GitLab CI/CD pipelines need a YAML file called .gitlab-ci.yml, which allows you to manage your pipeline. We have an example repository for this, so I’ll explain everything more smoothly. This project has a simple node.js app in it, and the pipeline automatically creates a container for every change that is made and deploys it on GKE via .gitlab-ci.yml file. Let’s take a closer look:
GitLab CI file has parameters that define the job’s behavior. If we look at the top, we have a parameter called stages that has three steps. Every step has a different job, and those jobs run on Gitlab Runners. By default, CI jobs run on shared Gitlab Runners, but you can install and register a runner from your own private environment. You can find more information here.
In the first step, which is called docker build, the runner uses Docker Engine to create a new docker image and pushes that image to the registry. This image starts up an HTTP server on port 3000, that server response back You're on, HOSTNAME, to every request. HOSTNAME here is the server’s actual hostname. Again, this is a simple HTTP server, and so far, all it needs is a Docker Engine. If we want this server reachable from the outside world, we need proper networking and network management, which leads us to step two.
The second step is called gcloud deploy; it uses the Google Cloud command-line tool on the runner and securely authenticates a Google Cloud account. It uses the SERVICE_ACCOUNT variable here, and that holds an environment variable which applied to environments via the runner. The Environment variables can be protected by only exposing them to protected branches or tags. Additionally, they can be masked, so they are hidden in job logs. With that account information, the runner creates a Kubernetes cluster with the specs sets in the .gitlab-ci.yml file. Lastly, the same runner uses the Kubernetes command-line tool this time and deploys the pods specified in the simple-app.yaml file, which I’ll explain that file later.
gcloud destroy is the last step. I add this step because I create the repository for just test purposes, so I would like to destroy the deployment automatically when I’m done. Because of the when: manual parameter, this step triggers only manually.
To do that, you can navigate to your project’s CI/CD > Pipelines menu, then click the Manual Job button; the jobs execute as configured.
Now we can go back to simple-app.yaml file, Kubernetes treats all aspects as an object and those objects represented by a RESTful resource. You can provide this object information to Kubernetes via a YAML file. Let’s take a look:
This YAML file has two sections. Kubernetes divide these sections with a parameter called kind. So, we have two kind here; the first one is kind: Deployment, the other one is kind: Service. Both sections have to include ApiVersion, Kind, Metadata, and Spec parameters keeping the necessary information for Kubernetes objects.
This deployment gets the container image created in step one, then copies that image in 3 separate nodes (that’s what ReplicaSet demands in the filereplicas: 3) and exposes them on port 3000 (containerPort: 3000). These three pods will be exposed to the outside world with a LoadBalancer service that serves for load balancing traffic among pods, exposes the Service externally using Google Cloud’s load balancer. With the service section in our simple-app.yaml file, GKE creates a load balancer service and redirect the pod’s 3000 port to 80 port from the outside world.
There’s a lot more that needs to be explained on this topic. I tried to keep it as beginner-friendly and straightforward as possible, enjoy!
Author: Onur Özkan
Date Published: Sep 8, 2020
