GitOps – DevOps for Infrastructure Automation
GitOps offers a way to automate and manage infrastructure by using proven DevOps best practices such as version control, code review, and CI/CD pipelines.
Join the DZone community and get the full member experience.Join For Free
GitOps offers a way to automate and manage infrastructure. It does this by using the same DevOps best practices that many teams already use, such as version control, code review, and CI/CD pipelines.
Companies have been adopting DevOps because of its great potential to improve productivity and software quality. Along the way, we’ve found ways to automate the software development lifecycle. But when it comes to infrastructure setup and deployments, it’s still mostly a manual process.
With GitOps teams can automate the infrastructure provisioning process. This is due to the ability to write your infrastructure as code (IaC) with the use of declaration files. We can store them in a Git repository, exactly as we store application development code.
How Does GitOps Work?
The GitOps concept was initially introduced by Weaveworks, a Kubernetes management company. So discussions around GitOps are mainly in the context of Kubernetes. The transformation to microservices running in containers brought a need for orchestration platforms. Container-based applications can be complex and difficult for provisioning and management. GitOps helps in simplifying this by applying techniques proven in the DevOps world.
Nowadays the idea has become popular among DevOps enthusiasts, representing an upgraded model of the IaC concept. It revolves around 3 major components:
- Infrastructure as code
- Pull requests
Let’s look at them separately.
Infrastructure as Code
IaC is a practice of provisioning and managing infrastructure as declaration files, stored as code. By leveraging IaC and version control teams can optimize all operational procedures.
GitOps centers around the declarative model of IaC. This is why Kubernetes is a great example of implementation. Declarative means that configuration is more a declaration of an expected state, instead of a set of commands. For example, in Kubernetes, you can define the number of pods desired for a service in the manifest. The system will then take care of itself. No need for an engineer to write an imperative script that should get to the desired pod number.
Any cloud-native software that conforms to the declarative model can be treated as code. We use AWS CloudFormation, which is a declarative tool, to write AWS infrastructure. This means that we can treat infrastructure itself as code. Declare the desired state as code. The system applies the changes to achieve that state with automation.
With that said, declarative models are not a must to benefit in GitOps. You can do as well with imperatively defined environments.
The main idea behind the GitOps concept is that the version control system is a single source of truth. We use Git as a change management system for our application code. We can also use it for our infrastructure code. So the entire set of declaration files is in a single place where you can collaborate. This enables us to use the key concept of Git - the pull request for operational changes.
In an app development workflow, we use one main branch as a release branch. Developers create feature branches from the main branch. Develop a particular feature or story and when done create a pull request to merge it back into the main branch. This same approach is convenient for infrastructure code.
Creating a pull request enables the code to go through a process of code review before we integrate it into another branch of the codebase. Code reviews stop bad code from getting into test or production environments. This is even more important for infrastructure code. Having formal approvals in place via code reviews helps a lot with the auditing and troubleshooting.
The deployment process in GitOps requires at least two repos: the application repo and the environment configuration repo. The first one contains the source code of the app together with its deployment manifests. The second one contains the desired state of the whole system described using a declarative specification for each environment. You can describe your environments as dev, test, production in a code repository, containing the applications and infrastructure services that can run with a particular version of that environment.
In the case of infrastructure, the main branch can represent an environment. We can implement the changes in the feature branch. Then create a pull request to merge the changes in the main branch. With this, we enable collaboration, while being transparent of who performed which changes. This is also beneficial for issue tracking to the root cause since all changes are commits in Git.
GitOps works with any Git-based system, like GitHub, BitBucket or GitLab. It is not dependent on any tool or technology.
To achieve a full GitOps implementation, you need a CI/CD pipeline. With automated delivery pipelines you can deliver infrastructure changes to designated environments, each time there is a change in the Git repository.
Pipelines are here to connect your Git pull requests to the orchestration system. When you trigger the pipeline with a pull request, the orchestration system executes the task.
There are two possibilities for a GitOps deployment strategy: Push and Pull Pipelines. The difference between them is in the way you ensure the deployment environment resembles the desired infrastructure.
Many popular CI/CD tools are using this strategy. We store the source code of the application and its deployment manifests in one repository. The build pipeline triggers when a new update happens in the application code. The pipeline builds the container images and pushes the changes to the environment. This strategy brings more flexibility, as it can support any type of infrastructure. The disadvantage is that it gives the CI/CD tool access to write to your environment.
The community considers the pull pipeline approach a more secure practice for GitOps. With this approach, the operator is introduced. The operator is a component between the pipeline and the orchestration tool. It constantly compares the target state in the environment repository with the actual state in the deployed infrastructure. The operator changes the infrastructure to fit the environment repository if it detects any changes. Also, it's possible to monitor the image registry to identify new versions of images to deploy. This is what makes GitOps so special.
Published at DZone with permission of Sara Miteva. See the original article here.
Opinions expressed by DZone contributors are their own.