游戏运维 | DevOps之Gitlab-CICD实践篇

lyonger

2020-08-10346次浏览

1评论

3收藏

3点赞

分享

如果对文章技术或岗位感兴趣,欢迎投递校招岗位【运维研发工程师(SRE)】- 游戏综合方向

投递链接:https://game.campus.163.com/position-detail/53


关于作者

18年加入网易,先后负责过多个游戏产品的运维工作,多年运维生涯。负责小游戏CI/CD、事件处理平台开发、游戏Nomad运维模式探索、gitlab平台维护等工作。主要关注Linux性能优化、DevOps、云原生领域。

一、背景

随着公司项目使用gitlab越来越多,业务发布的次数越来越频繁,对于发布效率提出了更高的要求。从2012开始,Gitlab官方开始集成了Continuous Integration (CI) & Continuous Delivery (CD)功能。本文主要针对该功能的实践做一个分享。

二、基础介绍

GitLab CI/CD可以做很多事情,下图展现了GitLab CI/CD工作流程中整个的服务能力,而无需使用外部工具来交付软件。

在介绍实践方案之前,我们先简单的了解一下和Continuous Integration (CI) & Continuous Delivery (CD)功能有关的相关知识。

1.术语介绍

2.gitlab-pipeline介绍

一次pipeline其实相当于一次任务构建,里面可以包含多个流程,如安装依赖、运行测试、编译代码、部署测试服务器、部署生产服务器等。任何提交或者Merge Request的合并都可以触发pipeline,触发pipeline创建的方式主要有如下。如需详细了解,请查阅官网
(https://about.gitlab.com/blog/2019/07/12/guide-to-ci-cd-pipelines/)。

3.gitlab-stage介绍

Stage表示一个构建阶段,我们可以在一个Pipeline中定义多个Stage,这些Stage会有以下特点:

1.所有Stage会按照Stages参数里定义的顺序串行执行,即当一个Stage完成后,才会执行下一个Stage

2.默认情况下只有当所有Stage成功后,最终的pipeline构建任务才会成功。

3.默认情况下任何一个Stage失败,那么后面的Stage不会执行,该构建任务最终会失败。

pipelinestage的关系简单理解为下图。

4.gitlab-job介绍

job表示构建工作,即某个Stage里面执行的工作内容。我们可以在同一个Stage里面定义多个Job,这些Jobs会有以下特点:

1.相同Stage中的Job会并行执行。

2.相同Stage中的Job都执行成功时,该Stage才会成功。

3.如果任何一个Job失败,那么该Stage失败,即该构建任务失败。

stagejobs的关系简单理解为下图。

4.我们以某个pipeline为例解释pipelinestagejob的含义,具体请看下图。

5.gitlab-ci-yaml介绍

pipeline执行的内容使用ymal语言进行描述,默认文件名为.gitlab-ci.yml,该文件默认放在仓库的根目录下即可生效。关于ymal语言的使用可点击这里。
(https://www.ruanyifeng.com/blog/2016/07/yaml.html)

下表对gitlab 11.11.4版本中.gitlab-ci.yml文件里常用的关键字参数进行简单说明。如需深入了解可查阅官方文档(https://docs.gitlab.com/ee/ci/yaml/)。

6.gitlab-runner介绍

.gitlab-ci.yml文件里的内容由谁来执行呢,答案就是gitlab-runnter,一般gitlab-runner会和gitlab所在服务器进行隔离,因为一个任务的构建,往往会执行编译、测试、发布的过程,这个过程会大量消耗系统资源。gitlab-runner几乎可以安装在任何机器上。下面介绍gitlab-runner的官方仓库源安装方式。关于gitlab-runner的其他安装方式请查阅官方文档(https://docs.gitlab.com/runner/install/)。

添加仓库源

安装指定的gitlab-runner版本,比如这里安装11.11.4版本。

点击左侧栏Settings->CI/CD->Runners->Collapse获取runner的token,如下图。

注册gitlab-runner到gitlab实例。

三、实践方案

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

1.持续集成CI

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

2.容器镜像集成

下面为集成系统层docker镜像Dockerfile的主要内容:

那么怎么把docker镜像推送到docker仓库呢?可在.gitlab-ci.yml文件中进行描述,把build好的镜像推送到gitlab内置的registry中。关于gitlab内置的registry部署可参考官网说明(https://docs.gitlab.com/ce/user/packages/container_registry/index.html)。下面为打包并上传容器镜像stage的主要内容。

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

3.持续交付CD

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

4.发布容器

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

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

四、发布流程

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

1.常规发布

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

2.热更发布

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

五、效果展示

1.常规发布下的pipeline

2.热更发布下的pipeline

资料参考

  • https://about.gitlab.com/product/continuous-integration

  • https://docs.gitlab.com/ce/ci/introduction/index.html


如果对文章技术或岗位感兴趣,欢迎投递校招岗位【运维研发工程师(SRE)】- 游戏综合方向

投递链接:https://game.campus.163.com/position-detail/53

评论 (1)

0/1000
网易游学APP
为热爱赋能
扫描二维码下载APP