GitOps

GitOps is a concept that manages in­fra­struc­tures and ap­pli­ca­tions via a de­clar­a­tive approach and controls them with Git. The goal is automated pro­cess­ing which saves time and allows for secure col­lab­o­ra­tion of in­di­vid­ual teams across repos­i­to­ries.

When it comes to software de­vel­op­ment, au­toma­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­u­ra­tions of an IT system to make them re­pro­ducible. 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­pli­ca­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­vid­ual mon­i­tor­ing methods for con­tain­ers. These can be applied to Ku­ber­netes and other tech­nolo­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­o­rate on a project in parallel. Changes are adopted only after joint co­or­di­na­tion and older de­vel­op­ment statuses are preserved. De­vel­op­ers can work si­mul­ta­ne­ous­ly on different aspects and merge them at the end. You can find a com­pre­hen­sive Git tutorial in our Digital Guide.

With GitOps, the target state of a system is first described de­clar­a­tive­ly. Changes are made according to the principle of Git via pull requests. When carried out, they change the Git repos­i­to­ry. Now, when a pull request is made in an en­vi­ron­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 repos­i­to­ry. 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­cess­ing, but ensures the stability and re­li­a­bil­i­ty of the system.

Because of the clearly defined and un­change­able prin­ci­ples, GitOps workflows are pretty reliable. This affects the de­clar­a­tive systems that are familiar from other cloud natives. The de­clar­a­tive 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­a­tions from the Git version can be detected and reported im­me­di­ate­ly. In addition, SSH keys ensure that the origin of a code can always be traced. Due to prior de­c­la­ra­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­o­rate closely, the end product tends to improve and changes can be made faster and more ac­cu­rate­ly. GitOps takes this approach and applies it con­sis­tent­ly to the execution part (Op­er­a­tions). GitOps focuses entirely on Git, while DevOps and DevSecOps are more fun­da­men­tal ideas to drive col­lab­o­ra­tion between formerly separate areas relying on CI and CD pipelines. However, both ap­proach­es can be combined.

In contrast to Con­tin­u­ous Delivery and Con­tin­u­ous In­te­gra­tion, GitOps pulls all required in­for­ma­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­spon­si­ble for building and testing. Find out more about Con­tin­u­ous In­te­gra­tion vs. Con­tin­u­ous Delivery vs. Con­tin­u­ous De­ploy­ment in the Digital Guide.

Because of its ver­sa­til­i­ty Ku­ber­netes is perhaps the most important platform to manage container-based ap­pli­ca­tions. Ku­ber­netes works de­clar­a­tive­ly 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­u­ra­tion need to be separated. The actual state can then be stored in a separate Git repos­i­to­ry. Ap­pro­pri­ate syn­chro­niza­tion tools to prevent unau­tho­rized access and possible errors should be used.

There are now plenty of tools for GitOps intended to simplify and improve au­toma­tion. They include tools for working with Ku­ber­netes as operators for the im­ple­men­ta­tion of GitOps. The best-known operator (or custom con­troller) is Flux. Al­ter­na­tives 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 Ku­ber­netes clusters. Overall, the market is com­par­a­tive­ly large, so that there is a suitable tool for almost every ap­pli­ca­tion.

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

• Pro­duc­tiv­i­ty: Au­toma­tion enables changes to be made in less time. De­vel­op­ers are able to work more ef­fec­tive­ly.
• Security and stability: Precise checks mean that errors are detected rapidly and corrected au­to­mat­i­cal­ly. This con­tributes to greater security and stability. Thanks to resilient rollbacks, restoring older states is much easier and the pull approach prevents unwanted com­pli­ca­tions.
• Unity: Workflows are stan­dard­ized through GitOps. This leads to better and easier col­lab­o­ra­tion and allows new employees to get started faster.

• Sep­a­ra­tion of CI and CD: Due to strict sep­a­ra­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­vi­ron­ments, GitOps can become confusing. Numerous repos­i­to­ries and con­fig­u­ra­tions can add to the confusion.