- Configuring your Google account
- Creating a new project from a template
- Creating a Kubernetes cluster from within GitLab
- Installing Helm, Ingress, and Prometheus
- Enabling Auto DevOps (optional)
- Deploying the application
This is a step-by-step guide that will help you use Auto DevOps to deploy a project hosted on GitLab.com to Google Kubernetes Engine.
We will use GitLab’s native Kubernetes integration, so you will not need to create a Kubernetes cluster manually using the Google Cloud Platform console. We will create and deploy a simple application that we create from a GitLab template.
Before creating and connecting your Kubernetes cluster to your GitLab project, you need a Google Cloud Platform account. If you don’t already have one, sign up at https://console.cloud.google.com. You’ll need to either sign in with an existing Google account (for example, one that you use to access Gmail, Drive, etc.) or create a new one.
- Follow the steps as outlined in the “Before you begin” section of the Kubernetes Engine docs in order for the required APIs and related services to be enabled.
- Make sure you have created a billing account.
We will use one of GitLab’s project templates to get started. As the name suggests, those projects provide a barebones application built on some well-known frameworks.
- In GitLab, click the plus icon (+) at the top of the navigation bar and select New project.
Go to the Create from template tab where you can choose among a Ruby on Rails, Spring, or NodeJS Express project. We’ll use the Ruby on Rails template.
Give your project a name, optionally a description, and make it public so that you can take advantage of the features available in the GitLab Gold plan.
- Click Create project.
Now that the project is created, the next step is to create the Kubernetes cluster under which this application will be deployed.
On the project’s landing page, click the button labeled Add Kubernetes cluster (note that this option is also available when you navigate to Operations > Kubernetes).
One the Create new cluster on GKE tab, click “Sign in with Google”.
Connect with your Google account and press Allow when asked (this will be shown only the first time you connect GitLab with your Google account).
The last step is to provide the cluster details. Give it a name, leave the environment scope as is, and choose the GCP project under which the cluster will be created. (Per the instructions when you configured your Google account, a project should have already been created for you.) Next, choose the region/zone under which the cluster will be created, enter the number of nodes you want it to have, and finally choose the machine type.
Once ready, click Create Kubernetes cluster.
After a couple of minutes, the cluster will be created. You can also see its status on your GCP dashboard.
The next step is to install some applications on your cluster that are needed to take full advantage of Auto DevOps.
GitLab’s Kubernetes integration comes with some pre-defined applications for you to install.
The first one to install is Helm Tiller, a package manager for Kubernetes, which is needed in order to install the rest of the applications. Go ahead and click its Install button.
Once it’s installed, the other applications that rely on it will each have their Install button enabled. For this guide, we need Ingress and Prometheus. Ingress provides load balancing, SSL termination, and name-based virtual hosting, using NGINX behind the scenes. Prometheus is an open-source monitoring and alerting system that we’ll use to supervise the deployed application. We will not install GitLab Runner as we’ll use the shared Runners that GitLab.com provides.
After the Ingress is installed, wait a few seconds and copy the IP address that is displayed in order to add in your base Domain at the top of the page. For the purpose of this guide, we will use the one suggested by GitLab. Once you have filled in the domain, click Save changes.
Starting with GitLab 11.3, Auto DevOps is enabled by default. However, it is possible to disable Auto DevOps at both the instance-level (for self-managed instances) and also at the group-level. Follow these steps if Auto DevOps has been manually disabled.
- First, navigate to Settings > CI/CD > Auto DevOps.
- Select Default to Auto DevOps pipeline.
- Lastly, let’s select the continuous deployment strategy
which will automatically deploy the application to production once the pipeline
successfully runs on the
Click Save changes.
Once you complete all the above and save your changes, a new pipeline is automatically created. To view the pipeline, go to CI/CD > Pipelines.
In the next section we’ll break down the pipeline and explain what each job does.
By now you should see the pipeline running, but what is it running exactly?
To navigate inside the pipeline, click its status badge. (Its status should be “running”). The pipeline is split into 4 stages, each running a couple of jobs.
In the test stage, GitLab runs various checks on the application:
testjob runs unit and integration tests by detecting the language and framework (Auto Test)
code_qualityjob checks the code quality and is allowed to fail (Auto Code Quality)
container_scanningjob checks the Docker container if it has any vulnerabilities and is allowed to fail (Auto Container Scanning)
dependency_scanningjob checks if the application has any dependencies susceptible to vulnerabilities and is allowed to fail (Auto Dependency Scanning)
sastjob runs static analysis on the current code to check for potential security issues and is allowed to fail(Auto SAST)
license_managementjob searches the application’s dependencies to determine each of their licenses and is allowed to fail (Auto License Compliance)
testare allowed to fail in the test stage.
The production stage is run after the tests and checks finish, and it automatically deploys the application in Kubernetes (Auto Deploy).
Lastly, in the performance stage, some performance tests will run on the deployed application (Auto Browser Performance Testing).
The URL for the deployed application can be found under the Environments page where you can also monitor your application. Let’s explore that.
Now that the application is successfully deployed, let’s navigate to its website. First, go to Operations > Environments.
In Environments you can see some details about the deployed applications. In the rightmost column for the production environment, you can make use of the three icons:
- The first icon will open the URL of the application that is deployed in production. It’s a very simple page, but the important part is that it works!
The next icon, with the small graph, will take you to the metrics page where Prometheus collects data about the Kubernetes cluster and how the application affects it (in terms of memory/CPU usage, latency, etc.).
- The third icon is the web terminal and it will open a terminal session right inside the container where the application is running.
Right below, there is the Deploy Board. The squares represent pods in your Kubernetes cluster that are associated with the given environment. Hovering above each square you can see the state of a deployment and clicking a square will take you to the pod’s logs page.
REPLICASvariable under Settings > CI/CD > Environment variables.
Following the GitLab flow, let’s create a feature branch that will add some content to the application.
Under your repository, navigate to the following file:
By now, it should only contain a paragraph:
<p>You're on Rails!</p>, so let’s
start adding content. Let’s use GitLab’s Web IDE to make the change. Once
you’re on the Web IDE, make the following change:
<p>You're on Rails! Powered by GitLab Auto DevOps.</p>
Stage the file, add a commit message, and create a new branch and a merge request by clicking Commit.
Once you submit the merge request, you’ll see the pipeline running. This will
run all the jobs as described previously, as well as
a few more that run only on branches other than
After a few minutes you’ll notice that there was a failure in a test.
This means there’s a test that was ‘broken’ by our change.
Navigating into the
test job that failed, you can see what the broken test is:
Failure: WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]: <You're on Rails!> expected but was <You're on Rails! Powered by GitLab Auto DevOps.>.. Expected 0 to be >= 1. bin/rails test test/controllers/welcome_controller_test.rb:4
Let’s fix that:
- Back to the merge request, click the Open in Web IDE button.
- Find the
test/controllers/welcome_controller_test.rbfile and open it.
- Change line 7 to say
You're on Rails! Powered by GitLab Auto DevOps.
- Click Commit.
- On your left, under “Unstaged changes”, click the little checkmark icon to stage the changes.
- Write a commit message and click Commit.
Now, if you go back to the merge request you should not only see the test passing, but also the application deployed as a review app. You can visit it by following clicking the View app button. You will see the changes that we previously made.
Once you merge the merge request, the pipeline will run on the
and the application will be eventually deployed straight to production.
After implementing this project, you should now have a solid understanding of the basics of Auto DevOps. We started from building and testing to deploying and monitoring an application all within GitLab. Despite its automatic nature, Auto DevOps can also be configured and customized to fit your workflow. Here are some helpful resources for further reading: