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 的下半年，他們會繼續加強右半邊的工具整合。...
最近看了一篇熱門文章《利用 Apps Script 讓 Google 表單回覆自動產出 Google 文件》，不看不知道，看了才知道原來 Google 有推出 Apps Script 這麼神奇好用的東西，透過它可以搭配 Google 的服務實現各種「辦公自動化」。
這麼有趣的服務，令人不禁想要天馬行空的運用它，究竟我們可以拿 Apps Script 做什麼事情呢？
（本文同步發佈於 Medium。）
如前面所述，在思考 Apps Script 可以拿來做什麼時，忽然想起前一陣子研究 Jira service management 所注意到的一個功能——Customer Portal。簡單來說 Customer Portal 就是一個面向使用者的單一窗口與入口，假設今天是 IT/MIS 部門在使用 Jira service management，那麼 IT 部門就可以利用 Customer Portal 建立一個給一般員工使用的「IT 問題回報表單」。假如員工有各種 IT 問題，就填寫該表單，IT 部門則會從 Jira service management 得到員工回報的問題資訊，根據資訊開立 Ticket 並分配給工程師處理。IT 部門除了可以從 Customer Portal 得到表單提供的資訊，甚至還能夠設定當員工填寫了表單的某些選項時，就直接觸發事先準備好的自動化腳本，直接自動處理某些 IT 問題。
（Jira service management 的 Customer Portal。）
Customer Portal 這麼棒的功能，真希望 GitLab 也能擁有，但很可惜目前只能自己打造。所以就讓我們參考上面那篇文章，利用 Google 表單 + Apps Script + GitLab 試著快速搭建一個陽春版的「IT 問題回報表單」。...
（活動延期至 2021/11/24，已順利舉辦！） （非常可惜，因為 COVID-19 忽然爆發，活動已延期暫緩。看著當時寫的這篇宣傳文，真是百感交集。）
下個月 5/27、5/28 即將舉辦 DevOpsDays Taipei 2021，這次的活動場地一樣在大家熟悉的老地方「臺北文創」。由於 COVID-19 疫情的緣故，今年的講師群幾乎清一色都是國內講師，活動的規模也縮小至 1 天半，即 5/27 下午舉辦「開放空間會議」，5/28 為一整天的研討會。
（本文同步發佈於 Medium。）
活動介紹 今年是自 2017 年以來，第四次舉辦 DevOpsDays Taipei， 雖然今年活動規模縮小，但活動的豐富度依然不減。
開放空間會議 （截圖來自 FB 粉專，2019 年 Open space 的盛況。）
首先，按照慣例今年一樣會舉行大受好評的「開放空間會議」（Open Space Technology），時間會安排在 5/27 下午 13:00 ~ 16:30。
想當初 2017 年時，籌備小組一直很擔心與煩惱 Open space 到底該如何進行，擔憂會不會白白準備了場地與設備，但最後根本沒人願意額外花費一整個下午來參加一個沒有講師沒有議程的交流活動。
然而 2017 年的經驗徹底地跌破了我們的眼鏡，當年有超過一半的購票者願意在聽都沒聽過的狀態下，參加 Open space。那一年的經驗，讓籌備小組徹底地感受到 Open space 的魔力，原來人們是有辦法在很短的時間內，即產生共識、連結與認同，原來深度的經驗交流與分享可以發生的如此自然與順暢，以及原來人們並不是抗拒交流，也許只是習慣了「聽講」或者人們只是欠缺一個合適的「交流場域」。
（截圖自 FB 粉專，2017 年的 Open space 盛況。）
「開放空間會議」就是一個如此神奇、充滿魔力的「交流場域」。如果你已經確定報名參加 DevOpsDays Taipei 2021，還請千萬不要錯過 Open space。請帶著你自身的經驗、你在職場上遇到的困難與疑問、以及一個開放的心，來到 Open space 與其他人進行交流，這個下午也許你有可能會獲得超乎你想像的收穫。...
2020 年，因為爆發 COVID-19 疫情的緣故，世界各地許多的研討會都被迫中止舉辦，當時 DevOpsDays Tokyo 2020 也受到影響，被迫臨時中止。在疫情肆虐一年之後的 2021 年 4 月，DevOpsDays Tokyo 再次出發，這次以線上、線下同步進行的全新形式回到了眾人面前。（當年 DevOpsDays Taipei 2020 也同樣受到 COVID-19 疫情影響，在不斷延後舉辦與籌備事宜之後，最終也是決定中止舉辦。）
【補充】當時 DevOpsDays Tokyo 決定中止活動的事情，可以參考這篇 Blog 記錄 DevOpsDays Tokyo 2020 中止の経緯
在 DevOpsDays Taipei 2019，台灣這邊邀請了日本的 DevOpsDays 組織者（Organizer）與講師來台交流，今年則是日本的組織者邀請我們以線上的方式參加 DevOpsDays Tokyo 2021。本文就以簡短的文字紀錄 4/15、4/16 這兩天透過線上參與 DevOpsDays Tokyo 2021 的部分見聞。
（本文同步發表於 Medium。）
活動形式與大會運用的各種線上服務 （大會公告，活動將會採取線上、線下同步進行。）
DevOpsDays Tokyo 2021 採取線上、線下同步進行的形式舉辦，但由於疫情的緣故，很多講師也是採取遠距的方式進行演講。
即便是日本當地的講師，很多也是透過遠距的方式演講。有些演講會有多位講師以遠距的方式同台分享。所以有時在演講正式開始之前或結束之後，在不經意之間還可以聽見講師們在互相聊天。
如果講師是遠距演講，在線下的場地，就會將遠距的畫面投影給線下的參與者；反之，如果講師是實際來到現場分享，則會由線下將現場的講師及簡報畫面提供給遠距的參與者。
而 DevOpsDays Tokyo 2021 這次採用的遠距工具是 ZOOM。由於活動議程分為三軌同步進行，因此總共開了三個 ZOOM 會議室，參與者需要自行按照議程時間表，進入不同議程的會議室。
DevOpsDays Tokyo 2021 有英文講師，而大會很貼心的聘請了即時口譯員，因此在英文演講的時候，該議程的 ZOOM 會議室會多出一個「語言」選項。這是 ZOOM 的一項貼心功能，如此一來日本的與會者即可切換至 Japanese 聆聽口譯員翻譯的日文，反之當日文與會者在提問時，英文講師即可切換至 English 聆聽口譯員翻譯後的英文進行回覆。...
本文將說明如何透過 GitLab CI + JMeter 實現小規模的 Load testing。
（本文同步發表於 Medium。）
操作步驟 先準備一個能夠操控 Container 的 GitLab Runner，gitlab.com 的使用者可直接用官方提供的 Shared runners。
站在巨人的肩膀上，我們要借用 justb4/docker-jmeter 這個優秀的 GitHub 專案，用它作為基底。
【補充說明】justb4/docker-jmeter 的作者已經寫好一個立即可用的 Test Plan 並搭配變數和幾個 script，也有易讀易懂的文件。因此如果你只是想要立即使用 JMeter 執行小規模的 Load testing，它只需要稍微微調就可以直接在 local 環境中拿來運用。
先將此專案 import 至 GitLab。由於是公開的 GitHub 專案，所以 Import project from 我們直接選擇 Repo by URL 並填入 GitHub 的 Git repository URL 即可順利 Import。 （等待 Import 動作執行完畢。）
由於 justb4/docker-jmeter 是設計用來直接拿來使用的，因此我們要稍作微調，讓它變成適合我們放在 GitLab CI 的模樣。調整的方向有 2 個：
修改 Test Plan，讓我們可以用 Variables 動態調整更多的 Load testing 參數。 讓 Variables 可以透過 GitLab CI 的各種方式輸入，方便以各種測試參數進行 Load testing。 決定好方向之後，開始實施客製作業。首先修改 Test Plan (....
在先前的文章，艦長曾說到 GitLab CI 的一項缺點，即是我們無法輕易的在 Local 環境運行 GitLab CI，往往需要反覆修改 .gitlab-ci.yml、送出 Commit 並等待 CI Pipeline 顯示出執行結果。這冗長又反覆的過程實在是為規劃 CI Pipeline 及撰寫 CI Job 帶來困擾，也大幅拖慢針對 CI Pipeline 本身的測試與驗證速度。
然而，這項長久困擾 GitLab 使用者的困擾，似乎浮現了一線曙光！為我們帶來希望的即是名為 glci 的工具。
（本文同步發表於 Medium。）
TL;DR glci 目前還在 v0.4.3，尚未進入 v1.0，是個 2021/2/17 才開始沒多久時間的年輕工具。因此尚無法在 Local 完整的還原 GitLab CI 的所有功能與行為。
但我必須說，能在 Local 執行 .gitlab-ci.yml 中的 CI Pipeline 與 CI Job 實在是很有吸引力的一件事，希望 glci 能持續發展下去，有興趣的朋友除了試用之外，不妨也考慮考慮發揮一下開源精神為此工具貢獻己力吧！
試用記錄 以下僅記錄這次試用過程的各項操作。
根據 README 的簡短註記，glci 可透過 yarn 安裝，所以先在 mac 安裝 yarn。
# macOS 使用 Homebrew 安裝是最省力的
brew install yarn 接著用 yarn 安裝 glci...
使用者在初次踏進 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 來因應。...