Gitlab
Gitlab入门系列
Gitlab字典
Gitlab原理说明
Gitlab安装部署
centos部署代码仓库gitlab
Gitlab服务维护
Gitlab日常维护
gitlab 备份&恢复
gitlab升级
Gitlab系统配置
Gitlab使用配置
Gitlab用户在组中有五种权限
gitlab的分支保护配置
Git忽略提交规则 .gitignore文件
Gitlab新闻
Gitlab使用案例
gitlab配置免密拉取推送
Gitlab更改项目间的fork提交关系
gitlab官方api使用
python使用gitlab-api
gitlab 集成openldap
Gitlab-CICD实践篇
Gitlab Flow到容器
本文档使用 MrDoc 发布
-
+
home page
Gitlab-CICD实践篇
## 一.背景 随着公司项目使用gitlab越来越多,业务发布的次数越来越频繁,对于发布效率提出了更高的要求。从2012开始,Gitlab官方开始集成了Continuous Integration (CI) & Continuous Delivery (CD)功能。本文主要针对该功能的实践做一个分享。 GitLab CI/CD可以做很多事情,下图展现了GitLab CI/CD工作流程中整个的服务能力,而无需使用外部工具来交付软件。  在介绍实践方案之前,我们先简单的了解一下和Continuous Integration (CI) & Continuous Delivery (CD)功能有关的相关知识。 ## 二.基础知识 **术语介绍**  **gitlab-pipeline** 一次pipeline其实相当于一次任务构建,里面可以包含多个流程,如安装依赖、运行测试、编译代码、部署测试服务器、部署生产服务器等。任何提交或者Merge Request的合并都可以触发pipeline,触发pipeline创建的方式主要有如下。如需详细了解,请查阅官网  **gitlab-stage** Stage表示一个构建阶段,我们可以在一个Pipeline中定义多个Stage,这些Stage会有以下特点: 所有Stage会按照Stages参数里定义的顺序串行执行,即当一个Stage完成后,才会执行下一个Stage。 默认情况下只有当所有Stage成功后,最终的pipeline构建任务才会成功。 默认情况下任何一个Stage失败,那么后面的Stage不会执行,该构建任务最终会失败。 pipeline和stage的关系简单理解为下图。  **gitlab-job** job表示构建工作,即某个Stage里面执行的工作内容。我们可以在同一个Stage里面定义多个Job,这些Jobs会有以下特点: 相同Stage中的Job会并行执行。 相同Stage中的Job都执行成功时,该Stage才会成功。 如果任何一个Job失败,那么该Stage失败,即该构建任务失败。 stage和jobs的关系简单理解为下图。  我们以某个pipeline为例解释pipeline、stage、job的含义,具体请看下图。  **gitlab-ci-yaml** pipeline执行的内容使用ymal语言进行描述,默认文件名为.gitlab-ci.yml,该文件默认放在仓库的根目录下即可生效。 下表对gitlab 11.11.4版本中.gitlab-ci.yml文件里常用的关键字参数进行简单说明。    **gitlab-runner** .gitlab-ci.yml文件里的内容由谁来执行呢,答案就是gitlab-runnter,一般gitlab-runner会和gitlab所在服务器进行隔离,因为一个任务的构建,往往会执行编译、测试、发布的过程,这个过程会大量消耗系统资源。gitlab-runner几乎可以安装在任何机器上。下面介绍gitlab-runner的官方仓库源安装方式。关于gitlab-runner的其他安装方式请查阅官方文档(https://docs.gitlab.com/runner/install/)。 1.添加仓库源 ```python # For Debian/Ubuntu/Mint curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash # For RHEL/CentOS/Fedora curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash ``` 2.安装指定的gitlab-runner版本,比如这里安装11.11.4版本。 ```python# for DEB based systems sudo apt-get install gitlab-runner=11.11.4 # for RPM based systems sudo yum install gitlab-runner-11.11.4 ``` 3.点击左侧栏Settings->CI/CD->Runners->Collapse获取runner的token,如下图。  4.注册gitlab-runner到gitlab实例。  ## 三.实践方案 该实践方案主要介绍微服务项目使用gitlab自带的GitLab Continuous Integration (CI) & Continuous Delivery (CD)功能,在gitlab提供的runner里面进行打包、测试、发布。 持续集成主要是代码编译和打包的过程,一般最终会集成一个适合业务场景的系统层docker镜像。下面为集成系统层docker镜像Dockerfile的主要内容: ```python FROM debian:stretch # 准备软件包文件 ADD soft/ /data/soft/ # 安装基本软件 RUN DEBIAN_FRONTEND=noninteractive apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get install -y vim htop wget dnsutils dmidecode ipmitool pciutils perl \ rsync screen less sysstat at stress tcpdump lsof curl telnet ntp rsyslog sudo locales logrotate cron supervisor \ numactl openssh-server-x509 openssh-client iptables gawk filebeat mongodb3.4.16 graphviz \ && apt-get clean # 安装开发环境 RUN DEBIAN_FRONTEND=noninteractive apt-get update \ && apt-get install -y python python-pip gcc g++ build-essential python-dev python-setuptools python-smbus \ build-essential libncursesw5-dev libgdbm-dev libc6-dev zlib1g-dev libsqlite3-dev tk-dev libssl-dev openssl \ libffi-dev cmake automake python-setuptools libtcmalloc-minimal4 sockstat strace gdb graphviz \ && apt-get clean # 安装python3.7 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 \ && make && make install && cp libpython3.7m.so.1.0 /lib64/ && ldconfig && rm -rf /data/soft # 业务启动脚本 COPY entrypoint.sh /sbin/entrypoint.sh ENTRYPOINT ["/bin/bash", "-x", "/sbin/entrypoint.sh"] ``` 那么怎么把docker镜像推送到docker仓库呢?可在.gitlab-ci.yml文件中进行描述,把build好的镜像推送到gitlab内置的registry中。关于gitlab内置的registry部署可参考官网说明 (https://docs.gitlab.com/ce/user/packages/container_registry/index.html)。下面为打包并上传容器镜像stage的主要内容。 ```python build_push: only: refs: - tags variables: - $CI_COMMIT_REF_NAME =~ /^rel_[0-9].*$/ # 规定必须通过打tag且名字为rel_xxx的格式才触发pipeline。 tags: - docker stage: ex_build script: # build docker image - docker login $DOCKER_REGISTRY - echo "$ docker pull $BUILD_IMAGE" - docker pull $BUILD_IMAGE # 防止$BUILD_IMAGE更新后,runner会缓存,故在build之前先pull一次。 - echo "$ docker build -t $image" - docker build --no-cache -t $image . - echo "$ docker tag $image $latest" - docker tag $image $latest # push docker image - echo "$ docker push $image" - docker push $image - echo "$ docker push $latest" - docker push $latest - docker logout $DOCKER_REGISTRY when: manual # 手工确认 allow_failure: false environment: name: build ``` gitlab-runner中对应job的部分日志截图如下:  持续交付CD 持续交付或者持续发布的方式其实有很多种,理论上只要服务方提供了发布接口,你就可以封装在.gitlab-ci.yml文件里使用gitlab-runner调用api进行自动发布。下面主要介绍容器的发布方式。 发布容器时主要调用自建容器服务的发布接口,其中主要的stage内容如下: ```python deployment_production: only: refs: - tags variables: - $CI_COMMIT_REF_NAME =~ /^exrel_[0-9].*$/ tags: - docker stage: ex_deployment_production script: # 更新当前环境下指定渠道 - deploy_service ${CI_ENVIRONMENT_NAME} "$image" #image为持续集成build后push到registry的docker镜像。deploy_service是封装容器发布过程的函数。该函数主要是根据传入的image,请求k8s的kube接口进行微服务发布。 when: manual environment: name: production ``` gitlab-runner中发布game微服务的job日志截图如下。  发布流程 微服务的发布流程主要分2种类型:常规发布和热更发布。常规发布需要重建容器,热更发布无需重建容器。 下面为常规发布场景下整体的发布流程。  热更发布 核心思路是把需要热更的内容put到etcd集群,服务端集群自动获取内容进行热更,下面为热更发布场景下整体的发布流程。  ## 四.效果展示 常规发布下的pipeline  热更发布下的pipeline 
日行一善
April 23, 2021, 1:27 p.m.
Share documents
Collection documents
Last
Next
Scan wechat
Copy link
Scan your mobile phone to share
Copy link
关于 MrDoc
觅思文档MrDoc
是
州的先生
开发并开源的在线文档系统,其适合作为个人和小型团队的云笔记、文档和知识库管理工具。
如果觅思文档给你或你的团队带来了帮助,欢迎对作者进行一些打赏捐助,这将有力支持作者持续投入精力更新和维护觅思文档,感谢你的捐助!
>>>捐助鸣谢列表
微信
支付宝
QQ
PayPal
QQ粉丝交流群:882382311
Markdown文件
share
link
type
password
Update password