Agile Software Development principles have gained more and more attention in recent years. They help making product teams more flexible and productive. However, to fully leverage the potential of agility in software development projects, you also need an agile operations model and embrace DevOps principles. GitOps follows modern DevOps principles and allows for secure, fast and reliable deployments.
DevOps is not about losing control
Our work with various clients tells us that many IT-Architects wrongly believe that following DevOps principles leads to a loss of control, especially regarding how IT operations are done. More often than not we hear that the operation and development teams need to be strictly separated. Automation along this interface (e.g. Continuous Delivery / Deployment) appears to be difficult because it topples security and neglects auditing and approval requirements.
In this blogpost, we will demonstrate how GitOps can be used to automate deployments while still maintaining approval processes and auditing mechanisms and allowing for a high degree of security.
Continuous Integration and Delivery to implement DevOps paradigms
Before we delve deeper into the concept of GitOps, it is crucial to understand what DevOps actually is. The term DevOps is a combination of the terms Development and Operations, emphasizing the close collaboration between the two tasks - a requirement for a flexible and agile software development lifecycle. The core idea of DevOps is to enable a fast, yet flexible process for the development, integration and deployment of applications. To achieve such a process, heavy automation along each step of the software development lifecycle is crucial. Continuous Integration and Continuous Delivery / Deployment are two principles to achieve this kind of automation.
The principle of Continuous Integration (CI) suggests that code is automatically built and tested as soon as a commit is pushed to the applications repository. Thus, CI enables the software development team to find bugs early by failing tests or builds in the CI pipeline. CI is a well adopted approach and there is a myriad of tools supporting it.
Continuous Delivery / Deployment (CD) relates to automation along the release and deployment process of the software development lifecycle. Although often taken for the same, there is a slight yet important difference between Continuous Delivery and Continuous Deployment. Continuous Delivery describes the state of being ready to release a certain version of your application to production (or any other environment) at any time by just the single click of a button. On the contrary, Continuous Deployment describes the process of automatically deploying each commit, which results in a successful build, to a certain environment (which can be the development, QA or production environment).
Are you already using CD pipelines?
Although we find that CI mechanisms are widely adopted, we see that CD mechanisms are frowned upon by many IT-Architects for the reasons mentioned above. Large organizations make heavy use of CI yet fall back on a manual process for the deployment to QA and production environments. Not only does this introduce human errors in the deployment process but it also slows down the process. To avoid these impediments, we propose GitOps to stay in control of automatic deployments to any environment while allowing for a custom approval process and seamless auditability.
GitOps to improve transparency
GitOps allows to operate deployments to a Kubernetes cluster only by commits to a git repository. The git repository (also called state repository) acts as the single source of truth for the state of your application landscape. Whenever your application landscape is to be changed, this is done through one or more commits to the state repository. By utilizing Merge / Pull Request features that come with most commonly used source control systems, it is possible to implement any approval process required in a company. Once the approval is given for the changes, GitOps suggests automatic deployments to the desired environment.
By using git as the single source of truth for the application landscape, every change is automatically recorded in the git history. This allows for seamless auditability with regard to who made what changes at what time. Furthermore, having your application landscape historized allows for quick rollbacks to previous versions of your landscape. Going back is as easy as reverting to a previous git commit and pushing that change to the state repository of your application.
CNCF recommends Flux
If you are orchestrating your application landscape through Kubernetes, Flux CD is a daemon that runs inside your Kubernetes cluster and is responsible for synchronizing a GitOps state repository with the cluster. Whenever Flux CD detects a discrepancy between the current state of your Kubernetes cluster and the state that is defined in the state repository, it will update the cluster to eliminate the difference. The figure below illustrates the GitOps operations model with Flux CD.
GitOps operations model with Flux CD (https://github.com/fluxcd/flux)
With GitOps, a developer commits the configuration of a Kubernetes cluster (Kubernetes .yaml files) to the state repository instead of applying it directly to the Kubernetes cluster. This allows for approval processes via Merge / Pull Requests and historizes every state of the Kubernetes cluster to enable seamless auditing. Next, Flux CD is responsible for picking up the changes from the state repository and applying it to the cluster.
One important difference to other operation models is that Flux CD, which runs inside the Kubernetes cluster, actually pulls the changes from the state repository instead of the state repository pushing changes to the cluster. This allows for a higher level of security since we do not need to give administrative privileges to the state repository outside of the cluster. In fact, we could disallow any write operation to the Kubernetes cluster from outside of the cluster. It would even be possible to further maximize security by not exposing the Kubernetes API endpoint at all.
Another benefit of Flux CD is that it allows you to synchronize one state repository with any number of Kubernetes clusters. Thus, the GitOps model allows to manage an IT landscape compromised of many Kubernetes clusters by one or more state repositories. Moreover, as the whole configuration of your application landscape is defined in git, it is easy to redeploy your landscape to a new Kubernetes cluster in case there are issues with the current one.
Take away
All in all, GitOps is a modern CD principle that fulfils the requirements for auditing, approval processes and security. If you want to learn more about GitOps, check out our recorded Websession where we go into more detail with the concept of DevOps, CI / CD, GitOps and Flux CD - including a live demonstration that showcases a typical GitOps workflow.
If you are planning to use GitOps in your organization, we would love to hear about your plans. Just get in touch with us through the comment form below or send me an email directly.
Back to blog overview
