安裝GitLab Runner
本教程的安裝環境為Ubuntu18.04。
運作以下指令增加GitLab官方倉庫：
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
安裝最新版本的GitLab Runner，或者選擇特定的版本：
安裝最新版本
sudo apt-get install gitlab-runner
選擇特定的版本
sudo apt-get install gitlab-runner=10.0.0
注冊GitLab Runner
此處是将你的GitLab Runner注冊到GitLab page上，讓GitLab page可以和你的Runner通信。
先決條件
在注冊Runner之前，你首先需要：
安裝好Runner的Linux主機
從GitLab page上獲得token
注冊
運作如下指令：
sudo gitlab-runner register
輸入GitLab URL：
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://code.siemens.com/
注意：你可以通過GitLab page -> Settings -> CI/CD -> Runners來獲得URL，當然前提條件是你有權限進入這些頁面。
RegisterRunner.PNG
輸入你的注冊token：
Please enter the gitlab-ci token for this runner
xxx
在步驟2中你也可以同時看到 token資訊
輸入對這個Runner的表述(同時也是這個Runner的名字)，當然，你也可以稍後在GitLab page上修改它：
Please enter the gitlab-ci description for this runner
[hostame] my-runner
輸入Runner的tag，稍後你同樣可以在GitLab page上修改它：
Please enter the gitlab-ci tags for this runner (comma separated):
my-tag,another-tag
注意 tag可以有多個，各 tag之間用逗号隔開。如果你使用了多個 tag，那麼當你想用這個 Runner時，在.gitlab-ci.yml的 tag字段裡也必須明确指明這些 tags。
輸入Runner的executor：
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
docker
如果你選擇Docker作為Runner的executor，你還要選擇預設的docker image來運作job(當然，你也可以在.gitlab-ci.yml裡指明你需要用的image)：
Please enter the Docker image (eg. ruby:2.1):
alpine:latest
注冊完成後你可以在/etc/gitlab-runner裡發現 config.toml檔案，該檔案是Runner的配置檔案
使用GitLab Runner
直接運作Runner
sudo gitlab-runner run
将Runner作為一個服務
将GitLab Runner安裝為系統服務：
sudo gitlab-runner install -n "" -u
啟動服務：
sudo gitlab-runner start -n ""
注意：這些服務相關的指令是不推薦的并且将會在接下來的版本中删除。
想要了解更多GitLab Runner相關的指令，請通路GitLab Runner Commands.
重要的話題 —— Executor
Shell Executor
以主控端(此處為Ubuntu18.04系統)作為Runner的所有jobs的執行器。
Runner将會從遠端倉庫pull你的工程，工程的目錄為：/builds。
如果你使用了cache，那麼cache将會存在/cache//。
想了解更多關于Shell executor的内容，請通路Shell Executor。
Docker Executor
所有jobs的執行環境為指定的docker image所生成的container，每個job都會生成一個container并且在job結束後立即銷毀。
Docker executor預設将所有的builds存儲在/builds//(這裡的路徑是container裡的路徑，Runner配置檔案config.toml裡的build_dir字段可以重新指明build的目錄，預設對應于主控端的目錄是在主控端的docker volume下：/var/lib/docker/volumes//_data/)，預設将所有的caches存儲在container裡的/cache目錄(config.toml裡的cache_dir字段可以重新指明cache的目錄)，注意build_dir和cache_dir指向的均是container裡的目錄，要想将container裡的資料持久化，需要用到volumes字段，這個字段的使用和docker volume的使用是類似的，隻需在config.toml的[runner.docker]部分添加volumes = ["/cache", ":rw"]即可實作container裡/cache目錄資料的永久儲存以及将host目錄挂載到相應的container目錄并具有讀寫的功能。
當你使用docker 或 docker+machine executors時，你可以通過設定pull_policy來決定Runner如何pull docker image。pull_policy有三種值：
always —— Runner始終從遠端pull docker image。
if-not-present —— Runner會首先檢查本地是否有該image，如果有則用本地的，如果沒有則從遠端拉取。
never —— Runner始終使用本地的image。
當你使用docker, docker+machine 或 kubernetes作為executor時，GitLab Runner将會使用特定的container來處理Git、artifacts 和cache 操作。通過在主控端中鍵入以下指令：
sudo docker images
你會發現一些特殊的images，如：
REPOSITORY TAG
gitlab/gitlab-runner-helper x86_64-3afdaba6
gitlab/gitlab-runner-helper x86_64-cf91d5e1
當然，你也可以通過配置config.toml裡的helper_image字段來讓Runner使用你自己定制化的helper image。
想要了解更多關于docker executor的資訊，請通路docker executor。
常見問題
當在Ubuntu18.04上使用docker executor runner時，出現Runner無法連接配接網絡的問題
這個是Ubuntu18.04與Docker的問題，是關于主控端與Container的DNS的映射問題，詳情可以通路https://github.com/docker/libnetwork/issues/2187。
你的pipeline可能出現如下情況：
fatal: unable to access 'https://gitlab-ci-token:[email protected]/zhen.xie/iavgitlabrunnertest.git/': Could not resolve host: code.siemens.com
該問題的解決辦法是在Runner的配置檔案config.toml裡增加dns = ["***.***.***.***"]，dns的值你可以通過在主控端上運作nmcli dev show來獲得。
Pipeline出現"JAVA_HOME is not set and no java command could be found in your PATH"
這個錯誤通常出現在你使用Shell executor時，你可以在GitLab page上設定這個環境變量，具體路徑是GitLab page -> Settings -> CI/CD -> Variables。
如何配置GitLab Runner
Runner間隔多久去GitLab上檢查是否有job
config.toml檔案的check_interval字段會決定這個時間間隔，它的預設值是3秒(注意當你把它設為0時依然采用的是預設值3秒，而不是0秒)。要解釋它的意義，首先我們先來定義worker，在config.toml檔案中定義了很多runner，它們可能executor類型不同，可能注冊位址不同，但都是由GitLab Runner這個服務來管理的，為了與GitLab Runner區分開，我們将config.toml檔案中定義的runner稱為worker。對于不同的worker，worker之間(如worker A ---> worker B)的間隔為check_interval / worker_nums，但是對于worker A本身來說它下次去檢查是否有job的時間間隔仍為check_interval。我們再舉個簡單例子：config.toml定義了3個worker—— worker A, worker B 和 worker C，check_interval采用預設值為3秒，第0秒時worker A會去檢查是否有屬于自己的job，第1秒時worker B會去檢查，第2秒時worker C去檢查，第3秒時worker A再檢查……這個過程中worker A到worker B的間隔為3 / 3 = 1秒，而對于worker A下次檢查job時的時間間隔為check_interval，即3秒。
config.toml裡的concurrent字段的意義
concurrent限制了整個GitLab Runner能并發處理job的數量。特别注意concurrent與worker數量無任何關系，所有worker的工作是受GitLab Runner控制的，如果concurrent值為1并且有一個worker已經在工作了，那麼即使其他worker達到了可以工作的條件也隻能“pending”。
cache存儲在哪裡
怎樣清除cache
注意cache是沒有過期時間的，而且每一次新的push觸發的pipeline，都會重新生成cache，重新生成的cache的名字為“-”，其中num是随着push數量遞增的。如果不去清除cache，cache會永久保留在Runner上，日積月累會填滿存儲空間的，是以最好隔一段時間進行一次清除，清除方法請參考https://docs.gitlab.com/ee/ci/caching/#clearing-the-cache，或者使用clear_volumes.sh 這個簡單腳本來處理它, 清除cache的原理是将相關的volume移除，當然，docker也有自帶的清除指令，推薦将docker system prune -f --volumes加入到定時任務中。
GitLab Runner 變量的優先級
GitLab Runner有哪些預定義的變量
當我的Runner采用docker作為executor時，無法build docker image
這是個“dind(docker in docker)” 問題，一般pipeline會報如下錯誤：
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
time="2018-12-17T11:12:33Z" level=error msg="failed to dial gRPC: cannot connect to the Docker daemon. Is 'docker daemon' running on this host?: dial unix
你可以将本地的docker socket綁定到container裡來解決這個問題，具體方法是将volumes = ["/var/run/docker.sock:/var/run/docker.sock"]配置到config.toml檔案裡。
如何在job所對應的container裡使用git clone指令
如果你想在job運作期間clone某些代碼(如shell或python的腳本)，首先要確定你的主控端有權限clone代碼，然後你就可以将你的secret挂載到container裡，例如，你是通過ssh的方式克隆代碼，并且你的ssh目錄為home//.ssh，你就可以在config.toml檔案裡添加如下配置：
volumes = ["/home/x1twbm/.ssh:/root/.ssh:ro"]
然後，這個job所對應的container就可以拉取指定代碼了。