CINQby Victor Louisa
Recently I presented a webinar about CI/CD and GitLab. It contained a demo of the Auto DevOps feature of GitLab. Connected to a Kubernetes cluster, this Auto DevOps feature really impressed me. Setting this up appeared to be rather easy. Hence I would like to share how you can do this, so you can play around with this Auto DevOps feature of GitLab yourself.
Why should you experience the power of GitLab's Auto DevOps feature with Kubernetes yourself?
Because, when you push just a simple Java Spring Boot helloworld app to your GitLab repository. The Auto DevOps feature gives you out-of-the-box an impressive, full fledged, very powerful standard pipeline. This pipeline isn't only complete in terms of testing, scanning, security and performance. But it also deploys your code on your Kubernetes cluster and can expose it at a public domain with TLS enabled.
Before we start, there are a couple of prerequisites. You need two accounts and three CLI's:
Remark: There are minor costs involved in AWS for this setup, e.g. EKS, Load Balancer, route53.
What we are going to do:
The tool eksctl provides a very nice and easy CLI to create an EKS cluster. We use it to create an EKS cluster with name eks-gitlab in AWS region eu-central-1.
Note that eksctl has updated your kubeconf with the new Kubernetes cluster, hence you can directly connect with kubectl. You can also verify your Kubernetes cluster in the AWS console.
Let's first create a new blank project in GitLab.
Now we can connect our Kubernetes cluster to this new project by granting GitLab cluster-admin access.
We need to fill in some cluster values here, which we can retrieve as follows:
Then push "Add Kubernetes cluster" to create the connection.
Now that GitLab has control over your cluster, it can install apps for you. These apps are installed with a single click.
For this demo it is enough to install:
But feel free to discover other apps as well, like:
GitLab can use a public domain to expose your web app.
If you do not have a registered domain in AWS, create one.
Note 1: AWS says it can take 3 days before the domain is ready. Mine took just 15 minutes.
Note 2: AWS will also create a hosted zone for your domain.
When you installed Ingress in the previous step. Kubernetes has created a load balancer in AWS. We will connect the domain to the load balancer by creating a CNAME DNS record.
When the domain is connected to the load balancer, we need to configure the domain name in GitLab.
Note: Do not add the wildcard * to the domain here.
Everything is ready to enable Auto DevOps.
Now you can push your code to your new repo. Here is a simple Java Spring Boot helloworld example which you can use, but you can also choose a helloworld web app of any other popular language.
Note that this repo does not contain any Dockerfile, Helm chart or even a ci/cd config file. It is just a simple Java Spring Boot app with two tests defined and a standard pom file.
The moment you push your code a new pipeline is started:
View the pipeline at: CI/CD > Pipelines
This standard pipeline has an amazing set of features, like:
It then creates a DAST namespace in your Kubernetes cluster, to deploy your app and perform:
And then, when all of this is succeeded, it deploys your app into the production namespace in your cluster. And makes it available at
https://dirc-gitlab-demo.c3s.io
Or more general, at: https://<gitlab-group>-<gitlab-repo>.<your-domain>
You can also view your environments at: Operations > Environments
Now change some code and make a merge request to see that this triggers a similar pipeline, but now it is deployed to a branch related namespace. So you can compare it easily to your web app that is running in namespace production. When you are happy with your change, approve the merge request and your change will be deployed in production.
Note: All of the above pipeline steps consist of open source software and can be configured if needed.
Recall that the helloworld repo did not contain any ci/cd config files. GitLab Auto DevOps together with Kubernetes gives you a very mature and powerful standard pipeline. Of course, every project will need it's own tweaks and additions, but this standard pipeline gives DevOps teams just a very good and easy starting point for setting up their CI/CD.