云时代的程序猿(书)（3）
作为程序员，代码是一定要写的，而且要天天写。在好多地方见过这样一种说法：
只会写程序的程序员不是好程序员
当然，我不赞同这种观点，因为有的人他天生就是为程序而生的。但是掌握一些代码之外的理论知识也是一个不错的选择，它能让你的代码质量上一个新的台阶，能极大的提高你的“抠码”效率。
最近新的APP即将上线，但在产品、研发、运营几个环节出了一些问题，也让我静下心来思考一些一个程序员觉得很难直面的问题。这其中和技术相关的问题包括：
APP版本更新较为频繁的问题。
测试覆盖不到位的问题。
APP的开发可能跟以前我所经历的大部分企业级应用软件、IaaS\/PaaS平台、大数据平台相关产品完全的不同，为了响应市场需求，APP的迭代周期要以周为单位（打开手机看看常用 的APP大部分每周一更新）,IOS还受到苹果审核周期的影响，会有更多的不可控因素。为了解决这些问题，目前我们主要做的工作包括几个方面：
解决运营和产品环节的反馈机制问题。
优化APP的打包、测试的方式。
合理的制定版本发布计划。
今天想给技术人员分享的主要就是持续集成和交付/部署（CI/CD）方面的一些基础知识，同时结合我们现在正在开发的APP中遇到的一些问题，和大家共同探讨如何才能更好的优化我们的产品打包、测试过程。
持续集成和持续交付/部署 CI/CD
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
By integrating regularly, you can detect errors quickly, and locate them more easily.
上面对CI的定义参考 ，可能把它生硬的翻译过来也不太好理解，我从这些年的产品研发过程中见到过的各种CI工具来定义CI的话，可以做如下定义：
CI是软件（产品）研发生命周期中对代码质量、系统集成的一个持续构进的过程，当作为一个团队开发产品时，每个人都要开发自己的功能模块，最终都需要集成在一起，代码也需要集中托管到同一个地方，通过使用一些自动化的代码打包、测试工具，能够在开发人员每提交一次代码的时候，系统自动对程序进行打包和单元测试，如果出现问题，及时通过邮件等方式通知相关的开发人员。
5年前，我还在从事企业级应用软件的开发，那时根本就没有什么单元测试，更没有自动打包、测试的工具，也就大家开发完功能，提交到SVN服务器，还有一个专业的人在需要打包里把代码down下来在自己机器上打包，然后部署到测试环境跑一把，没什么大问题就上生产环境。现在想想还是真“土”。
这几年，我和我的团队主要是基于openstack开发一款企业级的云管理平台，从一开始的懵懵懂懂，到现在形成比较成熟的基于CI的整个开发流程，也爬过了一个又一个的坑和坎。
目前我们比较成熟的套路是： _ git+gerrit+jenkins _
其中git用于代码托管，gerrit主要是是代码的评审，jenkins用于打包和跑单元测试。这样的组合百度一下，会有很多先辈们已经写了很多博客和文章，我这里就不在烂费精力了。今天我想介绍一下的是目前我们的APP开发过程中想采用的gitlab。要不然大家都觉得我写的东西没干货，也不好意思啊。
GitLab是一个集代码管理、测试、代码部署于一体的开源应用程序，它包括一个有非常好的权限控制的Git版本管理系统，代码评审系统，问题跟踪系统，活动反馈系统，wiki，持续集成CI系统等。
上面的翻译可能有点别扭，没办法，我就这水平了，咱们直接进入正题吧。
我个人比较喜欢的就是gitlab长的太像github了，使用很方便，同时采用了github的pull request方式来对代码进行审核，还集成了CI（虽然大部分还是要看你写脚本的水平如何）。
我将通过使用一个ios的demo项目来给大家展示如何用gitlab来管理代码、进行代码审核、CI等等。
安装GitLab
在Docker盛行的今天，我也就偷偷懒，跑个docker实例给大家演示一下，如果您在打算在生产环境使用gitlab，可以参考官方的安装文档，包括一些集群方案都能找到。用Docker跑gitlab就一个命令：
这里假设我们的服务器IP是：47.88.21.77 一定要记得根据您的实际情况更改IP地址哦。
-- -- .. --
服务启动后，浏览器进入：
首次进入可以设置root的密码，注册用户即可进入系统，这里我们演示时使用的用户名是cjzhao，登录后如下图所示：
空空如也……
使用gitlab评审代码
在这里可以创建组织、项目，基本概念和github一样，这里我们直接创建我们要演示的项目ios_ci_demo。
OK，多的不解释了，一看就懂。
创建完成后，进入项目首页，看到黄色的提示信息了吧，为了能从远程把代码推到服务器，需要配置一个ssh公钥，点击add an SSH key把你自己的公钥添加完成，就可以把代码上传上去了，这个过程就不截图了哦，看到我的公钥也不是太好……呵呵。
添加完公钥后，回到项目首页，如下图所示：
我们根据第三种方法把现有的代码上传到gitlab，即执行下面的代码：
cd existing_folder
git remote add origin git@47.88.21.77:cjzhao/ios_ci_demo.git
git commit
git push -u origin master
我们的app很简单，如下图所示:
很明显， word是错的哦，后面我们将演示另一个用户修改完后提交代码，并做代码审核。
上传完代码后，进入项目首页，如下图所示：
再注册一个新用户jack，然后用cjzhao登录后，进入项目设置页面(如下图所示)，把jack增加到项目中，这样他就能提交代码了。
添加的过程自己研究吧，很简单，要不编辑会认为我的文章就靠截图凑数了。加完后如下图所示：
OK了，接下来用用户jack修改代码，并提交到git服务器。
jack的操作主要包括以下几个步骤：
git clone git@47.88.21.77:cjzhao/ios_ci_demo.git
git checkout -b wordbug
//将word改为world
git commit -m "change word to world"
git push origin wordbug
这时jack登录系统后，会看到提交的代码，同时系统会提示您创建一个Merge request,如下图所示：
点击Create Merge Request，填写一些修改内容的描述信息，请求cjzhao将代码合并到master即可提交。
cjzhao登录系统后就能看到jack请求合并的分支，如下图所示：
在完成代码评审后，点击Accept Merge Request即可将代码合并到master。选中Remove source branch同时将wordbug分支删除。
OK，这就完成了多开发人员合作的项目代码评审流程。
gitlab中的CI
在gitlab中完成持续集成CI包括两个操作：
配置一个Runner(用来编译、测试、打包的服务器节点)。
在项目根目录增加格式的CI脚本文件.gitlab-ci.yml。
配置Runner
我们首先来为我们的项目配置一个Runner，由于我们的项目是ios的，因此需要在安装了macos操作系统和xcode的环境下才能编译、打包我们的APP，因此我们需要将一台mac计算机配置成我们的一个Runner，基本原理就是在Mac上安装一个代理程序gitlab-ci-multi-runner，然后将mac注册到gitlab服务器端，然后这台mac机器就能接收到gitlab服务器下发的CI任务，完成相应的编译、测试、打包等工作，然后将结果反馈给gitlab服务器。
在一台Mac机器上执行如下命令安装gitlab-ci-multi-runner(可能需要翻墙才能装哦):
sudo curl --output /usr/local/bin/gitlab-ci-multi-runner https:
sudo chmod +x /usr/local/bin/gitlab-ci-multi-runner
进入项目的Runner配置页面，如下图所示：
在Mac机器上执行如下命令，将这台Mac注册到gitlab并绑定到我们示例项目。
gitlab-ci-multi-runner register
#Please enter the gitlab-ci coordinator URL (e.g. /ci):
#输入上图中的URL.
#Please enter the gitlab-ci token for this runner:
#输入上图中的token.
#Please enter the gitlab-ci description for this runner:
#输入一个描述信息，这里我们输入mac_runner
#Please enter the gitlab-ci tags for this runner (comma separated):
#输入一些标签，这里我们输入"mac,xcode7.1"
# Registering runner... succeeded runner=euasz2j9
#Please enter the executor: docker-ssh+machine, docker, docker-ssh, parallels, shell, ssh, virtualbox, docker+machine:
#这里我们输入shell，因为ios项目的编译、测试、打包我们都采用脚本来执行。
#Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
#注册成功，接下来启动它
gitlab-ci-multi-runner install
gitlab-ci-multi-runner start
现在我们的Mac机器就注册为一个Runner了，查看项目的Runner页面，如下图所示：
我们的Runner就成功注册上了。接下来就可以编写CI的脚本了。
增加CI脚本文件.gitlab-ci.yml
在项目根目录创建.gitlab-ci.yml文件，内容如下：
build_project:
stage: build
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo clean
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo test -test-sdk iphonesimulator9.3
archive_project:
stage: archive
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo archive -archivePath build/ioscidemo
- xcodebuild -exportArchive -exportFormat ipa -archivePath "build/ioscidemo.xcarchive" -exportPath "build/ioscidemo.ipa"
artifacts:
- build/ioscidemo.ipa
上面脚本使用了，它是facebook推出的一款替代xcodebuild的app打包和测试工具，它日志输出更加友好，性能高效，我们需要在刚才安装了Runner的Mac机器上先安装它，可以使用如下命令安装：
brew install xctool
OK,接下来就是提交我们最新的代码了：
git commit -m "add CI cfg file"
git push origin master
如果没有什么异常的话，CI已经在开始执行编译、测试、打包等工作了。见下图所示：
看到绿色的passed了吧？这就说明编译、测试、打包都成功了（我可是耗费了好长时间才成功的哦，中间总会出现各种各样的问题）。就写到这儿吧，最后再给大家提供一点CD的思路（技术层面的），刚才的过程已经完成了app的打包，我们可以创建一个Releases的分支，在脚本中增加APP上传到itunesconnect的脚本，这样就可以在发布新版本的时候完成APP的整个发布流程。
Apple给我们提供了一套命令行工具altool可以直接把ipa上传到itunesconnect，很方便的，详见：
OK，真的结束了，自己去研究吧。
希望本文对您有所帮助，谢谢。
更多精彩内容请关注公众号：国际范程序员
一大堆干货等着你哦。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：135877次
积分：1589
积分：1589
排名：第18312名
原创：17篇
评论：12条
(1)(3)(1)(4)(1)(1)(1)(1)(1)(2)(1)(1)(2)(2)(2)(1)使用GitLab来实现IOS项目的持续集成CI - 简书
下载简书移动应用
写了18402字，被97人关注，获得了368个喜欢
使用GitLab来实现IOS项目的持续集成CI
作为程序员，代码是一定要写的，而且要天天写。在好多地方见过这样一种说法：
只会写程序的程序员不是好程序员
当然，我不赞同这种观点，因为有的人他天生就是为程序而生的。但是掌握一些代码之外的理论知识也是一个不错的选择，它能让你的代码质量上一个新的台阶，能极大的提高你的“抠码”效率。
最近新的APP即将上线，但在产品、研发、运营几个环节出了一些问题，也让我静下心来思考一些一个程序员觉得很难直面的问题。这其中和技术相关的问题包括：
APP版本更新较为频繁的问题。
测试覆盖不到位的问题。
APP的开发可能跟以前我所经历的大部分企业级应用软件、IaaS\/PaaS平台、大数据平台相关产品完全的不同，为了响应市场需求，APP的迭代周期要以周为单位（打开手机看看常用 的APP大部分每周一更新）,IOS还受到苹果审核周期的影响，会有更多的不可控因素。为了解决这些问题，目前我们主要做的工作包括几个方面：
解决运营和产品环节的反馈机制问题。
优化APP的打包、测试的方式。
合理的制定版本发布计划。
今天想给技术人员分享的主要就是持续集成和交付/部署（CI/CD）方面的一些基础知识，同时结合我们现在正在开发的APP中遇到的一些问题，和大家共同探讨如何才能更好的优化我们的产品打包、测试过程。
持续集成和持续交付/部署 CI/CD
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
By integrating regularly, you can detect errors quickly, and locate them more easily.
上面对CI的定义参考 ，可能把它生硬的翻译过来也不太好理解，我从这些年的产品研发过程中见到过的各种CI工具来定义CI的话，可以做如下定义：
CI是软件（产品）研发生命周期中对代码质量、系统集成的一个持续构进的过程，当作为一个团队开发产品时，每个人都要开发自己的功能模块，最终都需要集成在一起，代码也需要集中托管到同一个地方，通过使用一些自动化的代码打包、测试工具，能够在开发人员每提交一次代码的时候，系统自动对程序进行打包和单元测试，如果出现问题，及时通过邮件等方式通知相关的开发人员。
5年前，我还在从事企业级应用软件的开发，那时根本就没有什么单元测试，更没有自动打包、测试的工具，也就大家开发完功能，提交到SVN服务器，还有一个专业的人在需要打包里把代码down下来在自己机器上打包，然后部署到测试环境跑一把，没什么大问题就上生产环境。现在想想还是真“土”。
这几年，我和我的团队主要是基于openstack开发一款企业级的云管理平台，从一开始的懵懵懂懂，到现在形成比较成熟的基于CI的整个开发流程，也爬过了一个又一个的坑和坎。
目前我们比较成熟的套路是：
git+gerrit+jenkins
其中git用于代码托管，gerrit主要是是代码的评审，jenkins用于打包和跑单元测试。这样的组合百度一下，会有很多先辈们已经写了很多博客和文章，我这里就不在烂费精力了。今天我想介绍一下的是目前我们的APP开发过程中想采用的gitlab。要不然大家都觉得我写的东西没干货，也不好意思啊。
GitLab是一个集代码管理、测试、代码部署于一体的开源应用程序，它包括一个有非常好的权限控制的Git版本管理系统，代码评审系统，问题跟踪系统，活动反馈系统，wiki，持续集成CI系统等。
上面的翻译可能有点别扭，没办法，我就这水平了，咱们直接进入正题吧。
我个人比较喜欢的就是gitlab长的太像github了，使用很方便，同时采用了github的pull request方式来对代码进行审核，还集成了CI（虽然大部分还是要看你写脚本的水平如何）。
我将通过使用一个ios的demo项目来给大家展示如何用gitlab来管理代码、进行代码审核、CI等等。
安装GitLab
在Docker盛行的今天，我也就偷偷懒，跑个docker实例给大家演示一下，如果您在打算在生产环境使用gitlab，可以参考官方的安装文档，包括一些集群方案都能找到。用Docker跑gitlab就一个命令：
这里假设我们的服务器IP是：47.88.21.77 一定要记得根据您的实际情况更改IP地址哦。
sudo docker run --detach --hostname
--env GITLAB_OMNIBUS_CONFIG="external_url 'http://47.88.21.77/'; gitlab_rails['lfs_enabled'] =" --publish 443:443 --publish 80:80 --publish 22:22 --name gitlab --restart always --volume /srv/gitlab/config:/etc/gitlab --volume /srv/gitlab/logs:/var/log/gitlab --volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest
服务启动后，浏览器进入：
gitlab_login.png
首次进入可以设置root的密码，注册用户即可进入系统，这里我们演示时使用的用户名是cjzhao，登录后如下图所示：
gitlab_firstpage.png
空空如也……
使用gitlab评审代码
在这里可以创建组织、项目，基本概念和github一样，这里我们直接创建我们要演示的项目ios_ci_demo。
gitlab_newproject.png
OK，多的不解释了，一看就懂。
gitlab_projecthome.png
创建完成后，进入项目首页，看到黄色的提示信息了吧，为了能从远程把代码推到服务器，需要配置一个ssh公钥，点击add an SSH key把你自己的公钥添加完成，就可以把代码上传上去了，这个过程就不截图了哦，看到我的公钥也不是太好……呵呵。
添加完公钥后，回到项目首页，如下图所示：
gitlab_codeuploadmethod.png
我们根据第三种方法把现有的代码上传到gitlab，即执行下面的代码：
cd existing_folder
git remote add origin git@47.88.21.77:cjzhao/ios_ci_demo.git
git commit
git push -u origin master
我们的app很简单，如下图所示:
Simulator_hello.png
很明显， word是错的哦，后面我们将演示另一个用户修改完后提交代码，并做代码审核。
上传完代码后，进入项目首页，如下图所示：
gitlab_project_home_first.png
再注册一个新用户jack，然后用cjzhao登录后，进入项目设置页面(如下图所示)，把jack增加到项目中，这样他就能提交代码了。
gitlab_project_setting_menu.png
添加的过程自己研究吧，很简单，要不编辑会认为我的文章就靠截图凑数了。加完后如下图所示：
gitlab_add_user_to_project.png
OK了，接下来用用户jack修改代码，并提交到git服务器。
jack的操作主要包括以下几个步骤：
git clone git@47.88.21.77:cjzhao/ios_ci_demo.git
git checkout -b wordbug
//将word改为world
git commit -m "change word to world"
git push origin wordbug
这时jack登录系统后，会看到提交的代码，同时系统会提示您创建一个Merge request,如下图所示：
gitlab_create_merge_request.png
点击Create Merge Request，填写一些修改内容的描述信息，请求cjzhao将代码合并到master即可提交。
cjzhao登录系统后就能看到jack请求合并的分支，如下图所示：
gitlab_accept_merge_request.png
在完成代码评审后，点击Accept Merge Request即可将代码合并到master。选中Remove source branch同时将wordbug分支删除。
OK，这就完成了多开发人员合作的项目代码评审流程。
gitlab中的CI
在gitlab中完成持续集成CI包括两个操作：
配置一个Runner(用来编译、测试、打包的服务器节点)。
在项目根目录增加格式的CI脚本文件.gitlab-ci.yml。
配置Runner
我们首先来为我们的项目配置一个Runner，由于我们的项目是ios的，因此需要在安装了macos操作系统和xcode的环境下才能编译、打包我们的APP，因此我们需要将一台mac计算机配置成我们的一个Runner，基本原理就是在Mac上安装一个代理程序gitlab-ci-multi-runner，然后将mac注册到gitlab服务器端，然后这台mac机器就能接收到gitlab服务器下发的CI任务，完成相应的编译、测试、打包等工作，然后将结果反馈给gitlab服务器。
在一台Mac机器上执行如下命令安装gitlab-ci-multi-runner(可能需要翻墙才能装哦):
sudo curl --output /usr/local/bin/gitlab-ci-multi-runner https://gitlab-ci-multi-runner-downloads./latest/binaries/gitlab-ci-multi-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-ci-multi-runner
进入项目的Runner配置页面，如下图所示：
gitlab_config_runner.png
在Mac机器上执行如下命令，将这台Mac注册到gitlab并绑定到我们示例项目。
gitlab-ci-multi-runner register
#Please enter the gitlab-ci coordinator URL (e.g. /ci):
#输入上图中的URL.
#Please enter the gitlab-ci token for this runner:
#输入上图中的token.
#Please enter the gitlab-ci description for this runner:
#输入一个描述信息，这里我们输入mac_runner
#Please enter the gitlab-ci tags for this runner (comma separated):
#输入一些标签，这里我们输入"mac,xcode7.1"
# Registering runner... succeeded runner=euasz2j9
#Please enter the executor: docker-ssh+machine, docker, docker-ssh, parallels, shell, ssh, virtualbox, docker+machine:
#这里我们输入shell，因为ios项目的编译、测试、打包我们都采用脚本来执行。
#Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
#注册成功，接下来启动它
gitlab-ci-multi-runner install
gitlab-ci-multi-runner start
现在我们的Mac机器就注册为一个Runner了，查看项目的Runner页面，如下图所示：
gitlab_runner_running.png
我们的Runner就成功注册上了。接下来就可以编写CI的脚本了。
增加CI脚本文件.gitlab-ci.yml
在项目根目录创建.gitlab-ci.yml文件，内容如下：
build_project:
stage: build
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo clean
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo test -test-sdk iphonesimulator9.3
archive_project:
stage: archive
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo archive -archivePath build/ioscidemo
- xcodebuild -exportArchive -exportFormat ipa -archivePath "build/ioscidemo.xcarchive" -exportPath "build/ioscidemo.ipa"
artifacts:
- build/ioscidemo.ipa
上面脚本使用了，它是facebook推出的一款替代xcodebuild的app打包和测试工具，它日志输出更加友好，性能高效，我们需要在刚才安装了Runner的Mac机器上先安装它，可以使用如下命令安装：
brew install xctool
OK,接下来就是提交我们最新的代码了：
git commit -m "add CI cfg file"
git push origin master
如果没有什么异常的话，CI已经在开始执行编译、测试、打包等工作了。见下图所示：
gitlab_project_build_status.png
看到绿色的passed了吧？这就说明编译、测试、打包都成功了（我可是耗费了好长时间才成功的哦，中间总会出现各种各样的问题）。就写到这儿吧，最后再给大家提供一点CD的思路（技术层面的），刚才的过程已经完成了app的打包，我们可以创建一个Releases的分支，在脚本中增加APP上传到itunesconnect的脚本，这样就可以在发布新版本的时候完成APP的整个发布流程。
Apple给我们提供了一套命令行工具altool可以直接把ipa上传到itunesconnect，很方便的，详见：
OK，真的结束了，自己去研究吧。
希望本文对您有所帮助，谢谢。
如果觉得我的文章对您有用，请我吃根雪糕吧……，我不喝咖啡的……
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
被以下专题收入，发现更多相似内容：
如果你是程序员，或者有一颗喜欢写程序的心，喜欢分享技术干货、项目经验、程序员日常囧事等等，欢迎投稿《程序员》专题。
专题主编：小...
· 161806人关注
玩转简书的第一步，从这个专题开始。
想上首页热门榜么？好内容想被更多人看到么？来投稿吧！如果被拒也不要灰心哦～入选文章会进一个队...
· 127004人关注
分享 iOS 开发的知识，解决大家遇到的问题，讨论iOS开发的前沿，欢迎大家投稿~
· 25261人关注
如果觉得我的文章对您有用，请我吃根雪糕吧……，我不喝咖啡的……
选择支付方式：基于docker+gitlabCI搭建私有集成环境 - 推酷
基于docker+gitlabCI搭建私有集成环境
看了几天的docker，感觉好极了。现在回到我一开始的目标：构建一个团队内部的持续集成（下文统称CI）环境，并梳理出适合我们自己的工作流。
今天我们主要是来搭建依赖的环境：
virtualBox
ubuntu server 16
gitlab version8+(该版本以上自带CI模块)
gitlab runner
gitlab需要的其它组件（redis，postgresql）
之前学习docker时，一直都是基于自己的工作机，装的是win7 64bit，win下和docker相关的问题可以看我之前的文章。由于我们现在是要搭建一个自动化CI环境，提供web ui来供用户使用，所以环境搭建部分的操作完全不需要使用者参与，就不存在之前考虑的所谓的OS水土不服问题！介于网上多数资料都是使用ubuntu来作为docker的宿主系统，所以我这里就放弃了亲爱的centos（其实centos也是没问题的，我只是低调的炫耀自己通吃而已~见谅）。
老规矩，先来共享一下相关的文献资料：
(主要借鉴该文章后半部分提到的“提升构建速度”)
(gitlab docker镜像的使用文档)
ubuntu下安装docker
我们这次不使用win下的dockerToolbox来安装docker了，而是直接在虚拟机中安装unbuntu系统，然后直接在unbuntu中安装docker：
curl -sSL / | sudo sh
目前这样的安装方式，依然需要注意，后面运行gitlab容器时配置的端口映射只是将容器的端口映射到了ubuntu虚拟机系统上，如果想让物理机直接访问，还需要在virtualBox上再进行一次端口映射，具体步骤在这篇文章中我已经详细介绍过了。
镜像选择问题
docker环境装好后，就需要开始下载所需要的镜像了：
sameersbn/gitlab:latest
sameersbn/postgresql:latest
sameersbn/redis:latest
sameersbn/gitlab-ci-multi-runner:latest
由于我们是在国内，所以直接使用来下载无异于浪费生命，还好国内也有良心镜像库：
这里需要提醒的是，尽管灵雀云上显示的 sameersbn/gitlab 镜像版本是”7.14.1”，不过别担心，只是md文件没有更新而已，可以切换到页面的“版本”选项卡来确认 latest 版本。
这样基本上20分钟就可以把三个镜像全部下载到本地啦~
镜像下载完毕后，根据官方文档我们需要创建对应的docker容器来启动相关的服务，我并没有使用官方提供的第一种方法（docker-compose），主要是不熟悉~
我们手动来完成三个容器的启动：
#启动postgresql容器docker run --name gitlab-postgresql -d \
--env 'DB_NAME=gitlabhq_production' \
--env 'DB_USER=gitlab' --env 'DB_PASS=password' \
--env 'DB_EXTENSION=pg_trgm' \
--volume /srv/docker/gitlab/postgresql:/var/lib/postgresql \
/sameersbn/postgresql#启动redis容器docker run --name gitlab-redis -d \
--volume /srv/docker/gitlab/redis:/var/lib/redis \
/sameersbn/redis#最后启动gitlab容器docker run --name gitlab -d \
--link gitlab-postgresql:postgresql --link gitlab-redis:redisio \
--publish 10022:22 --publish 10080:80 \
--env 'GITLAB_PORT=10080' --env 'GITLAB_SSH_PORT=10022' \
--env 'GITLAB_SECRETS_DB_KEY_BASE=kazaffisagoodcoder' \
--volume /srv/docker/gitlab/gitlab:/home/git/data \
/sameersbn/gitlab
注意，上面的命令我已经改成使用我们本地镜像的名字了，还有在启动gitlab容器时我使用了一个自定义的字符串来赋值 GITLAB_SECRETS_DB_KEY_BASE ，由于是本地测试环境，外加我实在不知道如何通过在 --env 命令中使用shell变量来使用 pwgen -Bsv1 64 生成的随机字符串（手动输入简直等于自杀！）~知道如何做的朋友请留言赐教，不胜感激。
根据自己的硬件配置，可能需要稍等那么一分钟左右，在做好物理机端口映射配置后，我们就可以在本地浏览器中访问
来使用gitlab了！（可能由于gitlab首次启动初始化问题，你可能会看到gitlab提示的500错误，稍等一下再刷新即可）
现在你基本上就已经拥有了本地的gitlab环境，你可以使用本地的git客户端来创建一个gitlab测试项目，试试clone到本地，试试commit到gitlab，应该妥妥的~
Gitlab Runner
这部分内容文章开头给的文档并没有汉化，不过没关系，我们都懂英文，对吧？
出于性能考虑官方不推荐将Runner安装在和gitlab同一台物理机上，出于安全考虑也不推荐将其安装在独立的物理机上，靠，也只能用docker来跑了！
这里还有两个概念：
特定Runner
共享Runner
前者适配有特殊需求的项目，同时也可以避免重要的项目runner资源被占用的问题。
而如果多个项目的优先级一样，并且有非常相似的依赖环境，那使用共享Runner是一个不错的选择。
既然我们决定使用docker容器来跑runner，那就先选个镜像吧，官方提供的是：
，我是用的
了，注意，这里灵雀云镜像上的md介绍依然是错误的，镜像本身是和官方镜像一致的，小不完美啊 :———(~
还要说的一点是，官方提供的这个镜像是纯净镜像，不包含任何其它的环境（例如java环境或node环境），而你需要根据自己的项目实际情况来创建满足的自定义镜像。官方提供了几个语言环境的
这种使用runner的思路相当于我们拿这个运行着runner的docker容器当作一个“物理机”，然后在这台“物理机”上做 .gitlab-ci.yml 指定要做的事儿。在此基础上，我们依然可以让Runner执行docker build模式，这里就涉及到“docker-in-docker”的思想了。具体细节官方提供了比较清晰的
。（其实，如果你使用文档中提到的“docker-in-docker”方案的话，那实际上就是“docker-in-(docker-in-docker)”，好绕啊~）
提到Runner的executor的类型，
里有提到不少（shell，docker，ssh，等等），差别我感觉都不是太大，主要还是shell和docker两大类。
理论姿势就这么多，接下来我们跑起我的runner容器：
mkdir -p /srv/docker/gitlab-runnerdocker run --name gitlab-ci-multi-runner -d --restart=always \ --volume /srv/docker/gitlab-runner:/home/gitlab_ci_multi_runner/data \ --link gitlab:gitlab --env='CI_SERVER_URL=http://gitlab/ci' \ --env='RUNNER_TOKEN=你gitlab生成的token' \ --env='RUNNER_DESCRIPTION=myrunner' --env='RUNNER_EXECUTOR=shell' \ /sameersbn/gitlab-ci-multi-runner
这里需要提醒的是两点：
你自己的gitlab生成的token可以在
看到（我假设你和我一样要创建的是一个共享Runner）
CI_SERVER_URL参数不要使用你物理机浏览器地址栏里的值，我们在上面的命令中已经将之前创建的gitlab容器link到了runner容器，so，我们只需要填写设置的主机名即可，否则无法注册成功！
接下来刷新你的gitlab管理员后台，你将会看到注册成功的Runner信息。
还没完，由于我们使用的是 shell 模式，所以我们还需要进入到runner容器中来安装docker环境：
docker exec -it gitlab-ci-multi-runner bashcurl -sSL / | sudo shsudo usermod -aG docker gitlab-runnersudo -u gitlab-runner -H docker info
如果可以看到正确的docker版本信息，那就说明一切顺利。 但怎么可能那么顺利！！ 事实证明我太天真了，在docker容器中由于文件系统是只读的，所以无法安装docker环境~至少我们现在的做法还不行，如下图：
这里说一个插曲，当得到这个结论后的我失望的打算将这个悲剧的镜像删除，我在gitlab admin后台的runner页面点击“remove”按钮，然后又将对应的docker容器也删除掉。当我再次使用相同的命令打算启动一个干净的runner容器时，我发现gitlab的runner页面不在提示成功注册runner了！我彻底方了！一切都和第一次执行流程一致，为啥这次就不认了呢？
于是我发现了一个秘密，上面的创建runner容器的命令中有一个参数：
--volume /srv/docker/gitlab-runner:/home/gitlab_ci_multi_runner/data
我在宿主机的 /srv/docker/gitlab-runner 目录下找到了答案，原来一直试图想找到的 config.toml 文件在这里，也是因为这个文件的缘故所以gitlab才不在接受我的runner注册的！删除并重建这个目录即可！
走了弯路不可怕，可怕的是接下来不知道怎么办？没关系，我们现在先在宿主机上
，并使用官方提供的docker-in-docker方式来增加一台runner：
curl -L /install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bashsudo apt-get install gitlab-ci-multi-runnersudo gitlab-ci-multi-runner register -n \
--url http://localhost:10080/ci \
--token 你gitlab生成的token \
--executor docker \
--description &My Docker Runner& \
--docker-image &/library/docker:latest& \
--docker-privileged
记住，我们这里要填写的gitlab-ci coordinator URL应该是： http://localhost:10080/ci 。
这里还有个细节是官方文档没有提到的，那就是
，不过其实默认安装好gitlab-ci-multi-runner后它就自己已经以服务的方式注册到系统里了（服务名：gitlab-runner），每次注册runner导致 config.toml 文件变更后都会自动触发该服务的reload。但了解一下这个细节还是对分析问题很有帮助的！
这样我们就应该有两个runner了（一个是shell类型，一个是docker类型）：
//todo ubuntu -& docker-in-docker -& runner -& docker engine
.gitlab-ci.yml
这个文件应该放在我们的项目repo的根目录下，用来描述当发生目标行为后，runner要做的工作。官方文档有对其语法的
环境基本上就搭建好了，下一篇我们就开始设计工作流了。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致}