gitlab-ci坑后感與指北

jerry 發(fā)布于2019-06-28 17:55 / 3141人閱讀

摘要：本文的目的最主要是備忘其次是分享療效并不能讓你一下子掌握這只是一個比較完整的解決方案其他基礎知識自行補充基調(diào)首先這不是屠龍刀不要奢望一篇文章可以走遍天下這里只是提供一個具體的落地方案一個具體的技術選型階段代碼倉庫關于代碼倉庫本文選取的方案是

本文的目的:

最主要是備忘, 其次是分享

療效:

并不能讓你一下子掌握CI/CD, 這只是一個比較完整的解決方案,其他基礎知識,自行補充.

基調(diào)

首先,這不是屠龍刀,不要奢望一篇文章可以走遍天下.這里只是提供一個具體的落地方案, 一個具體的技術選型.

階段1: 代碼倉庫

關于 代碼倉庫, 本文選取的方案是 gitlab

gitlab的搭建:

以目前的情況來說, 推薦使用docker來搭建你的系統(tǒng), 不然你會陷入各種膜明其妙的問題.

docker的知識, 請自行補充一下,篇幅有限不能展開細說.

在這里我推薦一個:

https://hub.docker.com/r/sameersbn/gitlab/

打開以后直接搜索Quick Start, 按照docker-compose的方式啟動你的gitlab.

不要對英文心存恐懼 ---- 孔子

下載好 docker-compose.yml之后不要急著啟動, 需要修改幾個參數(shù):

需要學習一點點yml的知識, 大約5分鐘, 自行google

GITLAB_SECRETS_DB_KEY_BASE,

GITLAB_SECRETS_SECRET_KEY_BASE,

GITLAB_SECRETS_OTP_KEY_BASE

上面三個是gitlab用于加密時用的key, 隨便給個長度64的字符串, 這塊不做深究.

GITLAB_ROOT_EMAIL

GITLAB_ROOT_PASSWORD

上面兩個就是初始化時管理員賬號的賬號密碼, 按自己的需要填寫

GITLAB_HOST

這是 gitlab 內(nèi)部使用的地址, 這關系到你gitlab頁面上的項目地址,沒設置的話, 到時候顯示的是127.0.0.1, 這個鬼才能clone下來.

這個 host 一旦設置, 初始化完就改不了了, 所以一定要在第一次啟動之前 就設置好.

啟動

docker-compose up

一系列的初始化信息以后, 你就能訪問你的gitlab了.

默認是 http://{你的IP}:10080

其他關于gitlab的使用技巧, 就不深入了.
能關注這篇文章的都不是萌新了,這些內(nèi)容自己補充吧.

階段2: 提交觸發(fā)

接上文.

gitlab-ci在最新版的gitlab已經(jīng)是內(nèi)置的了, 只要項目里有.gitlab-ci.yml,同時有對應的gitlab-runner, 就能實現(xiàn)CI, 相比之下不需要太多的配置.

名詞解釋:

.gitlab-ci.yml:

這是gitlab-ci使用的任務描述文件, 里面主要是定義CI的過程需要執(zhí)行哪些行為, 簡單說就是, 要進行哪幾個步驟, 每個步驟是哪些命令.

gitlab-runner:

另一個程序, 也可以用docker啟動, 就是負責執(zhí)行 CI 任務的機器人, runner這塊后面會展開講.

啟動并注冊gitlab-runner

我們還是使用docker來啟動,這是一個大方向

docker run -d --name gitlab-runner --restart always 

-v /srv/gitlab-runner/config:/etc/gitlab-runner 

-v /var/run/docker.sock:/var/run/docker.sock 

gitlab/gitlab-runner:latest

想深入了解的話, 請看

https://docs.gitlab.com/runne...

敲黑板!!

在這里, 我們將宿主機的docker.sock映射進去,讓runner可以跟宿主用同一個daemon, (意味著你進去runner內(nèi)部執(zhí)行docker images是可以看到外面的鏡像列表的), 這樣做是埋下一個伏筆, 以便后面階段使用dind(docker in docker)時, 獲得更好的體驗.

繼續(xù)

好了, 這個時候你啟動了一個runner, 你要告訴它應該到哪里去"服役",

這一步叫做: 注冊

注冊runner的方式請看

https://docs.gitlab.com/runne...

不過, 還是請你使用以下命令來注冊:

docker exec -it gitlab-runner gitlab-runner register 

--docker-volumes /var/run/docker.sock:/var/run/docker.sock 

--docker-privileged

這里使用了兩個參數(shù), 都是為了 docker in docker 能得到更好的體驗而服務的.

輸入以上命令后, 根據(jù)提示填寫信息, 其中:

host,token 這些, 請打開你剛裝好的gitlab, 進入 Admin area-Runners ,然后照著填寫就是了

特別注意期間會讓你選一個executor 類型, 個人推薦最好的方式是docker , 至于shell這種方式, 玩玩可以,實際使用時副作用太多.

更多參數(shù)的細節(jié), 自行研究.

完成以上步驟之后, 你在gitlab - Admin area-Runners 頁面就能看到注冊好的runner了, 當然你現(xiàn)在還是感覺不到它的作用.

這個環(huán)節(jié)內(nèi)容比較多, 操作比較多, 走到這里建議休息一下喝杯茶.

階段3: Runner Job

這個階段, 是指代碼提交以后, gitlab-runner會自動讀取項目的.gitlab-ci.yml, 運行里面定義的每個Job.

這里給出一個極簡的.gitlab-ci.yml例子,

它做的就是, 在提交代碼以后, 自動的測試, 自動的構建, 自動的發(fā)布 :

stages:
  - test
  - build
  - deploy

job_01:
  stage: test
  image: dev_tool/node_builder:1.0.0
  script: 
   - npm install --registry=https://registry.npm.taobao.org
   - node server.js &
   - node test_api.js

job_02:
  stage: build
  image: gitlab/dind
  script:
  - docker build -t ci-demo:latest .
   
job_03:
  stage: deploy
  image: dev_tool/rancher-cli:latest
  script:
  - rancher-tool init
  - rancher up -d  --pull --force-upgrade --confirm-upgrade

一目了然, 上面的第一個定義: stages 數(shù)組,

意思是這個項目的CI/CD過程要執(zhí)行三個步驟(stage),

分別是test測試-build編譯-deploy發(fā)布

然后下面的三個job_*,名字是隨意的, 重點是里面的stage屬性,

告訴gitlab-ci這個任務是在哪個stage執(zhí)行的,

一個stage你可以寫很多個job

敲黑板!!!

需要注意的是, 我們之前選擇了docker executor, job里面就要聲明image屬性,指定這個Job的scripts要在哪個image里面運行.

重點說明!! 再次大力敲黑板!!

這里第二步使用了gitlab/dind , 仔細看script, 這是在一個容器里面去構建一個鏡像, 為了整體體驗與構建效率著想, 我們之前注冊runner的時候,將宿主機的docker.sock映射進去是十分必要的!!
(重新翻上去看吧)

看到這里, 聰明的朋友已經(jīng)發(fā)現(xiàn)了,

我們需要自己打造一批用于運行Job的基礎鏡像, 這些鏡像里要預先安裝好我們需要的依賴環(huán)境.

舉個栗子:

你要在build這一步做webpack打包的話, 你要準備好一個內(nèi)部安裝好webpack的鏡像(相關的node,npm之類就更不用說了)

聽起來好麻煩?

也不是, 這是個 功在當代,利在千秋 的行為, 前期打造好基礎鏡像, 后面的項目就可以很容易寫CI Job了.

更多 gitlab-ci.yml 的高級寫法,還是建議看官方文檔
https://docs.gitlab.com/ee/ci...

階段4: 坐享其成 && 總結

如果按照上面的步驟把這個系統(tǒng)搭建起來以后, 你應該已經(jīng)能夠感受到gitlab-ci帶來的好處了.

現(xiàn)在你只管提交代碼, 就能快速看到新功能集成到相應的環(huán)境了.

此后, 你只要寫好每一步的Job 就可以了.

尤其是測試這個環(huán)節(jié).

后記

gitlab 真的很吃資源, 虛擬機玩夠嗆, 團隊用的話, 建議裝一臺PC來搭建.

基礎鏡像別偷懶, 多打磨,讓你的scripts可以更簡潔

更進一步的話, 自己開發(fā)一系列的命令行工具, 讓你的scripts更強大.

有事找我, 包教會.

GPU云服務器云服務器指北入坑指北后感觀后感

文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/28033.html

持續(xù)集成之.gitlab-ci.yml篇

摘要：因為可以安裝到不同的機器上，所以在構建任務運行期間并不會影響到的性能。注冊打開中的項目頁面，在項目設置中找到在運行的機器上，用命令行注冊，比如按照提示一步一步安裝就可以了。任務將按此順序執(zhí)行。當然，這是不符合語義的。在介紹.gitlab-ci.yml之前，我們先看幾個概念： GitLab Runner 一般來說，構建任務都會占用很多的系統(tǒng)資源 (譬如編譯代碼)，而 GitLab CI...

Ajian 2019-06-28 17:23 評論0 收藏0
React Native項目自動化打包發(fā)布

摘要：所以在此給大家分享一下不使用構建工具實現(xiàn)項目自動化打包發(fā)布的思路。對于一個前端項目來說，自動化的構建是很有必要的，同時我們也可以通過實現(xiàn)更多的功能比如代碼檢測，單元測試等等。另外這種思路同樣適用于其他項目等前端項目，等移動端項目。今天這篇文章的目的是在rn項目的構建，并不會涉及到rn框架或者使用的講解，說起構建，特別是前端構建大家應該很快會想到webpack、Grunt、 Gulp等...

desdik 2019-08-22 18:05 評論0 收藏0
基于 GitLab CI 搭建前端自動構建環(huán)境

摘要：什么是持續(xù)集成持續(xù)集成，簡稱指的是，頻繁地一天多次將代碼集成到主干。如圖什么是一次其實相當于一次構建任務，里面可以包含多個流程，如安裝依賴運行測試編譯部署測試服務器部署生產(chǎn)服務器等流程。參考鏈接用進行持續(xù)集成什么是持續(xù)集成 ? 持續(xù)集成（Continuous integration，簡稱CI）指的是，頻繁地（一天多次）將代碼集成到主干。 GitLab CI 什么是 GitLab CI...

Warren 2019-08-22 18:40 評論0 收藏0
webkit內(nèi)核瀏覽器自定義滾動條樣式

摘要：滾動條兩端的按鈕。內(nèi)層軌道，滾動條中間部分除去。有如下功能若是水平滾動條，則屬性不起作用，屬性用來控制滾動條相應部分豎直方向高度若是豎直滾動條，則屬性不起作用，屬性用來控制相應部分的寬度。 CSS ::-webkit-scrollbar { /* 1 */ } ::-webkit-scrollbar-button { /* 2 */ } :...

testbird 2019-08-29 12:17 評論0 收藏0
webkit內(nèi)核瀏覽器自定義滾動條樣式

摘要：滾動條兩端的按鈕。內(nèi)層軌道，滾動條中間部分除去。有如下功能若是水平滾動條，則屬性不起作用，屬性用來控制滾動條相應部分豎直方向高度若是豎直滾動條，則屬性不起作用，屬性用來控制相應部分的寬度。 CSS ::-webkit-scrollbar { /* 1 */ } ::-webkit-scrollbar-button { /* 2 */ } :...

Achilles 2019-08-01 16:35 評論0 收藏0