自动化部署方案CICD

自动化部署方案

 

由于来来也的时间不久，可能对现有的部署情况不是很了解，以下是个人对POC自动化部署的设计方案。

自动化部署优点

降低成本，提高生产力，高可用，更可靠，性能优化

 

与gitlab持续集成的比较流行的有jenkins和gitlab-ci

Jenkins:

优点：编译服务和代码仓库分离，而且编译配置文件不需要在工程中配置，如果团队有开发、测试、配置管理员、运维、实施等完整的人员配置，那就采用jenkins，这样职责分明。jenkins依靠它丰富的插件，可以配置很多gitlab-ci不存在的功能，比如说看编译状况统计等。

缺点：配置相对复杂，维护成本较高等

gitlab-ci:

优点：完美和gitlab进行集成，gitlab-ci已经集成进gitlab服务器中，在使用的时候只需要安装配置gitlab-runner即可。 gitlab-runner基本上提供了一个可以进行编译的环境，负责从gitlab中拉取代码，根据工程中配置的gitlab-ci.yml，执行相应的命令进行编译。

缺点：功能相对少一些，没有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特有的gitlab-ci.yml执行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的概念，从急需的需求，慢慢做起。