在私人的試用帳號即將到期前，測試了用 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 官網查詢。）...
上一篇文章我們介紹了 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 的 ....
相信所有的 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。 當然，如果 ....
在 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。...
日前收到私訊提問，GitLab 社群朋友在讓 GitLab 串接 Mattermost slash command 時遇到了一些狀況，但根據艦長的印象，slash command 的背後是直接透過 GitLab API 以 POST 的方式進行串接的，理論上不太會遇到問題。於是好奇心發作的艦長，就頭洗下去的做了一番測試，同時將串接步驟也留做紀錄於本篇文章中。（本文撰寫時，使用的 GitLab 版本為 13.7 。）
（本文同步發表於 Medium。）
過程紀錄 Mattermost 與 GitLab 相同，都可以選擇自架或使用官方提供的 SaaS，因此如果會出現問題，會不會是 Self-hosted 與 Cloud 的問題呢？故此我們會有以下四種串接情境。
gitlab.com + Mattermost Cloud gitlab.com + Self-hosted Mattermost Self-hosted GitLab + Mattermost Cloud Self-hosted GitLab + Self-hosted Mattermost 上面四種情境要串接 Mattermost slash commands 的操作步驟都是大同小異的，以下就讓我們逐一示範。
gitlab.com + Mattermost Cloud 第一個示範組是最不會出錯的 Cloud SaaS 組合。
在開始設定之前，請先確定你擁有 gitlab.com 與 Mattermost 的足夠權限，GitLab 這邊需要有權限設定 Project 的 Settings；而 Mattermost 則需要管理 Integrations 的權限。...
身為 GitLab Hero，善用（應該要用） GitLab Pages 來建立靜態網站也是理所當然的事情，之前都是把個人網頁放在自己長期租用的 VPS 上，但最近想要省一點錢，決定把 VPS 砍了，將靜態網站通通都搬到 GitLab Pages 上，所以本文就拿 chengweichen.com 作為案例，實際示範一遍給大家看。（本文撰寫時，使用的 GitLab 版本為 13.7 。）
（官方目前已經提供了多種 GitLab Pages 的 examples。） （本文同步發表於 Medium。）
過程紀錄 根據 GitLab 官方文件的說明，GitLab Pages 目前可以在 gitlab.com 上免費使用（既使該靜態網站是為了商業用途也可以免費使用），同時 GitLab Pages 也支援 HTTPS 及 Custom domain。因此我那個沒啥流量的個人網頁，是完全能夠以 GitLab Pages 架設的。
架設步驟十分簡單，首先是事前準備：
（非必要）準備好你的 Custom domain，如果你沒有自己的網域名稱，GitLab 也有免費提供如 xxx.gitlab.io 的預設子網域名稱可直接套用。 【小提醒】xxx.gitlab.io 其中的 xxx 其實是你 GitLab Project 的 Namespace。以下圖為例，我的 Project namespace 就是 chengwei.chen。 如果你想要使用 GitLab 免費提供的預設網域，同時又想要 GitLab 幫你自動使用免費的 SSL 憑證來啟用 HTTPS，那必須要注意該 Project 的 Namespace 不可以有 ....
感謝 iThome 的邀請，有幸能擔任 iThome Cloud Edge Summit 2020 的講師，負責一場演講及大會稱之為「雲端體驗營」的其中一場 Lab。
這次準備的主題是目前正熱門的 GitOps。 （本文同步發表於 Medium）
時間非常巧的，在大會舉辦的前些日子，正好有其他厲害的講師（邱牛）於 Cloud Native Taiwan 社群分享相同的主題，因此最後決定改變演講內容，嘗試用不同的角度來切入分享 GitOps。
因此這次演講與 Lab 的關鍵字雖然是 GitOps，但比起如何在 K8S 上實踐 GitOps 及相關的技術實作細節，我想要分享的內容是：
實踐 GitOps 一定要透過 K8S 嗎？ 除了技術層面上帶來的優點之外，GitOps 還帶來哪些好處？ 另外，由於在上半年期間都沒有在社群中分享 GitLab 的相關演講，覺得有愧於 GitLab Hero 的身份，最終演講題目定為《From DevOps to GitOps with GitLab》，而 Lab 的題目則是《GitOps with GitLab》。借這次大會分享 GitLab 公司及我個人對於 GitOps 的一些看法。 已經有研究過 GitOps 的人應該都知道，GitOps 一詞來自於 Kubernetes（K8S）及 Cloud Native 社群，甚至可以說是來自於 WEAVEWORKS。因此早先關於 GitOps 的看法，幾乎都是來自於此。
不過與 DevOps 的狀況類似，當有一個新詞開始熱門時，各雲端服務供應商可是不會放過這股潮流趨勢，GitLab 公司當然也不落人後。目前在 GitLab 官網上已經提供了 GitOps 的相關內容。而且資料是越來越多，目前看來 GitLab 有計畫要將 GitOps 作為市場的切入點，從我開始準備題目，直到實際演講的這幾個月內，GitLab 官網就默默的新增許多值得參考的內容。...