一、持續集成(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就會通知相應的工人執行軟件集成腳本。如下圖所示:
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。如下圖所示:
如果要注冊Specific Runner,你需要到項目的設置的Runner頁面里面去找注冊token。如下圖所示:
找到token之后,運行下面這條命令注冊Runner(當然,除了url和token之外,還需要其他的信息,比如執行器executor
、構建目錄builds_dir
等)。
gitlab-ci-multi-runner register
注冊完成之后,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
- 在其他操作系統下以及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 --help
NAME:
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-image Docker image 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-images Whitelist allowed images [$DOCKER_ALLOWED_IMAGES]
--docker-allowed-services Whitelist allowed services [$DOCKER_ALLOWED_SERVICES]
--docker-image-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 --help
NAME:
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 --help
NAME:
install - install service
USAGE:
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 --help
NAME:
start - start service
USAGE:
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的用法了解清楚,自己做了很多的測試,但也難全面,中間有一些內容也只是個人理解,未必準確,歡迎批評指正。