Hello everyone, I’m Zhang Jintao.

This is the first in a series of GitOps practices.

What is a GitOps

First, let’s take a look at GitOps:

GitOps was first proposed by Weaveworks in 2017 as a way to manage the Kubernetes cluster and deliver applications. GitOps uses Git as a single source of fact for declarative infrastructure and applications. The core idea of GitOps is to have a Git Repository that contains a declarative description of the infrastructure currently required in the target environment and an automated process to match the target environment to the state described in Git Repository. With GitOps, any discrepancies between Git Repository and what is running in the cluster can be alerted, and if there are discrepancies, the Kubernetes Reconcilers automatically update or roll back the cluster as appropriate. With Git at the center of a pipeline, developers can issue PR using tools they are familiar with to speed up and simplify application deployment and operational tasks in Kubernetes.

This has made GitOps quite the sensation on Twitter and KubeCon.

Weaveworks is a company that provides developers with the most efficient way to connect, observe, and control Docker containers. On the website, you can see the principles and patterns of GitOps workflows, how they can be used to run Kubernetes at scale in production, the differences and best practices between GitOps and infrastructure-as-code (IAC) configuration management tools, and more. www.weave.works/technologie…

Kelsey Hightower, one of the founders of K8S, tweeted that GitOps is versioned CI/CD based on a declarative infrastructure that stops scripting and starts (automated) distribution.

How does GitOps work?

Configure your environment as a Git repository

GitOps organizes deployment around the core of the code base. We need to have at least two repositories: the application library and the environment configuration library. The application library contains the source code for the application and the manifests of the deployment application. The environment configuration repository contains all deployment manifests of the infrastructure currently required by the deployment environment. It describes, among other things, which application and infrastructure services (message brokers, service grids, monitoring tools, and so on) should run in what configuration and version in the deployment environment.

Push-based versus pull-based deployments

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 that a pull based approach be preferred, as implementing GitOps is safer and there are many existing best practices to learn from.

Pull-based deployment

Traditional CI/CD pipelines are triggered by external events, such as when new code is pushed to an application library.

The pull-based deployment method introduces operator. It takes over the role of pipeline by constantly comparing the expected state in the environment configuration library to the actual state in the deployment environment. When a difference is detected, operator updates the state in the deployment environment to match the environment repository. In addition, it can monitor the Image Registry to find new versions of images to deploy.

Deployment based on the Pull model can not only update the environment when the environment configuration library changes;

Operator can also restore the actual environment if there is a difference between the environment configuration library and the actual environment.

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

This way, the monitoring point is on the operator and the components (for example, whether the mirror warehouse can pull the image properly, and so on).

To avoid god mode permission issues in Push based scenarios, operators should always be in the same environment or cluster as the application to be deployed. (K8S RBAC authorization: Kubernetes supports role-based Access (RBAC) mechanism since 1.6. Cluster administrators can control resource Access more accurately for users or service account roles. In RBAC, permissions are associated with roles, and users gain permissions for those roles by becoming a member 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 for the application resides in the application library along with Kubernetes YAML required by the deployed application. Each time the application code is updated, the build pipeline is triggered, the container image is built, and finally the environment configuration library is updated with the new deployment Manifest.

YAML templates can also be stored in application libraries. When you build a new version, you can use templates to generate YAML in the environment configuration library.

Changes to the environment configuration library trigger the deployment pipeline. Pipeline is responsible for applying all manifests in the environment configuration library to the infrastructure. This requires us to pay more attention to the segmentation and control of deployment permissions. Also, this approach does not automatically notice any deviations from the environment and its desired state. We need additional monitoring alerts to ensure that the environment is consistent with what is described in the environment repository.

Complex application environment

Using only one application library and one environment configuration library is not practical for most applications. GitOps can handle it, too. Multiple build Pipelines can be set up to update the environment configuration libraries. Then, just as in the previous two described processes, the automated GitOps workflow starts and deploys the application.

We need to use separate branches in the environment repository to manage multiple environments. Choose to set up the operator or build the pipeline to automate the GitOps workflow to start and deploy the application.

Tips:

1. Environments that do not use K8S can also consider using GitOps. (Most pull-based GitOps are currently implemented under Kubernetes.)

2. Password. Never store passwords as plain text in Git! Within the K8s ecosystem, there are tools to support this encryption. (such as a Vault)

3. Dev, QA and PROD environments cannot be directly handled by GitOps, so CI/CD pipeline can be introduced to manage the environment.

4.DevOps and GitOps don’t conflict. DevOps is about cultural change in an organization that allows programmers and system maintainers to work together better. GitOps is a technology for continuous delivery. If you’re already pushing DevOps, it’s probably better to tap into GitOps.

Please feel free to subscribe to my official account [MoeLove]