本教程的安裝環境爲Ubuntu18.04。html
運行如下命令增長GitLab官方倉庫:java
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
安裝最新版本的GitLab Runner,或者選擇特定的版本:python
安裝最新版本git
sudo apt-get install gitlab-runner
選擇特定的版本github
sudo apt-get install gitlab-runner=10.0.0
此處是將你的GitLab Runner註冊到GitLab page上,讓GitLab page能夠和你的Runner通訊。docker
在註冊Runner以前,你首先須要:shell
運行以下命令:ruby
sudo gitlab-runner register
輸入GitLab URL:bash
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com ) https://code.siemens.com/
注意:你能夠經過GitLab page -> Settings -> CI/CD -> Runners
來得到URL,固然前提條件是你有權限進入這些頁面。網絡
輸入你的註冊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的配置文件
直接運行Runner
sudo gitlab-runner run
將Runner做爲一個服務
想要了解更多GitLab Runner相關的命令,請訪問GitLab Runner Commands.
以宿主機(此處爲Ubuntu18.04系統)做爲Runner的全部jobs的執行器。
Runner將會從遠程倉庫pull你的工程,工程的目錄爲:<working-directory>/builds/<short-token>/<concurrent-id>/<namespace>/<project-name>
。
若是你使用了cache,那麼cache將會存在<working-directory>/cache/<namespace>/<project-name>
。
想了解更多關於Shell executor的內容,請訪問Shell Executor。
全部jobs的執行環境爲指定的docker image所生成的container,每一個job都會生成一個container而且在job結束後當即銷燬。
Docker executor默認將全部的builds存儲在/builds/<namespace>/<project-name>
(這裏的路徑是container裏的路徑,Runner配置文件config.toml
裏的build_dir
字段能夠從新指明build的目錄,默認對應於宿主機的目錄是在宿主機的docker volume下:/var/lib/docker/volumes/<volume-id>/_data/<project-name>
),默認將全部的caches存儲在container裏的/cache
目錄(config.toml
裏的cache_dir
字段能夠從新指明cache的目錄),注意build_dir
和cache_dir
指向的均是container裏的目錄,要想將container裏的數據持久化,須要用到volumes
字段,這個字段的使用和docker volume的使用是相似的,只需在config.toml
的[runner.docker]
部分添加volumes = ["/cache", "<host_dir:container_dir>: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的問題,是關於宿主機與Container的DNS的映射問題,詳情能夠訪問https://github.com/docker/lib...。
你的pipeline可能出現以下狀況:
fatal: unable to access 'https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@code.siemens.com/zhen.xie/iavgitlabrunnertest.git/': Could not resolve host: code.siemens.com
該問題的解決辦法是在Runner的配置文件config.toml
裏增長dns = ["***.***.***.***"]
,dns的值你能夠經過在宿主機上運行nmcli dev show
來得到。
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
。
請參考https://docs.gitlab.com/runne...。
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秒。
官方文檔對check_interval
的解釋:https://docs.gitlab.com/runne...。
config.toml
裏的concurrent
字段的意義concurrent
限制了整個GitLab Runner能併發處理job的數量。特別注意concurrent
與worker數量無任何關係,全部worker的工做是受GitLab Runner控制的,若是concurrent
值爲1而且有一個worker已經在工做了,那麼即便其餘worker達到了能夠工做的條件也只能「pending」。
請參考https://docs.gitlab.com/ee/ci...
注意cache是沒有過時時間的,並且每一次新的push觸發的pipeline,都會從新生成cache,從新生成的cache的名字爲「<cache-key>-<num>」,其中num是隨着push數量遞增的。若是不去清除cache,cache會永久保留在Runner上,日積月累會填滿存儲空間的,所以最好隔一段時間進行一次清除,清除方法請參考https://docs.gitlab.com/ee/ci...,或者使用clear_volumes.sh 這個簡單腳原本處理它, 清除cache的原理是將相關的volume移除,固然,docker也有自帶的清除命令,推薦將docker system prune -f --volumes
加入到定時任務中。
請參考https://docs.gitlab.com/ee/ci...
請參考https://docs.gitlab.com/ee/ci...
這是個「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
文件裏。
想要了解更多關於「dind」的信息,請參考https://docs.gitlab.com/ee/ci...。
git clone
命令若是你想在job運行期間clone某些代碼(如shell或python的腳本),首先要確保你的宿主機有權限clone代碼,而後你就能夠將你的secret掛載到container裏,例如,你是經過ssh的方式克隆代碼,而且你的ssh目錄爲home/<user>/.ssh
,你就能夠在config.toml
文件裏添加以下配置:
volumes = ["/home/x1twbm/.ssh:/root/.ssh:ro"]
而後,這個job所對應的container就能夠拉取指定代碼了。