本文的目的:最主要是備忘, 其次是分享html
療效:node
並不能讓你一會兒掌握CI/CD, 這只是一個比較完整的解決方案,其餘基礎知識,自行補充.webpack
首先,這不是屠龍刀,不要奢望一篇文章能夠走遍天下.這裏只是提供一個具體的落地方案, 一個具體的技術選型.
關於 代碼倉庫, 本文選取的方案是 gitlab
git
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的使用技巧, 就不深刻了. 能關注這篇文章的都不是萌新了,這些內容本身補充吧.
接上文.
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
想深刻了解的話, 請看
敲黑板!!
在這裏, 咱們將宿主機的docker.sock
映射進去,讓runner
能夠跟宿主用同一個daemon
, (意味着你進去runner內部執行docker images
是能夠看到外面的鏡像列表的), 這樣作是埋下一個伏筆, 以便後面階段使用dind
(docker in docker)時, 得到更好的體驗.
繼續
好了, 這個時候你啓動了一個runner
, 你要告訴它應該到哪裏去"服役",
這一步叫作: 註冊
註冊runner的方式請看
不過, 仍是請你使用如下命令來註冊:
docker exec -it gitlab-runner gitlab-runner register \ --docker-volumes /var/run/docker.sock:/var/run/docker.sock \ --docker-privileged
這裏使用了兩個參數, 都是爲了 docker in docker 能獲得更好的體驗而服務的.
輸入以上命令後, 根據提示填寫信息, 其中:
Admin area
-Runners
,而後照着填寫就是了executor
類型, 我的推薦最好的方式是docker
, 至於shell
這種方式, 玩玩能夠,實際使用時反作用太多.完成以上步驟以後, 你在gitlab
- Admin area
-Runners
頁面就能看到註冊好的runner
了, 固然你如今仍是感受不到它的做用.
這個環節內容比較多, 操做比較多, 走到這裏建議休息一下喝杯茶.
這個階段, 是指代碼提交之後, 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
屬性,指定這個Job
的scripts
要在哪一個image
裏面運行.
重點說明!! 再次大力敲黑板!!
這裏第二步使用了gitlab/dind
, 仔細看script
, 這是在一個容器裏面去構建一個鏡像, 爲了總體體驗與構建效率着想, 咱們以前註冊runner
的時候,將宿主機的docker.sock
映射進去是十分必要的!!
(從新翻上去看吧)
看到這裏, 聰明的朋友已經發現了,
咱們須要本身打造一批用於運行Job
的基礎鏡像, 這些鏡像裏要預先安裝好咱們須要的依賴環境.
舉個栗子:
你要在build
這一步作webpack
打包的話, 你要準備好一個內部安裝好webpack
的鏡像(相關的node
,npm
之類就更不用說了)
聽起來好麻煩?
也不是, 這是個 功在當代,利在千秋 的行爲, 前期打造好基礎鏡像, 後面的項目就能夠很容易寫CI Job
了.
更多 gitlab-ci.yml 的高級寫法,仍是建議看官方文檔
https://docs.gitlab.com/ee/ci...
若是按照上面的步驟把這個系統搭建起來之後, 你應該已經可以感覺到gitlab-ci
帶來的好處了.
如今你只管提交代碼, 就能快速看到新功能集成到相應的環境了.
此後, 你只要寫好每一步的Job
就能夠了.
尤爲是測試這個環節.
尤爲是測試這個環節.
尤爲是測試這個環節.
gitlab
真的很吃資源, 虛擬機玩夠嗆, 團隊用的話, 建議裝一臺PC來搭建.基礎鏡像
別偷懶, 多打磨,讓你的scripts
能夠更簡潔scripts
更強大.