前言 延續 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 流程 • 實際體驗如何修復程式碼中含有的漏洞...
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。...
（本文首次發佈於 2023-01-01，於 2023-10-24 更新。）
根據 iThome 的報導，Google 釋出了一個新的免費開源軟體漏洞掃描工具 OSV-Scanner，可以幫助開發者自動掃描找出專案內的相依套件是否存有漏洞。看見這樣的好工具，我們第一時間當然要問一句，這玩意能夠放進我們的 CI Pipeline 嗎？是否能有助於我們及早發現程式碼中潛藏的資安問題呢？
因此本文，就讓我們試著在 GitLab CI Pipeline 中運用 OSV-Scanner 吧！
操作步驟 尋找可用的 Docker Image 老樣子，想要在 GitLab CI Pipeline 中試用一個新工具的第一步，當然是先找找看有沒有現成的 Docker image 可以使用。
在 2023/10/24 於 Docker Hub 上搜尋「osv-scanner」，目前都只能找到非 Google 官方建立的 Docker Image。
（截圖時間：2023/01/01）
不知為何這些 Docker 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。...
本文為系列文章《跟著 GitLab Auto DevOps 學習 CI/CD Pipeline》的第四篇，藉由逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
在上一篇文章，我們學習到 workflow: 可以幫助我們控制在哪些條件之下才需要產生 CI/CD Pipeline。這次我們則是要進入第一個 Template - Jobs/Build.gitlab-ci.yml，看看 Auto DevOps 是如何實現同一個 CI Build 卻能適用於不同的程式語言。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） Jobs/Build.gitlab-ci.yml 首先讓我們直搗黃龍，直接查看 Jobs/Build.gitlab-ci.yml 的內容。
# 下面的版本來自 2022/02/04 的 https://gitlab....
在先前的文章，已分享過使用 JMeter 和 drill 進行小規模 Load Testing，今天延續同樣的主題，這次要使用另一個新興熱門的 Load Testing 工具 K6，試一試「如何透過 GitLab CI + K6 進行小規模 Load Testing」。
操作步驟 首先，K6 在 2021 年已經被 Grafana Labs 買下來了，但目前（2022/02/03）看來，K6 官網依然還維持原貌，沒有太大的變化，只是多掛上了 Grafana Labs 的 Logo。K6 有提供 Open Source 與 K6 Cloud 兩種方案，而本文將採用的是 Open Source 方案。
準備 GitLab Runner 老樣子，第一步我們要先預備合適的 GitLab CI 環境，應該不用再多做解釋，請先準備好能夠操控 Container 的 GitLab Runner，如果你不知該如何準備 Runner，又想要快速試一下本文的內容，那最簡單的做法是註冊一個 gitlab.com 帳號，然後建立新 Project 並使用官方提供的 Shared Runners。
準備 Docker image - K6 第二步，預備一個能夠運行 K6 的 Docker image。
這次很幸運，已經有現成的 Image 可以使用 loadimpact/k6...
本文為系列文章《跟著 GitLab Auto DevOps 學習 CI/CD Pipeline》的第三篇，藉由逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
在上一篇文章，我們學習了善用 include: 並透過合適的層級規劃，讓我們可以建立出屬於自己的 CI/CD Pipeline Templates。接著在本篇文章，我們要來認識在規劃 GitLab CI Pipeline 時，一個重要的進階功能 workflow:。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） workflow 在本系列文的第一篇我們介紹 Auto-DevOps.gitlab-ci.yml 時，有稍微提到 workflow:，但當時只有快速帶過，說明關於它的一個基本認識，在文章中我是這樣解釋的：
workflow: 類似程式語言中的 if / else，在 GitLab CI 我們可以利用 workflow: 設置不同的條件，藉此控制 GitLab CI 判斷哪些情境之下，才需要產生 CI/CD Pipeline。...