CI/CD Pipeline

CI/CD Pipeline

更新於 發佈於 閱讀時間約 4 分鐘

CI/CD Pipeline 是一連串自動化步驟,可以測試軟體,部屬應用程式。但實際上到底要做什麼事情呢?可以從 GitLab 的 Auto DevOps 了解。

Auto Dependency Scanning

掃描第三方函式庫的安全性漏洞。參考下圖:

raw-image

如果是 .NET 6 可以用以下指令掃描:

dotnet list package --vulnerable

參考如下:

https://devblogs.microsoft.com/nuget/how-to-scan-nuget-packages-for-security-vulnerabilities/
raw-image

測試功能性

執行 Unit Test、Integration Test,確保這次程式碼的調整,沒有改壞現有功能。

Auto Code Quality

https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html

https://gitlab.com/gitlab-org/ci-cd/codequality

Auto Code Quality 是靜態程式碼分析,也會將報告附在 Merge Request、Pipeline 上。GitLab 是使用 Code Climate 做程式碼分析,但已經包成 codequality 這個 Docker Image。

除了 Code Climate,還有 SonarQube 之類的軟體可以使用。

Auto Container Scanning

https://docs.gitlab.com/ee/user/application_security/container_scanning/

掃描 Docker Image 的漏洞,因為 Docker Image 上可能有安裝不少的軟體,這些軟體可能 6 個月後發現安全性上的問題。掃描出問題後,可以盡快的更新相關軟體,避免安全性上的問題。

Auto Review Apps

https://docs.gitlab.com/ee/ci/review_apps/

Review App 可以讓我們看 feature branch 的功能。當審核通過後,才合併到 Dev branch。

Auto Deploy

https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-deploy

自動部屬到 Kubernetes 上,是採用 Push Model,也就是 CI/CD Pipeline 主動更新 Kubernetes。

Auto Static Application Security Testing (SAST)

https://docs.gitlab.com/ee/user/application_security/sast/

靜態程式碼分析,專門掃描安全性的問題。

Auto Dynamic Application Security Testing (DAST)

https://docs.gitlab.com/ee/user/application_security/dast/

對運行中的程式執行安全性測試。

Auto Secret Detection

https://docs.gitlab.com/ee/user/application_security/secret_detection/

https://github.com/zricethezav/gitleaks

gitleaks detect -v

掃描程式碼,看有沒有密碼、API token 等等的敏感資訊。

avatar-img
C# 工匠的 DevOps 旅程
5會員
12內容數
專注於 C#, DevOps 的工程師
留言
avatar-img
留言分享你的想法!
Prometheus 提供 PromQL 讓我們對 metrics 查詢,可以查出最近 1 小時內的請求成功率,最近 30 分鐘內的請求延遲等等的資訊,下面用範例說明。 Request Per Second 此範例查詢「每秒的請求數量」,我用 Traefik 當作範例說明。 這幫我們得出以下結果:
API Gateway 是什麼? 參考上圖,API Gateway 是一個程式,位於 Client 和 Microservice 之間。當伺服器架構採用這種設計後,會有以下優點: 架構彈性 - 當伺服器架構需要調整的時候,Client 不需要調整(前提是 API 維持不變)。 IP Listing
我發現從統計學、電子、電腦繪圖的角度來看取樣,在說法上有點不同,但我認為大致上的概念是相同的。 資料實在是「太多了」,沒辦法拿這麼多的資料處理,但我們可以降低資料的數量,但和原本的資料大致上差不多,我們就可以做分析,得到我們想要的結果。 Reference:
監控的解決方案有很多種,我這裡選擇的是 Prometheus。實際上只有 Prometheus 還不夠,真正其實會安裝以下項目: 以上這些安裝項目都可以用 kube-prometheus-stack 這個專案提供的 helm chart 安裝。 用 helm 安裝: Reference:
Autoscaling 的目的是當有大量請求時,系統可以自動的增加運算資源,處理當下的大量請求;也可以根據當下資源使用率低時,自動降低運算資源,達到省錢的目的。
Prometheus 提供 PromQL 讓我們對 metrics 查詢,可以查出最近 1 小時內的請求成功率,最近 30 分鐘內的請求延遲等等的資訊,下面用範例說明。 Request Per Second 此範例查詢「每秒的請求數量」,我用 Traefik 當作範例說明。 這幫我們得出以下結果:
API Gateway 是什麼? 參考上圖,API Gateway 是一個程式,位於 Client 和 Microservice 之間。當伺服器架構採用這種設計後,會有以下優點: 架構彈性 - 當伺服器架構需要調整的時候,Client 不需要調整(前提是 API 維持不變)。 IP Listing
我發現從統計學、電子、電腦繪圖的角度來看取樣,在說法上有點不同,但我認為大致上的概念是相同的。 資料實在是「太多了」,沒辦法拿這麼多的資料處理,但我們可以降低資料的數量,但和原本的資料大致上差不多,我們就可以做分析,得到我們想要的結果。 Reference:
監控的解決方案有很多種,我這裡選擇的是 Prometheus。實際上只有 Prometheus 還不夠,真正其實會安裝以下項目: 以上這些安裝項目都可以用 kube-prometheus-stack 這個專案提供的 helm chart 安裝。 用 helm 安裝: Reference:
Autoscaling 的目的是當有大量請求時,系統可以自動的增加運算資源,處理當下的大量請求;也可以根據當下資源使用率低時,自動降低運算資源,達到省錢的目的。