DevOps

I. Argo CD 与 GitOps 简介 在现代云原生应用开发和部署领域，Kubernetes 已成为容器编排的事实标准。然而，随着应用规模和复杂性的增长，如何在 Kubernetes 上实现高效、可靠且可重复的持续交付（Continuous Delivery, CD）成为了新的挑战。Argo CD 应运而生，旨在解决这一核心问题。 什么是 Argo CD？Kubernetes 的声明式 GitOps 工具 Argo CD 被明确定义为一种用于 Kubernetes 的声明式、基于 GitOps 的持续交付（CD）工具 1。它的核心功能是通过将 Git 仓库中定义的期望状态（Desired State）与 Kubernetes 集群中的实际运行状态（Live State）进行同步，从而自动化应用程序的部署过程 1。 这种声明式的特性是其根本。与命令式工具（需要编写脚本指定如何部署）不同，使用 Argo CD 时，开发者在 Git 中声明最终状态应该是什么样子，而 Argo CD 则负责计算并执行达到该状态所需的步骤。这代表了一种核心的范式转变。 Argo CD 是一个开源项目，最初由 Intuit 公司创建 1，现已成为云原生计算基金会（Cloud Native Computing Foundation, CNCF）的毕业项目 1。CNCF 的毕业状态标志着该项目具有稳定性、强大的治理结构和广泛的社区采纳度，使其成为一个可靠的技术选型 15。 核心解决的问题：声明式管理 Kubernetes 部署 传统的 Kubernetes 部署方法可能涉及手动执行 kubectl apply 命令或编写复杂的部署脚本。这些方法往往容易出错、缺乏可审计性，并且难以在多个环境间保持一致性 1。Kubernetes 本身也受益于自动化、一致的部署工作流 1。Argo CD 正是针对这一痛点，满足了将应用程序定义、配置和环境进行声明式管理和版本控制的需求 2。...

why? 故事是从这个 proposal 开始idea~ 🤖 OpenIM cicd robot machine proposal Prow是基于Kubernetes的CI/CD系统。作业可以由各种类型的事件触发，并将其状态报告给许多不同的服务。除了作业执行，Prow还以策略执行、通过 /foo 风格命令的聊天操作和自动PR合并的形式提供GitHub自动化。 有关 Golang 文档，请参阅 GoDoc。请注意，这些库仅供prow使用，我们不会尝试保留向后兼容性。 Kubernetes 专门为 Prow 提供了网页命令查询： https://prow.k8s.io/command-help 关于Prow如何运行作业的简要概述，请参阅 Prow作业的生命周期。 要查看Prow的常用用法和交互流，请参见拉取请求交互序列图。 hello world 最简单的一个上手案例莫过于 pull request 。 提出一个拉取请求（以下简称PR）。在PR正文中，可以随意添加区域标签（如果合适），例如 /area <AREA> 。标签列表在这里。也可以随意推荐一位评论者 /assign @theirname 。 一旦你的审阅者满意，他们会说 /lgtm ，这将应用 lgtm 标签，如果他们是OWNER，将应用 approved 标签。 approved 标签也将自动应用于所有者打开的PR。如果你和你的审阅者都不是OWNER，请 /assign 某个所有者。如果你的PR有 lgtm 和 approved 标签，没有任何 do-not-merge/* 标签，并且所有测试均通过，则PR将自动合并。 查看测试结果 Kubernetes TestGrid 显示历史测试结果 在 testgrid/config.yaml 配置自己的 testgrid 仪表盘 Gubernator 格式化每次运行的输出 PR Dashboard 查找需要注意的 PR Prow 安排测试并更新问题 Prow 响应 GitHub 事件、定时器和在 GitHub 评论中给出的手动命令。 prow dashboard 显示当前正在测试什么 在 config/jobs 配置 prow 运行新测试 Triage Dashboard 汇总故障 将故障集群在一起 搜索跨作业的测试失败 在特定的测试和/或作业的 regex 中过滤失败 Velodrome 指标跟踪作业和测试健康状况。 Kettle 进行收集，metrics 进行报告，velodrome 是前端。 功能和特性 prow 的功能很强大，甚至是比 actions 更加出众。可以测试、批处理、工件发布的作业执行。...

DevOps DevOps 🔥 DevOps是一种软件开发和运营的文化和方法论，旨在通过自动化和协作来缩短软件开发周期和提高软件质量。 DevOps（Development和Operations的混成词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 为什么 OpenIM 需要 DevOps？ 我想用一句话来概括，DevOps 能解决 OpenIM 当前的团队管理，能高效组织团队，并且能通过 自动化 工具协作于沟通。 从而实现用更少的浪费、更频繁的交付更稳定的产品。 最开始的 OpenIM 是什么样子的？ 找到了之前的一个很古老的版本，链接是：https://github.com/OpenIMSDK/Open-IM-Server/tree/test-tuoyun 几乎存在 commit 信息丢失，因为信息不全导致代码无法跟踪问题，导致文档缺失，代码不规范等一系列的问题。 我们跨越了从原始社会到传统的协作方式，再到后面的 devops 为什么说及时到现在，我依旧没有将 OpenIM 转变为 devops，一个很明显的判断标准，每一次运维和交互工作依旧需要我手动去做，无疑是区分了 dev 和 ops 的职责。不仅仅让成本变高，效率变低，更重要的是团队没有了更清晰的定位。 那么我后面的计划如何？ 不管是 prow, actions, 等等 CI 工具，以及各种 ops（gitops, aiops, chatops,） 也不管是各种设计的 自动化 以及 自动化管理工具，自动化交互工具。 无疑他们是一套体系： 提供无感知的开发环境，无论交付是否频繁，每一个 feature 的 PR 都能快速的，规范并且经过大量自动化测试，更加快速上线，也能更快地响应客户需求。每一次发布的变更变少，所以风险，以及合并的冲突，工作量就变少。而且代码 code review 更方便，代码质量和团队水平提升很高的档次。 🔥 OpenIM 当时我的设计理念是 main 分支作为一个类似于传统的 dev 分支，保证代码的最新以及基本可靠，release-v* 分支作为稳定的分支。 DevOps 最重要的就是自动化，和自动化运维。非常鼓励自动化，甚至可以让开发者即使不会任何运维也能去走整套自动化的流程。 OpenIM 的团队约束制定：https://traveling-thistle-a0c.notion.site/OpenIM-standardization-ebd0c1529ab54e4fb92840e67a73aac1?pvs=4...