在 2021 年四月的文章中，我分享了透過 GitLab CI + JMeter 進行小規模 Load Testing；而在 2021 年七月的文章中，我則是試用了 Drill 這個新興的 Load Testing 工具。
承襲這兩次的經驗，在本文我們就以 GitLab CI + Drill，試一試「如何透過 GitLab CI + Drill 進行小規模 Load Testing」。
（本文同步發表於 Medium。）
操作步驟 首先我們要準備合適的 GitLab CI 環境，老樣子會需要一個可以操控 Container 的 GitLab Runner。如果你只是打算先試玩看看，那最簡單的方式就是使用 gitlab.com 以及官方提供的 Shared runners。
【小提醒】再次提醒大家 gitlab.com 的 Free plan 現在只有 400 CI/CD minutes per month。而且由於一直都有人在濫用這些免費資源，因此官方也有在評估該如何規範濫用的狀況。假如你真的想要由 GitLab CI 觸發 Load Testing，最好還是使用自己架設的 GitLab Runner 喔！
準備 Docker image - drill 接著準備合適的 Docker image。這邊一樣偷懶，就不追求容器 size 最小化，用最直白的方式建立一個可以在 GitLab CI 中使用的 Docker image - drill。...
在觀摩了幾次如何運用 Zoom、Miro、GatherTown 舉辦線上活動後，自己腦補了一下可以如何運用這些工具舉辦簡易線上版的開放空間會議。
（本文同步發表於 Medium。）
【補充】下面文章所分享的線上活動規劃，我並沒有實際執行過，因此我完全不知道實際執行時，有可能會遇到哪些問題，所以本文標題才會是「純腦補之」。如果你對於腦補的內容沒興趣，那可以直接跳到結語，在結語那邊有稍微想要聊一聊「數位落差」這件事。
如果你不知道什麼是「開放空間會議」（Open Space Technology），可以參考以下幾個連結。
【影片】Open Space Technology Introduction 【文章】何謂開放空間？ 【文章】分享發生在台灣的開放空間會議經驗 【書籍】開放空間科技引導者手冊 如果你已經知道「開放空間會議」，就讓我們繼續看下去。
特別感謝 在開始說明我的腦補內容之前，要先獻上我的感謝。
感謝這兩年所有嘗試舉辦線上活動的各個企業、組織與單位，因應疫情全球忽然間被迫執行新一波的「數位轉型」，可以感受到大家都在摸索與尋找更優質的線上活動解決方案。而每一個走在前頭的人，都是後面跟進者學習與觀摩的對象。 感謝 IAF Taiwan 舉辦「引導週線上分享會」，並且不藏私的分享他們成功舉辦線上活動，如何在線上活動進行引導的經驗談。這篇腦補文的許多細節是建立在他們的經驗談之上。（如果沒有預算問題，我真的覺得可以找 IAF Taiwan 來協助舉辦各種需要引導及高度互動的實體或線上活動。） 感謝 RSG Taipei 2021 舉辦線上的「開放空間會議」，讓我能有機會實際觀摩線上的「開放空間會議」。（台灣敏捷社群的志工群實在是非常強大。） 腦補的活動規劃 我所腦補的「簡易線上版開放空間會議」大致規劃如下。
所需資源 多個 Zoom 帳號 / 會議室 付費版的 Miro 帳號 多位志工 一位主要的引導者 / 主持人 供主持人與志工使用的順暢網路及電腦設備 供主持人及志工幕後使用的即時聯繫管道 活動事前工作 在正式舉辦活動之前，需要完成以下的事前工作：
先決定屆時要開啟多少個討論議題的小空間。
續上，根據小空間的數量預備相同數量的 Zoom 會議室。
續上，根據小空間的數量預備「小空間數量 x 2 + 1」的志工。
預備「主會場」的 Zoom 會議室。
建置活動所需的 Miro board，其中需要包含以下幾個空間：
圓形的主會場：巨大的圓形，旁邊附上主會場的 Zoom 會議室連結，以及主會場的簡單說明文字。
議題大看板：矩形看板，根據這次開放空間會議的回合數及小空間數量，分隔為多行多列，每一格寫上對應的「討論時段 + 小空間名稱」，並直接在格子內附上對應的 Zoom 會議室連結。...
Drill 是一個以程式語言 Rust 撰寫的輕量級 HTTP Load testing 工具，Load testing 工具百百款，之所以會特別想認識 Drill 則是因為該工具的一段簡介「You can write benchmark files, in YAML format, describing all the stuff you want to test. It was inspired by Ansible syntax because it is really easy to use and extend.」
看到上面那段簡介，身為 Ansible 的使用者，怎麼可以不來驗證一下，是不是真的如它所言！
（本文撰寫時，使用的 Drill 版本為 0.7.1。）
（本文同步發表於 Medium。）
操作步驟 我們知道試用任何工作的第一步是先看官方文件！
錯！當然是先看有沒有已經包好立即可用的 Container image！（咦）
可惜在撰文的當下，尚未看見官方有自己包好 Container image，在 Docker Hub 只有找到 Drill 版本 0.5.0 的 Docker image。
https://hub.docker.com/r/xridge/drill 由於沒有最新版的 Container image，只好自己 build 一個，這邊就偷懶不追求 Container Size 的最小化，先搶快做出 Drill 0....
本文只有一個重點，就是介紹可以使用 GitLab API 為 Project 設定 GitLab Runner，如果是使用工具前都會查閱說明書的資深 GitLab 使用者，可以直接轉身離開喔（喂～哪有文章一開頭就把人趕走的～）
（本文撰寫時，使用的 GitLab 環境為 14.0。） （本文同步發表於 Medium。）
前情提要 之前在 GitLab Taipei User Group 中有一位苦主表示遇到了一個狀況，他必須要將指定的 GitLab Runner 分配給超過百個 Project 使用，想詢問有沒有比較簡單的方法？
一般來說如果有 Runner 需要同時供應給多個 Project 使用，通常會建議將 Runner 建立為 Group Runner。如此一來在相同 Group 內的所有 Project 皆能直接取用此 Runner，唯一的限制就是 Project 必須隸屬在相同的 Group。因此對於苦主來說，這個解法他會需要將超過百個 Project 全部搬家至 Group 內，因此不太適用。
另一個方案是，假如你是自架 GitLab Server，則可以透過 Admin 管理者，架設 Shared Runner，便能夠如同 gitlab.com 那樣，直接提供不限 User、Project 皆能任意使用的 Runner。當然要說缺點就是 Shared runner 預設是全開放給所有人皆能使用的 Runner，因此如果你又想要做出額外的權限控管，同樣又要另外想辦法。不幸的是印象中苦主似乎是使用 gitlab.com，GitLab 官方當然沒開放權限讓使用者自行在 gitlab.com 上架設 Shared runner。...
先前在擔任講師時，有時會遇見學員反應「我的 GitLab CI 沒有在運作」，出狀況的原因當然很多種，像是 .gitlab-ci.yml 的格式錯誤、內容錯誤、Runner 設定錯誤⋯⋯，本文就來條列一些常見的原因。
（本文同步發表於 Medium。）
常見狀況 以下逐一分享幾種常見的異常狀況。
一、CI/CD Pipeline 設定檔的檔名錯誤 GitLab 預設的 CI/CD Pipeline 設定檔為 .gitlab-ci.yml，要注意前面有一個 .，以及是 yaml 檔案 .yml，不要太順手寫成 .yaml。另外就是 GitLab 也能設定改用別的檔名作為 CI/CD Pipeline 的設定檔，因此也要注意是不是有啟用這項設定，搞不好你的專案還真的已經改用 gitlab.yaml 當作 CI/CD Pipeline 設定檔了喔～
二、CI/CD Pipeline 設定檔的存放位置錯誤 續上，除了檔名之外，CI/CD Pipeline 設定檔的存放位置也很重要。預設的存放位置是專案的根目錄，存放位置也同樣可以自行修改。
【小提醒】CI/CD Pipeline 設定檔的檔名及存放位置都可以在 GitLab 的 Porject > Settings > CI/CD > General pipelines > CI/CD configuration file 中修改。
三、忘了啟用 Runner CI/CD Pipeline 要能運作，你必須要為 Project 啟用 GitLab Runner 才行。在 Porject > Settings > CI/CD > Runner 中確認是否有 Enable 任何一台 Specific runner 給此專案使用。...
因為 COVID-19 疫情，所以 DevOps Taiwan Meetup #33 臨時決定從實體活動轉變成線上活動。因此需要尋找合適的線上活動解決方案。但市面上有著各式各樣的「線上會議 + 串流直播」解決方案，有沒有哪一種是花一點小錢就能一次搞定的方案呢？
也許這次 DevOps Taiwan Community 打算嘗試的 Zoom 付費方案會是一個可以考慮的選項。
本文記錄此種方案的操作步驟。
（本文同步發表於 Medium。）
操作步驟 下面逐一說明各項操作步驟。
取得 PRO 以上等級的 Zoom 帳號 首先我們需要有至少為 PRO 等級的 Zoom 付費帳號。
從下圖的比較可以發現，雖然 PRO 等級的帳號依然只能主持最多 100 名與會者的會議，但重要的是 PRO 就提供了我們想要的「社交媒體串流」及「1 GB 雲端錄製」。
有了「社交媒體串流」，就某個角度也算是間接解決線上活動「參加人數上限」的問題，未能順利搶到線上票的朋友，可以改為觀看直播，一樣能聽見講師的分享。至於與講師的互動這部分，則可以透過 sli.do 之類的額外工具收集 Q & A，再讓講師逐一回答，另外也可以適度地引導參加者將提問與討論延續至 FB 社團或其他的討論空間。
【小提醒】Zoom 的付費方案是採訂閱制的，因此如果你只打算運用在單場線上活動，在活動舉辦完畢後，記得在訂閱週期將至之前，登入 Zoom 帳號去取消訂閱。
Zoom 帳號採購的部分就不逐一說明，唯獨提醒大家在採購的時候，要注意自己有沒有不小心勾選到了不需要的「附加功能」。
（採購過程中，Zoom 會一直鼓吹你多買一點功能。）
（Zoom 不死心，繼續問你要不要多買一點其他方案。）
開啟 Zoom 的「社交媒體串流」 有了 PRO 帳號，接著要啟用「社交媒體串流」。（預設是不啟用的。）
請透過瀏覽器登入 Zoom 網站，接著進入 管理員 > 帳號設定 > 會議 > 會議中（進階）。...
DevOps Taiwan Community 於 2021/3/29 舉辦了實體的 Meetup #31，本文針對這次活動做個簡短的紀錄。
因為 COVID-19 疫情及缺講師的緣故，DevOps Taiwan Community 有好一陣子沒舉辦活動，陷入無法每月舉辦實體 Meetup，活動有一場沒一場的狀態。而這次能在 2021 年 3 月再次舉辦 Meetup 必須要特別感謝本次負責擔任講師的兩個單位——資策會及 F5/NGINX；感謝兩方的聯絡窗口及講師的協助，讓志工們可以在很短的時間內促成這次的 Meetup。
Meetup #31 一如往常由兩位講師上場，分別帶來不同的主題。
（本文同步發佈於 Medium。）
講題一：資策會的開源 DevOps 整合工具分享 這是由資策會數位轉型研究所的資深工程師蔡宗融帶來的分享，主要在介紹資策會目前打造出來的開源 DevOps 工具懶人包。（懶人包是我自己的評語）
講師表示當 DevOps 一詞在台灣開始普遍廣為人知時，資策會當然也不例外，在資策會內部也有追上這股 DevOps 熱潮，到底什麼是 DevOps、DevOps 能夠為我們（資策會）帶來什麼、以及我們（資策會）又可以為 DevOps 做些什麼。資策會在內部經歷了一番醞釀與努力之後，最後順利推出這套「開源 DevOps 整合工具」。
該工具目前有一個介紹官網，有興趣的朋友可以參閱上面的介紹，官網的網址為 https://www.iiidevops.org/
演講中講師提到 DevOps 可以帶來三項好處：
加快軟體開發與交付的速度 縮短更版週期、降低更版風險 讓開發與維運團隊共同面對問題 但要如何讓團隊開始進行 DevOps 轉型呢？一個要從文化及思維層面著手，另一方面則是從工具面著手。因此如果能提供團隊一套可以快速啟用、容易上手、已經打通 Workflow 各環節所需之自動化工具的「DevOps 整合工具」，也能有助於推進團隊的 DevOps 轉型。
那麼資策會推出這套「DevOps 整合工具」已經包含了哪些工具呢？
講師表示目前已經整合了 Redmine、GitLab、Sonarqube、Rancher、Kubernetes⋯⋯等多項工具，可以說下面這張常見的 DevOps 循環的左半邊 plan、code、build、test 的工具已經整合的差不多了。2021 的下半年，他們會繼續加強右半邊的工具整合。...