GitOps with GitLab: Connecting GitLab with a Kubernetes cluster - Auto DevOps

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.

Prerequisites

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

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/.

The application

In this section we will create our super simple hello world application and put a Dockerfile beside it.

1. Start a new project.
2. Add src/main.py with 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()
   

3. Create the Dockerfile with:

   FROM python:3.9.10-slim-bullseye
   
   WORKDIR /app
   
   COPY ./src .
   
   EXPOSE 5000
   
   CMD [ "python", "main.py" ]
   

4. Commit the change to the repository.

Setting up Auto DevOps

1. 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>
   

2. 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 
   

3. Create your .gitlab-ci.yml file 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: 74.220.23.215.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"
   

4. Commit the changes.

As you can see, I disabled many Auto DevOps functionalities in the above CI YAML. I did this for two reasons:

1. Some of these features require a Premium or Ultimate license or tests in the repo. I wanted to keep this tutorial "stable" for everyone.
2. 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 REVIEW_DISABLED line.

There are actually only three settings to get the Auto DevOps pipeline up and running:

• The KUBE_CONTEXT specifies the context used for the connection, it's provided by the GitLab Agent for Kubernetes.
• The KUBE_NAMESPACE specifies the Kubernetes namespace to target with the deployments. This namespace will be used as we apply the Helm charts used behind the hood.
• The KUBE_INGRESS_BASE_DOMAIN sets up an Ingress and enables user friendly access to the deployed service.

Recap

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.

What's next

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.