GitLab-CI與GitLab-Runner

時間  2019-11-15
標籤 gitlab runner 欄目 Git 简体版
原文   原文鏈接

1、持續集成（Continuous Integration）

要了解GitLab-CI與GitLab Runner，咱們得先了解持續集成是什麼。ios

持續集成是一種軟件開發實踐，即團隊開發成員常常集成他們的工做，一般每一個成員天天至少集成一次，也就意味着天天可能會發生屢次集成。每次集成都經過自動化的構建（包括編譯，發佈，自動化測試)來驗證，從而儘快地發現集成錯誤。許多團隊發現這個過程能夠大大減小集成的問題，讓團隊可以更快的開發內聚的軟件。git

看完這段話，估計仍是有點懵。怎麼理解呢？我是這樣理解的：sql

軟件集成是軟件開發過程當中的一個環節，這個環節的工做通常會包括如下流程：合併代碼---->安裝依賴---->編譯---->測試---->發佈。軟件集成的工做通常會比較細碎繁瑣，爲了避免影響開發效率，之前軟件集成這個環節通常不會常常進行或者只會等到項目後期再進行。可是有些問題，若是等到後期才發現，解決問題的代價很大，有可能致使項目延期或者失敗。所以，爲了儘早發現軟件集成錯誤，鼓勵團隊成員應該常常集成他們的工做，一般每一個成員天天應該至少集成一次。這就是所說的持續集成。因此說，持續集成是一種軟件開發實踐。docker

軟件集成的工做細碎繁瑣，之前是由人工完成的。可是如今鼓勵持續集成，那豈不是要累死人，還影響開發效率。因此，應該考慮將軟件集成這個工做自動化，這就出現了所謂的持續集成系統。shell

持續集成詳情見百度百科-持續集成xcode

2、GitLab-CI

GitLab-CI就是一套配合GitLab使用的持續集成系統（固然，還有其它的持續集成系統，一樣能夠配合GitLab使用，好比Jenkins）。並且GitLab8.0之後的版本是默認集成了GitLab-CI而且默認啓用的。安全

3、GitLab-Runner

那GitLab-Runner又是什麼東東呢？與GitLab-CI有什麼關係呢？ruby

GitLab-Runner是配合GitLab-CI進行使用的。通常地，GitLab裏面的每個工程都會定義一個屬於這個工程的軟件集成腳本，用來自動化地完成一些軟件集成工做。當這個工程的倉庫代碼發生變更時，好比有人push了代碼，GitLab就會將這個變更通知GitLab-CI。這時GitLab-CI會找出與這個工程相關聯的Runner，並通知這些Runner把代碼更新到本地並執行預約義好的執行腳本。bash

因此，GitLab-Runner就是一個用來執行軟件集成腳本的東西。你能夠想象一下：Runner就像一個個的工人，而GitLab-CI就是這些工人的一個管理中心，全部工人都要在GitLab-CI裏面登記註冊，而且代表本身是爲哪一個工程服務的。當相應的工程發生變化時，GitLab-CI就會通知相應的工人執行軟件集成腳本。以下圖所示：
服務器

1240

GitLab-CI與GitLab-Runner關係示意圖

Runner能夠分佈在不一樣的主機上，同一個主機上也能夠有多個Runner。

Runner類型

GitLab-Runner能夠分類兩種類型：Shared Runner（共享型）和Specific Runner（指定型）。

Shared Runner：這種Runner（工人）是全部工程都可以用的。只有系統管理員可以建立Shared Runner。

Specific Runner：這種Runner（工人）只能爲指定的工程服務。擁有該工程訪問權限的人都可以爲該工程建立Shared Runner。

4、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。以下圖所示：

1240

Shared Runner

若是要註冊Specific Runner，你須要到項目的設置的Runner頁面裏面去找註冊token。以下圖所示：

1240

Specific Runner

找到token以後，運行下面這條命令註冊Runner（固然，除了url和token以外，還須要其餘的信息，好比執行器executor、構建目錄builds_dir等）。
gitlab-ci-multi-runner register
註冊完成以後，GitLab-CI就會多出一條Runner記錄，以下圖所示：

1240

GitLab-CI Runner

GitLab-CI會爲這個Runner生成一個惟一的token，之後Runner就經過這個token與GitLab-CI進行通訊。

那麼，問題來了。註冊好了的Runner的信息存放在哪兒了呢？
原來，Runner的信息是存放在一個配置文件裏面的，配置文件的格式通常是.toml。這個配置文件的存放位置有如下幾種狀況：

  • 在類Unix操做系統下（0.5.0以後版本）

  1. 若是是以root用戶身份運行gitlab-ci-multi-runner register，那麼配置文件默認是/etc/gitlab-runner/config.toml

  2. 若是是以非root用戶身份運行gitlab-ci-multi-runner register，那麼配置文件默認是~/.gitlab-runner/config.toml

在其餘操做系統下以及0.5.0以前版本配置文件默認在當前工做目錄下./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的配置項基本上是同樣的。那這個命令的運行和配置文件有沒有什麼關係呢？從個人試驗和思考來看，應該是沒有什麼關係的。由於：

  1. 這個命令裏面並無指定配置文件位置的選項，若是讀取配置文件難道去讀取默認位置嗎？可是配置文件的位置是能夠指定的，不必定在默認位置，這不符合邏輯，因此它應該不會去讀配置文件。

  2. 我刪掉配置文件，這個命令依然可以運行

因此，這個命令應該只是一個能讓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相似，就不一一介紹了。

5、其餘一些思考

  1. 什麼狀況下須要註冊Shared Runner？
    好比，GitLab上面全部的工程都有可能須要在公司的服務器上進行編譯、測試、部署等工做，這個時候註冊一個Shared Runner供全部工程使用就很合適。

  2. 什麼狀況下須要註冊Specific Runner？
    好比，我可能須要在我我的的電腦或者服務器上自動構建我參與的某個工程，這個時候註冊一個Specific Runner就很合適。

  3. 什麼狀況下須要在同一臺機器上註冊多個Runner？
    好比，我是GitLab的普通用戶，沒有管理員權限，我同時參與多個項目，那我就須要爲個人全部項目都註冊一個Specific Runner，這個時候就須要在同一臺機器上註冊多個Runner。

6、最後

囉囉嗦嗦寫了一堆，大致上也算把本身對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服務器，廢話不說的說，演示以下：


  1. 在一臺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

  2. 進入到項目的Runner配置頁面，查看項目的runner信息，而後在mac機器上執行以下命令來進行註冊動做，並綁定到指定的項目

    a.gitlab-ci-multi-runner register:輸入相應的URL

    b.輸入項目的token

    c.輸入一個對於項目的描述

    d.輸入一些標籤

    e.提示輸入編譯的方式，固然有不少，這裏根據本身的選擇，通常會選擇shell的方式，由於用腳原本執行一系列的動做

    註冊成功了

  3. gitlab-ci-multi-runner install

    再去查看項目的runner信息，就會看見註冊成功的runner信息了

  4. 下面固然就是腳本了，咱們採用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

  5. 上面的腳本使用了xctool,它是Facebook推出的一款替代xcodebuild的app打包工具，它的日誌輸入更加友好，性能高效，固然要使用它，要先在mac上安裝它，很簡單：brew install xctool

  6. 固然餘下的就是測試一下，經過代碼更新的方式，來檢驗一下你的runner吧

  7. 最後就剩下CD的工做了，這裏的CD是指持續發佈了；apple給咱們提供了一套命令行工具altool，能夠直接把ipa上傳到itunesconnect,很方便，你們本身去嘗試一下吧

  8. 這個小過程到此結束，謝謝

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程