GitOps Application Practice Series-Summary

Hi everyone, this is Zhang Jintao.

Next, I will bring you a GitOps application practice series of articles, this is the first one.

What is GitOps

First, let's understand GitOps:

GitOps was first created and proposed by Weaveworks in 2017. It is a way of Kubernetes cluster management and application delivery. GitOps uses Git as the single source of truth for declarative infrastructure and applications. The core idea of GitOps is to have a Git repository, which contains the declarative description of the infrastructure currently required in the target environment, and an automated process to match the target environment with the state described in the Git repository. With GitOps, you can issue alerts for any differences between the Git repository and the content running in the cluster. If there are differences, Kubernetes reconcilers will automatically update or roll back the cluster based on the situation. With Git as the center of the pipeline, developers can use their familiar tools to issue PR to accelerate and simplify application deployment and operation tasks in Kubernetes.

This caused GitOps to cause quite a stir on Twitter and KubeCon.

Let’s talk about Weaveworks, a company that provides developers with the most efficient way to connect, observe, and control Docker containers. On the official website, we can see the principles and patterns of GitOps workflow, how to implement them to run Kubernetes on a large scale in production, and the differences and best practices between GitOps and Infrastructure as Code (IAC) configuration management tools, etc. Wait. https://www.weave.works/technologies/gitops/

One of the founders of : 1616e3bc9b403c Kelsey Hightower once tweeted to comment that GitOps is a versioned CI/CD based on declarative infrastructure, stopped scripting operations, and started (automated) distribution.

How does GitOps work?

Configure the environment as a Git repository

GitOps organizes deployment with a code base as the core. We need to have at least two warehouses: application library and environment configuration library. The application library contains the source code of the application and the manifests for deploying the application. The environment configuration library contains all the deployment manifests of the infrastructure currently required by the deployment environment. It describes which applications and infrastructure services (message brokers, service grids, monitoring tools, etc.) should run in what configuration and version in the deployment environment.

Push-based and pull-based deployment

The difference between the two deployment types is how to ensure that the deployment environment is the same as the required infrastructure. It is recommended here that prefers the pull-based method to implement GitOps more securely, and there are many existing best practices to learn from.

Pull-based deployment

The traditional CI/CD pipeline is triggered by external events, such as when new code is pushed to the application library.

The deployment method based on Pull introduces operator. It takes over the role of the pipeline by constantly comparing the expected state in the environment configuration library with the actual state in the deployment environment. When a difference is found, the operator updates the state in the deployment environment to match the environment configuration library. In addition, it can also monitor the image registry to find new image versions to be deployed.

The deployment based on the pull model can not only update the environment when the environment configuration library changes;

The operator can also restore when there is a difference between the actual environment and the environment configuration library.

This ensures that all changes can be tracked in the Git log, because no one is allowed to make direct changes to the cluster.

Then, the monitoring points in this way are concentrated on the operator and each component (for example, whether the mirror warehouse can pull the mirror normally, etc.).

In order to avoid the God-mode permission problem based on the Push scenario, the operator should always be in the same environment or cluster as the application to be deployed. (K8s RBAC authorization: Kubernetes has supported Role-Based Access (RBAC) since 1.6. Cluster administrators can perform more precise resource access control on the roles of users or service accounts. In RBAC, permissions and Roles are associated, and users get the permissions of these roles by becoming members of the appropriate roles.)

Push-based deployment

Push-based deployment strategies can be implemented using popular CI/CD tools, such as Jenkins, CircleCI, or Travis CI. The source code of the application exists in the application library along with the Kubernetes YAML required by the deployed application. Whenever the application code is updated, it will trigger the build pipeline, build the container image, and finally use the new deployment manifest to update the environment configuration library.

You can also store YAML templates in the application library. When building a new version, you can use a template to generate YAML in the environment configuration library.

Changes to the environment configuration library will trigger the deployment pipeline. The pipeline is responsible for applying all the manifests in the environment configuration library to the infrastructure. This requires us to pay more attention to the subdivision and control of deployment permissions. At the same time, this method cannot automatically notice any deviations in the environment and its desired state. We need additional monitoring and alarm methods to ensure that the environment is consistent with the content described in the environment repository.

Complex application environment

For most applications, it is unrealistic to use only one application library and one environment configuration library. GitOps can also handle it. You can set up multiple build pipelines to update the environment configuration library. Then just like the previous two described processes, the automated GitOps workflow starts and deploys the application.

We need to use independent branches in the environment configuration library to manage multiple environments. Choose to set up an operator or build a pipeline to automate the start of the GitOps workflow and deploy the application.

Tips：

1. The environment that does not use k8s can also consider using GitOps. (Currently, most pull-based GitOps are implemented under Kubernetes.)

2. Password. Never store passwords in plain text in git! In the K8s ecosystem, there are tools to support this encryption. (Such as Vault)

3. The dev, qa, and prod environments cannot be directly processed by GitOps. You can consider introducing CI/CD pipeline to manage the environment.

4. DevOps and GitOps do not conflict. DevOps is about cultural change in an organization that allows programmers and system maintainers to collaborate better. And GitOps is a technology to achieve continuous delivery. If you are already advancing DevOps, you may be better connected to GitOps.

---

Welcome to subscribe to my article public account【MoeLove】