Cheng Wei Chen | 艦長

前言 前幾天在 GitLab 社群中看見有人針對在 Windows WSL 上架設 GitLab 提出了一些疑問，覺得這是一個可以動手嘗試的題目，因此也抽了一個空檔快速的實驗了一次，下面就紀錄我這次實驗的過程與操作步驟。 操作步驟 1. 安裝 WSL WSL 目前可以直接在 Microsoft Store 中安裝，如下圖那個看起來有點喜感的企鵝，就是我們要安裝的 WSL。 2. 確認 WSL 版本 WSL 安裝完畢後，接著我們要進入 PowerShell，在 PowerShell 中輸入 wsl -l -v 來確認一下 WSL 的版本，以及目前是否已經有安裝了 Linux 環境。 如果要進入 PowerShell，可以在 Windows 的搜尋列中輸入 PowerShell 來啟動 PowerShell。 啟動 PowerShell 後，畫面上會出現一個類似下圖的「命令提示字元」視窗，但不同的地方是在 Command Line 的最前面會有 PS。 如上圖，輸入 wsl -l -v 即可查看 WSL 的版本與目前是否已經安裝了 Linux 環境；如圖片所示，在我的 WSL 中尚未安裝任何 Linux 環境。 3. 在 WSL 中安裝 Ubuntu 首先，我們要確認 WSL 可以安裝哪些 Linux 環境，在 PowerShell 中輸入指令 wsl --list --online。...

前言 延續 DevOps，DevSecOps 一詞在 IT 圈內也已經不是一個新詞，市面上有非常多的廠商都在銷售號稱與 DevSecOps 有關的產品，亦有不少來自資安圈的講師分享過 DevSecOps 的主題。就如 DevOps 一樣，DevSecOps 同樣也具備著「十個講師會有十一種 DevSecOps 的內容」的現象，但無論如何 DevSecOps 絕對是 DevOps 的其中一位後繼者，是當前企業多少會開始了解與碰觸的一項熱門議題。 在今年 2023 的 iThome Cloud Summit，我邀請了 GitLab 原廠的 Staff Solutions Architect - Toshitaka Ito，以及另一位 GitLab Hero - Mouson (墨嗓) ，一起針對 DevSecOps 這個主題，規劃了一場「輕輕鬆鬆體驗 DevSecOps」的 Hands-on Lab。 議程簡介 這次投稿的是 Hands-on Lab，以下是本次提供給主辦單位的議程簡介資訊： 延續 DevOps 風潮，其實 DevSecOps 一詞自 2012 年被人提出後，至今也超過 10 年了。DevSecOps 作為一個根源自 DevOps 而來的新詞，我們會發現它跟 DevOps 一樣有著「似乎沒有標準定義」、「不同企業的實踐方式皆不相同」的現象。 課程目標 • 認識 DevSecOps • 體驗來自 GitLab 的 DevSecOps 流程 • 實際體驗如何修復程式碼中含有的漏洞...

千呼萬喚始出來，認識許久的前輩、部落格 Complete Think 的主人 Rick 大大終於出書了。隨著新書資訊已經對外公開，我也終於可以把這個好消息分享給大家了。以下就全文獻上我為 Rick 的著作《SRE實踐與開發平台指南》所寫的推薦序，希望大家會喜歡。 啊，想要買書的這邊請喔！購書傳送門：《SRE實踐與開發平台指南》 Complete Think—知識工作者都必須學習的專業能力 如果你身處在 IT 或軟體開發相關產業，你可能會聽過下面的這些經典問題「星期五下班前可不可以部署？」、「為什麼老工程師要用註解的方式留下目前用不到的程式碼？」、「ＯＯＸＸ很潮，我們要不要用？」⋯⋯當你遇到這些經典問題時，不知道你第一時間的反應是什麼？是立即帶著（正面或負面）情緒回答呢？還是一笑置之？又或者是你會先退後兩步，釐清問題的範圍、全貌及背景資訊，然後再回答問題呢？ Rick Hwang，一位我有幸在社群中結識亦師亦友的前輩，「Complete think」不僅是他個人技術部落格的名稱，也是他個人思考方式的最佳寫照。如果你問我什麼是現代知識工作者都必須學習的重要能力，我認為答案會是「如何思考、看透問題背後的問題（QBQ）、洞悉問題本質、以及建構自己的知識（思維）體系」，而在 Rick 身上，我看見了這些能力的真實體現。回到前面的經典問題，如果是讓 Rick 來回答它們，你絕不會聽見「等到你老了，就知道為什麼要這麼做」，反之你會看到他清楚的陳述問題背後的問題，並提供具有清晰前提要件和背景資訊的完整論述。 有沒有一本書，都還沒進到正文，只是閱讀作者給讀者的「如何閱讀這本書」，就令人體驗到受益無窮和開啟思維的體驗？有！就是 Rick 的這本《SRE實踐與開發平台指南》。這本書乍看是在談論如何實踐 SRE，實則深入探討了能幫助團隊和組織運作順暢的各種架構和原則。 即便你不是 SRE，但只要你仍在 IT 或軟體開發相關產業，你絕對不能錯過這本書。而如果你已經是 SRE，你又不希望自己只是一位 Server Reboot Engineer 或 Service Restart Engineer，那麼你最好說服整個團隊一起結伴細讀這本能幫助你們學習 Complete think 的好書。學習作者是如何運用矩陣思維、從不同的層次來看待各種問題與現象，從更宏觀全貌的角度進行思考，明白如何依據自身的時空背景，找到適用於你們問題的「適切答案」。 最後，讓我再問一次「星期五下班前可不可以部署？」，想知道答案嗎？去找吧！Rick 已經將一切的答案都放在他的書中了！ —— DevOps Taiwan Community 志工 / 前 Organizer 陳正瑋（艦長） （再次附上購書傳送門：《SRE實踐與開發平台指南》）

2023 年，ChatGPT 與 OpenAI 議題大熱門，全球都在探討可以將它們運用在哪些工作領域中，當然軟體開發工程師也不例外，舉凡寫程式、程式碼重構、產生 Commit messages、code review、pair programming、寫測試⋯⋯，幾乎每一個動作都有人在嘗試結合這波「AI」熱潮，希望讓這些任務能做得又快又好。 最近剛好看見台灣知名的講師與開源專案貢獻者 AppleBoy 也投身在此議題，開發了名為 CodeGPT 的工具，不僅能用它來自動生成 Commit 總結，甚至能做出 Code review 提供一些程式碼的改善建議。 按著 AppleBoy 的 CodeGPT 工具說明，我第一時間的想法即是，這樣的一個工具是不是適合放進 CI Pipeline 中呢？如果能讓隨著 Merge request (或 Pull request) 而執行的 CI Pipeline 能自動產生一份由 GPT 提供的 Code review 程式碼改善建議，這樣我們就可以自動額外獲得一份來自「非真人觀點」的 Code review 建議；即便這些「非真人的觀點」不一定正確或準確（因為 GPT 已被證實有時會一本正經的說瞎話），但它的建議依然有機會幫助真人跳脫自己固有的觀點，以不同的角度思考同一個問題。 以下我們就搶先試驗，試著將 CodeGPT 放進 GitLab Merge request CI Pipeline 吧！ （本文初版撰寫於 2023.04.02，於 2023.04.04 更新。本文使用的 CodeGPT 版本為 v0.1.5，當你閱讀本文時，很可能 CodeGPT 已經改版與本文下述的操作步驟不同，還請自行關注各工具的最新異動資訊。） 操作步驟 下面我們就用一個最輕鬆的方式，來做出一個 Merge request 之 CI Pipeline，來實驗 CodeGPT。既然是最輕鬆的方式，所以我就直接在 gitlab....

這是一篇留在草稿區很久的文章草稿，本來應該在 2022 年 7 月把它寫出來，但一拖稿，就無限延後了，趁著春節休假期間，終於有時間將它整理為一篇「堪用」的文章。 前言 感謝 iThome 的邀請，2022 年能有機會再次擔任 iThome Cloud Summit 的講師，負責一場分享一場 Hands-on Lab。 由於 2021 ~ 2022 年，個人並沒有玩太多新鮮的雲端新工具，因此最後還是決定以 GitOps 為題來準備這場 Hands-on Lab。但畢竟我在 2020 年就已經分享過一次 GitOps，總不能直接拿老東西出來分享，因此這次特別針對內容做了調整，試著將 Kubernetes（K8s）放進 Lab 的內容中。 在 2020 年時分享的 Hands-on Lab 是以 GitOps with GitLab 為題，主要是以 GitLab 的 CI/CD Pipeline，搭配 GitLab 當時仍在 beta 階段的 Terraform 相關功能，讓學員運用 GitLab Runner 透過 CI/CD Pipeline 可以彼此 Tirgger 的方式來實現 GitOps 的概念；當時還跟 AWS 合作索取了一些試用額度，讓 Lab 學員可以用 GitOps 的方式，在 AWS 建立 Ec2 並部署 Application。...

根據 iThome 的報導，Google 釋出了一個新的免費開源軟體漏洞掃描工具 OSV-Scanner，可以幫助開發者自動掃描找出專案內的相依套件是否存有漏洞。看見這樣的好工具，我們第一時間當然要問一句，這玩意能夠放進我們的 CI Pipeline 嗎？是否能有助於我們及早發現程式碼中潛藏的資安問題呢？ 因此本文，就讓我們試著在 GitLab CI Pipeline 中運用 OSV-Scanner 吧！ 操作步驟 尋找可用的 Docker Image 老樣子，想要在 GitLab CI Pipeline 中試用一個新工具的第一步，當然是先找找看有沒有現成的 Docker image 可以使用。 在今天 2023/1/1 於 Docker Hub 上搜尋「osv-scanner」，只能找到兩個看起來並非是 Google 官方建立的 Image。 這兩個 Image 看起來都沒什麼人 Download 使用，稍微深入瀏覽後，可以發現 anmalkov/osv-scanner 的說明較完整，有興趣者可以嘗試看看。 以 anmalkov/osv-scanner 為例，我用它來嘗試掃描了手邊的一個專案，得到如下圖的結果，它依據 package-lock.json 的資訊，幫我找出許多的 Vulnerabilities，並且每一個 Vulnerability 都會提供一個 OSV URL，讓我可以了解更多的詳細資訊。 OSV URL 的網頁內容如下，會有完整的漏洞說明。 如果你想要自己 Build 一個 Image，則可以參考 GitHub Repo - osv-scanner ，在 Repo 中有提供 Dockerfile ，可以用來 Build image。在本文，我就是參考 GitHub Repo 的 Dockerfile，自行 Build 了一個可以讓我在 GitLab CI 中使用的 Image，並上傳 Docker Hub - chengweisdocker/osv-scanner-for-ci。...

辛苦了一整年（！？）終於在 2022 年底，將《和艦長一起30天玩轉GitLab》改版完成。這次也是走一個拖稿拖稿再拖稿的路線。好在出版社編輯沒有真的殺到我家樓下來堵我，畢竟都已經進行到排版二校時，我還一直試圖要塞入新的內容，實在是感謝他們的一再寬容。 除了感謝出版社，這次還要特別感謝三位朋友幫忙撰寫推薦序，以及家人們一再的包容與支持，二版新增的一小段致謝，就原汁原味的全文刊登如下。 2022 第二版致謝 隨著 GitLab 的迭代更新，我一直希望能有機會將本書改版更新，終於這份期望得以在 2022 年底實現。感謝在這段改版寫書過程中，提供我各種協助的各方好手——感謝願意推薦本書的社群前輩 William 及 Rick，你們豐富的知識與經驗一直是我努力學習的標竿；感謝同為 GitLab Hero 的墨嗓，你是我在專研 GitLab 之路上不可多得的好夥伴；感謝在 GitLab Taipei User Group 及 DevOps Taiwan Community 認識的多位社群朋友，彼此經驗交流、教學相長，讓社群能持續的成長茁壯。 最後，再次感謝我親愛的家人，感謝你們體諒並陪伴我每一次的寫稿生活，本書誕生的每一字一句都是你們的功勞。 其實在 2020 年《和艦長一起30天玩轉GitLab》初版上市時，我就已建立了 https://gitlab-book.tw 網站，在網站上提供最新的書籍內容勘誤，並一度想要將該網站轉化成為 GitLab 相關新知的分享平台，沒意外的話，明年會再次嘗試活化 gitlab-book.tw，看看可以如何讓網站能產生更多的價值。 2022/12/31 更新 由於 GitLab 實在是改版快速，因此我也會視狀況在 https://gitlab-book.tw 上更新一些書籍內容；像是 GitLab 15.7 推出後，在 gitlab.com 上就直接啟用新版的 Web IDE (VS Code)，導致我在書中經常提到的 File Templates 功能目前是暫時無法使用的，為了因應這個狀況，我就有在 gitlab-book.tw 網站上提供對應的內容更新。 最後，還是厚臉皮的來一段工商服務，如果你問我自己最喜歡《和艦長一起30天玩轉GitLab》第二版的哪些內容？我會推薦第五章「實作 CI/CD Pipeline」。這個章節是我將自己過去的職場工作、CI/CD Pipeline 工作坊及對外開課所獲得的各種經驗，再次整理後重新撰寫的；希望能讓這本 GitLab 專書，不只有 GitLab 功能面的內容，也可以有更多跳脫單一工具、有助於大家實踐 CI/CD Pipeline 的經驗分享。如果你也正在擔任 CI/CD Pipeline 水管工人，推薦你一定要讀第五章，也歡迎與我交流分享你的經驗喔！...