GitOps idea is initially revealed in 2017 by Weaveworks. The core idea is to use Git as the single source of truth for cloud native application development and deployment, in Kubernetes environment.
GitOps is a set of automated delivery processes with the help of software tools to ensure the desired state of the target deployment environments are always matching the described states in the Git repositories. Developers can make pull requests to accelerate and simplify application deployments and operations tasks to Kurbernetes.
GitOps created many buzz today and we have seen communities are starting to take a serious look into GitOps. There are many imperatives of GitOps. I have shortlisted them into four key characteristics in order to implement a successful GitOps.
The Key Characteristics of GitOps
Declarative Application Configuration
The application configuration must be declarative to embrace the ease of maintenance and readability. The declarative approach also make it easy to be served as standard documentation across development team and operation team. Hence the term of declarative descriptions is used.
Since GitOps is designed for Kubernetes environment, the application configuration mostly is referring to the Kubernetes manifests.
It is the declarative approach together with the use of templating tools such as Kustomize, Helm and Tekton, that make it possible to make GitOps an easier path.
Separating Declarative Descriptions and The Source Code
There should always be two Gits in the GitOps environment. One Git for the application source codes and the other Git for declarative descriptions of the desired state of the targeted environments.
There are few advantages of Git separation.
There will be time that you would like to trigger deployment without triggering the container image build such as changing of the application service name.
You may want to ensure proper security access or segregation of duties to only allow developers to access to source code Git but not the declarative descriptions Git.
You certainly do not want to have the source codes pushed by developers to cause the redeployment of the applications in the targeted environments when the declarative descriptions are not ready or not updated per application changes yet.
Separated Git provides cleaner audit logs especially when investigation is needed to rectify the problem caused by declarative descriptions. At most times, if the problem is caused by declarative descriptions and it is much easier to roll back to the previous working version.
There will Always be Two Separated Processes in GitOps – Build and Deployment
The build process which is also referred to CI (continuous integration) is responsible to build and package the application codes into container image. In microservices this will result in many container images. Ideally these container images should be stored in container image registry. This could be Quay, Docker Hub, JFrog Artifactory and etc. The build process can be automated with CI engines such as Jenkins, Spinnaker, JenkinsX and etc.
The deployment process is where the CD (continuous deployment) take place. This is where the heart of GitOps is, where it is key to ensure that the desired state of the targeted deployment environments are always tally with the declarative descriptions in the repository.
The manual process of updating the declarative descriptions in the Git seems unavoidable. In real life environment, you do not want the declarative descriptions to be automatically updated when the container images changed. Especially when there are more than one configuration that may need to be changed before deploying into the Kubernetes environments.
GitOps Pull vs Push Strategy
Typical Push strategy is to use CD engine with pipelines to push the changes from image registry and declarative descriptions repository to the Kubernetes cluster. The CD engine requires cluster credential and read/write access to repository and cluster.
Pull strategy is the opposite. The container image and declarative descriptions changes are pulled into the cluster from inside the cluster itself, with the CD engine running inside the cluster. This is considered more secure approach because there is no need to share Kubernetes cluster credentials and read/write permissions outside of Kubernetes cluster.
One of the software tools provides the pull strategy is ArgoCD. ArgoCD is the GitOps server deployed in Kubernetes cluster. It detects OutOfSync application state and take corrective actions to bring the targeted environment to the desire state declared in the repository.
GitOps vs DevOps
So is GitOps a DevOps?
DevOps is a set of practices that combines software development (Dev) and information-technology operations (Ops) which aims to shorten the systems development life cycle and provide continuous delivery with high software quality.
From Wikipedia
DevOps is a set of practices that involve adapting the organisation culture to achieve the above software development and delivery goals. It is also means organisation is freely to adapt any process and software tools to achieve the goals.
GitOps is an opinionted software delivery process rather than a set of common practices. There is limited freedom to choose how you would want to implement it and where you can use it. As it is defined today, you have to use Git as your centre of your GitOps and it is meanly for Kubernetes platform.
You may change it to adapt to your own environment which maybe you are using Microsoft Teams Foundation as your source control system. It will not be called GitOps anymore.
Summary
When we look at what GitOps has to offer, take aside the Git requirement, we will notice this processes is there in the past and has been used by many organisation today. It is not new however it is more fine tuned version and a more structured version compared to what we see in the past. It has more communities support and innovation to provide a better software tools to make it easier to be implemented today.
As like many DevOps tools available today. It is still lack of the key element – the human. As how DevOps is defined, human is the key part of the entire culture and practices. I have highlighted previously you can not run away from having human to change the declarative descriptions in the Git. We need a better controlled and auditor friendly approach to deal with this such as a checker-maker process to ensure no single team or person has the total authority to make changes in the Git freely.
Please do not get me wrong. GitOps is definitely a good concept. It helps to define a clearer process and pave the path to a better continuous delivery implementation.