如何进行GitOps的原理分析

61次阅读
没有评论

共计 5846 个字符,预计需要花费 15 分钟才能阅读完成。

这篇文章将为大家详细讲解有关如何进行 GitOps 的原理分析,文章内容质量较高,因此丸趣 TV 小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。

也许你之前听说过 GitOps,但是对其并不了解。在本文中,我将对其进行简单介绍,它其实是一个应用程序开发和管理中的一个术语,其核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 的版本控制库中。我们将介绍 GitOps 是什么,它将如何影响组织以及如何与 Kubernetes 保持同步。

什么是 GitOps

GitOps 是一种实现持续交付的模型,利用 Git 开发工具对云原生应用程序进行操作和管理。当将应用程序部署到 Kubernetes 时,Git 应该是唯一的事实来源。当开发人员更改应用程序时,Git 将自动把它们 push 到 Kubernetes 进行部署。而且,如果 Kubernetes 内的运行状态发生变化但与 Git 内的状态不一致,则它们会从 Git 内恢复到已知状态。

GitOps 与 CI/CD:它们之间有什么联系?

GitOps 和 CI/CD 是十分重要的工作伙伴。CI/CD 可以让开发人员持续迭代、开发和部署应用程序。而迭代通常通过一个 Git 配置仓库进行(尽管也会有其他配置仓库)。在部署 / 交付阶段,构建的基于容器的应用程序被“push”到 Kubernetes 进行部署。GitOps 会通过 Kubernetes 使用“pull”的方法来增强 CI/CD 模型,从而将运维层面带入部署 / 交付中。

但是,如果有人更改了 Kubernetes 集群中运行的某些内容,会发生什么?我们将使用 Git 作为声明性部署工具的主要事实来源,并利用其他工具在出现差异时向我们发出警报。此外,通过利用可以识别运行状态和声明状态之间差异的工具,Kubernetes 可以修复为已知 / 声明的运行状态。

注意:持续集成和持续开发是互补但独立的过程。在理想状态下,GitOps 会将批处理规模拆分为单件流程,每次只处理一个单元。但是,由于 CI 和 CD 流程发生在不同的组中,因此组织之间的流程可能会有所不同。

GitOps 和应用程序生命周期

让我们从应用程序生命周期的视角来看一下 GitOps 的作用。在典型的生命周期中,应用程序会经历多个状态,包括:

代码

构建

创建镜像

测试

发布

而使用 GitOps,这些状态将会扩展为:

部署

在 Git 仓库中监控更改

日志更改和事件

发生更改时发出警报,并于现有的监控 / 告警系统集成

更新

在 GitOps 操作模型下,当应用程序发布时,Kubernetes 需要确保其按预期运行。同时,Kubernetes 通过确保其稳定性和可用性来管理应用程序的运维工作。如果一个开发人员通过 Git 更改了该应用程序,Kubernetes 将会接受声明并根据需要应用它。

GitOps 带来了什么?

GitOps 为应用程序提供一个操作模型,它可以确保 Git 提供一个框架来统一应用程序的运行、操作和持续开发。

作为 CI/CD 流水线的一部分,GitOps 为应用程序构建 / 交付与运行它的位置之间提供了粘合剂。

在 Kubernetes 平台中,Git 为应用程序的开发和运维提供了唯一的事实来源。

应用程序交付和平台管理都是声明式的,同时还能通过 Git 进行版本控制

Git 可以控制回滚、升级以及更改

开发人员不需要知道如何操作运维平台(如 Kubernetes),无需了解复杂的部署交付流程,仅需使用熟悉的工具发布新功能即可。极大提升开发者体验。

Git 控制并修证差异或“漂移”

GitOps 利用审核、监控以及回滚功能来增加应用程序发布的可靠性和稳定性

最后,尽管在 GitOps 模式下还有很多工作要做,但是 GitOps、DevOps 以及现有 CI/CD 模式之间存在十分明显的协同作用。GitOps 提供了一种用于将应用程序交付到 Kubernetes 平台的模型,该模型确保了 Git 是唯一的事实来源并且充分利用 Kubernetes 平台上的功能。但值得注意的是,GitOps 不能替代工具。恰恰相反,GitOps 通过声明性的流程和工具来强化流程、提高其成熟度并帮助团队交付应用程序。

GitOps 实践:FluxCD Demo

FluxCD(或 Flux)是一个很棒的工具,它可以将 Git 和 Kubernetes 集成起来。Flux 本质上是一个 Kubernetes Operator,这意味着,你作为一个管理员可以将其安装到 Kubernetes 以管理 Git 和原生 Kubernetes 之间的集成。

在 Kubernetes 中,Operator 是 Kubernetes 原生平台的扩展,是一种自定义资源的模式,该自定义资源主要用于管理应用程序及其组件。这意味着,在 Kubernetes 内部 Operator 的帮助下,所需状态(如运行状态)将不断检查和调整以符合 Git 仓库声明的内容。Flux 可以集成到你现有的 CI/CD 工具集中,以进行其他工作流程、权限批准和审核。在 Kubernetes 中,Flux 会监控你通过配置声明的 Git 仓库是否发生更改,并且如果 Kubernetes Pod 上在本地发生了不应发生的更改,Flux 将会把 Kubernetes 更新到所需的运行状态。请记住,Git 是事实来源。Flux Operator 会检测到这一点,并将正在运行的配置更改回声明的状态。

以下 demo,我将会展示如何安装和实现 Flux。

前期准备

你将需要:

一个 Docker Hub 镜像仓库,你可以将 Flaskapp docker 镜像上传到此处

一个 Git Repo 并连接它,然后你可以在整个演示过程中根据需要用你的设置替换“”中的任何内容

具体步骤

安装 Kubernetes

安装并配置 fluxctl,Flux 部署的原生安装程序

配置 Flux 以连接到 Git Repo

在 Git Repo 中升级 deployment manifest

升级容器镜像并同步

配置漂移(drift)并同步

你可以使用以下配置进行测试或演示。它包括 Flask 应用程序的 Docker file 以及 Kubernetes deployment/ 配置文件。在演示中,你会需要它们,此外你还可以将它们上传到你指定的 Git 仓库中。

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 脚本文件

import os
from flask import Flask
app = 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 文件

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/ your docker repo /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: v1
kind: ConfigMap 
metadata: 
 name: nginx-conf
 namespace: my-demo
data:
 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 
 }
 }

安装 Flux

安装 Fluxctl

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

安装 Fluxcd

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

为 Repo 配置 Flux

创建一个命名空间

kubectl create ns  namespace 
export FLUX_FORWARD_NAMESPACE=  namespace 
fluxctl list-workloads

安装 Fluxcd 以建立与你的 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 -

创建 SSH 密钥以添加到 Github 仓库

在你的 terminal 中输入以下命令,以获取下一步所需的密钥:

fluxctl identity

打开 Github,导航到安装 Fluxcd 时添加的仓库,转到设置 - 部署密钥,单击【添加部署密钥】,为其指定 title,选中【允许 write access】,粘贴公共密钥,然后单击【添加密钥】。

在 Git Repo 中升级 Deployment Manifest

打开你的 Git Repo,里面应该有 deployment.yaml 文件,向下滑动直到如下所示部分,然后更改 APP_VERSION 号码

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

保存并 Commit 更改到你的 Repo。

Flux 将在 5 分钟之内升级你的 deployment

要从 localhost 进行测试,请在 Kubernetes 中使用“Port-forward”命令:

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

打开其他 terminal:

curl -s -i http://localhost:8080

升级容器镜像并同步

现在让我们对 Docker 镜像进行修改并将其上传到我们的 Docker Hub 镜像仓库中。为此,我们将修改 flaskapp 目录中的 main.py 文件。

升级 main.py 文件。将 Hello World 更改为其他内容

response =  %s - %s.%s\n  %(Flux World , appname, appversion)

创建一个新的 Docker 文件并上传到 Docker(以及另一个增量版本号)。

等待 5 分钟,Flux 将会自动部署新镜像

配置漂移并同步

现在,我们来测试一下手动更改正在运行的配置会发生什么。

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

现在,我们花几分钟来看看 pod 并观察发生了什么。我们将会在短时间内(5 分钟以内)看到其他的 pod,此外我们还将看到许多 pod 终止。因此,Flux 已使配置恢复到当前在 Git 中保留的已声明的部署状态。

kubectl get po -n --watch

重新运行相同的命令,并且你会看到目前仅有一个正在运行的 pod。

别忘了清理和移除 deployment 和 Git 连接(如果你想移除它)。否则,你需要开始添加更多的仓库并继续进行构建。

关于如何进行 GitOps 的原理分析就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-16发表,共计5846字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)