GitOps

GitOps is a concept that manages in­fra­struc­tures and ap­plic­a­tions via a de­clar­at­ive approach and controls them with Git. The goal is automated pro­cessing which saves time and allows for secure col­lab­or­a­tion of in­di­vidu­al teams across re­pos­it­or­ies.

When it comes to software de­vel­op­ment, auto­ma­tion is important. That’s one of the reasons why DevOps has become so popular. The un­der­ly­ing idea is ‘In­fra­struc­ture as Code (IaC)’ which is intended to map the in­fra­struc­tures and con­fig­ur­a­tions of an IT system to make them re­pro­du­cible. GitOps is a logical extension of this approach. Since 2017, the open source software Git has con­trolled the entire man­age­ment process of an ap­plic­a­tion from ad­min­is­tra­tion to ultimate software de­vel­op­ment as a ‘single source of truth’. For this purpose, GitOps defines a target state and, where necessary, adjusts the in­fra­struc­ture until this state is reached.

Weave­works provides a set of best practices for unifying in­di­vidu­al mon­it­or­ing methods for con­tain­ers. These can be applied to Kuber­netes and other tech­no­lo­gies with a cloud back­ground, making them easier to manage. Git is based on a version control system developed by Linus Torvald in 2005. This allows different de­vel­op­ment teams to col­lab­or­ate on a project in parallel. Changes are adopted only after joint co­ordin­a­tion and older de­vel­op­ment statuses are preserved. De­velopers can work sim­ul­tan­eously on different aspects and merge them at the end. You can find a com­pre­hens­ive Git tutorial in our Digital Guide.

With GitOps, the target state of a system is first described de­clar­at­ively. Changes are made according to the principle of Git via pull requests. When carried out, they change the Git re­pos­it­ory. Now, when a pull request is made in an en­vir­on­ment with GitOps, the operator activates, captures the Commit, and queries the current state via Git. This is then compared with the desired state in the re­pos­it­ory. Once the changes are signed off, they are merged with the previous state and applied directly to the live in­fra­struc­ture. This leads to faster and smoother pro­cessing, but ensures the stability and re­li­ab­il­ity of the system.

Because of the clearly defined and un­change­able prin­ciples, GitOps workflows are pretty reliable. This affects the de­clar­at­ive systems that are familiar from other cloud natives. The de­clar­at­ive de­scrip­tion ensures that the entire system can be treated as code and versioned, serving the security and stability of the entire system, as de­vi­ations from the Git version can be detected and reported im­me­di­ately. In addition, SSH keys ensure that the origin of a code can always be traced. Due to prior de­clar­a­tion, changes can be automated and possible sources of errors can be detected and corrected early on.

The primary approach of DevOps is and has been the merging of de­vel­op­ment and execution to simplify workflows. Because teams col­lab­or­ate closely, the end product tends to improve and changes can be made faster and more ac­cur­ately. GitOps takes this approach and applies it con­sist­ently to the execution part (Op­er­a­tions). GitOps focuses entirely on Git, while DevOps and DevSecOps are more fun­da­ment­al ideas to drive col­lab­or­a­tion between formerly separate areas relying on CI and CD pipelines. However, both ap­proaches can be combined.

In contrast to Con­tinu­ous Delivery and Con­tinu­ous In­teg­ra­tion, GitOps pulls all required in­form­a­tion directly from Git according to the pull principle and does so without de­ploy­ment via a CI server. This can be used with GitOps, but is now only re­spons­ible for building and testing. Find out more about Con­tinu­ous In­teg­ra­tion vs. Con­tinu­ous Delivery vs. Con­tinu­ous De­ploy­ment in the Digital Guide.

Because of its ver­sat­il­ity Kuber­netes is perhaps the most important platform to manage container-based ap­plic­a­tions. Kuber­netes works de­clar­at­ively and considers the target state of a system which makes it a good option for working with GitOps and for acting as an operator. However, for security reasons and to retain a better overview the source code and con­fig­ur­a­tion need to be separated. The actual state can then be stored in a separate Git re­pos­it­ory. Ap­pro­pri­ate syn­chron­isa­tion tools to prevent un­au­thor­ised access and possible errors should be used.

There are now plenty of tools for GitOps intended to simplify and improve auto­ma­tion. They include tools for working with Kuber­netes as operators for the im­ple­ment­a­tion of GitOps. The best-known operator (or custom con­trol­ler) is Flux. Al­tern­at­ives are ArgoCD or Fleet. Key tools for increased security include SOPS from Mozilla and Sealed Secrets from Bitnami. Cluster API or Fleet are great for use with Kuber­netes clusters. Overall, the market is com­par­at­ively large, so that there is a suitable tool for almost every ap­plic­a­tion.

To find out if GitOps is suitable for your purpose, check out these pros and cons.

• Pro­ductiv­ity: Auto­ma­tion enables changes to be made in less time. De­velopers are able to work more ef­fect­ively.
• Security and stability: Precise checks mean that errors are detected rapidly and corrected auto­mat­ic­ally. This con­trib­utes to greater security and stability. Thanks to resilient rollbacks, restoring older states is much easier and the pull approach prevents unwanted com­plic­a­tions.
• Unity: Workflows are stand­ard­ised through GitOps. This leads to better and easier col­lab­or­a­tion and allows new employees to get started faster.

• Sep­ar­a­tion of CI and CD: Due to strict sep­ar­a­tion of CI and CD in the GitOps approach, it can be difficult to perform post-de­ploy­ment testing.
• Overview: When working with multiple en­vir­on­ments, GitOps can become confusing. Numerous re­pos­it­or­ies and con­fig­ur­a­tions can add to the confusion.