===========================
CI介绍
CI：持续集成
我们通常使用CI来做一些自动化工作，比如程序的打包，单元测试，部署等，这种构建方式避免了打包环境差异引起的错误，提高了工作效率。Gitlab-CI是Gitlab官方提供的持续集成服务，我们可以在仓库的根目录下新建.gitlab-ci.yml文件，自己定义持续集成流程模板，并且在Gitlab中配置runner，在之后的每次提交合并中将会触发构建，并且可以通过Gitlab的hook, 在代码提交的各个环节自动地完成一系列的构建工作，总之对于一些非复杂性的集成需求，都是可以满足的
CI：持续集成 必要性
机械的事情让机器做。一个开发团队，没有CI/CD，我想可能是这样子的：无法管理代码多人多地协作（git repository也是CI的一部分），系列的shell需要人工处理，代码的发布需要登录服务器等等；相反，拥有CI/CD，这些事情都交给机器去完成，腾出的碎片时间去做更有意义的事情（比如摸鱼放松下）。
部署步骤
1.安装runner
sudo apt-get install gitlab-runner
2.注册runner
sudo gitlab-runner register
之后是QA式操作，按照提示语输入信息即可，可参考官网操作，需要注意： 官网文档 register gitlab-runner
①. gitlab host和token在你的gitlab项目上找，页面路径是：Settings >> CI/CD >> Runners 如下图所示：
②. runner执行器选择 docker，image（镜像）输入 自己做好的镜像,或者自己的默认镜像
注册成功后，我们就能在：Settings >> CI/CD >> Runners下看到我们注册的runner，并会看到小绿点
3.配置.gitlab-ci.yml
翻译文档 .gitlab-ci.yml 官方文档 .gitlab-ci.yml
配置好 Runner 之后，我们要做的事情就是在项目根目录中添加 .gitlab-ci.yml 文件了。 当我们添加了 .gitlab-ci.yml 文件后，每次提交代码或者合并 MR 都会自动运行构建任务了。 在.gitlab-ci.yml有一些基本的概念：
Pipeline
一次 Pipeline 其实相当于一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。我们的任何提交或者 Merge Request 的合并都可以触发 Pipeline。如下图:
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
Stages
Stages 表示构建阶段，说白了就是上面提到的流程。 我们可以在一次 Pipeline 中定义多个 Stages，每个Stage可以完成不同的任务。 Stages有下面的特点： 所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始 只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功 如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败
因此，Stages 和 Pipeline 的关系就是：
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
Jobs
Jobs 表示构建工作，表示某个 Stage 里面执行的工作。 我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：
相同 Stage 中的 Jobs 会并行执行 相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功 如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败
所以，Jobs 和 Stage 的关系图就是：
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
4.配置runner
配置文件
进入 gitlab-runner/config 目录，会发现一个 config.toml 文件，里面是 gitlab-runner 相关的配置信息。
[[runners]]
name = "pms-pytest"
url = "" # 配置的host
token = "" # token
executor = "docker"
[runners.custom_build_dir]
[runners.docker]
tls_verify = false
image = "" # 使用此映像运行构建
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = [] # 挂载
pull_policy = "if-not-present"
shm_size = 0
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.custom]
run_exec = ""
5.docker的使用
构建我的镜像
Docker 构建镜像有两种方式，一种方式是使用 docker commit 命令，另外一种方式使用 docker build 命令和 Dockerfile 文件。其中，不推荐使用 docker commit 命令进行构建，因为它没有使得整个流程标准化，因此，在企业的中更加推荐使用 docker build 命令和 Dockerfile 文件来构建我们的镜像。我们使用Dockerfile 文件可以让构建镜像更具备可重复性，同时保证启动脚本和运行程序的标准化。
指令大致如下图：
将镜像推送到远程仓库
镜像构建完毕之后，我们可以将它上传到 Docker Hub 上面。首先，我们需要通过 docker login 保证我们已经登录了。紧接着，我们使用 docker push 命令进行推送。 同时，我们也可以使用国内的仓库，比如阿里云。首先，在终端中输入访问凭证，登录 Registry 实例。如果你不知道是哪个，可以访问 cr.console.aliyun.com/cn-hangzhou…
docker login --username=帐号 registry.cn-hangzhou.aliyuncs.com
现在，将镜像推送到阿里云镜像仓库。其中:
docker tag [IMAGE_ID] registry.cn-hangzhou.aliyuncs.com/[命名空间]/[镜像名称]:[版本] 和 docker push registry.cn-hangzhou.aliyuncs.com/[命名空间]/[镜像名称]:[版本] 命令的使用如下所示。
docker tag 794c07361565 registry.cn-hangzhou.aliyuncs.com/lianggzone/nginx_demo:v1
docker push registry.cn-hangzhou.aliyuncs.com/lianggzone/nginx_demo:v1
# 拉取镜像
docker pull [选项] [Docker Registry 地址[:端口号]/]仓库名[:标签]
