2022 的第一篇部落格，就從整理一則舊筆記開始吧！這次整理的舊筆記是關於在 Ansible 的 Varaible 中使用 boolean 的一些個人經驗。（本文使用的 Ansible 版本為 2.10。）
內文 在撰寫 Ansible Playbook 的時候，我們為了讓它能夠運用在多種情境，我們經常會使用到 when: 來控制各個 task 是否需要執行，例如：
# 當目標 Host 的 Linux 為 Ubuntu 時，才執行此 Task - name: "Create nginx sites-enabled link | (Ubuntu)" file: src: "/etc/nginx/sites-available/{{ APP_NAME }}" dest: "/etc/nginx/sites-enabled/{{ APP_NAME }}" state: link when: ansible_distribution == "Ubuntu" 而在剛開始學習 Ansible，對於 Ansible、Python 及 Jinja2 還不夠熟悉時，我們可能會寫出下面這種 when:。
# 希望做到當 Variable is_laravel 為 true 時，就執行 task - name: Create ....
自從 GitLab 推出 Auto DevOps 功能之後，我在許多演講與社群的場合都曾分享過，其實 Auto DevOps 並不是真的那麼「Auto」，它的背後是仰賴 GitLab 官方事先預備好的眾多 GitLab CI Templates，這些 Templates 能夠根據 Project 內容，自動產生多種情境的 CI/CD Pipeline。因此如果你想要自學 GitLab CI 的各種進階用法與技巧，或想要參考別人如何規劃 CI/CD Pipeline，那麼這些建構出 Auto DevOps 的諸多 CI Templates 即是我們絕佳的學習與參考對象。
既然 GitLab 官方準備了這麼好的學習材料，當然要好好運用它，因此從本文開始，接下來我將以系列文的方式，逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） Auto DevOps CI Templates 首先讓我們快速查看 GitLab 官方準備的 Auto DevOps CI Templates，如下網址，我們可以在官方公開的 GitLab Project 中找到它們。...
說到最近 IT 圈最熱門的資安問題，想必大家一定都知道，即是源自 Apache Log4j 2 被開採的漏洞 Log4Shell，事件爆發至今依然燒個不停，多少 IT 人為了盤點影響範圍與修補漏洞，不知道少睡了多少時間、死了多少腦細胞，此時此刻要先向所有 IT 人說一聲「辛苦了！」。
連上網路即是被攻擊的第一步 回到本文主題，如果你有經手 Server 管理與維護的工作，想必你一定有過這樣的經驗，即是只要 Server 一接上網路，接著在 Log 中就會開始看見各式各樣嘗試攻擊你的紀錄，以最常見的 Web Server 為例，我們經常會在 access.log 看見類似下面這幾種 Log：
# 下面以 Nginx 的 access.log 為例 ## 針對 Wordpress 的攻擊，看你是不是會不小心把 wp-admin.php 暴露在外 14.18.100.250 - - [18/Dec/2021:03:41:40 +0800] "GET /wp-admin.php HTTP/1.1" 301 178 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36" ## 嘗試找到 MySQL 的介面或資訊 14.18.100.250 - - [18/Dec/2021:04:25:32 +0800] "GET /admin/mysql/ HTTP/1....
感謝所有的贊助商、講師、社群、以及報名參加的所有與會者的支持，最終經過多次延期的 DevOpsDays Taipei 2021 已於 2021/11/24 在臺北文創大樓 6F 順利舉辦。今年一樣擔任大會籌備人員之一，但老實說由於 COVID-19 疫情的緣故，所以個人能投入在籌備工作上的心力不比往年，這次活動能順利舉辦，真的要感謝 iThome 在籌備工作、金流、物流、人力全方位的全力支持，以及 iThome 辦活動大神 Chris 的辛勞。今年一樣用一篇簡短的文章，紀錄與本次大會相關的所見所聞。
活動基本資料 官網：https://devopsdays.tw 日期：2021/11/24 09:00 ~ 17:30 地點：臺北文創大樓 6F 議程：共 17 場（含 3 場 Keynote） 工作坊：共 13 場 贊助商：共 25 家 活動人數：超過 500 人 活動共筆：https://hackmd.io/@DevOpsDay/2021 開場 我的部分 今年還是被推坑負責 10 分鐘的開場，老實說直到活動舉辦的前一晚，我都還在思考開場到底應該要講些什麼？最後還是決定順著當時閱讀《一個 Scrum Master 的獨白》這文章時獲得的感動，想要提一下「反思」這件事情。
因此最終就如我事後在 FB 貼文中做的簡短分享，這次開場主要想分享幾件事情：
DevOps 從 2009 年出現至今，已經超過 10 年了。 台灣大約是從 2014 年開始有人浮上水面談論 DevOps 議題，至今也差不多 6-7 年了。 DevOps 是個「不新」的東西了，那麼你目前實踐 DevOps 了嗎？實踐的狀況如何？ DevOps 是個「開放」的議題，人們對於它有著不同的觀點、期待與想像，那麼你又是如何描繪你所謂的「實踐 DevOps」？ 反思，當一個關鍵字熱門與普遍到一個程度之後，我們應該對它有更多的反思。同樣再回到前面幾點，過去、現在 DevOps 在談討哪些議題，世界的趨勢潮流正往何處發展？台灣的 IT 圈內又是如何看待它？更延伸的如何看待各界各方推崇的各種「實踐方法」、「認證」、「解決方案」、「工具」⋯⋯ 延續反思，也許我們應該回歸初衷，思考為何當年會舉辦第一場 DevOpsDays，為何 Flickr 可以在 2009 就讓 Dev 與 Ops 合作，進而實現一天部署 10 次以上，以及為何 Patrick Debois 會說 DevOps is a human problem。也許 DevOps 最核心最單純的就只是想要解決「讓人(Dev)與人(Ops)可以良好的合作協作」，它的初衷目標想要解決這項「人」的問題，於是眾人圍繞著初衷，開始持續不斷運用各種方法及工具來「持續改善」的解決它。 最後一點是實踐，DevOps 是需要逐步實踐的，別人的 best practice 也許用在自己身上只剩下 good practice！？正是因為如此，我們期待未來可以有機會，在更多的場域，聽見來自不同產業及規模的組織，分享更多元的 DevOps 實踐經驗，彼此借鏡、彼此學習、彼此成長。 其實開場講稿，重寫了好幾遍，也腦中練習了好幾次，但上台時只記得「老東西、反思、初衷及實踐」這幾個關鍵字，希望最終在台上的表現不會太差，感謝大家的包容啦。...
2021/09/28 的晚上，台灣敏捷協會 ACT 舉辦了一場線上直播【Agile Talks 敏捷論壇系列】全台敏捷大調查，Scrum Master 的三兩事。剛好那一天晚上有一些空閒，於是就來當了一下雅婷逐字稿，邊聽邊記錄了一些自己有聽見的重點，這些重點筆記當晚已經有直接分享於 FB 貼文，本文只是再做一次簡單的校稿與整理。
活動基本資訊 （基本資訊轉貼自活動報名頁面。）
敏捷是這幾年最熱門的話題，Scrum 也是台灣普遍使用的 framework。Scrum Master 這個角色，普遍對他的定位也充滿爭議。感謝 Josh 陳俊樺 佛心對敏捷在台灣社會的發展做了深入研究，並撰述論文發表。
這次 Agile Talks 論壇除了邀請 Josh，還邀請幾位 Scrum Master 一起來對話，來聽聽彼此的看法與研究。
與談人 敏捷實踐者
敏捷行者 / Josh 陳俊樺 魚尾 Agile Coach / Russi 王泰瑞 Jason 廖健勝 主持人
敏捷總舵主 / Hermes 張昀煒 直播影片網址 https://www.youtube.com/watch?v=UPNqzuJnPSQ
筆記 Q: 使用看板方法是否需要 Scrum Master？ 要，因為看板有更多的資訊流與資訊需要解讀，如果有一個角色可以適度的幫助大家解讀，令團隊能有所改善是好的。（謎之音：但這樣的角色還叫做 Scrum Master 嗎？） Q: Scrum 的正確性？ Russi：還是應該要回到為何要做這件事？ 為了團隊自主管理、有助於團隊實現商業價值、對齊商業指標、響應變化的能力⋯⋯。敏捷可以運用在更多領域。
王泰瑞：組織有響應變化的能力不等於組織有能力賺比較多的錢。我當初認為 Scrum 是用來幫助團隊可以不再受到 Waterfall 的壓榨，避免不懂的人只知道壓時程。因為有很多時候，不懂技術、工程的人只懂的壓時程，這當然也不是他的錯，因為他有他要負責的考量。我認為 Scrum 只有適合不適合，沒有正確不正確。Scrum 是一種可以幫助團隊成長的框架。...
在 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 會議室連結。...