又是开篇

• 上一篇文章我们大概分享了DevOps项目管理中怎么企业级搭建
• 本篇文章主要介绍两个子系统【CICD、效能看板】

CICD系统

• CI（Continuous Integration）：指持续集成，它属于开发人员的自动化流程。
• 持续集成是一种软件开发实践，团队开发成员经常提交代码到代码仓库，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成，且每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误，从而使问题尽早解决。持续集成是一个将集成提前至开发周期的早期阶段的实践方式，让构建、测试和集成代码更经常反复地发生。虽然持续集成无法消除bug，但却能大大降低修复bug的难度和时间。
• CD（Continuous Delivery）：指的是持续交付和/或持续部署
• 通过持续交付，其软件交付流程进一步自动化，以便随时轻松地部署到生成环境中。CD 集中依赖于部署流水线，团队通过流水线自动化测试和部署过程。通过持续交付，可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。
  
• 清晰cicd流程图：https://www.processon.com/view/link/63536f66e0b34d081671f08d

CICD开源组件

GitLab【代码仓库】

• 通过细粒度的访问控制来管理Git存储库，确保您的代码安全。执行代码审查并通过合并请求的实现更紧密的开发协作。每个项目还可以配置议题跟踪和wiki。
• 官网：https://about.gitlab.com/
• 企业版本：https://gitlab.cn/
• Rest API：https://www.apifox.cn/web/project/406098/

docker

• Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows操作系统的机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。
• 官网：https://www.docker.com/
• 官网仓库：https://hub.docker.com/

Kubernetes (K8s)【部署】

• kubernetes，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。
• 官网：https://kubernetes.io/zh-cn/
• 开源地址：https://github.com/kubernetes/kubernetes

Kubesphere

• KubeSphere 愿景是打造一个以 Kubernetes 为内核的 云原生分布式操作系统，它的架构可以非常方便地使第三方应用与云原生生态组件进行即插即用（plug-and-play）的集成，支持云原生应用在多云与多集群的统一分发和运维管理。 KubeSphere 也是一个多租户容器平台，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流
• 官网：https://kubesphere.io/
• 开源地址：https://github.com/kubesphere/kubesphere

Rancher

• Rancher 是供采用容器的团队使用的完整软件堆栈。它解决了管理多个Kubernetes集群的运营和安全挑战，并为DevOps团队提供用于运行容器化工作负载的集成工具。
• 官网：https://www.rancher.cn/
• 开源地址：https://github.com/rancher/rancher

构建打包流水线【Jenkins】

• Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件项目可以进行持续集成
• 官网：https://www.jenkins.io/zh/
• 开源地址：https://github.com/jenkinsci/jenkins

代码扫描【SonarQube 】

• SonarQube 是一个开源的代码分析平台, 用来持续分析和评测项目源代码的质量。 通过SonarQube我们可以检测出项目中重复代码， 潜在bug， 代码规范，安全性漏洞等问题， 并通过SonarQube web UI展示出来。
• 官网：https://www.sonarqube.org/
• 开源地址：https://github.com/SonarSource/sonarqube

镜像仓库【Harbor】

• Harbor 是一个开源注册表，它使用策略和基于角色的访问控制来保护工件，确保图像被扫描并且没有漏洞，并将图像标记为可信。Harbor 是一个 CNCF 毕业项目，它提供合规性、性能和互操作性，以帮助您跨云原生计算平台（如 Kubernetes 和 Docker）一致且安全地管理工件。
• 官网：https://goharbor.io/
• 开源地址：添加链接描述

自动化运维【ansible】

• ansible是新出现的自动化运维工具，基于Python开发，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。Ansible架构相对比较简单，仅需通过SSH连接客户机执行任务即可
• 官网：https://www.ansible.com/
• 开源地址：https://github.com/ansible/ansible

单点登录【casdoor】

• 支持 OAuth 2.0、OIDC 和 SAML 的 UI 优先集中式身份验证/单点登录 (SSO) 平台，与 Casbin RBAC 和 ABAC 权限管理集成。
• 官网：https://casdoor.org/zh/
• 开源地址：https://github.com/casdoor/casdoor

功能列表

凭证管理

Git凭证

• 支持Git凭证的增删改查，可以支持Git多种授权方式
• 用户名密码授权、密钥授权、项目令牌授权
  
• 有了凭证管理过后后续在拉取代码的时候会用到进行鉴权

Docker Harbor 仓库凭证

• 主要采用用户名密码的形式进行存储，在后续进行构建完成后把镜像包上传到Harbor仓库上面
• 为了方便不同项目不用每个都开启一个Harbor账号，可以由CICD平台统一开起一个默认的Harbor账号初始化进项目中
• PS：无论是Git账号、Docker Harbor账号在持久化存储的时间，都必须镜像密码加密存储，加密方式参考：
• https://blog.csdn.net/u010800804/article/details/118708711

代码源管理

• 在CICD系统中，需要用到源代码授权，在获取源代码的情况进行然后进行不同开发语言进行打包
• 使用统一代码仓库作为代码源，将从您在平台对应的GitLab个人账号下选择一个自己的代码仓库，在CI/CD系统中的当前项目内进行共享。
• 表示代码源添加后，本项目内的所有成员都可以在构建任务、单元测试中使用该代码仓库作为自己的代码源，同时不需要配置其他鉴权信息就可以在任务执行过程中下载到该代码仓库的代码。
• 如后续使用中需要取消共享，您可以在代码源中移除自己添加的代码仓库，但移除后可能会导致依赖的任务无法执行。
  
• 在这里会用到远程调用Gitlab【或者其他代码仓库管理平台】API，进行当前用户账号有权限的代码和公共的代码仓库，当然可以进行搜索。
• 在上面讲到的凭证管理，推荐大家使用项目token的方式
• 在Gitlab进行token权限设置，只给只读权限，因为CICD平台只会拉取代码进行构建产物，不会对源代码镜像修改和提交，当然防止别有用心之人对其进行修改。
  
  

基础设置

角色管理

• 支持自定义角色，可以给自定义角色划分相应的增删改查权限【如流水线、构建权限等】

成员管理

• 支持管理员主动从用户中心进行人员同步
• 在外层公共的地方也支持用户主动进行申请，然后项目管理员进行审核
  

构建管理

基本信息

• 构建的名字、构建的添加时间、构建的其他基础信息【如是否禁用等字段】
  

选择代码源

• 构建的时候是否是固定分支、出发的方式又是什么【如手动构建、Webhook的方式构建】可以进行编辑及选择
  

构建步骤

• 进行常用的代码进行做成模板进行构建【如Java构建、Golang构建、NPM构建等】，或者自定义命令介绍。
  
• 使用封装好的Java代码编译环境（如Maven、JDK），以docker run的方式启动一个临时的容器进行构建。【这会编译在Jenkins脚本中】
• 构建的时候传入凭证、构建信息等，调用Jenkins的API进行调用。
  
• Dcoker进行镜像构建，输入相应的参数
  
• 通过“docker build”和“docker push”把构建结果以镜像方式进行交付至镜像仓库。
• docker build的Context为代码根目录，注意Dockerfile中的相对路径要以根目录为参考。

环境管理

K8S公共集群

• 可以使用在公司资源池创建的K8S集群创建环境，也可以使用其他外部云服务商的集群创建环境（前提是能够正常访问到K8S的API）。
• 不同的K8S环境可以使用相同的K8S集群，但必须通过不同的namespace加以区分。
  

K8S私有集群

• 一般在生产环境下，不同部门使用的是不同的K8S集群，甚至运维也是不同的人在运维，所以一个公司会有很多个生产集群供不同项目选择使用，但是开发环境、测试环境可以统一使用一个公共大集群，方便大家统一环境，快速构建测试生产环境。
• 私有K8S集群接入主要依赖Config.yml,进入导入，然后调用K8S SDK进行环境校验接入。
  

部署管理

基本信息

• 写入部署基本信息，如名称、部署的环境、镜像地址、Docker仓库鉴权选择等
  

部署配置

• 部署配置，主要就是把K8S的常用信息，如Deployment、ConfiMap、服务暴露等信息进行可视化页面操作。

• Deployment在K8S中就是最主要的，主要包含多个Pod，如最大最小内存、最大最小CPU限制，这样设置后也会保护我们的主机
  
  

• ConfigMap

• ConfigMap是K8S中可用于存储配置信息的一种资源对象，

• 您可以在此处上传应用在该环境运行时需要的配置文件，

• 部署任务执行时对这些文件将以ConfigMap的方式挂载到应用容器中指定的目录下。

• 服务暴露：Service

• K8S的Service主要分两种，ClusterIP和Nodeport。

• ClusterIP仅能在K8S集群内部通过 [内部访问地址] 访问。

• NodePort除了支持内部访问外，还可以通过K8S任一节点IP及映射的端口号进行访问。
  

• 服务暴露：Ingress

• Ingress相当于K8S集群的流量入口（后端通过Nginx实现），根据Host和Path判断把流量分发到具体的后端应用。

• 填写的Host不会自动解析到K8S集群入口，需要用户自行解析到集群任一节点的IP。

• Ingress仅支持以HTTP协议提供服务的应用从K8S外部访问，访问端口号一律是80。

• 服务暴露：GRPC Ingress

• GRPC Ingress用于代理GRPC类型的服务。

• 如果调用者与GRPC服务在同一个K8S集群中，可直接通过列表中的访问地址进行访问，无须加端口。

• 如果调用者与GRPC服务不在用一个K8S集群中，则访问者需要绑Hosts，域名为访问地址。
  

应用管理

• 支持查看Pod实例
  
• 支持K8S在线扩缩容等操作，查看K8S Deployment描述文件等。

流水线管理

• 企业级持续集成和持续交付工具，通过构建自动化、集成自动化、验证自动化、部署自动化，完成从开发到上线CICD过程。通过持续向团队提供及时反馈，让交付过程高效顺畅。
  
• 最佳实践
• 我们在实际应用的过程中，通常把我们的单元测试、代码扫描等，构建，部署统一添加到一个流水线中，然后当代码提交时，出发WebHook进行出发流水线。

基本信息

工作流

• 构建： 支持以Docker镜像的方式封装测试所需的运行环境，然后执行自定义的测试过程，在工作流程进入交付环节之前保证代码达到必要的质量。
• 部署： 结合实际的软件发布流程，以已有的应用部署任务为核心。
• 单元测试： 使用已有的测试任务为持续交付流程提供测试功能。
• 卡点操作： 可通过卡点实现流水线执行过程的人工审核机制，也可以在卡点阶段执行外部依赖操作，提高流程的合理性。
• 代码扫描： 通过HTTP方式调用外部接口，实现CICD工作流与外部能力快速集成。
  

效能看板

• 效能看板一款专业的交付过程观测和研发效能度量分析工具，从计划、执行、风险等 6 个方面度量交付过程、暴露交付风险、保障交付效率和质量，通过流动效率、资源效率、质量保障 3 个维度可视化团队效能状态、深入分析问题、精准指导效能改进。

整体说明

• 前面我们用到了很多的开源组件：如Gitlab、禅道、Jenkins等
• 是一整套完整的DevOps工具链，我们也参数了很多的数据集
• 当然领导最喜欢的就是看报表、看板、我们可以根据不同公司、不同维度、进行指标库统一创建、然后进行不同部门不同指标自定义展示。

功能描述

项目交付过程度量

• 度量项目的交付过程，跟进计划和执行，及时发现问题和偏差
• 帮助管理者保障项目交付的规范、效率和质量

团队资源可视化

• 可视化团队资源规划，即时反映团队中人力的分配、工作负荷和产出效率
• 帮助管理者精准调配人力、优化资源配置，并客观评价资源产出能力，有针对地提升组织效能

研发效能度量和分析

• 基于专业的效能模型，客观评价团队效能状态，分析效能问题
• 让效能状态一目了然，改进有据可依，改进结果可量化

权威的研发效能度量解读

• 为各个报表和度量指标提供系统的解读，帮助团队深入理解度量指标含义和使用方法
• 面向各个场景，提供度量方案设计建议，提升方案的可行性和落地效果

写完啦

• CICD篇算是告一段落啦，过程中，只描述了大概的一些信息，细节方面都没有详细列出，毕竟DevOps不是三言两语就能很好的概括的，只是在这里写了一个大致的方向，供大家参考。
• 企业级DevOps平台搭建及技术选型-项目管理篇
• https://rundreams.blog.csdn.net/article/details/127451055

当然如有问题沟通，也可以私信与我交流，谢谢。