自动化部署方案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的概念，从急需的需求，慢慢作起。