DevOps

DevOps产品体验

Posted by 爱折腾的工程师 on Thursday, September 9, 2021

1. 选型对比

1.1 Erda DevOps

1.1.1 简介

Erda 是新一代数字化云原生 PaaS 平台，其核心包含三大模块：应用（微服务）研发治理平台、快数据治理平台和混合云管理平台。

  • 应用（微服务）研发治理平台具备项目管理、API 管理、CI/CD、自动化测试、应用管理、监控、日志分析、APM 和微服务观测等核心功能，从项目需求到上线交付，实现真正的一站式全流程管理。
  • 快数据治理平台采用流批一体的架构设计，基于实时的数据计算，提供数据源管理、数据地图、数据模型开发、数据资产、数据血缘等一体化的数据治理能力，可应用于数据中台建设、实时数据仓库建设等场景。
  • 混合云管理平台基于 Kubernetes（K8s）架构的容器云服务，提供 K8s 的可视化管理、常见公有云的资源管理和编排，以及立体式的智能监控告警，能够将应用部署到不同的云平台，实现混合云架构。

1.1.2 场景

1.1.2.1 业务项目管理

Devops 平台管理一个需求从设计到开发上线的完整生命周期。

迭代可分为以下几个阶段：

  1. 需求设计
  2. 开发
    • 任务分发
    • API 设计
    • 开发实现
  3. 提测
  4. 上线
  5. 简单监控
  6. 迭代质量

1.1.2.2 基于 Git 源码部署

准备示范代码 ->定义流水线 -> 执行流水线 -> 查看部署结果

1.1.2.3 基于 Docker Image 部署

基于 Docker Image 部署本质上和 基于 Git 源码部署 相同， 区别在于前者不需要源码构建Image产物。

1.1.2.4 部署一个 Go Web 程序

1.1.2.5 更灵活地自定义构建 Java 应用

  • Maven 构建
  • Gradle 构建
  • Tomcat 构建

1.1.2.6 使用缓存加速构建

  • Java 缓存
  • JS 缓存
  • 其他语言缓存

1.1.2.7 使用 Nexus 加速构建

  • 推送 JAR 包至私服（Maven）
  • 推送 JAR 包至私服（Gradle）

1.1.2.8 如何管理镜像

  • 通过 dockerfile 构建镜像
  • 通过 docker push 推送镜像
  • 通过 docker pull 拉取镜像
  • 自定义命令推送或拉取镜像

1.1.3 概念

![](/img/posts/2021-09-09/Erda DevOps.png)

1.1.4 设计理念

1.1.4.1 高效协同

平台自带研发协作的事件管理，主要包含产品待办事项（Product Backlog）、迭代计划（Sprint）、迭代任务（Sprint Backlog）、缺陷（Bug）等。

1.1.4.2 IaC

IaC（Infrastructure as Code），即基础设施即代码。

在服务上云的大趋势下，基础设施的概念已不再局限于 IaaS 层。云原生时代，开发者的焦点逐渐聚集到了应用上，即以应用为中心。持续集成、持续部署和 DevOps 概念的广泛推行和接受， 要求产品团队对部署和运维具备更高的自主性。一个开发工程师若仅是把代码写好，是远远不够的，充其量完成了 Dev。 而真正的软件交付生命周期，从 Ops 开始，运维工程师已不再负责应用的部署和运维，这些都是开发者的份内之事。

Erda可以通过 pipeline.yml 定义应用的 CI/CD 全流程，而 pipeline.yml 即该应用基础设施的一部分。 同时，您需要以一个声明式的 erda.yml 描述应用微服务架构，包括微服务之间的依赖关系、对中间件的依赖等。

当这些 Infrastructure 都被作为 Code 提交之后，Erda 平台便可以根据这些配置，进行持续集成和持续交付，最终自动把应用完整部署起来。

erda.yml 部分内容示意如下：

用于 CI 的 pipeline.yml 部分内容示意如下：

1.1.4.3 pipeline.yaml

Erda Pipeline 是由端点自研、用 Go 编写的一款企业级流水线服务。

pipeline架构

Pipeline 支持 UI、OPENAPI、CLI 等多种交互方式，同时支持水平扩展，保证高可用，并可将其划分为服务层、核心层和引擎层。

服务层

  • yaml parser 解析流程定义文件，支持灵活的变量语法，例如上下文值引用 ${{ outputs.preTaskName.key }}，配置管理引用 ${{ configs.key }} 等。
  • 对接扩展市场获取扩展能力。

核心层

  • Cron 守护进程。
  • EventManager 抽象内部事件发送，使用适配器模式解耦监控指标上报、发送 WS 消息、支持 Webhook 等。
  • AOP 扩展点机制（借鉴 Spring），暴露代码关键节点，便于开发同学在不修改核心代码的前提下定制流水线行为。

引擎层

  • 流程推进器（Reconciler）
  • 优先队列管理器
  • 任务执行器插件机制（ActionExecutor插件机制）

在引擎侧，pipeline.yaml 被解析为 DAG（Directed Acyclic Graph，有向无环图）结构后被推进。

中间件依赖

  • 使用 MySQL 做数据持久化。
  • 使用 etcd watch 功能实现多实例状态同步以及分布式锁。
  • 使用 etcd key ttl 实现数据 defer GC。

Pipeline 作为技术底座，可向上支撑：

  • DevOps：CI/CD 场景，包括 Erda 自身的持续集成和 Release 版本发布。
  • 快数据：工作流编排，流批一体，支持工作流优先级队列，保证高优先级数据任务必须执行。
  • 自动化测试：测试流程编排，API（出参、断言）、数据银行等不同类型的任务统一编排。
  • SRE 集群运维链路。
  • 提供无限扩展：基于 ActionExecutor 扩展机制和扩展市场。

在 Pipeline 中，平台对一个任务执行的抽象是 ActionExecutor，一个执行器只需实现单个任务的创建、启动、更新、状态查询、删除等基础方法， 即可注册成为一个 ActionExecutor。恰当的任务执行器抽象，使得 Batch/Streaming/InMemory Job 的配置和使用方式完全一致，批流一体， 对使用者屏蔽底层细节，做到无感知切换。在同一条流水线中，可以混用各种 ActionExecutor。

调度时，Pipeline 根据任务类型和集群信息，将任务调度至对应的任务执行器上。

1.1.4.4 erda.yaml

平台通过让开发者声明的方式，描述微服务运行的整体环境，并将该声明转化成环境搭建的过程。

YAML 文件的声明可分为两部分：

  • 微服务声明，包括微服务数量，以及各微服务所需的资源、副本个数、端口、环境变量，甚至对外网关的域名、网关的转发设置。
  • 扩展服务设置，即 Addon。开发者只需声明应用涉及的 Addon，例如 MySQL，指明 MySQL 的规格、版本即可，平台将自动为应用创建 MySQL，并将其配置通过环境变量的方式传递给微服务。同时 Addon 是可扩展的，通过这一开放的方式，您几乎可以将所有中间件集成进平台。

erda yaml vs k8s yaml区别？

通过 erda.yml 文件，开发者在中心平台经过验证的部署过程，无需修改，即可同时适配至客户环境，为一键部署打下基础。

1.1.4.5 Gitflow

Gitflow 即 Git 工作流，有助于持续软件开发和实施 DevOps 实践，其概念由文森特·德里森在 nvie (opens new window)首次提出并广受欢迎。 Gitflow 定义了围绕项目发布设计的严格分支模型，适用于有计划的发布周期项目和持续交付。

标准的 Gitflow 示例如下：

Gitflow 完整工作流程如下：

  1. develop 分支从 master 分支切出。
  2. release 分支从 develop 分支切出。
  3. feature 分支从 develop 分支切出。
  4. 当 feature 分支完成时，合并至 develop 分支。
  5. 当 release 分支完成时，合并至 develop 分支和 master 分支。
  6. 若 master 检测到问题，则会从 master 分支切出 hotfix 分支。
  7. 当 hotfix 分支完成时，合并至 develop 分支和 master 分支。

  • develop/master分支：

    标准的 Gitflow 使用两个分支记录项目的演进历史。其中 master 分支记录正式发布记录，develop 记录演进历程。 develop 分支和各个 feature 分支进行交互：feature 分支不断集成到 develop 分支，develop 分支则不断切出分支作为新的 feature 分支基线。

    master 分支可通过 tag 标记版本，并以 tag 为节点发布至生产环境。

  • feature分支：

    任何 feature 理应有一个自己的 feature 分支，不同 feature 不能混用同一分支。

    feature 分支需以最新的 develop 分支为基线，完成开发后，再合并回 develop 分支中。feature 分支不会与 master 分支产生关联。

  • release分支

    当 develop 分支中集成了一定量的 feature 或预定的发布日期临近时，即可考虑发版了。 发版是从 develop 分支切出一个 release 分支，同时表示本 release 周期已结束，并开启了下一个 release 周期。此后所有新的 feature 都不会体现在这个已 release 的分支上，只会集成至 develop 并最终切到下一个 release 分支。

    release 分支上的修改仅限于缺陷修复、自动化工具生成的文档等，不允许出现新的 feature。

    对于 release 分支上的缺陷修复，应切出新的分支进行问题修复并验证，之后再合并回该 release 和 develop 分支。

    release 分支可以合并到 master 分支并打上对应 tag ，然后删除release 分支。

  • hotfix分支

    hotfix 分支用以快速修复生产上的问题。当生产线上出现问题并定位后，从对应 tag 的 master 分支切出 hotfix 分支，解决问题并验证后， hotfix 分支需合并回 master 和 develop 分支，并在 master 分支上 tag。

1.1.5 借鉴

  • 组织->项目->应用的层级结构，每个层级对应不同的角色（Erda角色权限：https://erda.cloud/test12345/perm?scope=app），配额作用在项目
  • DevOps全家桶
  • 有个理念，不同分支对应到不同的部署环境和制品部署环境（如feature分支对应DEV部署/制品部署环境，develop分支对应TEST部署/制品部署环境）

1.1.6 VS OPS发布流程

  1. OPS有环境的概念，实际上环境也是对应集群，OPS的多环境实质上是对应一个集群的多个命名空间

    Erda devops是不同分支对应不同的部署环境和制品部署环境（4个固定环境：生产环境、预发环境、测试环境、开发环境）

  2. 审批流程差异

    • OPS: dev环境 -> qa环境 -> uat环境 -> 审批(dev审批人、qa审批人、现在审批人) -> live环境
    • Erda DevOps：是否审批 -> feature分支 -> 是否审批-> devlop分支 -> 是否审批 -> release分支 -> 是否审批 -> master分支（待确认？）

  3. 管理层级不一样，OPS是项目的概念，Erda devops有组织、项目、应用的概念

1.2 Kubesphere DevOps

1.2.1 简介

KubeSphere DevOps 提供基于 Jenkins 的 CI/CD 流水线，支持自动化工作流，包括 Binary-to-Image (B2I) 和 Source-to-Image (S2I) 等， 帮助不同的组织加快产品上市时间。

流水线支持Git、GitHub、Gitlab、SVN、以及Bitbucket代码仓库

1.2.2 案例

1.2.2.1 Source to Image

1.2.2.2 基于Spring Boot项目构建流水线

1.2.2.3 图形化构建流水线 (Jenkinsfile out of SCM)

1.2.3 概念

![](/img/posts/2021-09-09/KubeSphere DevOps.png)

1.2.4 借鉴

  1. 动态构建 jenkins slave，根据需要自动创建 Pod（解决并发构建问题）；KubeSphere 的 CI/CD 是基于底层 Kubernetes 的动态 Jenkins Slave，也就是说 Jenkins Slave 具有动态伸缩的能力，能够根据任务的执行状态进行动态创建或自动注销释放资源。实际上，Jenkins Master 和 Jenkins Slave 以 Pod 形式运行在 KubeSphere 集群的 Node 上，Master 运行在其中一个节点，并且将其配置数据存储到一个 Volume 中，Slave 运行在各个节点上，并且它不是一直处于运行状态，它会按照需求动态的创建并自动删除。
  2. 可创建 CI/CD 流水线且无需编写 Jenkinsfile
  3. 支持依赖项缓存，加快构建和部署
  4. Source-to-Image 从源代码构建可再现容器镜像，无需编写 Dockerfile
  5. Binary-to-image 将制品自动构建成可运行镜像

1.2.5 VS OPS发布流程

  1. OPS有环境的概念，实际上环境也是对应集群，OPS的多环境实质上是对应一个集群的多个命名空间

    KubeSphere devops cd的时候可部署不同的集群和不同的命名空间（

  2. 审批流程差异

    • OPS: dev环境 -> qa环境 -> uat环境 -> 审批(dev审批人、qa审批人、现在审批人) -> live环境
    • KubeSphere：人工确认 -> dev集群 -> 人工确认-> qa集群 -> 人工确认 -> uat集群 -> 人工确认 -> live集群
    • KubeSphere：人工确认 -> 集群(dev命名空间) -> 人工确认-> 集群(qa命名空间) -> 人工确认 -> 集群(uat命名空间) -> 人工确认 -> 集群(live命名空间)

  3. 管理层级不一样，OPS是项目的概念，KubeSphere devops有企业空间、DevOps工程的概念

1.3 CODING DevOps

1.3.1 简介

CODING DevOps 面向容器业务场景，提供代码编译、容器镜像构建、镜像推送及应用部署等功能， 与容器服务 TKE、容器镜像服务 TCR 紧密结合，共同提供强大的云原生 DevOps 服务。

CODING DevOps的子产品：

1.3.2 业务流程

1.3.3 功能特性

1.3.3.1 持续构建

  • 兼容 Jenkins 使用方式，可提供 Jenkinsfile 完整定义编译构建流程
  • 支持 CODING、GitHub、GitLab、私有 GitLab，码云主流源代码托管平台
  • 支持持续构建模板，可根据业务类型快速配置编译构建流程

1.3.3.2 镜像托管分发

  • 云上独享 Docker Registry 服务，同时支持 Helm Chart 托管
  • 支持公网及私有网络访问控制，支持仓库级细颗粒度操作权限控制
  • 支持 Webhook 触发器、镜像安全扫描、跨地域同步，灵活接入企业内已有发布系统，保障部署安全

1.3.3.3 持续部署

  • 兼容 Spinnaker 使用方式，支持蓝绿发布、金丝雀发布等多种发布策略
  • 支持直接部署至容器服务 TKE 集群，同时兼容标准集群、弹性集群、边缘集群
  • 同时提供简单易用的交付工作流及强大的原生 Spinnaker 使用方式，满足客户不同场景的使用需求

1.3.4 应用场景

1.3.4.1 敏捷开发实践

从用户故事开始，到需求池管理以及任务拆解、缺陷管理、测试管理，敏捷开发过程都有序建立。 帮助企业以最低的预算、最快速的迭代方式验证产品版本投入市场的效果。

1.3.4.2 瀑布流开发实践

CODING DevOps 涵盖了从需求规划、开发计划、需求评审、开发测试、持续部署整个研发生命周期的管理，满足不同规模团队的瀑布式研发模式， 让项目严格按计划流程推进，有效控制项目风险。

1.3.4.3 DevOps 自动化实践

CODING DevOps 提供持续集成到自动部署的全过程工具：自动构建、自动化测试、制品库、持续部署。 支撑项目的快速迭代，保证软件稳定、持续构建发布。实现 DevOps 持续交付全流程应用。

1.3.5 CODING 持续集成

1.3.5.1 CODING 持续集成简介

CODING 持续集成（CODING Continuous Integration，CODING-CI）全面兼容 Jenkins 的持续集成服务， 支持 Java、Python、NodeJS 等所有主流语言，并且支持 Docker 镜像的构建。图形化编排，高配集群多 Job 并行构建全面提速您的构建任务。 支持主流的 Git 代码仓库，包括 CODING 代码托管、GitHub、GitLab 等。在构建依赖拉取方面，对于包括 Maven、NPM 在内的主流镜像源有专用网络优化， 保证拉取速度，进一步提升构建的速度。

1.3.5.2 应用场景 - 自动构建

CODING 持续集成可以用于自动构建代码，在用户自定义的构建环境和构建脚本指令下， 基于云端的强大计算能力和网络快速把源代码构建为可运行的目标产物，并存放入构建版本仓库。

1.3.5.3 应用场景 - 辅助评审

适用于辅助代码评审，代码评审工作繁杂而又重要，应用持续集成能力可以在所有评审工作之前进行全自动的构建、自动化测试、风格检查、质量扫描、安全评估等前置工作， 为后续的评审工作大大减负。

1.3.5.4 应用场景 - 自动化测试

DevOps 要求软件交付流程的高度自动化，其中自动化测试工作尤为重要，持续集成可参与项目发布、代码评审、项目验收等环节的自动化测试，为交付流程提高效率。

1.3.6 CODING 持续部署

1.3.6.1 CODING 持续部署简介

CODING 持续部署（CODING Continuous Deployment，CODING-CD）用以管理软件在经过构建之后的发布和部署交付过程， 可以无缝对接上游 Git 仓库、制品仓库实现全自动化部署，同时支持 Webhook 等外部对接能力，方便集成各种开发、运维工具。 在配以合适的技术架构、运维工具的基础上，可以方便的实现蓝绿发布、灰度发布(金丝雀发布)、滚动发布、快速回滚等功能。

1.3.6.2 应用场景 - 全流程管控

持续部署是实现 DevOps 闭环的核心流程，CODING 持续部署通过整合上下游，实现 DevOps 全流程管控。

1.3.6.3 应用场景 - 灰度发布

CODING 持续部署可配以合适的技术架构和运维工具实现蓝绿发布，灰度发布，快速回滚等能力。

1.3.6.4 应用场景 - 发布审批

CODING 持续部署支持在发布流程开始前实现多场景的人工和自动化审批。

1.3.7 概念

![](/img/posts/2021-09-09/CODING DevOps.png)

1.3.8 借鉴

可以借鉴的地方：

  1. 应用->部署流程，提供多种部署模版
  2. 团队->项目->应用的层级结构
  3. CD支持Helm
  4. 提供API：项目/项目设置/开发者选项
  5. 前端面板控制：项目/项目设置/功能开关
  6. DevOps全家桶（大而全）

1.3.9 VS OPS发布流程

  1. OPS有环境的概念，实际上环境也是对应集群，OPS的多环境实质上是对应一个集群的多个命名空间

    CODING支持多集群和单集群多命名空间；

  2. 应用高级特性支持，CODING支持

  3. 审批流程差异

    • OPS: dev环境 -> qa环境 -> uat环境 -> 审批(dev审批人、qa审批人、现在审批人) -> live环境
    • CODING：人工确认 -> dev集群 -> 人工确认-> qa集群 -> 人工确认 -> uat集群 -> 人工确认 -> live集群
    • CODING：人工确认 -> 集群(dev命名空间) -> 人工确认-> 集群(qa命名空间) -> 人工确认 -> 集群(uat命名空间) -> 人工确认 -> 集群(live命名空间)

  4. 管理层级不一样，OPS是项目的概念，CODING有团队、项目、应用的概念

2. DevOps vs DevSecOps vs GitOps vs AlOps vs ChatOps vs NoOps 区别?

2.1 DevSecOps

DevSecOps采用了传统的DevOps方法，并在工作流程中添加了额外的安全检查、代码验证和深入测试。DevSecOps从流程的一开始就集成了安全性，而不是在周期结束时让安全性成为一个问题。

2.2 GitOps

2.2.1 简介

GitOps 是Weaveworks提出的一种持续交付方式， 它的核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 版本库中。将Git作为交付流水线的核心，每个开发人员都可以提交拉取请求（Pull Request）并使用 Git 来加速和简化 Kubernetes 的应用程序部署和运维任务。 通过使用像Git这样的简单工具，开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上（例如，应用系统安装、配置、迁移等）

2.2.2 应用场景

不管如何选择构造自己的交付流水线，将基于Git（或者其他版本控制工具）的GitOps最佳实践应用在交付流水线中都是一个不二选择，GitOps 也不是万能的，它也有相应的应用场景。

2.2.2.1 不可变基础设施

应用都需要运行在多台机器上，它们被组织成不同的环境，例如开发环境、测试环境和生产环境等等。 需要将相同的应用部署到不同的机器上。通常需要系统管理员确保所有的机器都处于相同的状态。 接着所有的修改、补丁、升级需要在所有的机器中进行。随着时间的推移，很难再确保所有的机器处于相同的状态，同时越来越容易出错。 这就是传统的可变架构中经常出现的问题。这时我们有了不可变架构，它将整个机器环境打包成一个单一的不可变单元，而不是传统方式仅仅打包应用。 这个单元包含了之前所说的整个环境栈和应用所有的修改、补丁和升级，这就解决了前面的问题。 —— 摘自InfoQ的《关于不可变架构以及为什么需要不可变架构》作者 百占辉

不可变基础设施这一概念不是刚刚才提出来的，它也不是必须需要容器技术。然而，通过容器，它变得更易于理解，更加实用， 不可变基础设施让我们以全新的方式理解和面对应用系统，尤其是使以微服务为代表的分布式系统在部署、运维等方面变得不那么复杂，而有很好的可控性。

2.2.2.2 声明性容器编排

借助 Kubernetes 的声明性特点，应用系统的整个配置文件集可以在Git库中进行版本控制。 通过使用Git库，应用程序更容易部署到Kubernetes中，以及进行版本回滚。 更重要的是，当灾难发生时，集群的基础架构可以从 Git 库中可靠且快速地恢复。

Kubernetes等云原生工具的声明性体现在可以对实例、容器、网络、存储、CPU 等配置通过一组代码方便的表达出来， Kubernetes 等云原生工具可以利用这些配置代码运行出来一套基于容器的应用系统。

GitOps充分利用了不可变基础设施和声明性容器编排，通过GitOps可以轻松地管理多个应用部署。为了最大限度地降低部署后的变更风险，无论是有意还是偶然的“配置差异”， GitOps构建了一个可重复且可靠的部署过程，在整个应用系统宕机或者损坏情况下，为快速且完全恢复提供了所需条件。

2.2.3 基本原则

  • 任何能够被描述的内容都必须存储在Git库中：通过使用Git作为存储声明性基础架构和应用程序代码的存储仓库，可以方便地监控集群，以及检查比较实际环境的状态与代码库上的状态是否一致。 所以，我们的目标是描述系统相关的所有内容：策略，代码，配置，甚至监控事件和版本控制等，并且将这些内容全部存储在版本库中， 在通过版本库中的内容构建系统的基础架构或者应用程序的时候，如果没有成功，则可以迅速的回滚，并且重新来过。

  • 不应直接使用kubectl 命令：一般不提倡在命令行中直接使用kubectl命令操作执行部署基础架构或应用程序到集群中。 还有一些开发者使用 CI 工具驱动应用程序的部署，但如果这样做，可能会给生产环境带来潜在不可预测的风险。

  • 调用 Kubernetes的API接口或者控制器应该遵循Operator模式：集群的状态和Git库中的配置文件等要保持一致，并且查看分析它们之间的状态差异。

2.2.4 GitOps流水线

GitOps的Config Updater检测到有镜像更新，从存储库中提取新镜像，然后在 Git 配置仓库中更新其YAML。 然后，GitOps的Deploy Operator会检测到集群中应用已过期，并从配置库中提取已更改的清单，并将新镜像部署到集群中。

3.2.5 实现工具

实现 GitOps 中有两个重要的概念：Config Updater和Deploy Operator，这在Kubernetes中通常也是使用Operator来实现的， 目前比较热门的用于实现GitOps的工具有Flux、ArgoCD、Jenkins X。

三个工具之间的具体对比参考：https://blog.container-solutions.com/fluxcd-argocd-jenkins-x-gitops-tools

2.3 AlOps

根据Gartner的定义，AIOps的主要目标包括：通过采集当前环境中的运维数据，集成现有IT运维管理工具，利用算法等高级数据分析技术对IT系统中各个环节的问题进行快速定位、故障排除和预测； 对来自业务环节中各个分布式系统的数据进行聚合分析，合理优化IT服务，挖掘关键业务的KPI指标，反哺业务端，帮助其做出明智决策； 通过大数据和人工智能技术分析用户的行为日志和运维数据，发掘潜在的系统安全和合规问题，为企业的信息安全保驾护航。

以发现异常为例，传统IT运维工具中都会采用基于经验值来定义异常阈值，这种方法主要基于人的主观判断。 而基于机器学习的方法，通过积累历史运维数据，根据日常运维的需求在数据特征的基础上建立算法模型，对模型进行周期性地训练学习， 从而能为IT系统提供更为及时、准确、高覆盖的检测结果。比如，传统异常发现的流程是运维人员在系统中创建了业务路径，并对路径中关注的节点或连线进行告警设置。 如数据中心网银交易服务器响应时间告警的设置为>300ms，如果运维软件监测到响应时间超过300ms，系统告警。 而采用AI方法进行异常检测时，运维人员不用对业务路径做任何告警设置，当机器学习算法检测到某个业务路径的某个节点或连线上产生了异常值，就会自动抛出异常事件。

2.4 ChatOps

2.4.1 简介

ChatOps以聊天室（聊天群），即实时聊天软件为中心，通过一系列的机器人去对接后台的各种服务，开发&测试&运维人员只需要在聊天窗口中与机器人对话， 即可与后台服务进行交互，整个工作的展开就像是使唤一个智能助手那样简单自然。

2.4.2 优势

ChatOps的好处：

  • 公开透明。所有的工作消息都在同一个聊天平台中沉淀并公开给所有相关成员，消除沟通壁垒，工作历史有迹可循，团队合作更加顺畅。
  • 上下文共享。减少因工作台切换等对消息的截断，保证消息的完整性，让工作承接有序，各角色，各工具都成为完成工作流中的一环，打造真正流畅的工作体验。
  • 移动友好。只需要在前台与预设好的机器人对话即可完成与后台工具、系统的交互，在移动环境下无需再与众多复杂的工具直接对接，大大提升移动办公的可行性。
  • DevOps 文化打造。用与机器人对话这种简单的方式降低 DevOps 的接受门槛，让这种自动化办公的理念更容易的扩展到团队的每一个角落。

2.4.3 案例

ChatOps的理解最早要源于在GitHub上参与开源项目的一些经历，在向Kubernetes相关项目提交PR时， 会有一个名叫k8s-ci-robot的小机器人来自动为该PR打上标签，并且根据你提交PR时的comment信息来为你分配Reviewers， 如果没有填的话，则会自动为你分配 Reviewers 等功能。同时可以在 comment 中输入命令，还可以进行其他的操作。 而其实这个机器人的后端就是名为Prow的由Google发起的适应云原生CI/CD开源项目。 Prow 快速入门向导

2.5 NoOps

NoOps是最早由Forrester创造的一个术语，旨在提高生产力并比 DevOps 更快地交付结果。 在理想情况下，开发人员永远不必与运营团队的成员协作。相反，他们可以使用一组工具和服务，以安全的方式负责任地部署开发所需的云组件，包括代码和基础设施。 托管云服务（如PaaS或无服务器）充当NoOps的支柱，并利用CI/CD作为其部署的核心引擎。因此，请注意，并非所有场景都适合应用 NoOps。

NoOps是DevOps的演变结果，其目标是实现高度自动化的完美最终状态。

3. 我们的方案

选择KubeSphere为底座

  • 流水线并发构建
  • 构建流水可视化、可编辑
  • 容器平台底座也是KubeSphere（WiseCloud、CODING不开源）
  • 流水线以Jenkins为核心，深度集成Jenkins（Erda pipeline自研）
  • 发布策略、多版本（这部分工作需开发，下沉到k8s，新抽象一种工作负载） ![](/img/posts/2021-09-09/CI_CD v2.0.png)

流水线流程图： ![](/img/posts/2021-09-09/CI_CD v2.0流程图.png)

4. 参考链接

「真诚赞赏，手留余香」

爱折腾的工程师

真诚赞赏，手留余香

使用微信扫描二维码完成支付

CATALOG
    FEATURED TAGS
    devops go k8s llm openstack tkestack 练车