Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what is GitOps". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

What is GitOps?

GitOps is a continuous delivery model that uses Git development tools to operate and manage cloud native applications. When deploying an application to Kubernetes, Git should be the only source of fact. When developers change applications, Git automatically push them to Kubernetes for deployment. Moreover, if the running state within the Kubernetes changes but is inconsistent with the state within the Git, they will revert to the known state from within the Git.

GitOps and CI/CD: what is the connection between them?

GitOps and CI/CD are very important partners. CI/CD allows developers to iterate, develop, and deploy applications continuously. Iterations are usually done through a Git configuration repository (although there will be other configuration repositories as well). During the deployment / delivery phase, the built container-based application is "push" to Kubernetes for deployment. GitOps enhances the CI/CD model through Kubernetes's use of "pull" to bring the operation and maintenance level into deployment / delivery.

But what happens if someone changes something running in the Kubernetes cluster? We will use Git as the primary source of facts for declarative deployment tools and other tools to alert us when differences occur. In addition, Kubernetes can be fixed to a known / declared running state by using tools that can identify the difference between the running state and the declared state.

Note: continuous integration and continuous development are complementary but independent processes. Ideally, GitOps would split the batch size into a single process, processing only one unit at a time. However, because the CI and CD processes occur in different groups, the processes may be different between organizations.

GitOps and application lifecycle

Let's look at the role of GitOps from the perspective of the application life cycle. In a typical lifecycle, an application goes through several states, including:

Code

Construction

Create a mirror

test

Publish

With GitOps, these states will be expanded to:

Deployment

Monitor changes in the Git repository

Log changes and events

Alert when changes occur and integrate with existing monitoring / alarm systems

Update

Under the GitOps operating model, when an application is released, Kubernetes needs to ensure that it works as expected. At the same time, Kubernetes manages the operation and maintenance of the application by ensuring its stability and availability. If a developer changes the application through Git, Kubernetes will accept the declaration and apply it as needed.

What did GitOps bring?

GitOps provides an operational model for applications, which ensures that Git provides a framework to unify the operation, operation, and continuous development of applications.

As part of the CI/CD pipeline, GitOps provides glue between where the application is built / delivered and where it is run.

In the Kubernetes platform, Git provides the only factual source for application development and operation and maintenance.

Application delivery and platform management are declarative, while versioning can be done through Git

Git can control rollbacks, upgrades, and changes

Developers do not need to know how to operate an operation and maintenance platform (such as Kubernetes), nor do they need to understand the complex deployment delivery process, they just need to release new features using familiar tools. Greatly improve the developer experience.

Git controls and repairs differences or "drift"

GitOps uses audit, monitoring, and rollback capabilities to increase the reliability and stability of application releases

Finally, although there is still a lot of work to be done in the GitOps mode, there is a significant synergy between GitOps, DevOps and the existing CI/CD mode. GitOps provides a model for delivering applications to the Kubernetes platform, which ensures that Git is the only source of fact and takes full advantage of the capabilities on the Kubernetes platform. It is worth noting, however, that GitOps is not a substitute for tools. On the contrary, GitOps uses declarative processes and tools to strengthen processes, improve their maturity, and help teams deliver applications.

GitOps practice: FluxCD Demo

FluxCD (or Flux) is a great tool that integrates Git and Kubernetes. Flux is essentially a Kubernetes Operator, which means that you, as an administrator, can install it into Kubernetes to manage the integration between Git and native Kubernetes.

In Kubernetes, Operator is an extension of the Kubernetes native platform and is a pattern for customizing resources that are mainly used to manage applications and their components. This means that with the help of Kubernetes's internal Operator, the required state (such as running status) will be constantly checked and adjusted to match the content of the Git repository declaration. Flux can be integrated into your existing CI/CD toolset for other workflows, permission approvals, and audits. In Kubernetes, Flux will monitor whether the Git repository you declare through configuration has changed, and if there are local changes on Kubernetes Pod that should not have occurred, Flux will update Kubernetes to the desired running state. Keep in mind that Git is the source of facts. Flux Operator detects this and changes the running configuration back to the declared state.

The following demo, I will show you how to install and implement Flux.

Preparation in advance

A Docker Hub image repository where you can upload Flaskapp docker images.

A Git Repo and connect it, and then you can replace it with your settings as needed throughout the presentation. "

"anything in"

Concrete steps

Install Kubernetes

Install and configure the native installer for fluxctl,Flux deployment

Configure Flux to connect to Git Repo

Upgrade deployment manifest in Git Repo

Upgrade container image and synchronize

Configure drift (drift) and synchronize

You can use the following configuration for testing or demonstration. It includes the Docker file of the Flask application and the Kubernetes deployment/ configuration file. You will need them in the demo, and you can also upload them to your designated Git repository.

Docker File

FROM python:3 RUN pip install flask RUN mkdir-p / corp/app WORKDIR / corp/app COPY main.py. ENV FLASK_APP=/corp/app/main.py ENV APP_NAME=MyApp.DevOps ENV APP_VERSION=v1.0.0 CMD ["flask", "run", "--host=127.0.0.1"]

Main.py Python script file

Import osfrom flask import Flaskapp = Flask (_ _ name__) @ app.route ('/') def index (): appname = os.environ ['APP_NAME'] appversion = os.environ [' APP_VERSION'] response = "% s -% s% s\ n"% ('Hello World', appname, appversion) return response

Kubernetes Deployment file

ApiVersion: v1 kind: Namespace metadata: name: my-demo-apiVersion: apps/v1 kind: Deployment metadata: name: fluxdemo namespace: my-demo annotations: flux.weave.works/tag.flask: glob:develop-v* flux.weave.works/automated: 'true' labels: role: fluxdemo env: demo app: flux spec: replicas: 1 selector: matchLabels: role: fluxdemo template: metadata: labels : role: fluxdemo spec: containers:-name: nginx image: nginx:1.16-perl imagePullPolicy: IfNotPresent ports:-name: http containerPort: 80 volumeMounts:-name: nginx-proxy-config mountPath: / etc/nginx/conf.d/default.conf subPath: nginx.conf -name: flask image: docker.io//flaskapp:develop-v1.8.0 imagePullPolicy: IfNotPresent ports:-name: http containerPort: 5000 env:-name: APP_NAME value: myfluxdemo.K8s.GitOps-name: APP_VERSION value: v1.0.5 volumes:-name: nginx-proxy -config configMap: name: nginx-conf-apiVersion: v1kind: ConfigMap metadata: name: nginx-conf namespace: my-demodata: nginx.conf: |-# CODE1.0: # add the nginx.conf configuration-this will be referenced within the deployment.yaml server {listen 80 Server_name localhost; location / {proxy_pass http://localhost:5000/; proxy_set_header Host "localhost";}}

Install Flux

Https://docs.fluxcd.io/en/1.18.0/references/fluxctl.html

Install Fluxcd

Https://docs.fluxcd.io/en/1.18.0/tutorials/get-started.html

Configure Flux for Repo

Create a namespace

Kubectl create nsexport FLUX_FORWARD_NAMESPACE=fluxctl list-workloads

Install Fluxcd to establish a connection to your Git Repo

Export GHUSER= "" export REPO= "gitops-demo" export NS= "flux" fluxctl install\-git-user=$ {GHUSER}\-git-email=$ {GHUSER} @ users.noreply.github.com\-git-url=git@github.com:Image download failed. {REPO}\-namespace=$ {NS} | kubectl apply-f-

Create a SSH key to add to the Github repository

Enter the following command in your terminal to get the key you need for the next step:

Fluxctl identity

Open Github, navigate to the repository added when installing Fluxcd, go to Settings-deployment key, click * * add deployment key * *, specify title for it, select * * allow write access * *, paste the public key, and then click * * add key * *.

Upgrade Deployment Manifest in Git Repo

Open your Git Repo, which should contain the deployment.yaml file, slide down to the section shown below, and then change the APP_VERSION number

Env:-name: APP_NAME value: myfluxdemo.K8s.GitOps-name: APP_VERSION value: v1.0.5

Save and Commit changes to your Repo.

Flux will upgrade your deployment in 5 minutes.

To test from localhost, use the "Port-forward" command in Kubernetes:

Kubectl get pods-n copy the pod name kubectl port-forward 8080 80-n

Open another terminal:

Curl-s-I http://localhost:8080

Upgrade container image and synchronize

Now let's modify the Docker image and upload it to our Docker Hub image repository. To do this, we will modify the main.py file in the flaskapp directory.

Upgrade the main.py file. Change Hello World to something else

Response = "% s -% s.% s\ n"% ('Flux World', appname, appversion)

Create a new Docker file and upload it to Docker (and another incremental version number).

Wait 5 minutes and Flux will automatically deploy the new image.

Configure drift and synchronize

Now, let's test what happens if you manually change the running configuration.

Kubectl scale deployment/fluxdemo-- replicas=4-n

Now, let's take a few minutes to look at pod and see what happens. We will see other pod in a short time (within 5 minutes), and we will also see many pod terminations. As a result, Flux has restored the configuration to the declared deployment state currently retained in Git.

Kubectl get po-n-- watch

Rerun the same command, and you will see that there is only one pod currently running.

Don't forget to clean up and remove deployment and Git connections (if you want to remove it). Otherwise, you need to start adding more repositories and continue to build.

This is the end of "what is GitOps". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.