幺幺星光 發表於 2020-6-8 19:07:00

我们是如何做DevOps的?

<p><img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/%E5%A4%B4%E9%83%A81.png" alt="头部1" loading="lazy"></p>
<h3 id="一devops的理解">一、DevOps的理解</h3>
<blockquote>
<p>DevOps的概念理解</p>
</blockquote>
<p>DevOps 的概念在软件开发行业中逐渐流行起来。越来越多的团队希望实现产品的敏捷开发,DevOps 使一切成为可能。有了 DevOps ,团队可以定期发布代码、自动化部署、并将持续集成 / 持续交付作为发布过程的一部分。<br>
一句话概括就是提高生产力,快速交付!</p>
<h3 id="二引入devops的背景">二、引入DevOps的背景</h3>
<h4 id="21-福禄技术栈介绍">2.1 福禄技术栈介绍</h4>
<ul>
<li>
<p>后端开发框架:基于C#的.netCore和Java的SpringCloud,少部分项目采用python和go开发</p>
</li>
<li>
<p>前端开发框架:vue、react</p>
</li>
<li>
<p>服务部署:前端站点基于ECS的nginx部署 ,后端服务统一部署在kubernetes上</p>
</li>
<li>
<p>代码仓库:gitlab</p>
</li>
<li>
<p>项目环境:目前有6套,开发、测试、压测、集成、PRE和生产</p>
</li>
</ul>
<h4 id="22-后端服务的cicd现状">2.2 后端服务的CICD现状</h4>
<p><img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608102906.png" alt="20200608102906" loading="lazy"><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;福禄后端CICD流程</p>
<p>CICD 流程说明</p>
<p>每一次的代码push,根据创建的分支,根据在gitlab的CICD文件gitlab.yml定义构建步骤,触发runner,从单元测试、通过dockerfile进行编译和生成镜像版本、将新镜像部署到K8S生成pod,然后触发接口自动化测试任务的执行</p>
<p>!!#00ffff<strong>好像缺了点什么</strong> !!</p>
<ul>
<li>
<p>初次部署应用到kubernetes怎么做的?</p>
</li>
<li>
<p>服务的configmap在哪里维护的?</p>
</li>
<li>
<p>每个服务的gitlab.yml文件都不一样,如何维护的?</p>
</li>
<li>
<p>应用的域名解析怎么做?</p>
</li>
</ul>
<p>目前有6套环境进行管理,其中开发、测试、集成、压测都是测试人员维护,预发布和生产运维人员维护;这也就要求每一个测试人员都必须对整个cicd流程和配置绝对掌握;所以当新人入职,需要掌握整个流程才能进入项目测试中,这是一个学习成本;</p>
<p>预发布和生产的kubernetes只有运维能够操作,当有新的服务需要上线上述环境,或者configmap有变动,或者有时候排查问题需要查看容器日志,我们只能通过运维的工单系统描述作业操作,中间文字描述可能存在理解差异,沟通成本和时间成本很大;</p>
<p>有的新应用我们去设置cicd的相关文件,比如dockerfile,我们发现应用的代码目录结构各种各样,这样往往就没法套用一个模板快速配置完成</p>
<h4 id="23-前端站点的cicd现状">2.3 前端站点的CICD现状</h4>
<p><img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103000.png" alt="20200608103000" loading="lazy"></p>
<blockquote>
<p>前端CICD流程说明</p>
</blockquote>
<p>开发人员push代码到gitlab,测试人员通过jenkins拉取最新的代码到jenkins本地,然后通过jenkins与服务器之间的传输管道,将要部署的文件更新到目标服务器,并触发UI自动化的job</p>
<p>完整的过程来看,也缺点内容</p>
<ul>
<li>一个新的站点部署,nginx需要做一些配置初始化工作,比如域名、路径的配置</li>
<li>前端的配置文件是如何管理的</li>
</ul>
<p>跟后端应用一样,前端的PRE和生产环境也是运维处理,所以当一个新的应用上线我们也需要发工单,描述具体操作,然后运维执行工单;配置文件一般不会变更,所以我们在jenkins推送更新文件到目标服务器的时候,将配置文件做了过滤处理。后续需要变更通过工单执行</p>
<h4 id="23-痛点你看到了吗">2.3 痛点你看到了吗</h4>
<h5 id="231--安全管控缺位">2.3.1安全管控缺位</h5>
<ul>
<li>代码安全:CICD的起点在gitlab里面,所以大家都有gitlab的账号,代码安全管控缺位</li>
<li>线上安全:线上项目部署也是通过gitlab的cicd直接触发,审批流程缺失</li>
</ul>
<h5 id="232--管理成本">2.3.2管理成本</h5>
<ul>
<li>维护账号多:gitlab账号、jenkins账号、kubernetes账号(本地和阿里云),每一个人员都需要上述账号,运维管理麻烦,大家每个平台维护自己的账号也麻烦</li>
<li>工单沟通:工单编写、沟通过程花费时间较多</li>
<li>代码规范:项目组多,微服务也多,代码框架各自发挥,无论是流程维护还是问题排查都增加了难度</li>
</ul>
<h3 id="三研发管理平台rdms应运而生">三、研发管理平台(RDMS)应运而生</h3>
<h4 id="31-如何理解这个平台">3.1 如何理解这个平台</h4>
<blockquote>
<p>!!#ff0000<strong>工具链到平台的转变</strong> !!</p>
</blockquote>
<p>当前的cicd是对工具链进行了打通,但需要大家登录各个工具平台操作,我们希望对工具集进行功能整合,打造一个系统平台,并且将CICD的技术细节进行屏蔽,开发人员能够专心进行业务需求的开发,测试人员能够专注到需求测试任务中,而运维人员能够解放繁重的工单内容,投入到服务高可用的建设上!</p>
<h4 id="32-业务功能设计">3.2 业务功能设计</h4>
<p><img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103031.png" alt="20200608103031" loading="lazy"><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;福禄研发管理平台功能结构图</p>
<h5 id="321-功能说明">3.2.1 功能说明</h5>
<ul>
<li>项目管理:项目的创建和维护,默认提供了.netcore的api和控制台,java的api和前端站点的应用初始化代码框架,开发人员开发新的应用直接根据应用类型选择对应的模板就可以在git默认创建代码仓库和初始化框架代码,并自动生成应用的http和https的域名</li>
<li>构建记录:获取gitlab的pipeline,展示所有分支的构建记录信息,可以一键跳转到git仓库</li>
<li>部署管理:部署构建的镜像到指定的环境,提供实时部署和定时部署功能</li>
<li>容器管理:提供容器的查看功能,可以看到容器的存活状态和容器实时日志</li>
<li>配置字段权限申请:针对PRE和生产环境查看配置,需要先走钉钉审批申请流程</li>
<li>配置信息:进行配置的维护,包括新增、编辑、删除,PRE和生产环境操作需要钉钉流程审批</li>
<li>操作日志:针对应用的操作日志记录</li>
<li>用户设置:在使用rdms前,需要先将用户git仓库的token设置在rdms上,这样用户在rdms操作与gitlab相关的业务才能正常使用</li>
</ul>
<h5 id="322-rdms几个核心页面的展示">3.2.2 RDMS几个核心页面的展示</h5>
<p>首页-创建应用<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103107.png" alt="20200608103107" loading="lazy"></p>
<p>构建记录<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103152.png" alt="20200608103152" loading="lazy"></p>
<p>部署管理<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103224.png" alt="20200608103224" loading="lazy"></p>
<p>容器管理<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103254.png" alt="20200608103254" loading="lazy"></p>
<h4 id="33-技术架构">3.3 技术架构</h4>
<p><img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103316.png" alt="20200608103316" loading="lazy"></p>
<p>对接系统的说明</p>
<ul>
<li>通行证:RDMS的目标用户是研发中心人员,这些人员在通行证中都有默认的账户信息,与通行证打通,可以直接登录使用</li>
<li>GitlabAPI:目前RDMS的CI还是采用的gitlab的ci支撑,包括新应用在rdms的创建到git仓库的代码初始化等,都需要调用gitlab的api接口</li>
<li>钉钉flow:安全管控的原因,PRE和生产的任何操作都会触发钉钉审批流,所属项目的项目经理审批通过后才会获取到数据或者执行操作指令</li>
<li>福禄开放平台:提供了网关相关的功能和菜单、角色等维护功能,公司所有后端服务都需要入驻开放平台</li>
<li>蜂巢:公司的调度作业平台,rdms的定时部署功能依赖该服务的支撑</li>
<li>运维工单系统:rdms的CD流程没有直接与kubernets进行交互,而是通过运维的工单系统包装了运维底层的shell脚本层,然后提供给rdms相关的api接口,也是基于安全控制的考虑</li>
<li>shell脚本层:shell脚本层会调用kubernetes的api进行kubernetes的相关操作(部署、配置更新、容器重启、日志查看等);调用阿里云的dns解析接口,对应用的域名自动解析;调用oss的接口,进行前端站点文件目录的维护</li>
</ul>
<h4 id="34-后端应用的devops实现详解">3.4 后端应用的devops实现详解</h4>
<p><img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103348.png" alt="20200608103348" loading="lazy"></p>
<blockquote>
<p>举个栗子进行介绍</p>
</blockquote>
<p>根据模板,创建一个应用<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103503.png" alt="20200608103503" loading="lazy"></p>
<p>根据名称默认生成域名<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103531.png" alt="20200608103531" loading="lazy"></p>
<p>初始化代码仓库,默认生成develop分支<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103601.png" alt="20200608103601" loading="lazy"><br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103707.png" alt="20200608103707" loading="lazy"><br>
在rdms第一次部署到对应环境(开发、测试、生产等)时,会默认读取appsettings.Development.json的文件,并写入kubernets的configmap</p>
<p>构建完成,进行部署<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103749.png" alt="20200608103749" loading="lazy"></p>
<p>在kubernets生成pod<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103815.png" alt="20200608103815" loading="lazy"></p>
<p>通过域名访问接口文档<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103903.png" alt="20200608103903" loading="lazy"></p>
<h4 id="35-前端站点的devops实现详解">3.5 前端站点的devops实现详解</h4>
<p><img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608103933.png" alt="20200608103933" loading="lazy"></p>
<blockquote>
<p>同样的,举个栗子介绍</p>
</blockquote>
<p>首页-创建前端站点<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608104011.png" alt="20200608104011" loading="lazy"></p>
<p>根据名称生成域名<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608104037.png" alt="20200608104037" loading="lazy"></p>
<p>初始化代码仓库,默认生成develop分支<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608104106.png" alt="20200608104106" loading="lazy"></p>
<p>配置文件,默认生成几套环境的配置文件,站点的配置维护就是维护这几个文件<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608104128.png" alt="20200608104128" loading="lazy"><br>
部署应用<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608104148.png" alt="20200608104148" loading="lazy"></p>
<p>kubernetes的nginx容器内可以看到部署的文件,实际就是挂载的oss到该pod上<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/20200608104203.png" alt="20200608104203" loading="lazy"></p>
<h3 id="四展望">四、展望</h3>
<p>目前RDMS投产一个月左右,我们希望能将devops理念在这个系统上进行持续的优化和实践,包括研发中心小伙伴也很踊跃参与共建,提出了很多好的方向和建议</p>
<ul>
<li>完善devops链条功能:通过字面来看有dev、ops两部分,我们后期需要加入test的比重,比如在CI部分,引入静态代码扫描、单测覆盖率;在CD部分集成我们的自动化测、性能测试</li>
<li>工具平台:RDMS的初衷是整合,针对研发中心经常使用的工具或者有相关工具化的需求,我们可以整合到rdms或者在RDMS上进行开发<br>
<img src="https://fulu-item11-zjk.oss-cn-zhangjiakou.aliyuncs.com/images/%E7%A6%8F%E5%B0%8F%E9%BE%99.png" alt="福小龙" loading="lazy"></li>
</ul><br><br>
来源:https://www.cnblogs.com/longxianghui/p/13067656.html
頁: [1]
查看完整版本: 我们是如何做DevOps的?