It is possible to use GitLab as a best-in-class GitOps tool, and this blog post series is going to show you how. These easy-to-follow tutorials will focus on different user problems, including provisioning, managing a base infrastructure, and deploying various third-party or custom applications on top of them. You can find the entire "Ultimate guide to GitOps with GitLab" tutorial series here.
In this article we will look at how one can use Auto DevOps with all its bells and whistles to easily manage deployments.
This article builds upon the previous tutorials in this series. We will assume that you have a Kubernetes cluster connected to GitLab using the GitLab Agent for Kubernetes, and you understand how the CI/CD tunnel works.
If this is not the case, I recommend to follow the previous articles to have a similar setup from where we will start today.
What is Auto DevOps
Auto DevOps is GitLab's answer to the complexity of software application delivery. It is a set of opinionated templates that can be used "as-is" or can be used to fast-track your own pipeline building. For some setups it works from testing through various security and compliance checks to canary deployments. Even if you have a less supported setup, you should be able to reuse some of its components, from security linting to deployment.
You can read more about the various features built into Auto DevOps in our documentation.
The plan for this article is to build and deploy a minimal application. The focus will be on showing how you can get started quickly, without any modifications on the Auto Deploy pipelines.
This setup will use the already known CI/CD tunnel. There will be a separate article that shows how to replace the "Auto Deploy" part of Auto DevOps with GitOps style deployments.
In this article, we will deploy a simple hello world application. This is not a tutorial about Auto DevOps, so we will only focus on the setup needed when used together with the GitLab Agent for Kubernetes.
You can see the final repository under https://gitlab.com/gitlab-examples/ops/gitops-demo/hello-world-service/.
In this section we will create our super simple hello world application and put a Dockerfile beside it.
- Start a new project.
src/main.pywith the following content:
# From https://gist.github.com/davidbgk/b10113c3779b8388e96e6d0c44e03a74 import http.server import socketserver from http import HTTPStatus class Handler(http.server.SimpleHTTPRequestHandler): def do_GET(self): self.send_response(HTTPStatus.OK) self.end_headers() self.wfile.write(b'Hello world') httpd = socketserver.TCPServer(('', 5000), Handler) httpd.serve_forever()
- Create the
FROM python:3.9.10-slim-bullseye WORKDIR /app COPY ./src . EXPOSE 5000 CMD [ "python", "main.py" ]
- Commit the change to the repository.
Setting up Auto DevOps
- Share the CI/CD tunnel with the hello-world project. Note, that the Agent configuration project amd the application project should be in the same project hierarchy and the Agent configuration project needs to be higher in this hierarchy.
ci_access: # This agent is accessible from CI jobs in projects in these groups projects: - id: <path>/<to>/<your>/<project>
- Find out the Kubernetes context name. The agent context name is
<namespace>/<group>/<project>:<agent-name>. You can see the available contexts in CI with the following job:
contexts: stage: .pre image: name: bitnami/kubectl:latest entrypoint: [""] script: - kubectl config get-contexts
- Create your
.gitlab-ci.ymlfile to have Auto DevOps working:
include: template: Auto-DevOps.gitlab-ci.yml variables: # KUBE_INGRESS_BASE_DOMAIN is the application deployment domain and should be set as a variable at the group or project level. KUBE_INGRESS_BASE_DOMAIN: 220.127.116.11.nip.io KUBE_CONTEXT: "gitlab-examples/ops/gitops-demo/k8s-agents:demo-agent" KUBE_NAMESPACE: "demo-agent" # Feel free to enable any of these TEST_DISABLED: "true" CODE_QUALITY_DISABLED: "true" LICENSE_MANAGEMENT_DISABLED: "true" BROWSER_PERFORMANCE_DISABLED: "true" LOAD_PERFORMANCE_DISABLED: "true" SAST_DISABLED: "true" SECRET_DETECTION_DISABLED: "true" DEPENDENCY_SCANNING_DISABLED: "true" CONTAINER_SCANNING_DISABLED: "true" DAST_DISABLED: "true" REVIEW_DISABLED: "true" CODE_INTELLIGENCE_DISABLED: "true" CLUSTER_IMAGE_SCANNING_DISABLED: "true" POSTGRES_ENABLED: "false"
- Commit the changes.
As you can see, I disabled many Auto DevOps functionalities in the above CI YAML. I did this for two reasons:
- Some of these features require a Premium or Ultimate license or tests in the repo. I wanted to keep this tutorial "stable" for everyone.
- Every use case differs a little bit and Auto DevOps allows a large number of customizations. I wanted to highlight this by showing you the most basic ones. Read more about customizing Auto DevOps. If you would like Review Apps support, just remove the
There are actually only three settings to get the Auto DevOps pipeline up and running:
KUBE_CONTEXTspecifies the context used for the connection, it's provided by the GitLab Agent for Kubernetes.
KUBE_NAMESPACEspecifies the Kubernetes namespace to target with the deployments. This namespace will be used as we apply the Helm charts used behind the hood.
KUBE_INGRESS_BASE_DOMAINsets up an Ingress and enables user friendly access to the deployed service.
A very common setup I see with GitLab customers is that the development team is responsible for writing the application code and packaging it into a Docker container. During this process, they take care of basic testing as well, but they are not familiar with all the security and compliance requirements or the deployment pipelines used within the company. The presented setup and the Auto DevOps suite of templates serves these teams. As you can see, the teams need minimal GitLab CI setup to run a complex pipeline that can take care of many of their requirements.
In the next article, I will show you how to deploy an application project with a GitOps style workflow.
Click here for the next tutorial.
“Learn about the best practices of doing GitOps with GitLab with our series of tutorials.” – Viktor Nagy
Click to tweet