GitLab CI 之 Runner 的 Executor 該如何選擇?

使用者在初次踏進 GitLab CI 的世界時,通常按著官方文件一步步照做,多半不會遇到什麼問題。唯獨有一項東西有可能讓新手產生較大的疑惑,那就是該如何選擇 Executor。 目前在官方文件上已經有提供了一份 Compatibility chart 幫助使用者選擇 Executor。本文就讓艦長也針對 Executor 表達一些看法吧! (本文同步發表於 Medium。) GitLab Runner 與 Executor 的關係 首先,讓我們先來解釋 GitLab、GitLab Runner 與 Executor 的關係。 讓我們拆開來說明,先從 GitLab 與 GitLab Runner 的關係開始。 如上圖,我們都知道 GitLab Runner 是用來幫助我們執行 CI Job 的工人,而 GitLab 就是這些工人的老闆。老闆(GitLab)會去查看需求單(.gitlab-ci.yml)建立一張又一張有先後順序的工單(CI Pipeline),而每一位工人(Runner)則是每隔固定的時間就去詢問老闆(GitLab)現在有分配給自己的工作(CI Job)嗎?現在自己應該做哪一項工作?工人拿到工作後開始執行,並且在執行過程中將處理進度即時填寫在工單上。 到這裡為止,大部分的人都不太會有什麼問題,讓我們接著說明 GitLab Runner 與 Executor 的關係。 前面我們將 GitLab 與 GitLab Runner 比喻為老闆與工人,那麼 Executor 是什麼?是工人的工具嗎?艦長覺得與其說是「工具」,Executor 反倒更像是工人的「完成工作的方式」或「工作的環境」。 舉例來說,就像我們都曾聽過的都市傳說,據說在國外有某知名企業的工程師,偷偷將自己的程式開發工作遠距外包給印度工程師完成,藉此實現上班摸魚打混還能取得高績效表揚的神奇故事。當然偷偷把正職工作私下外包是不正確的行為,但在這個故事中,這就是這位工程師「完成工作的方式」;同理用嘴巴命令別人做事、自己苦力的土法煉鋼、善用自動化工具或高科技工具輔助、遠距連線工作⋯⋯這些都是不同的「完成工作的方式」。 按著上面的比喻,依據你選擇的 Executor 決定了 Runner 將會採用何種「方式」及在哪個「工作環境」來完成 CI Job。 因此我們可以明白,這意味著身為老闆的我們,很可能需要聘雇多位不一樣的工人。舉例來說,炒菜煮飯這種工作,我們就會安排給在廚房工作的廚師、闖入民宅開寶箱這種工作,我們就會安排給 RPG 遊戲中的勇者。根據不同的 CI Job,我們有可能需要準備設置了不同 Executor 的 Runner 來因應。...

March 13, 2021 · Cheng Wei Chen

自架「密碼管理器」服務

這則一樣是從工作筆記中撈出來的舊筆記,重新整理後釋出在部落格分享。 對於「密碼管理器」觀望了很久,一直在考慮要不要使用它,最後看了這篇《為什麼今天就該開始使用密碼管理器》之後,覺得作者說的很有道理,我們應該用一套正規、有加密、有一定安全防護的「密碼管理器」來管理密碼;同時由於團隊協作的需要,難免會遇到必須共用帳號密碼的情況,故確實需要一個合適的服務來管理密碼。於是當時稍微花了一些時間比較了幾套常見的「密碼管理器」,最後在參考該文章的介紹後,選擇試用了 LessPass 與 Bitwarden 這兩套工具。 (本文同步發表於 Medium。) LessPass LessPass 在當時號稱是一個全開源(Fully open source)的軟體,你可以自行架設服務,也可以註冊使用官方維護的雲端服務。 實際試用之後,第一時間覺得 LessPass 的運作邏輯跟一般想像中的「密碼管理」不太相同。該怎麼說呢?當下使用的感覺是 LessPass 與其說是幫我們集中儲存與管理密碼的「密碼管理器」,正確來說它更像是一個「密碼產生器」。 也就是根據你輸入的「網址」、「帳號」、「主密碼」、「密碼強度與亂數的設定值」,它會幫你產生出一組「高強度的密碼」,於是你可以使用這一組密碼去註冊其他需要登入密碼的服務。 接著當下次需要輸入密碼登入某個服務時,你只要能在 LessPass 輸入正確的「網址」、「帳號」、「主密碼」、「密碼強度與亂數的設定值」,LessPass 就會再次幫你產生出相同的「高強度密碼」,讓你可以複製貼上,順利登入服務。 (如上案例,根據「網址」、「帳號」、「主密碼」、「密碼強度與亂數的設定值」,即可產生出一組獨一無二的「高強度的密碼」。) 看到這裡,你一定會想說「這也太麻煩了,我光是記憶密碼就夠累了,現在還要記憶這麼多組變數!?」,對此 LessPass 的解決辦法即是 LessPass Database。 因此不論是 lesspass.com 提供的雲端服務,或你自行架設的 LessPass Database Server,其實最主要的功能都是用來幫你儲存各個服務的「網址」、「帳號」、「密碼強度與亂數的設定值」,方便你下次要「產生」密碼時,可以免去輸入這些欄位。也就是說 LessPass 並不是直接儲存「密碼」本身,因此我才會說它本質上更像是一個「密碼產生器」。 LessPass 有 Chrome 的擴充套件可以安裝,方便使用者可以快速使用。 目前 LessPass 在 GitHub 上的 Readme 已經沒有直接寫明如何 Self Host your LessPass Database,並且 install-lesspass.sh 這個安裝腳本也已經在這個 Commit 中將其移除了。 因此如果想要自行架設 LessPass Database,可以自己研究一下現行版本的 docker-compose.yml,嘗試用 Docker 架設。 艦長當初是參考舊版本的 Readme,並對照前述的 install-lesspass.sh 及 docker-compose.yml 來架設的。但就如前述這些資訊都已經有些過期,只能做為參考輔助,無法保證照著做還能正常架設。 續上,再提供另一項資訊給各位參考。在上述 LessPass 官方提供的 docker-compose....

March 5, 2021 · Cheng Wei Chen

以 Azure AKS 創建 K8s Cluster 並整合至 GitLab

在私人的試用帳號即將到期前,測試了用 Azure AKS 建立 K8s Cluster 並將之整合至 GitLab。本文僅紀錄本次的操作步驟。(本文撰寫時,GitLab 版本為 13.9 。) (本文同步發表於 Medium。) 操作步驟 事前動作,請先註冊並啟用 Azure。目前 Azure 有提供 30 天內 6,100 元的免費點數,想要試玩 Azure 的人,可以考慮申請並集中火力在 30 天內善用那 6,100 元點數。 (官網上的說明。) Azure 帳號開通後,接著開始進入正題。第一步先安裝 Azure CLI。macOS 使用者可以透過 Homebrew 安裝。 brew install azure-cli (安裝過程中,Homebrew 會自己去下載所需的檔案) 安裝完畢後,確認一下 Azure CLI 安裝的版本,驗證是否安裝成功。 az version 接著讓 Azure CLI Login 以便後續能操作 Azure 雲端資源。 az login 輸入指令後,Azure CLI 會自動開啟瀏覽器,並連上指定的 oauth 網頁。 在網頁上確認你要登入的 Azure 帳戶。 成功登入後,會得到下面的畫面。 同時 Command line 也會得到登入成功的訊息。 接著先取得 Azure 的 Location 資訊,後面在建立 Resource Group 時會用到,我們要挑一個離台灣近一點的機房,一般來說滿多人會選擇香港機房。(Location 也可以到 Azure 官網查詢。)...

March 1, 2021 · Cheng Wei Chen

GitLab Pipeline Editor 與 Pipeline simulation

上一篇文章我們介紹了 CI Lint,本文再接再厲,繼續介紹另外兩個在規劃 CI Pipeline 會用到的功能——Pipeline Editor 與 Pipeline simulation。(本文撰寫時,使用的 GitLab 版本為 13.8 。) (本文同步發表於 Medium。) Pipeline Editor Pipeline Editor 是 GitLab 13.8 新增的功能。(就說 13.x 一直功能大噴發~) 過去在撰寫 .gitlab-ci.yml 時,我們只能看著檔案內容,自己在腦中想像屆時 CI Pipeline 會長成何種模樣。在 Pipeline 結構單純時,用想像的還足以應付。但如果 Pipeline 較為複雜,特別是當你有使用多個 Template 或需要依據 Tags、Variables 的差異來執行不同的 CI Job 時,只靠想像可能就有點辛苦了。 因此 GitLab 為了幫助使用者可以更友善的撰寫 .gitlab-ci.yml,終於在 13.8 新增了 Pipeline Editor 這個神奇的功能。Pipeline Editor 會根據 .gitlab-ci.yml 的內容直接在 WebUI 繪製出 CI Pipeline 的模擬圖(Visualize),讓我們不用實際送出 Commit 也能一覽目前規劃好的 CI Pipeline。 讓我們從一個簡單的範例開始,在剛進入 Pipeline Editor 功能介面的 Write pipeline configuration 時,它會自動幫你帶入該 Project 之 Default branch 的 ....

February 23, 2021 · Cheng Wei Chen

在送出 Commit 前讓 GitLab CI Lint 幫你檢查 .gitlab-ci.yml

相信所有的 GitLab 使用者一定都曾遇過一個狀況。即是好不容易撰寫了一份自覺完美的 .gitlab-ci.yml,但在 git push 送出 Commit 之後,卻只得到 GitLab 介面上顯示著紅色的錯誤 yaml invalid。(本文撰寫時,使用的 GitLab 版本為 13.8 。) (本文同步發表於 Medium。) (本來想要帥氣的展現 CI Pipeline,誰知道只看到 CI Pipeline 很糗的顯示 YAML 格式有錯!) 這種狀況不只會發生在 GitLab 新手,就連 GitLab 老手也經常發生。如果錯誤是因為寫錯 GitLab CI 專有的語法也就算了,畢竟 GitLab CI 越來越強大,有日漸複雜化的趨勢。但在真實情境中往往多半只是某一行 YAML 縮排沒正確對齊,導致出現 yaml invalid,因而白白浪費了寶貴的時間。 為了幫助使用者們能夠避免上述的狀況,GitLab 目前已提供 CI Lint 功能,讓使用者可以在送出 Commit 前,事先檢查 .gitlab-ci.yml 是否撰寫正確。 CI Lint - GitLab WebUI 如想要以 WebUI 的方式使用 CI Lint,可以在 Project > CI/CD > Pipelines 介面的右上角找到它。 WebUI 使用起來非常方便,就是一個簡易的線上編輯器,我們只要將 .gitlab-ci.yml 的內容複製貼上於此,並按下 Validate,即可得知是否撰寫正確。 按下 Validate 並通過 CI Lint 的檢查後,即可得到類似下圖的結果,CI Lint 不僅會告知你 Syntax is correct,同時也會條列你目前規劃了哪些 CI Job。 當然,如果 ....

February 17, 2021 · Cheng Wei Chen

GitLab 搭配 Slash command 快速建立 ChatOps

在 HipChat 依然主流、Slack 尚未席捲市場的那個年代,那時建立 ChatBot 的工具還不像現在這麼豐富、中文教學資源也比較匱乏,但在當時就已有不少公司藉由 HipChat + ChatBot 的方式實現自動化及 ChatOps。由於透過此種方式,團隊成員只要在即時通訊工具中呼叫 ChatBot 即可自動完成許多重複性工作,可說是 Dev 與 Ops 兩方都十分喜愛的工具。 本文就讓我們試著運用 GitLab CI 搭配 Mattermost slash command 實現 ChatOps,試著在沒有 ChatBot 的狀況下,快速建立 ChatOps。(本文撰寫時,使用的 GitLab 版本為 13.8 。) (本文同步發表於 Medium。) 過程紀錄 要透過 GitLab 實現 ChatOps 非常的簡單,基本概念就是將 GitLab CI Pipeline 視為是一個幫你執行自動化腳本的平台,在 CI Pipeline 中規劃各種 CI Job,接著再透過 Mattermost slash command 去 Trigger 特定的 CI Job 幫我們完成想要執行的重複性工作。 以下先說明必要的設定步驟。 啟用 Mattermost slash commands 首先請參考艦長上一篇文章《GitLab 啟用 Project integration - Mattermost slash commands》的步驟,建立一個專案,並且啟用此專案的 Project integration - Mattermost slash commands。...

February 6, 2021 · Cheng Wei Chen

定期自動執行 Selenium 來監控網站運作狀態

上週比較忙,所以只整理了一篇較短的舊工作筆記。 由於專案環境的緣故,在某個專案遇到無法按往常慣例為服務設置多重的監控措施。經過討論後,最終在此專案使用了一種不太平常的做法來實現「只設置一項監控 Rule,即同時確認 NGINX、PHP-FPM、MySQL 三者是否正常運作」。該做法是透過 Cron job 定期執行自動化腳本,該腳本會啟用 Selenium 來實際登入網站,並進入特定網頁,最後根據是否能回傳正確的網頁結果,來判斷該服務是否仍正常上線。 (本文同步發表於 Medium。) 前言 如果要確認一個網站是否仍正常運作,我們可以使用多種不同的工具來監控它,例如 Zabbix 的 Web Scenarios、pingdom.com 的 Website Monitoring 或其他各式各樣的 Monitoring tools。 除了直接監控網站之外,有些人也會選擇以監控 Server 上的 Web service(例如 NGINX)或其他 Service 的 Status 是否正常,來確認網站是否仍正常運作。不過有經驗的人都知道,導致網站故障的原因很多,Web service status 正常,但網站依然故障也是有可能發生的。因此更多的人通常是並行多種層面的監控措施,並且設置合宜的 Dashboard 一覽從使用者送出 Request 開始直到 Response 回覆使用者為止的整條路線;倘若網站發生故障,只要一覽 Dashboard 何處出現紅燈,就能迅速定位故障問題點。例如 SRE Taiwan 社群的 Earou Huang 就曾經利用 Serverless Framework 做了一個可以監控系統內部各節點健康狀況的 Project - draft-mesh。 (艦長也曾經試用 Earou 的 draft-mesh 弄了一個 Dashboard。) 總之要確認網站是否仍正常運作的方法很多,可以搭建複雜的監控工具,反之也可以撰寫 shell script + curl command 來快速實現簡易的監控。...

January 25, 2021 · Cheng Wei Chen