如何优雅的使用 GitOps 完成运维自动化
发布时间：2021-11-22 11:27:07 所属栏目：系统 来源：互联网
导读：1. GitOps 到底是个什么呢 GitOps = 基础设施即代码(IaC) + 合并请求(MR) + 持续集成/持续交付(CI/CD) GitOps 是一种运维框架，它采用了 DevOps 在应用程序开发阶段的最佳实践(例如版本控制、协作、合规性和CI/CD工具)，并将其应用于基础设施自动化。 与 GitO
|
1. GitOps 到底是个什么呢 GitOps = 基础设施即代码(IaC) + 合并请求(MR) + 持续集成/持续交付(CI/CD) GitOps 是一种运维框架，它采用了 DevOps 在应用程序开发阶段的最佳实践(例如版本控制、协作、合规性和CI/CD工具)，并将其应用于基础设施自动化。 与 GitOps 相比，传统的 DevOps 尽管在软件开发生命周期已实现自动化，但基础架构大体上仍然是一个需要专业团队进行手动操作的过程。随着对基础架构需求的不断增长，实现基础设施自动化变得越来越重要。现代化的基础设施需要弹性机制(速度和规模)，以便能有效地管理持续部署所需的云资源。 GitOps体系学习和理解 GitOps 用于对基础设施置备的过程进行自动化，采用以 配置文件 存储为代码(基础设施即代码)，配置文件在每次部署时都会生成相同的基础设施环境，来保证环境的一致性，完成整个运维流程的自动化。 三叉戟 - 基础设施即代码(IaC) - Terraform GitOps 使用 Git 仓库作为基础设施定义的单一可信来源，将所有基础设施以配置文件的方式存储起来，达到配置和管理应用服务的问题。 三叉戟 - 合并请求(MR) GitOps 使用合并请求作为所有基础设施更新的变更机制，合并请求是团队通过评审和评论进行协作的地方，合并会被提交到您的主干分支并可作为审计日志。 三叉戟 - 持续集成/持续交付(CI/CD) GitOps 使用具有持续集成和持续交付的 Git 工作流来自动化执行基础架构的更新，在新代码合并后，CI/CD 流水线将执行环境中的更改，从而避免手动配置的错误等问题。 对于任何需要协作的工作，改变都是很棘手的，GitOps 也不例外。GitOps 需要所有参与者遵守纪律，它是一种采用全新的方式来工作的承诺。对于团队来说，把所有的事情都记录下来至关重要。 2. GitOps 的核心在于协助 可以覆盖应用程序从构思到代码再到部署全流程的协作 从核心上来说，GitOps 指的是将 Git 存储库作为构建基础设施和部署应用程序所有代码的唯一可信数据源，然后将代码自动化部署到不同的云环境上面(可以借助Terraform完成资源编排)。 每个人都能够在同一个系统中工作，并了解事情的进展情况。无论你是在基础架构中还是在应用程序开发中，所有的更改都遵循同样的流程，即定义工作主体，将其分配给个人，团队协作，然后部署这些代码，并将 Git 存储库作为唯一可信数据源使用。 GitOps 与代码和协作都有紧密联系 使用版本控制系统可以确保一切都被记录且可见，审计跟踪使团队保持合规性。 针对于不同的项目和团队，新建 issue 来描述添加的目标和任务(多云平台)。 在 issue 中，记录列出的任务列表的执行程度和进展(通过ME合并请求)。 GitOps体系学习和理解 3. GitOps 的使用优秀实践 良好的运维体系拥有一个无缝链接且完美的体验，能够增进基础设施、运营和开发团队之间的协作，在提高软件环境的稳定性、可靠性和安全性的同时，实现更快速部署，这能够增强团队的信心。比如： GitOps体系学习和理解 [1] 版本控制 核心 - 配置文件 - 声明式系统 Git 仓库作为所有基础设施和应用部署代码的单一事实来源 通过受保护分支的独特权限，限制可以部署到生产的用户和团队 [2] 代码审查 团队 - 方便后续追溯问题原因 提高代码质量，传播最佳实践，防止问题的出现 [3] 持续集成/持续交付 部署 - 无缝体验 - 与 Terraform 紧密集成 将其与敏捷管理和源代码管理建立在同一个应用程序中 支持从物理机、虚拟机、容器到云原生平台的多种基础环境的部署 4. GitOps 的大致运行流程 伴随着 DevOps 在近些年的火爆，围绕 xOps 产生了很多概念，诸如 DevSecOps，AIOps，MLOps，ChatOps 等等，当然还有的主角 GitOps。而GitOps 这个词出现于 2017 年，是由 Weaveworks 公司根据多年云计算基础设施和应用程序管理经验而提出的一个概念。  GitOps体系学习和理解 - 乱七八糟的xOps造词运动 一般情况下，可以使用下面的持续交付系统(示意图)，来完成云原生应用程序的部署与交付。这种 从左到右走到底 的 Push 模式，虽然很容易实现一键式部署，但也存在一些问题。 GitOps体系学习和理解 - 完成云原生应用程序的部署与交付 简而言之，就是没有办法保证两侧的服务是一致的，这可能会导致 配置漂移 的发生和安全合规问题的出现，而使用声明式是解决这个问题的关键点。 [1] 很难保证 仓库里清单文件的内容是否和 k8s 集群的实际情况是否一致 [2] 不够灵活 镜像有更新时不能够自动同步至集群，除非每次从头到尾走一遍部署流程 [3] 安全合规 有可能需要操作人员通过 kubectl 命令做一些集群操作 声明式系统有个特点，其能够帮我们自动完成应用程序或基础设施系统的描述状态和实际状态的自动同步，保证两者能保持一致。比如，应用部署清单里面应用程序是一个副本(replicas=1)，那么集群侧应用程序就会是一个 pod。 GitOps体系学习和理解 - 关于声明式的理解以及解题思路 而 GitOps 以声明式系统为基座，以 Git 为单一可信源，即一切皆代码，从而我们可以将上述构建流程改为下面这样的 pull 模式。pull 模式的关键就是，单一可信源与 k8s 集群的集成，当可信源侧的文件清单发生变更的时候，集群侧能够及时捕捉到此变更，从而完成变更清单的部署。 这就需要使用的 Git 工具支持与 k8s 打交道的能力。 可以将 Git 工具与 Terraform 集成，来完成云基础设施的自动化管理。 GitOps体系学习和理解 - 关于声明式的理解以及解题思路。 GitOps体系学习和理解 - 关于声明式的理解以及解题思路 # ------- 0.0 ------- # GitOps的仓库代码结构 # ------------------- # 多云环境 ➜ tree -a GitOps GitOps └── gitops ├── .gitlab-ci.yaml # CI/CD └── environments ├── aliyun │ ├── kubeconfig.yaml # k8s集群配置 │ ├── main.tf # 基础设置配置 │ └── yaml │ └── app.yaml # 集群服务配置 └── k3s └── yaml ├── app.yaml # 集群服务配置 └── kubeconfig.yaml # k8s集群配置 （编辑：辽源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |