使用gitlab的container_regiter和gitlab_runner完成cicd中的环境构建、单元测试和服务发布

背景

持续集成和持续交付,在比较大的软件中，会不断的对产品进行优化，我理解的的集成就是不断的往一套体系中添加新的东西。拿个人计算机的发展来讲，刚开始只有一个主机和屏幕，后来有了音响、摄像头等。持续集成就是不断地将音响、摄像头等往计算机这个体系中存放。持续交付，不断开发新功能，或者不断的修复了bug，最终要让客户看看，因为最终由他们来掏钱。交付的方式有很多种，我看见客户，双手把产品交给客户，客户告诉我地址，我发快递给他。这两种属于传统行业的交付方式，当然还有很多种交付方式。软件这边交付会省去这些，软件开发完成了，通过互联网就可以直接交付给客户，因此客户可以快速的看到结果再反馈问题给供应商。持续交付就是可以快速的响应这种需求，且提供给客户。这是我认识的CICD，在这个领域，各家都有各家的实现，没有一个普适的解决方案，大体的思路是一致的。

名词解释

CICD

持续集成和持续交付和持续部署

GitLabRunner(gr)

gr是一个应用程序，但看起来它更像一个服务。拿到gitlab仓库的key，将仓库注册在gr中，称之为项目中的runners。

任务描述

python语言程序，dockerfile构建程序运行环境，pytest单元测试，tornado提供web服务。

开始之前

之前

一次vue中，我的代码在开发机中，跑代码的服务器在21gpu上，用容器映射了一个目录。开发机commit代码，push代码，21gpu上的那个目录也是代码，它只做pull操作，node.js在容器中run着，所以一直持续的动作就是commit->push->pull，因此想省了21gpu中pull的动作，看了gr，就尝试去做了起来，搞了一天失败了。

现在

brand项目中要对代码进行测试，期望在gitlab repo的pipeline中看到测试的结果，这样对管理者来说是一件便捷的事情，可以省去环境构建等操作，其本质是加快了测试的进度。实现的原理就是，gitlab repo与gr的通信，发一些请求，返回过来一些数据，gitlab repo的pipeline根据数据进行展示。

本质

尝试解释这件事情的本质，代码和环境的传输表现。开发机commit->push到gitlab服务器，gitalb服务器通知gr来执行任务，将代码交给gr服务器，gr由代码有环境，完成打包，测试和发布的工作。

SOP

这里采用了时间顺序，以第一次构建、测试和发布的顺序来介绍，dev代表开发工程师、ops代表运维工程师、cicd不知道是什么工程师来做。

dev

server_code

下面是一个使用tornado实现的一个简单的web服务的接口，提供了get和post两种请求方式，返回的都是一个字符串。这其中会包含一些包的信息，由于太过简单，我就不在提供requirements.txt的说明。

import tornado.ioloop
import tor