GitLab-Runner-入門及常見問題

安裝GitLab Runner

本教程的安裝環境爲Ubuntu18.04。html

  1. 運行如下命令增長GitLab官方倉庫:java

    curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
  2. 安裝最新版本的GitLab Runner,或者選擇特定的版本:python

    • 安裝最新版本git

      sudo apt-get install gitlab-runner
    • 選擇特定的版本github

      sudo apt-get install gitlab-runner=10.0.0

註冊GitLab Runner

此處是將你的GitLab Runner註冊到GitLab page上,讓GitLab page能夠和你的Runner通訊。docker

先決條件

在註冊Runner以前,你首先須要:shell

  • 安裝好Runner的Linux主機
  • 從GitLab page上得到token

註冊

  1. 運行以下命令:ruby

    sudo gitlab-runner register
  2. 輸入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,固然前提條件是你有權限進入這些頁面。
    RegisterRunner.PNG網絡

  3. 輸入你的註冊token:

    Please enter the gitlab-ci token for this runner  
    xxx

    在步驟2中你也能夠同時看到 token信息

  4. 輸入對這個Runner的表述(同時也是這個Runner的名字),固然,你也能夠稍後在GitLab page上修改它:

    Please enter the gitlab-ci description for this runner  
    [hostame] my-runner
  5. 輸入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。

  6. 輸入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做爲一個服務

    1. 將GitLab Runner安裝爲系統服務

      sudo gitlab-runner install -n "<service-name>" -u <user-name>
    2. 啓動服務:

      sudo gitlab-runner start -n "<service-name>"

      注意:這些服務相關的命令是不推薦的而且將會在接下來的版本中刪除。

想要了解更多GitLab Runner相關的命令,請訪問GitLab Runner Commands.


重要的話題 —— Executor

Shell Executor

以宿主機(此處爲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

Docker Executor

全部jobs的執行環境爲指定的docker image所生成的container,每一個job都會生成一個container而且在job結束後當即銷燬。

  • build和cache的存儲

    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_dircache_dir指向的均是container裏的目錄,要想將container裏的數據持久化,須要用到volumes字段,這個字段的使用和docker volume的使用是相似的,只需在config.toml[runner.docker]部分添加volumes = ["/cache", "<host_dir:container_dir>:rw"]便可實現container裏/cache目錄數據的永久保存以及將host目錄掛載到相應的container目錄並具備讀寫的功能。

  • Pull policies

    當你使用dockerdocker+machine executors時,你能夠經過設置pull_policy來決定Runner如何pull docker image。pull_policy有三種值:
    always —— Runner始終從遠程pull docker image。
    if-not-present —— Runner會首先檢查本地是否有該image,若是有則用本地的,若是沒有則從遠程拉取。
    never —— Runner始終使用本地的image。

  • Helper image

    當你使用docker, docker+machinekubernetes做爲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/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來得到。

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

請參考https://docs.gitlab.com/runne...

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秒。

官方文檔對check_interval的解釋:https://docs.gitlab.com/runne...

config.toml裏的concurrent字段的意義

concurrent限制了整個GitLab Runner能併發處理job的數量。特別注意concurrentworker數量無任何關係,全部worker的工做是受GitLab Runner控制的,若是concurrent值爲1而且有一個worker已經在工做了,那麼即便其餘worker達到了能夠工做的條件也只能「pending」。

cache存儲在哪裏

請參考https://docs.gitlab.com/ee/ci...

怎樣清除cache

注意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加入到定時任務中。

GitLab Runner 變量的優先級

請參考https://docs.gitlab.com/ee/ci...

GitLab Runner有哪些預約義的變量

請參考https://docs.gitlab.com/ee/ci...

當個人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文件裏。

想要了解更多關於「dind」的信息,請參考https://docs.gitlab.com/ee/ci...

如何在job所對應的container裏使用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就能夠拉取指定代碼了。

相關文章
相關標籤/搜索