0
点赞
收藏
分享

微信扫一扫

基于GitLab和docker的CI/CD系统

项目在演进过程中,团队有了一套较为完备的开发pipeline,这篇文章将讲述全栈系统中这个较为远离业务的环节 —— DevOps。

概念浅析

开宗明义,为了让大家更好的理解工作,我们先来一波名次的定义。

CI: Continuous Integration, 持续集成,指的是频繁的将代码集成到主干上,每次集成都通过自动化的构建(包括编译、发布、自动化测试)来验证;

CD: Continuous Deliver, 持续交付,指的是在代码集成,也就是分支代码合并到主干之后,能够被手动的触发,是否发布到生产环境,直接让用户体验最新代码;

CD: Continuous Deployment, 持续部署,和持续交付一样,只不过由手动触发变成自动发布,不再需要人为干扰。


如果想更了解CI/CD在业务层面的意思,可以阅读我的另一篇文章 精益开发,关于持续交付。

链路重点

项目开发经历了这样几个阶段:

  • 每个sprint的交付日都紧张兮兮,不同分支的代码都需要往master上合并,push、merge request、conflict、rebase、test,如此往复,单单集成开发的代码都需要一下午的时间;
  • 为了敢于合并,大胆上线,团队写足了自动化测试,完善了Gitlab的pipeline,随后在交付日就只需要半个小时到两个小时;
  • 随后发现部署新版本不方便,就用dockerfile来打包可运行的镜像,然后在交付日我们只需要点击部署就OK了,上线不过十分钟。

在奇迹般的变化背后,有这样几件事值得注意。

阶段一:紧张交付一下午

团队会尽可能在上午完成feature的开发,一般有三个分支需要合并,每个分支合并前后都需要手动运行测试,由于测试都依赖开发环境数据库而不能并发运行,上线之后需要持续监控半小时,很有可能hotfix改bug。

条件的艰苦,使每一次上线都是团队的大事件,也让我学会了代码部署的每一个小细节,更在之后的日子里让我感受到计算机对效率的提升之巨。

阶段二:轻松部署半小时

手动测试到自动测试

利用Gitlab的pipeline流程,在配置好runner后,就可以很轻松的运行自动化测试了。(在刚开始自动化时,我们选用了gitlab的webhook,webhook会在push和merge事件之后,触发一个钩子到特定的机器上运行测试,然后机器上会出现各种耦合,不建议使用)

完善测试

感受到自动化测试的便利之后,为了让团队对上线有信心,我们编写了大量的测试,方方面面测了个遍,终于不再惧怕重构,敢于上线。

testStage:
    stage: test
    image:
        name: image  # 使用合适的镜像,具备测试运行所需要的环境
    services:
        - name: https://hub.docker.com/_/mongo
          alias: mongo  # 使用官方的mongo镜像当作service,可以隔离集成测试的环境,让测试并发运行而不互相干扰
    script:
        - python -m unittest tests.test_a.TestA
    only:
        - develop  # 个性化设置,仅在develop分支上运行,让集成测试更快更方便

Advantages:

  • 并行的测试大大提高了集成的效率;
  • 每次提交都会运行的测试,杜绝了忘记测试的隐患;
  • 测试覆盖率很高,代码上线很放心;
  • yml文件中的注释都有一些痛的经历:
    • 在runner上准备python的虚拟环境非常困难,下文中将说到镜像的由来;
    • 为解决共享耦合的测试环境,我依次选用了mock mongo代码技术,local mongod本地mongo方案,和最终确定的mongo service阶段;
    • 测试的数量很大,只运行合适的测试可以有效加快效率;

Disadvantages:

  • 测试急剧增多,测试时间变得夸张的长,导致团队害怕push,害怕触发测试;
  • 测试不稳定,漫长的测试中一点出错,全部测试都必须重跑;

阶段三:持续交付真方便

在“痛苦”的自动化测试半小时之后,我们终于有了可交付的master代码库,然后就是重启服务,也就是重启一下机器,这很简单。但是,如果想要增加一台机器、删除一台机器就比较麻烦了。为了实现灰度发布,蓝绿发布,我紧接着开发了以docker为核心的部署系统。

deliverStage:
    stage: deliver
    script:
        # 把旧的镜像拉下来,如果是第一次运行(会拉不到就报错)就直接true跳过
        - docker pull ${OLD_IMAGE} || true
        # 获得sh文件的执行权限,以便运行镜像是容器有权限执行
        - chmod a+x *.sh
        # 打包可运行镜像
        - docker build --pull --cache-from ${OLD_IMAGE} -t ${NEW_IMAGE} -f Dockerfile .
        # 将镜像推送至远端仓库
        - docker push ${NEW_IMAGE}
    only:
        - master
    tags:
        - docker
# Dockerfile —— 打包可运行服务的dockerfile
# 使用这个缓存镜像作为源镜像
FROM ${my-image-repo-url}/gitlab-ci-cache/my-project:cache

# 用gitlab runner上的最新代码,直接覆盖,这样镜像就得到了最新代码
COPY . $APP_HOME
# 覆盖镜像中的run.sh,镜像将在启动最后运行此文件
COPY run.sh /run.sh

无论是重启还是新增,都只需要new一个新的容器,然后拉取可运行的镜像就可以了。

在学会了docker和gitlab CI/CD的流程之后,我重构了系统中的部分环节。

  1. 使用docker缓存python虚拟环境

docker系统的缓存层做的很棒,每执行一条新的语句就会生成一个新的镜像层,如果语句没有变化,则会直接使用已有的缓存层来继续执行下一条语句。

这样的话,如果我的Pipfile和Pipfile.lock(pipenv的依赖管理文件)没有发生变动,就直接使用现有的虚拟环境包文件,可以极大的优化pipeline的流程,极大的缩短pipeline的时长。

# Dockerfile.cache
# 环境缓存层的镜像dockerfile
FROM ${my-image-repo-url}/centos_py3:latest

ENV APP_HOME /home/my-project/

# 这里将最新的Pipfile复制到镜像中
COPY Pipfile $APP_HOME
COPY Pipfile.lock $APP_HOME

# 如果文件Pip依赖没有变更,这里的RUN语句将直接用镜像层,不会重新运行,可以节省大量的时间
RUN cd $APP_HOME && \
    pipenv install -d --skip-lock
  1. 提前打包镜像,使用待发布的镜像做测试

有了虚拟环境的缓存镜像,几乎消除了为自动化测试准备环境的时间,这样我就可以把测试分成很多小的runner job,就一举解决了测试运行时间过长、测试不稳定的问题。

cacheStage:
    stage: cache
    script:
        - do cache with centos_py3 image
    tags:
        - docker

buildStage:
    stage: build
    script:
        - do build with cache image
    tags:
        - docker

testStage-1:
    stage: test
    image:
        name: ${BUILD_IMAGE}
    services:
        - name: mongo
          alias: mongo
    script:
        - do test
    tags:
        - docker

testStage-2:
    stage: test
    image:
        name: ${BUILD_IMAGE}
    services:
        - name: mongo
          alias: mongo
    script:
        - do test
    tags:
        - docker

deliverStage:
    stage: deliver
    script:
        - push build image to prod environment
    tags:
        - docker

做个小结

今年写了几篇文章,个人感觉是更偏技术了,但是阅读者了了,甚至投稿审核都难以通过,还是比较令人受挫的。(可能我并非科班出身,无论是技术重点和写作重点,都需要更多的学习。)

这篇文章也只是一个方向的探索、总结和分享,具体要落地,需要有完备的容器化和docker技术,需要深入了解gitlab.yml和dockerfile的语法知识,需要团队的支持和时间的投入,当然结果也是显而易见的,会极大的优化团队开发效率,加快敏捷团队的迭代速度。

最后鼓励一下自己,哪怕看官不多,但是学习和总结的过程已经令人愉悦了,下面几期讲讲数据结构和基础算法的学习吧。

既然这可能是全栈的最后一篇文章,那么我也做个链接吧。

  • 如何转行做一名程序员? How to build?
  • 全栈的概念。 从零开始的异世界python全栈
  • 人生苦短,我选Python。 后端演进 —— python生态
  • 不会写前端的后端不是好架构。 前端浅析 —— Vue的妙用
  • 持续交付,你值得拥有。 运维基础 —— 派普兰实践

欢迎大家关注、点赞,也非常希望读者能说出自己关心的内容,共同进步,共同成长!

举报

相关推荐

0 条评论