一、持續集成（Continuous Integration）
要了解GitLab-CI與GitLab Runner，我們得先了解持續集成是什麼。
持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味着每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發佈，自動化測試)來驗證，從而儘快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。
看完這段話，估計還是有點懵。怎麼理解呢？我是這樣理解的：
軟件集成是軟件開發過程中的一個環節，這個環節的工作一般會包括以下流程：合併代碼---->安裝依賴---->編譯---->測試---->發佈。軟件集成的工作一般會比較細碎繁瑣，爲了不影響開發效率，以前軟件集成這個環節一般不會經常進行或者只會等到項目後期再進行。但是有些問題，如果等到後期才發現，解決問題的代價很大，有可能導致項目延期或者失敗。因此，爲了儘早發現軟件集成錯誤，鼓勵團隊成員應該經常集成他們的工作，通常每個成員每天應該至少集成一次。這就是所說的持續集成。所以說，持續集成是一種軟件開發實踐。
軟件集成的工作細碎繁瑣，以前是由人工完成的。但是現在鼓勵持續集成，那豈不是要累死人，還影響開發效率。所以，應該考慮將軟件集成這個工作自動化，這就出現了所謂的持續集成系統。
持續集成詳情見百度百科-持續集成
二、GitLab-CI
GitLab-CI就是一套配合GitLab使用的持續集成系統（當然，還有其它的持續集成系統，同樣可以配合GitLab使用，比如Jenkins）。而且GitLab8.0以後的版本是默認集成了GitLab-CI並且默認啓用的。
三、GitLab-Runner
那GitLab-Runner又是什麼東東呢？與GitLab-CI有什麼關係呢？
GitLab-Runner是配合GitLab-CI進行使用的。一般地，GitLab裏面的每一個工程都會定義一個屬於這個工程的軟件集成腳本，用來自動化地完成一些軟件集成工作。當這個工程的倉庫代碼發生變動時，比如有人push了代碼，GitLab就會將這個變動通知GitLab-CI。這時GitLab-CI會找出與這個工程相關聯的Runner，並通知這些Runner把代碼更新到本地並執行預定義好的執行腳本。
所以，GitLab-Runner就是一個用來執行軟件集成腳本的東西。你可以想象一下：Runner就像一個個的工人，而GitLab-CI就是這些工人的一個管理中心，所有工人都要在GitLab-CI裏面登記註冊，並且表明自己是爲哪個工程服務的。當相應的工程發生變化時，GitLab-CI就會通知相應的工人執行軟件集成腳本。如下圖所示：
GitLab-CI與GitLab-Runner關係示意圖
Runner可以分佈在不同的主機上，同一個主機上也可以有多個Runner。
Runner類型
GitLab-Runner可以分類兩種類型：Shared Runner（共享型）和Specific Runner（指定型）。
Shared Runner：這種Runner（工人）是所有工程都能夠用的。只有系統管理員能夠創建Shared Runner。
Specific Runner：這種Runner（工人）只能爲指定的工程服務。擁有該工程訪問權限的人都能夠爲該工程創建Shared Runner。
四、GitLab-Runner的安裝與使用
我的操作系統是：Centos 7.0 64位
安裝gitlab-ci-multi-runner
添加yum源
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
安裝
yum install gitlab-ci-multi-runner
這裏是官網的安裝教程，其它操作系統的請參考
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
使用gitlab-ci-multi-runner註冊Runner
安裝好gitlab-ci-multi-runner這個軟件之後，我們就可以用它向GitLab-CI註冊Runner了。
向GitLab-CI註冊一個Runner需要兩樣東西：GitLab-CI的url和註冊token。
其中，token是爲了確定你這個Runner是所有工程都能夠使用的Shared Runner還是具體某一個工程才能使用的Specific Runner。
如果要註冊Shared Runner，你需要到管理界面的Runners頁面裏面去找註冊token。如下圖所示：
Shared Runner
如果要註冊Specific Runner，你需要到項目的設置的Runner頁面裏面去找註冊token。如下圖所示：
Specific Runner
找到token之後，運行下面這條命令註冊Runner（當然，除了url和token之外，還需要其他的信息，比如執行器executor、構建目錄builds_dir等）。gitlab-ci-multi-runner register
註冊完成之後，GitLab-CI就會多出一條Runner記錄，如下圖所示：
GitLab-CI Runner
GitLab-CI會爲這個Runner生成一個唯一的token，以後Runner就通過這個token與GitLab-CI進行通信。
那麼，問題來了。註冊好了的Runner的信息存放在哪兒了呢？
原來，Runner的信息是存放在一個配置文件裏面的，配置文件的格式一般是.toml。這個配置文件的存放位置有以下幾種情況：
在類Unix操作系統下（0.5.0之後版本）
如果是以root用戶身份運行
gitlab-ci-multi-runner register，那麼配置文件默認是/etc/gitlab-runner/config.toml如果是以非root用戶身份運行
gitlab-ci-multi-runner register，那麼配置文件默認是~/.gitlab-runner/config.toml
一般情況下，使用默認的配置文件存放Runner的配置信息就可以了。當然，如果你有更細化的分類需求，你也可以在註冊的時候通過-c或--config選項指定配置文件的位置。具體查看register命令的使用方法：gitlab-ci-multi-runner register --help。
問題：如果不運行gitlab-ci-multi-runner register命令，直接在配置文件裏面添加Runner的配置信息可以嗎？
回答：當然不可以。因爲gitlab-ci-multi-runner register的作用除了把Runner的信息保存到配置文件以外，還有一個很重要的作用，那就是向GitLab-CI發出請求，在GitLab-CI中登記這個Runner的信息並且獲取後續通信所需要的token。
讓註冊好的Runner運行起來
Runner註冊完成之後還不行，還必須讓它運行起來，否則它無法接收到GitLab-CI的通知並且執行軟件集成腳本。怎麼讓Runner運行起來呢？gitlab-ci-multi-runner提供了這樣一條命令gitlab-ci-multi-runner run-single，詳情如下：
[root@iZ25bjcxoq5Z ~]# gitlab-ci-multi-runner run-single --helpNAME: run-single - start single runner USAGE: command run-single [command options] [arguments...] OPTIONS: --name, --description Runner name [$RUNNER_NAME] --limit Maximum number of builds processed by this runner [$RUNNER_LIMIT] --ouput-limit Maximum build trace size [$RUNNER_OUTPUT_LIMIT] -u, --url Runner URL [$CI_SERVER_URL] -t, --token Runner token [$CI_SERVER_TOKEN] --tls-ca-file File containing the certificates to verify the peer when using HTTPS [$CI_SERVER_TLS_CA_FILE] --executor Select executor, eg. shell, docker, etc. [$RUNNER_EXECUTOR] --builds-dir Directory where builds are stored [$RUNNER_BUILDS_DIR] --cache-dir Directory where build cache is stored [$RUNNER_CACHE_DIR] --env Custom environment variables injected to build environment [$RUNNER_ENV] --shell Select bash, cmd or powershell [$RUNNER_SHELL] --ssh-user User name [$SSH_USER] --ssh-password User password [$SSH_PASSWORD] --ssh-host Remote host [$SSH_HOST] --ssh-port Remote host port [$SSH_PORT] --ssh-identity-file Identity file to be used [$SSH_IDENTITY_FILE] --docker-host Docker daemon address [$DOCKER_HOST] --docker-cert-path Certificate path [$DOCKER_CERT_PATH] --docker-tlsverify Use TLS and verify the remote [$DOCKER_TLS_VERIFY] --docker-hostname Custom container hostname [$DOCKER_HOSTNAME] --docker-p_w_picpath Docker p_w_picpath to be used [$DOCKER_IMAGE] --docker-privileged Give extended privileges to container [$DOCKER_PRIVILEGED] --docker-disable-cache Disable all container caching [$DOCKER_DISABLE_CACHE] --docker-volumes Bind mount a volumes [$DOCKER_VOLUMES] --docker-cache-dir Directory where to store caches [$DOCKER_CACHE_DIR] --docker-extra-hosts Add a custom host-to-IP mapping [$DOCKER_EXTRA_HOSTS] --docker-links Add link to another container [$DOCKER_LINKS] --docker-services Add service that is started with container [$DOCKER_SERVICES] --docker-wait-for-services-timeout How long to wait for service startup [$DOCKER_WAIT_FOR_SERVICES_TIMEOUT] --docker-allowed-p_w_picpaths Whitelist allowed p_w_picpaths [$DOCKER_ALLOWED_IMAGES] --docker-allowed-services Whitelist allowed services [$DOCKER_ALLOWED_SERVICES] --docker-p_w_picpath-ttl [$DOCKER_IMAGE_TTL] --parallels-base-name VM name to be used [$PARALLELS_BASE_NAME] --parallels-template-name VM template to be created [$PARALLELS_TEMPLATE_NAME] --parallels-disable-snapshots Disable snapshoting to speedup VM creation [$PARALLELS_DISABLE_SNAPSHOTS] --virtualbox-base-name VM name to be used [$VIRTUALBOX_BASE_NAME] --virtualbox-disable-snapshots Disable snapshoting to speedup VM creation [$VIRTUALBOX_DISABLE_SNAPSHOTS]
要讓一個Runner運行起來，--url、--token和--executor選項是必要的。其他選項可根據具體情況和需求進行設置。我們可以看出來，這個命令裏面的選項跟配置文件中Runner的配置項基本上是一樣的。那這個命令的運行和配置文件有沒有什麼關係呢？從我的試驗和思考來看，應該是沒有什麼關係的。因爲：
這個命令裏面並沒有指定配置文件位置的選項，如果讀取配置文件難道去讀取默認位置嗎？但是配置文件的位置是可以指定的，不一定在默認位置，這不符合邏輯，所以它應該不會去讀配置文件。
我刪掉配置文件，這個命令依然能夠運行
所以，這個命令應該只是一個能讓Runner運行起來的基礎命令。但這個命令運行起來的前提是，GitLab-CI中必須事先註冊有這個Runner。
那配置文件有毛用？配置文件的作用在後面，但是從這裏我們知道一點：配置文件裏面有Runner運行時所需要的信息。
可能你還有一個問題：我用root的用戶註冊Runner時，註冊完Runner就可以用了，並沒有手動地去運行Runner啊？這個後面講。
批量地運行Runner
正常情況下，如果我有多個Runner，我並不想手動一個個地運行，要是能一次運行多個Runner多爽啊！嗯哼，gitlab-ci-multi-runner就提供了這樣一個命令gitlab-ci-multi-runner run，詳情如下：
[root@iZ25bjcxoq5Z gitlab-runner]# gitlab-ci-multi-runner run --helpNAME: run - run multi runner service USAGE: command run [command options] [arguments...] OPTIONS: -c, --config "/etc/gitlab-runner/config.toml" Config file [$CONFIG_FILE] -n, --service "gitlab-runner" Use different names for different services -d, --working-directory Specify custom working directory -u, --user Use specific user to execute shell scripts --syslog Log to syslog
這個命令總共有5個選項，讓我們從選項來理解一下這個命令：
-c, --config選項
這個選項是用來指定配置文件路徑的。如果你想同時運行多個Runner，你必須得知道你要運行哪些Runner以及這些Runner運行時所需要的信息。而前面我們說過，配置文件裏面就存放着Runner運行時所需要的信息。而且一個配置文件是可以存放多個Runner的信息的。如果不指定這個選項，就會使用默認的配置文件。-n, --service選項
這個選項是用來指定服務的別名的。爲什麼要有這個選項呢？指定別名有什麼意義呢？我們從上一個選項可以看出來，一次只能運行一批Runner，因爲一次只能指定一個配置文件。那如果我有多個配置文件，我要運行多批Runner，那是不是給每一次批量運行服務取不同的別名來區分更好一點呢。-d, --working-directory選項
這個選項是用來指定此次批量運行服務的工作目錄的。如果自己沒有指定builds_dir的話，此次運行起來的Runner會把builds_dir放到這個目錄裏面。-u, --user選項
這個選項很重要，它指定了該以什麼用戶權限來運行Runner。爲了安全，我認爲不應該給運行Runner的用戶過高的權限，更不應該以root用戶來運行Runner。--syslog選項
如果指定了這個選項，則把日誌記錄到系統日誌。
使用服務
能夠批量地運行Runner已經很好了，但是還不夠好，爲什麼呢？
首先，gitlab-ci-multi-runner run默認是前臺運行的，使用體驗不好；
其次，當gitlab-ci-multi-runner run在後臺運行的時候，要查看其運行狀態不方便，而且也沒有提供停止gitlab-ci-multi-runner run的命令。
所以，要是能將批量運行Runner這個功能安裝爲一項服務，就更爽了！
gitlab-ci-multi-runner確實就提供了這樣的功能。install、uninstall、start、stop、restart、status這6個命令就是和服務相關的。
我一開始對gitlab-ci-multi-runner的服務概念感覺比較懵，讓我們來看看安裝服務install這個命令到底幹了一件什麼事情。
[root@iZ25bjcxoq5Z ~]# gitlab-ci-multi-runner install --helpNAME: install - install serviceUSAGE: command install [command options] [arguments...] OPTIONS: --service, -n "gitlab-runner" Specify service name to use --working-directory, -d "/root" Specify custom root directory where all data are stored --config, -c "/etc/gitlab-runner/config.toml" Specify custom config file --user, -u Specify user-name to secure the runner
從選項可以看出，一項服務的信息有4個：服務名、工作目錄、配置文件和用戶。這個命令的選項和gitlab-ci-multi-runner run的選項基本一樣。可見，批量運行Runner和服務之間的關係曖昧。至於是什麼關係，往下看gitlab-ci-multi-runner start這個命令。
[root@iZ25bjcxoq5Z ~]# gitlab-ci-multi-runner start --helpNAME: start - start serviceUSAGE: command start [command options] [arguments...] OPTIONS: --service, -n "gitlab-runner" Specify service name to use
啓動一項服務，只要指定服務的名稱就行了（默認服務名稱是gitlab-runner）。啓動服務後，運行命令ps -aux | grep gitlab-runner查看後臺程序，發現啓動服務其實就是在後臺執行了一個批量運行Runner的任務，所以服務安裝命令的選項纔會和批量運行Runner命令的選項基本一樣。
root 18219 0.0 0.1 331872 5332 ? Ssl 00:06 0:00 /usr/bin/gitlab-ci-multi-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --user gitlab-runner --syslog
還有stop命令用於停止服務，restart命令用於重啓服務，status用於查看服務狀態。這三個命令的使用方法和start類似，就不一一介紹了。
五、其他一些思考
什麼情況下需要註冊Shared Runner？
比如，GitLab上面所有的工程都有可能需要在公司的服務器上進行編譯、測試、部署等工作，這個時候註冊一個Shared Runner供所有工程使用就很合適。什麼情況下需要註冊Specific Runner？
比如，我可能需要在我個人的電腦或者服務器上自動構建我參與的某個工程，這個時候註冊一個Specific Runner就很合適。什麼情況下需要在同一臺機器上註冊多個Runner？
比如，我是GitLab的普通用戶，沒有管理員權限，我同時參與多個項目，那我就需要爲我的所有項目都註冊一個Specific Runner，這個時候就需要在同一臺機器上註冊多個Runner。
六、最後
囉囉嗦嗦寫了一堆，大體上也算把自己對GitLab-Runner的理解過程寫清楚了。爲了把GitLab-Runner的用法瞭解清楚，自己做了很多的測試，但也難全面，中間有一些內容也只是個人理解，未必準確，歡迎批評指正。
文／tsyeyuanfeng（簡書作者）
原文鏈接：http://www.jianshu.com/p/2b43151fb92e
著作權歸作者所有，轉載請聯繫作者獲得授權，並標註“簡書作者”。
附加IOS項目的持續集成；
當然gitlab的CI功能要考runner來完成了，首先必須配置一個runner，由於項目是IOS的，所以需要在安裝了mac操作系統和Xcode的環境下才能編譯，打包我們的APP；基本原來就是在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.s3.amazonaws.com/latest/binaries/gitlab-c9-multi-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-ci-multi-runner
進入到項目的Runner配置頁面，查看項目的runner信息，然後在mac機器上執行如下命令來進行註冊動作，並綁定到指定的項目
a.gitlab-ci-multi-runner register:輸入相應的URL
b.輸入項目的token
c.輸入一個對於項目的描述
d.輸入一些標籤
e.提示輸入編譯的方式，當然有很多，這裏根據自己的選擇，一般會選擇shell的方式，因爲用腳本來執行一系列的動作
註冊成功了
gitlab-ci-multi-runner install
再去查看項目的runner信息，就會看見註冊成功的runner信息了
下面當然就是腳本了，我們採用yaml的腳本來執行，在項目的根目錄下創建gitlab-ci.yml文件，內容如下：
stages:
- build - archivebuild_project:
stage: build
script:
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo clean - xctool -project ioscidemo.xcodeproj -scheme ioscidemo test -test-sdk iphonesimulator9.3archive_poject:
stage: archive
script:
- xctool -project ioscidemo.xcodeproj -scheme ioscidemo archive -archivePath build/ioscidemo - xcodebuild -exportArchive -exportFormat ipa -archivePath "build/ioscidemo.xcarchive" -exportPath "build/ioscidemo.ipa" only:
- master artifacts:
paths:
- build/ioscidemo.ipa
上面的腳本使用了xctool,它是Facebook推出的一款替代xcodebuild的app打包工具，它的日誌輸入更加友好，性能高效，當然要使用它，要先在mac上安裝它，很簡單：brew install xctool
當然餘下的就是測試一下，通過代碼更新的方式，來檢驗一下你的runner吧
最後就剩下CD的工作了，這裏的CD是指持續發佈了；apple給我們提供了一套命令行工具altool，可以直接把ipa上傳到itunesconnect,很方便，大家自己去嘗試一下吧
這個小過程到此結束，謝謝