Gitlab-CICD实践篇（下）

2021-06-07 17:45:32 浏览数 (1)

三.实践方案

该实践方案主要介绍微服务项目使用gitlab自带的GitLab Continuous Integration (CI) & Continuous Delivery (CD)功能，在gitlab提供的runner里面进行打包、测试、发布。

持续集成主要是代码编译和打包的过程，一般最终会集成一个适合业务场景的系统层docker镜像。下面为集成系统层docker镜像Dockerfile的主要内容：

  1. FROM debian:stretch
  2. # 准备软件包文件
  3. ADD soft/ /data/soft/
  4. # 安装基本软件
  5. RUN DEBIAN_FRONTEND=noninteractive apt-get update
  6. && DEBIAN_FRONTEND=noninteractive apt-get install -y vim htop wget dnsutils dmidecode ipmitool pciutils perl
  7. rsync screen less sysstat at stress tcpdump lsof curl telnet ntp rsyslog sudo locales logrotate cron supervisor
  8. numactl openssh-server-x509 openssh-client iptables gawk filebeat mongodb3.4.16 graphviz
  9. && apt-get clean
  10. # 安装开发环境
  11. RUN DEBIAN_FRONTEND=noninteractive apt-get update
  12. && apt-get install -y python python-pip gcc g build-essential python-dev python-setuptools python-smbus
  13. build-essential libncursesw5-dev libgdbm-dev libc6-dev zlib1g-dev libsqlite3-dev tk-dev libssl-dev openssl
  14. libffi-dev cmake automake python-setuptools libtcmalloc-minimal4 sockstat strace gdb graphviz
  15. && apt-get clean
  16. # 安装python3.7
  17. RUN cd /data/soft/ && tar xf /data/soft/Python-3.7.0.tgz && cd Python-3.7.0 && ./configure --enable-optimizations --with-ssl-default-suites=openssl --enable-shared
  18. && make && make install && cp libpython3.7m.so.1.0 /lib64/ && ldconfig && rm -rf /data/soft
  19. # 业务启动脚本
  20. COPY entrypoint.sh /sbin/entrypoint.sh
  21. ENTRYPOINT ["/bin/bash", "-x", "/sbin/entrypoint.sh"]

那么怎么把docker镜像推送到docker仓库呢？可在.gitlab-ci.yml文件中进行描述，把build好的镜像推送到gitlab内置的registry中。关于gitlab内置的registry部署可参考官网说明

  1. build_push:
  2. only:
  3. refs:
  4. - tags
  5. variables:
  6. - $CI_COMMIT_REF_NAME =~ /^rel_[0-9].*$/ # 规定必须通过打tag且名字为rel_xxx的格式才触发pipeline。
  7. tags:
  8. - docker
  9. stage: ex_build
  10. script:
  11. # build docker image
  12. - docker login $DOCKER_REGISTRY
  13. - echo "$ docker pull $BUILD_IMAGE"
  14. - docker pull $BUILD_IMAGE # 防止$BUILD_IMAGE更新后，runner会缓存，故在build之前先pull一次。
  15. - echo "$ docker build -t $image"
  16. - docker build --no-cache -t $image .
  17. - echo "$ docker tag $image $latest"
  18. - docker tag $image $latest
  19. # push docker image
  20. - echo "$ docker push $image"
  21. - docker push $image
  22. - echo "$ docker push $latest"
  23. - docker push $latest
  24. - docker logout $DOCKER_REGISTRY
  25. when: manual # 手工确认
  26. allow_failure: false
  27. environment:
  28. name: build

gitlab-runner中对应job的部分日志截图如下：

持续交付CD 持续交付或者持续发布的方式其实有很多种，理论上只要服务方提供了发布接口，你就可以封装在.gitlab-ci.yml文件里使用gitlab-runner调用api进行自动发布。下面主要介绍容器的发布方式。

发布容器时主要调用自建容器服务的发布接口，其中主要的stage内容如下：

  1. deployment_production:
  2. only:
  3. refs:
  4. - tags
  5. variables:
  6. - $CI_COMMIT_REF_NAME =~ /^exrel_[0-9].*$/
  7. tags:
  8. - docker
  9. stage: ex_deployment_production
  10. script:
  11. # 更新当前环境下指定渠道
  12. - deploy_service ${CI_ENVIRONMENT_NAME} "$image" #image为持续集成build后push到registry的docker镜像。deploy_service是封装容器发布过程的函数。该函数主要是根据传入的image，请求k8s的kube接口进行微服务发布。
  13. when: manual
  14. environment:
  15. name: production

gitlab-runner中发布game微服务的job日志截图如下。

发布流程 微服务的发布流程主要分2种类型：常规发布和热更发布。常规发布需要重建容器，热更发布无需重建容器。

下面为常规发布场景下整体的发布流程。

热更发布 核心思路是把需要热更的内容put到etcd集群，服务端集群自动获取内容进行热更，下面为热更发布场景下整体的发布流程。

四.效果展示

常规发布下的pipeline

热更发布下的pipeline

容器镜像服务 git apt-get python http

0 人点赞