本文涉及一种利用容器部署 gitlab 和 jenkins 服务实现持续集成（CICD）的方法，其目的是为了在实际工作中使用代码托管及自动化操作。
一、引言
因工作需要，需部署 gitlab 和 jenkins 服务器进行 CICD 测试，换个高大上的名称，叫“组织革新”。本文记录个人的实践，但不涉及部署的具体步骤。
二、技术小结
- 不同工程，配置不同，本文使用 C++ 工程为例进行实验。
- 在配置 jenkins 时，建议经常使用页面下方的“应用”，随时保存设置好的参数，以防不测。
三、gitlab和jenkins联调
3.1 概述
实现CICD分几个阶段：使用 gitlab 托管代码，使用 jenkins 进行编译、打包以及发布。两个服务器各有项目对应，同时要进行必要的配置。不同项目，配置方式不尽相同。本节的配置原则上按顺序进行，因此会到 gitlab 和 jenkins 之间来回切换，故先行说明。
3.2 前置条件
3.2.1 允许本地网络请求
使用 root 用户登录 gitlab 服务器，在管理员配置选项选择**网络(Setting)页面，在外发请求（Outbound requests）**中，选择“允许Webhook和服务对本地网络的请求(Allow requests to the local network from web hooks and services)”，保存。如图1所示。
进行该设置的目的是因为本文的 gitlab 和 jenkins 服务均在同一物理服务器上使用 docker 部署。如果不设置，则在 gitlab 中设置 webhooks 时会提示Url is blocked: Requests to the local network are not allowed。
说明：如果jenkins和gitlab不在同一服务器，则不需要进行此设置。
3.2.2 关闭 CSFR
进入 jenkins 容器，找到/usr/local/bin/jenkins.sh文件，找到 exec java 行，在-Duser.home="$JENKINS_HOME"后添加-Dhudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION=true，完整的一行语句如下：
exec java -Duser.home="$JENKINS_HOME" -Dhudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION=true "${java_opts_array[@]}" -jar ${JENKINS_WAR} "${jenkins_opts_array[@]}" "$@
说明：在笔者定制的 jenkins 镜像中已经进行该修改了。
进行该设置，是因为高版本 Jenkins 无法在界面关闭跨站请求伪造保护（CSRF），因为在 gitlab 进行 webhooks 时会认证失败。提示：
Hook executed successfully but returned HTTP 403
关闭之后，再次进行 CSFR 页面，提示：
This configuration is unavailable because the System property hudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION is set to true.
说明修改成功。
对于物理机部署的 jenkins，则在 /etc/sysconfig/jenkins 文件中找到 JENKINS_JAVA_OPTIONS， 设置如下：
JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Dhudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION=true"
3.3 准备 gitlab 仓库
本文使用仓库地址为 http://10.8.18.168:8888/latelee/ci_test。
3.4 配置 jenkins 项目
3.4.1 新建项目
在 jenkins 首页左侧，点击“新建任务”，输入项目项目，选择第一项“自由风格软件项目”。
点击“确定”进入配置页面。
3.4.2 指定git仓库
在源码管理选项页面中，输入 gitlab 仓库地址，注意，URL 地址后须添加.git后缀。
点击“添加”->Jenkins，添加凭据，默认类型为用户名和密码。
添加后，选择添加的凭据，红色错误提示消失。
3.4.3 设置触发条件
在构建触发器页面进行触发器的选择。此处有多种方式可选，如定时构建和指定 gitlab 方式。
勾选“Build when a change is pushed to GitLab.”。注意，该项后面的 URL 地址需要记住，在 gitlab 中将使用。点击“高级”，在“Secret token”处点击“Generate”，生成 token，该 token 亦需要记住。
进行此设置目的是，当提交代码到 gitlab 仓库时，会自动触发 jenkins 执行 一次构建。触发条件在对应 gitlab 仓库中进行设置。如果不需要自动触发，则可以不触发条件。
3.4.4 指定构建步骤
在构建页面，点击“增加构建步骤”，选择“执行shell”，输入构建的命令。
3.4.5 指定构建后的步骤
在构建后操作页面，点击“增加构建后操作步骤”。选择“send build artifacts over SSH”。选择服务器、源目录、目标目录及执行的命令。注意，在本文实践前已经设置好服务器及目标，故只指定源文件和执行命令即可。
在笔者实践中发现，在“构建环境”、“构建”、“构建后操作”三个页面均可以选择将文件通过 SSH 发送服务器。
3.5 设置 gitlab 的 webhooks
在 gitlab 项目http://10.8.18.168:8888/latelee/ci_test页面， 选择“Settings”->“Webhooks”，输入上小节生成的 URL 和 token。
点击页面下方“Add webhook”，添加。
注：同一个gitlab仓库，可支持多个 webhook。
点击“Test”，选择“Push events”，进行测试验证。为保证触发成功，强烈建议在此处先行测试。
触发类型有很多种，根据实际情况选择。
3.4 验证
提交代码到 gitlab 仓库（此处从略）。稍等片刻，在 jenkins 工程的看到进行了触发。
输出日志如下：
编译、运行、执行ssh远程服务均成功。在远程服务器的/tmp目录出现a.out和log.txt。