⾃动化部署⽅案CICD
⾃动化部署⽅案
由于来来也的时间不久，可能对现有的部署情况不是很了解，以下是个⼈对POC⾃动化部署的设计⽅案。
⾃动化部署优点
降低成本，提⾼⽣产⼒，⾼可⽤，更可靠，性能优化
与gitlab持续集成的⽐较流⾏的有jenkins和gitlab-ci
Jenkins:
优点：编译服务和代码仓库分离，⽽且编译配置⽂件不需要在⼯程中配置，如果团队有开发、测试、配置管理员、运维、实施等完整的⼈员配置，那就采⽤jenkins，这样职责分明。jenkins依靠它丰富的插件，可以配置很多gitlab-ci不存在的功能，⽐如说看编译状况统计等。
缺点：配置相对复杂，维护成本较⾼等
gitlab-ci:
优点：完美和gitlab进⾏集成，gitlab-ci已经集成进gitlab服务器中，在使⽤的时候只需要安装配置gitlab-runner即可。 gitlab-runner基本上提供了⼀个可以进⾏编译的环境，负责从gitlab中拉取代码，根据⼯程中配置的l，执⾏相应的命令进⾏编译。
缺点：功能相对少⼀些，没有web页⾯查看等
总结：
个⼈觉得gitlab-ci更简单易⽤，如果有gitlab-ci达不到的要求，可以考虑使⽤jenkins。如果只部署poc相似的项⽬使⽤gitlab-ci可以满⾜需求。
⽅案⼀：gitlab-ce + gitlab-runner + docker
从左往右看，⾸先研发⼈员完成需求提交代码到 GitLab。GitLab 触发⼀次 Build，构建好服务，然后开始跑单元测试、集成测试。等待测试结果通过后，再由负责该项⽬的同事进⾏ CodeReview（可省略），灰度发布，正式部署到线上，⽀持shell部署和docker部署。
gitlab-ce 代码仓库管理与pipeline主控台
gitlab-runner 则是当pipeline启动时，会根据gitlab特有的l执⾏CI/CD
gitlab-ce 每个project会有⼀组⾃⼰的token，⽤以注册gitlab-runner
gitlab-runner注册时，可以选择执⾏⽅式(executor)，我们选择docker
gitlab-runner会另外开⼏个container来pull code与执⾏CI/CD，最后push到服务器上
持续集成的概念
主要步骤：
编写统⼀格式dockerfile，如果多应⽤关联编写docker-compose⽂件
编写统⼀pipeline，注册ci-runner等
上图是⼀个典型的 Pipeline，⼀共有 5 个阶段，Build，Test，Release， Staging， Production，每个阶段⾥都⾄少有⼀个 Job，Test 中有两个 Job。GitLab 会从左往右依次把任务给到 Runner 处理，如果中途有⼀个任务没有处理成功的话，整个 Pipeline 就会退出。这就是持续集成（CI）、持续发布（CD）的⼀个流程。
⽅案⼆：gitlab + jenkins + docker
开发者向⾃⼰的gitlab⽹站提交了代码
通过webhook让jenkins执⾏⾃动化构建过程
jenkins从git上拉取代码进⾏构建，如构建失败可配置邮件通知开发⼈员
jenkins在⾃动化构建脚本中调⽤docker命令将构建好的镜像push 私有镜像服务器
同时，jenkins也可以直接执⾏remote shell启动构建好的容器
服务端可以⼿动通过docker命令，从镜像仓库中⼼拉取镜像，进⾏⼿动
总结：个⼈意见如果只部署poc类似不是很复杂的应⽤可以选择⽅案⼀满⾜
原因：配置简单使⽤⽅便，可以花较少的时间完成⾃动化部署，节约成本，主要⽐较符合现状。但是如果以后需要区分环境部署，做⼀些类似sonar代码的健康检查等，可能不能很好的完成。
个⼈不成熟建议：随时时间变长，poc的项⽬也会越来越多，每个⼈的项⽬也会越来越多，可能需要⼀些资产的管理，例如CMDB，权限系统控制每个⼈操作的权限等，可以引⼊devops的概念，从急需的需求，慢慢做起。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。