In part one of our GitOps series, we described how to use a pull-based (or agent-based) approach. In this second blog post, we'll dig deep into how to use a push-based approach. The agentless approach may be preferable for situations with non-Kubernetes infrastructure components or when you don't want to install, run, and maintain agents in each infrastructure component for GitOps. In this post, we will discuss how the scripting capabilities of GitLab can be used in GitOps workflows, and how to use predefined GitLab variables to shape infrastructure components.
About a push-based or agentless approach
With the agentless approach, infrastructure expressed and managed as code on GitLab, and updates and drift detection are automated and handled by GitLab without having to install any agents on infrastructure components.
How to use scripting in your pipelines to shape infrastructure
GitLab allows automation using scripting. Whether you're using Docker, Helm, Ansible, or even direct SSH commands, you can use the scripting capabilities of GitLab to create, shape, and modify infrastructure.
In the example below, the pipeline determines the shape of the infrastructure the application runs on by specifying a Docker image as well as running Docker commands to build and push an application to the GitLab built-in container registry.
How to use Docker in your pipeline to shape infrastructure.
The infrastructure is shaped again at a later stage in the pipeline, but this time by using kubectl and Helm commands:
How to use kubectl in your pipeline to shape infrastructure.
Depending on the type of infrastructure, other technologies can be used to shape the infrastructure. In the next example, Ansible is used to run a playbook that sets up the infrastructure for an entire lab environment:
How to use Ansible in your pipeline to shape infrastructure.
The scripting capabilities of GitLab pipelines combined with GitLab's CI/CD capabilities allow users to create GitOps flows to manage Infrastructure as Code (IaC), which delivers more resilient infrastructure and less risk of unscheduled downtime.
How to use Auto DevOps to modify infrastructure using variables
GitLab also allows users to shape infrastructure by using project or group variables. The number of production pods in a Kubernetes cluster is updated to four in the example below:
How to use variables to shape infrastructure.
The number of the production pods are changed to four on the next execution of the pipeline:
Production pods changed using a variable update.
There are many GitLab build and deployment variables that can modify infrastructure. PostgreSQL is provisioned as a component in infrastructure by default in GitLab to support applications that require a database and also provides these variables to customize it.
How GitLab capabilities help agentless infrastructure
The scripting capabilities of GitLab are a convenient way to shape infrastructure components in GitOps workflows using a push-based approach. This method allows for the easy integration of IaC tools in your GitOps pipelines. If you are doing IaC and GitOps for non-Kubernetes infrastructure components, this is the best approach. GitLab also provides out-of-the-box variables, so users can impact selected infrastructure components. In the final part of this GitOps series, we will discuss an agentless approach using our integration to Terraform as well as examples of GitOps flows for AWS ECS and EC2.
Cover image by Rod Long on Unsplash
