Despite platforms, such as Kubernetes, which deal with container orchestration, it isn’t always easy to provide and manage container-based applications that are executed in cluster systems or the cloud. GitOps is a method that is designed to use experiences and tools derived from development work to operate applications. There are four basic principles behind the method:

• Declarative description: resources are described in formal language in their target status.
• Automation: the integrating of descriptions from the repository into the runtime environment must be fully automated, repeatable and must give the same result, even if they are executed several times.
• ‘Single source of truth’: system status must be described clearly and comprehensively. There is a single source that summarizes the overall status of the system.
• Reconciliation: software agents compare the current status of the system with the target status. As soon as any deviations emerge, the relevant actions are triggered.

GitOps as an operating model for Kubernetes

To guarantee operation of a software system, a supply chain is required that can be used to supply versions of the software, but also to modify configurations. A connection is therefore established between continuous delivery (CD) and the actual deployment and operation of the application. Kubernetes uses a method whereby it gives declarative descriptions of resources. This involves describing the status of the running application (e. g. three instances of application X in version Y with 2 CPUs and 500 MB of RAM each), and Kubernetes ensures the relevant components are launched. This means both the first basic principles of GitOps are in fact already covered by Kubernetes itself.

As the name suggests, Git version management is used as the ‘single source of truth’ in GitOps. This ensures the required system status is automatically stored in a dedicated location in a transparent, traceable manner in a range of versions. Traceability allows you to track changes, but also makes any rollback to an old version trivial. A significant advantage of Git is also the fact that the branching concept can be used to review changes via pull requests. This allows you to detect errors in configuration before they reach the system itself.

The fourth (and most important) basic principle of GitOps is comparing the runtime status within the Kubernetes cluster with the target status in the Git repository. What is known as a GitOps operator is used to do this, which is a specialized software component installed in Kubernetes that performs this task automatically. PostFinance uses the “Argo CD” tool for this purpose.

Benefits of GitOps

• Increased productivity: consistent automation allows the developer/operator to focus on essential configuration. Automatic rollout optimizes turnaround times.
• Shared tooling: developers and operators both use Git, a tried-and-tested tool.
• Stability and reliability: all changes are traceable. Rollbacks are trivial and, thanks a declarative description, a full recovery can be achieved within a short space of time in a disaster scenario.
• Consistency and standardization: GitOps is an operating model and standardizes the deployment process

Why we are using GitOps in IT for the digital commerce sector

At PostFinance, we implemented the first major GitOps case in IT for the digital commerce domain. We did this because we have migrated to the (on-premise) Kubernetes platform and were looking for a solution that would allow us to operate our high-availability systems as effectively as possible. We opted for the relatively recent GitOps because GitOps is becoming the standard method for deploying applications in this type of cluster. In digital commerce, we have been fully reliant on this stack since last autumn.

Since March 2020, we have been operating our Kubernetes workloads via GitOps. Our experiences from this period have been consistently positive. For one thing, we appreciate how simple it is to deploy new workloads (features, services etc.) in the systems. This process makes executing changes on an ongoing basis with a short turnaround time significantly easier. We are also still able to bank on reliable systems, even with this raft of changes. The search for configuration differences between different environments is limited to configuration in the Git repository. Operator reconciliation helps us maintain round-the-clock control of our systems whereby we can detect any undesired statuses, which we can then resolve in a standardized manner.

Finally, we are subject to stringent regulations as far as traceability and the “segregation of duties” is concerned in the digital commerce sector. GitOps has enabled us to reconcile all these regulations with the DevOps mentality. Nowadays, productive changes are merely simple pull requests to us that end up in production in a direct, automated manner following review and merging.