gitlab-ci坑後感與指北

本文的目的:

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

療效:node

並不能讓你一會兒掌握CI/CD, 這只是一個比較完整的解決方案,其餘基礎知識,自行補充.webpack


基調

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

階段1: 代碼倉庫

關於 代碼倉庫, 本文選取的方案是 gitlabgit

gitlab的搭建:web

以目前的狀況來講, 推薦使用docker來搭建你的系統, 否則你會陷入各類膜明其妙的問題.docker

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

在這裏我推薦一個:shell

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

打開之後直接搜索Quick Start, 按照docker-compose的方式啓動你的gitlab.api

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

下載好 docker-compose.yml以後不要急着啓動, 須要修改幾個參數:數組

須要學習一點點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 內部使用的地址, 這關係到你gitlab頁面上的項目地址,沒設置的話, 到時候顯示的是127.0.0.1, 這個鬼才能clone下來.

這個 host 一旦設置, 初始化完就改不了了, 因此必定要在第一次啓動以前 就設置好.
啓動

docker-compose up

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

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

其餘關於gitlab的使用技巧, 就不深刻了.
能關注這篇文章的都不是萌新了,這些內容本身補充吧.

階段2: 提交觸發

接上文.

gitlab-ci在最新版的gitlab已是內置的了, 只要項目裏有.gitlab-ci.yml,同時有對應的gitlab-runner, 就能實現CI, 相比之下不須要太多的配置.

名詞解釋:

.gitlab-ci.yml:

這是gitlab-ci使用的任務描述文件, 裏面主要是定義CI的過程須要執行哪些行爲, 簡單說就是, 要進行哪幾個步驟, 每一個步驟是哪些命令.

gitlab-runner:

另外一個程序, 也能夠用docker啓動, 就是負責執行 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內部執行docker images是能夠看到外面的鏡像列表的), 這樣作是埋下一個伏筆, 以便後面階段使用dind(docker in docker)時, 得到更好的體驗.


繼續

好了, 這個時候你啓動了一個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

這裏使用了兩個參數, 都是爲了 docker in docker 能獲得更好的體驗而服務的.

輸入以上命令後, 根據提示填寫信息, 其中:

  • host,token 這些, 請打開你剛裝好的gitlab, 進入 Admin area-Runners ,而後照着填寫就是了
  • 特別注意期間會讓你選一個executor 類型, 我的推薦最好的方式是docker , 至於shell這種方式, 玩玩能夠,實際使用時反作用太多.
  • 更多參數的細節, 自行研究.

完成以上步驟以後, 你在gitlab - Admin area-Runners 頁面就能看到註冊好的runner了, 固然你如今仍是感受不到它的做用.

這個環節內容比較多, 操做比較多, 走到這裏建議休息一下喝杯茶.

階段3: Runner Job

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

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

它作的就是, 在提交代碼之後, 自動的測試, 自動的構建, 自動的發佈 :

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 數組,

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

分別是test測試-build編譯-deploy發佈

而後下面的三個job_*,名字是隨意的, 重點是裏面的stage屬性,

告訴gitlab-ci這個任務是在哪一個stage執行的,

一個stage你能夠寫不少個job

敲黑板!!!

須要注意的是, 咱們以前選擇了docker executor, job裏面就要聲明image屬性,指定這個Jobscripts要在哪一個image裏面運行.

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

這裏第二步使用了gitlab/dind , 仔細看script, 這是在一個容器裏面去構建一個鏡像, 爲了總體體驗構建效率着想, 咱們以前註冊runner的時候,將宿主機的docker.sock映射進去是十分必要的!!
(從新翻上去看吧)

看到這裏, 聰明的朋友已經發現了,

咱們須要本身打造一批用於運行Job的基礎鏡像, 這些鏡像裏要預先安裝好咱們須要的依賴環境.

舉個栗子:

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

聽起來好麻煩?

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

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

階段4: 不勞而獲 && 總結

若是按照上面的步驟把這個系統搭建起來之後, 你應該已經可以感覺到gitlab-ci帶來的好處了.

如今你只管提交代碼, 就能快速看到新功能集成到相應的環境了.

此後, 你只要寫好每一步的Job 就能夠了.

尤爲是測試這個環節.

尤爲是測試這個環節.

尤爲是測試這個環節.


後記

  • gitlab 真的很吃資源, 虛擬機玩夠嗆, 團隊用的話, 建議裝一臺PC來搭建.
  • 基礎鏡像別偷懶, 多打磨,讓你的scripts能夠更簡潔
  • 更進一步的話, 本身開發一系列的命令行工具, 讓你的scripts更強大.
  • 有事找我, 包教會.
相關文章
相關標籤/搜索