一、DevOps 的理解

DevOps 的概念在软件开发行业中逐渐流行起来。越来越多的团队希望实现产品的敏捷开发，DevOps 使一切成为可能。有了 DevOps ，团队可以定期发布代码、自动化部署、并将持续集成 / 持续交付作为发布过程的一部分。一句话概括就是提高生产力，快速交付。

二、引入 DevOps 的背景


2.1 福禄技术栈介绍

• 后端开发框架：基于C#的.netCore和Java的SpringCloud，少部分项目采用 Python 和 Go 开发
• 前端开发框架：vue、react
• 服务部署：前端站点基于 ECS 的 Nginx 部署 ，后端服务统一部署在 Kubernetes上
• 代码仓库：Gitlab
• 项目环境：目前有6套，开发、测试、压测、集成、PRE 和生产
  
  

2.2 后端服务的 CICD 现状

CICD 流程说明

每一次的代码 push，根据创建的分支，根据在 Gitlab 的 CICD 文件 gitlab.yml 定义构建步骤，触发 runner，从单元测试、通过 dockerfile 进行编译和生成镜像版本、将新镜像部署到 K8S 生成 pod，然后触发接口自动化测试任务的执行

!!#00ffff 好像缺了点什么 !!

• 初次部署应用到 Kubernetes 怎么做的？
• 服务的 configmap 在哪里维护的？
• 每个服务的 gitlab.yml 文件都不一样，如何维护的？
• 应用的域名解析怎么做？
  

目前有6套环境进行管理，其中开发、测试、集成、压测都是测试人员维护，预发布和生产运维人员维护；这也就要求每一个测试人员都必须对整个cicd流程和配置绝对掌握；所以当新人入职，需要掌握整个流程才能进入项目测试中，这是一个学习成本；


预发布和生产的 Kubernetes 只有运维能够操作，当有新的服务需要上线上述环境，或者 configmap 有变动，或者有时候排查问题需要查看容器日志，我们只能通过运维的工单系统描述作业操作，中间文字描述可能存在理解差异，沟通成本和时间成本很大；


有的新应用我们去设置 CICD 的相关文件，比如 dockerfile，我们发现应用的代码目录结构各种各样，这样往往就没法套用一个模板快速配置完成。

2.3 前端站点的 CICD 现状

前端 CICD 流程说明

开发人员 push 代码到 Gitlab，测试人员通过 Jenkins 拉取最新的代码到 Jenkins 本地，然后通过 Jenkins 与服务器之间的传输管道，将要部署的文件更新到目标服务器，并触发 UI 自动化的 Job


完整的过程来看，也缺点内容

• 一个新的站点部署，Nginx 需要做一些配置初始化工作，比如域名、路径的配置
• 前端的配置文件是如何管理的
  

跟后端应用一样，前端的 PRE 和生产环境也是运维处理，所以当一个新的应用上线我们也需要发工单，描述具体操作，然后运维执行工单；配置文件一般不会变更，所以我们在 Jenkins 推送更新文件到目标服务器的时候，将配置文件做了过滤处理。后续需要变更通过工单执行

2.3 痛点你看到了吗

2.3.1 安全管控缺位

• 代码安全：CICD 的起点在 Gitlab 里面，所以大家都有 Gitlab 的账号，代码安全管控缺位
• 线上安全：线上项目部署也是通过 Gitlab 的 CICD 直接触发，审批流程缺失
  
  

2.3.2 管理成本

• 维护账号多：Gitlab账号、Jenkins 账号、Kubernetes 账号（本地和阿里云），每一个人员都需要上述账号，运维管理麻烦，大家每个平台维护自己的账号也麻烦
• 工单沟通：工单编写、沟通过程花费时间较多
• 代码规范：项目组多，微服务也多，代码框架各自发挥，无论是流程维护还是问题排查都增加了难度
  

三、研发管理平台（RDMS）应运而生

3.1 如何理解这个平台

!!#ff0000 工具链到平台的转变 !!

当前的 CICD 是对工具链进行了打通，但需要大家登录各个工具平台操作，我们希望对工具集进行功能整合，打造一个系统平台，并且将 CICD 的技术细节进行屏蔽，开发人员能够专心进行业务需求的开发，测试人员能够专注到需求测试任务中，而运维人员能够解放繁重的工单内容，投入到服务高可用的建设上！

3.2 业务功能设计

3.2.1 功能说明

• 项目管理：项目的创建和维护，默认提供了.netcore 的 API 和控制台，Java 的 API 和前端站点的应用初始化代码框架，开发人员开发新的应用直接根据应用类型选择对应的模板就可以在 Git 默认创建代码仓库和初始化框架代码，并自动生成应用的 http 和 https 的域名
• 构建记录：获取 Gitlab 的 pipeline，展示所有分支的构建记录信息，可以一键跳转到 Git 仓库
• 部署管理：部署构建的镜像到指定的环境，提供实时部署和定时部署功能
• 容器管理：提供容器的查看功能，可以看到容器的存活状态和容器实时日志
• 配置字段权限申请：针对 PRE 和生产环境查看配置，需要先走钉钉审批申请流程
• 配置信息：进行配置的维护，包括新增、编辑、删除，PRE 和生产环境操作需要钉钉流程审批
• 操作日志：针对应用的操作日志记录
• 用户设置：在使用 rdms 前，需要先将用户 git 仓库的 token 设置在 rdms 上，这样用户在 rdms 操作与 Gitlab 相关的业务才能正常使用
  

3.2.2 RDMS 几个核心页面的展示

首页-创建应用

构建记录

部署管理

容器管理

3.3 技术架构

对接系统的说明

• 通行证：RDMS 的目标用户是研发中心人员，这些人员在通行证中都有默认的账户信息，与通行证打通，可以直接登录使用
• GitlabAPI：目前 RDMS 的 CI 还是采用的 gitlab 的 ci 支撑，包括新应用在 rdms 的创建到 git 仓库的代码初始化等，都需要调用 gitlab 的 api 接口
• 钉钉 flow：安全管控的原因，PRE 和生产的任何操作都会触发钉钉审批流，所属项目的项目经理审批通过后才会获取到数据或者执行操作指令
• 福禄开放平台：提供了网关相关的功能和菜单、角色等维护功能，公司所有后端服务都需要入驻开放平台
• 蜂巢：公司的调度作业平台，rdms 的定时部署功能依赖该服务的支撑
• 运维工单系统：rdms 的 CD 流程没有直接与 Kubernetes 进行交互，而是通过运维的工单系统包装了运维底层的 shell 脚本层，然后提供给 rdms 相关的 api 接口，也是基于安全控制的考虑
• shell 脚本层：shell 脚本层会调用 Kubernetes 的 API 进行 Kubernetes 的相关操作（部署、配置更新、容器重启、日志查看等）；调用阿里云的 dns 解析接口，对应用的域名自动解析；调用 oss 的接口，进行前端站点文件目录的维护
  

3.4 后端应用的 DevOps 实现详解

举个栗子进行介绍

根据模板，创建一个应用

根据名称默认生成域名

初始化代码仓库，默认生成 Develop 分支

在 rdms 第一次部署到对应环境（开发、测试、生产等）时，会默认读取 appsettings.Development.json 的文件，并写入 kubernets 的 configmap

构建完成，进行部署

在 kubernets 生成 pod

通过域名访问接口文档

3.5 前端站点的 DevOps 实现详解

同样的，举个栗子介绍

首页-创建前端站点

根据名称生成域名

初始化代码仓库，默认生成 Develop 分支

配置文件，默认生成几套环境的配置文件，站点的配置维护就是维护这几个文件

部署应用

Kubernetes 的 nginx 容器内可以看到部署的文件，实际就是挂载的 oss 到该 pod 上

（转自福禄渣渣辉）

一、DevOps 的理解

DevOps 的概念在软件开发行业中逐渐流行起来。越来越多的团队希望实现产品的敏捷开发，DevOps 使一切成为可能。有了 DevOps ，团队可以定期发布代码、自动化部署、并将持续集成 / 持续交付作为发布过程的一部分。一句话概括就是提高生产力，快速交付。

二、引入 DevOps 的背景


2.1 福禄技术栈介绍

• 后端开发框架：基于C#的.netCore和Java的SpringCloud，少部分项目采用 Python 和 Go 开发
• 前端开发框架：vue、react
• 服务部署：前端站点基于 ECS 的 Nginx 部署 ，后端服务统一部署在 Kubernetes上
• 代码仓库：Gitlab
• 项目环境：目前有6套，开发、测试、压测、集成、PRE 和生产
  
  

2.2 后端服务的 CICD 现状

CICD 流程说明

每一次的代码 push，根据创建的分支，根据在 Gitlab 的 CICD 文件 gitlab.yml 定义构建步骤，触发 runner，从单元测试、通过 dockerfile 进行编译和生成镜像版本、将新镜像部署到 K8S 生成 pod，然后触发接口自动化测试任务的执行

!!#00ffff 好像缺了点什么 !!

• 初次部署应用到 Kubernetes 怎么做的？
• 服务的 configmap 在哪里维护的？
• 每个服务的 gitlab.yml 文件都不一样，如何维护的？
• 应用的域名解析怎么做？
  

目前有6套环境进行管理，其中开发、测试、集成、压测都是测试人员维护，预发布和生产运维人员维护；这也就要求每一个测试人员都必须对整个cicd流程和配置绝对掌握；所以当新人入职，需要掌握整个流程才能进入项目测试中，这是一个学习成本；


预发布和生产的 Kubernetes 只有运维能够操作，当有新的服务需要上线上述环境，或者 configmap 有变动，或者有时候排查问题需要查看容器日志，我们只能通过运维的工单系统描述作业操作，中间文字描述可能存在理解差异，沟通成本和时间成本很大；


有的新应用我们去设置 CICD 的相关文件，比如 dockerfile，我们发现应用的代码目录结构各种各样，这样往往就没法套用一个模板快速配置完成。

2.3 前端站点的 CICD 现状

前端 CICD 流程说明

开发人员 push 代码到 Gitlab，测试人员通过 Jenkins 拉取最新的代码到 Jenkins 本地，然后通过 Jenkins 与服务器之间的传输管道，将要部署的文件更新到目标服务器，并触发 UI 自动化的 Job


完整的过程来看，也缺点内容

• 一个新的站点部署，Nginx 需要做一些配置初始化工作，比如域名、路径的配置
• 前端的配置文件是如何管理的
  

跟后端应用一样，前端的 PRE 和生产环境也是运维处理，所以当一个新的应用上线我们也需要发工单，描述具体操作，然后运维执行工单；配置文件一般不会变更，所以我们在 Jenkins 推送更新文件到目标服务器的时候，将配置文件做了过滤处理。后续需要变更通过工单执行

2.3 痛点你看到了吗

2.3.1 安全管控缺位

• 代码安全：CICD 的起点在 Gitlab 里面，所以大家都有 Gitlab 的账号，代码安全管控缺位
• 线上安全：线上项目部署也是通过 Gitlab 的 CICD 直接触发，审批流程缺失
  
  

2.3.2 管理成本

• 维护账号多：Gitlab账号、Jenkins 账号、Kubernetes 账号（本地和阿里云），每一个人员都需要上述账号，运维管理麻烦，大家每个平台维护自己的账号也麻烦
• 工单沟通：工单编写、沟通过程花费时间较多
• 代码规范：项目组多，微服务也多，代码框架各自发挥，无论是流程维护还是问题排查都增加了难度
  

三、研发管理平台（RDMS）应运而生

3.1 如何理解这个平台

!!#ff0000 工具链到平台的转变 !!

当前的 CICD 是对工具链进行了打通，但需要大家登录各个工具平台操作，我们希望对工具集进行功能整合，打造一个系统平台，并且将 CICD 的技术细节进行屏蔽，开发人员能够专心进行业务需求的开发，测试人员能够专注到需求测试任务中，而运维人员能够解放繁重的工单内容，投入到服务高可用的建设上！

3.2 业务功能设计

3.2.1 功能说明

• 项目管理：项目的创建和维护，默认提供了.netcore 的 API 和控制台，Java 的 API 和前端站点的应用初始化代码框架，开发人员开发新的应用直接根据应用类型选择对应的模板就可以在 Git 默认创建代码仓库和初始化框架代码，并自动生成应用的 http 和 https 的域名
• 构建记录：获取 Gitlab 的 pipeline，展示所有分支的构建记录信息，可以一键跳转到 Git 仓库
• 部署管理：部署构建的镜像到指定的环境，提供实时部署和定时部署功能
• 容器管理：提供容器的查看功能，可以看到容器的存活状态和容器实时日志
• 配置字段权限申请：针对 PRE 和生产环境查看配置，需要先走钉钉审批申请流程
• 配置信息：进行配置的维护，包括新增、编辑、删除，PRE 和生产环境操作需要钉钉流程审批
• 操作日志：针对应用的操作日志记录
• 用户设置：在使用 rdms 前，需要先将用户 git 仓库的 token 设置在 rdms 上，这样用户在 rdms 操作与 Gitlab 相关的业务才能正常使用
  

3.2.2 RDMS 几个核心页面的展示

首页-创建应用

构建记录

部署管理

容器管理

3.3 技术架构

对接系统的说明

• 通行证：RDMS 的目标用户是研发中心人员，这些人员在通行证中都有默认的账户信息，与通行证打通，可以直接登录使用
• GitlabAPI：目前 RDMS 的 CI 还是采用的 gitlab 的 ci 支撑，包括新应用在 rdms 的创建到 git 仓库的代码初始化等，都需要调用 gitlab 的 api 接口
• 钉钉 flow：安全管控的原因，PRE 和生产的任何操作都会触发钉钉审批流，所属项目的项目经理审批通过后才会获取到数据或者执行操作指令
• 福禄开放平台：提供了网关相关的功能和菜单、角色等维护功能，公司所有后端服务都需要入驻开放平台
• 蜂巢：公司的调度作业平台，rdms 的定时部署功能依赖该服务的支撑
• 运维工单系统：rdms 的 CD 流程没有直接与 Kubernetes 进行交互，而是通过运维的工单系统包装了运维底层的 shell 脚本层，然后提供给 rdms 相关的 api 接口，也是基于安全控制的考虑
• shell 脚本层：shell 脚本层会调用 Kubernetes 的 API 进行 Kubernetes 的相关操作（部署、配置更新、容器重启、日志查看等）；调用阿里云的 dns 解析接口，对应用的域名自动解析；调用 oss 的接口，进行前端站点文件目录的维护
  

3.4 后端应用的 DevOps 实现详解

举个栗子进行介绍

根据模板，创建一个应用

根据名称默认生成域名

初始化代码仓库，默认生成 Develop 分支

在 rdms 第一次部署到对应环境（开发、测试、生产等）时，会默认读取 appsettings.Development.json 的文件，并写入 kubernets 的 configmap

构建完成，进行部署

在 kubernets 生成 pod

通过域名访问接口文档

3.5 前端站点的 DevOps 实现详解

同样的，举个栗子介绍

首页-创建前端站点

根据名称生成域名

初始化代码仓库，默认生成 Develop 分支

配置文件，默认生成几套环境的配置文件，站点的配置维护就是维护这几个文件

部署应用

Kubernetes 的 nginx 容器内可以看到部署的文件，实际就是挂载的 oss 到该 pod 上

（转自福禄渣渣辉）