13 KiB
Getting started with Auto DevOps
This is a step-by-step guide that will help you deploy a project hosted on GitLab.com to Google Kubernetes Engine, using Auto DevOps.
We will use the Kubernetes integration that GitLab provides, so you won't have to create a Kubernetes cluster manually using the GCP console.
Configuring your Google account
Before creating and connecting your Kubernetes cluster to your GitLab project, you have to set up your Google Cloud account. If you don't already have one, go and create it at https://console.cloud.google.com. If you already have a Google account that you use to access Gmail, etc., you can use it to sign in the Google Cloud.
- 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.
TIP: Tip: Every new Google Cloud Platform (GCP) account receives $300 in credit, and in partnership with Google, GitLab is able to offer an additional $200 for new GCP accounts to get started with GitLab's Google Kubernetes Engine Integration. All you have to do is follow this link and apply for credit.
Creating a new project from a template
We will use one of GitLab's project templates to get started. AS the name suggests, those projects provide a barebone of an application built on some well known frameworks.
-
Find the plus icon (+) at the top of the navigation bar, click it and select New project.
-
Go to the Create from template tab where you can choose among a Ruby on Rails, a Spring, or a NodeJS Express project. For the sake of the example let's 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.
-
Finally, click on the Create project button.
Now that the project is created, the next step is to create the Kubernetes cluster under which this application will be deployed.
Creating a Kubernetes cluster
One thing you should notice after you created the project is the Add Kubernetes cluster button on the project's landing page. Go ahead and click it.
TIP: Tip: Another way is to navigate to Operations > Kubernetes and click on Add Kubernetes cluster.
From there on, let's see how to create a new Kubernetes cluster on GKE:
-
Choose Create on Google Kubernetes Engine.
-
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 fill in 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 (if you followed the instructions when you configured your Google account, a project should have 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 their machine type.
-
Once ready, hit the Create Kubernetes cluster button.
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.
Installing Helm, Ingress and Prometheus
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 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 will show up, we'll use in the next step when enabling Auto DevOps.
Enabling Auto DevOps
Now that the Kubernetes cluster is set up and ready, let's enable Auto DevOps.
-
First, navigate to Settings > CI/CD > Auto DevOps.
-
Select Enable Auto DevOps.
-
Add in your base Domain by using the one GitLab suggests. Note that generally, you would associate the IP address with a domain name on your registrar's settings. In this case, for the sake of the guide, we will use an alternative DNS that will map any domain name of the scheme
anything.ip_address.nip.io
to the correspondingip_address
. For example, if the IP address of the Ingress is1.2.3.4
, the domain name to fill in would be1.2.3.4.nip.io
. -
Lastly, let's select the continuous deployment strategy which will automatically deploy the application to production once the pipeline successfully runs on
master
branch. -
Hit Save changes for the changes to take effect.
Once you complete all the above and save your changes, a new pipeline will be automatically created. Go to CI/CD > Pipelines to check it out.
In the next section we'll break down the pipeline and explain what each job does.
Deploying the application
So, by now you should see the pipeline running, but what is it running exactly?
To navigate inside the pipeline, click on its status badge (it should say running) The pipeline is split into 4 stages, each running a couple of jobs.
In the build stage, the application is built into a Docker image and then uploaded to your project's Container Registry (Auto Build).
In the test stage, GitLab runs various checks on the application:
- The
test
job runs unit and integration tests by detecting the language and framework (Auto Test) - The
code_quality
job checks the code quality and is allowed to fail (Auto Code Quality) [STARTER] - The
container_scanning
job checks the Docker container if it has any vulnerabilities and is allowed to fail (Auto Container Scanning) - The
dependency_scanning
job checks if the application has any dependencies susceptible to vulnerabilities and is allowed to fail (Auto Dependency Scanning) [ULTIMATE] - The
sast
job runs static analysis on the current code and checks for potential security issues and is allowed to fail(Auto SAST) [ULTIMATE] - The
license_management
job searches the application's dependencies for their license and is allowed to fail (Auto License Management) [ULTIMATE]
NOTE: Note:
As you might have noticed, all jobs except test
are 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). [PREMIUM]
The URL for the deployed application can be found under the Environments page where you can also monitor your application. Let's explore that.
Monitoring
Now that the application is successfully deployed, let's navigate to its website, by first going to Operations > Environments.
This is the Environments where you can see some details about the deployed applications. At the upper right or the production environment, you should see some icons:
-
The first one will take you to the URL of the application that is deployed in production. It's a very simple page, but the purpose is that it works!
-
The next icon with the little 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 on the square will take you to the pod's logs page.
TIP: Tip:
There is only one pod hosting the application at the moment, but you can add
more pods by defining the REPLICAS
variable
under Settings > CI/CD > Variables.
Working with branches
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: app/views/welcome/index.html.erb
.
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
a few more that run only on branches other than master
.
After a few minutes you'll realize that there was a failure in a test.
That means that there's a test that was broken when we made the change.
Navigating in 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 Web IDE button.
- Find the
test/controllers/welcome_controller_test.rb
file 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 hit Commit
Now, if you go back to the merge request you should see not only the test passing, but the application deployed as a review app. You can visit it by following the URL in the merge request. The changes that we previously made should be there.
Once you merge the merge request, the pipeline will run on the master
branch,
and the application will be eventually deployed straight to production.
Conclusion
By now, you should have gained a solid understanding of how Auto DevOps works. We started from building and testing to deploying and monitoring an application all within GitLab. In spite of its auto nature, this doesn't mean that you can't configure and customize Auto DevOps to fit your workflow. Here are a few interesting links: