關於 ci/cd推薦 ，我們在網路上蒐集到這些相關的討論、資訊與評價

ref: https://jzimnowo.medium.com/harbor-keycloak-and-istio-a-good-dance-troupe-6c3520fb87de

本篇是個經驗分享文，作者想要打造一個基於 Kubernetes namespace 的多租戶 Kubernetes 平台。
該平台主要針對的是團隊內不同的 DevOps team，並且每個 Team 都會有自己的下列資源
1. Harbor: Private Container Registry
2. Keycloak: SSO
3. Istio: Service Mesh.

# Harbor
Harbor 是 CNCF 的畢業專案，專注於提供 private container registry，本身除了有友善的操作介面外，也整合了多項常見功能，譬如
1. 基於 OIDC 的授權認證機制
2. 容器安全性掃描
3. Chartmuseum (未來會被移除)
4. 專案管理

透過 OIDC 與專案的機制，能夠很輕鬆的針對不同專案設定不同權限，譬如屬於群組 A 的只能使用 Project A。
此外每個專案本身也有提供 robot account，該 robot account 的目的則是讓整個工作流程更佳簡潔。

如果要於 Kubernetes 中去抓取這些 Private Container Registry，則必須要透過 ImagePullSecret 的物件來描述登入資訊。
為了避免使用個人帳戶來存取，作者推薦每個專案都要準備兩個 Robot Account，這兩個 Robot Account 都只能針對該專案底下的 container 去存取
所以也不用擔心會去存取到其他 Team 的專案。
第一個 robot account 專注於 Pull Image，主要是讓 Kubernetes 內部可以下載 Image 使用。
第二個 robot account 則是給 CI/CD pipeline 使用，讓 pipeline 有能力將新的 image 給推向 Harbor。

前述所說 Harbor 可以基於 OIDC 來滿足認證的機制，作者於團隊中就使用 Keycloak 這個開源來作為一個 OIDC 提供者(另外一個常見的是 Dex)。
文章中有稍微介紹如何於 Keycloak 中創立一個 Client 的物件，並且於 Harbor 如何設定。
如果團隊有這個需求的可以看一下要如何操作。

文章最後探討使用這三個專案的一些經驗與痛點，有興趣的可以閱讀全文參考

ref: https://faun.pub/the-best-infrastructure-as-code-tools-for-2021-b37c323e89f0

這篇文章是一個 IaC (Infrastructure as Code) 的推廣文，文章分成幾個部分，從 IaC 的基本概念與應用談起，接者分析了幾個常見的 IaC 工具，最後探討了實際的使用案例

文章偏長，對於 IaC 概念很熟悉的讀者應該可以很快速地看完，以下針對部分進行一些摘要

The need for Infrastructure as Code
作者先描述過去幫機房部署新伺服器時的各種流程，機器少量時能夠透過人力慢慢處理，但是這類型的操作繁瑣，重複且惱人
為了讓這些流程處理得更佳順遂與一致，會有各式各樣的 scripts 等相關工具被開發出來，而這些流程慢慢的會往自動化的方式去發展。
IaC 文化的興起會使得有愈來愈多獲得共識的工具被開發出來，這使得 IaC 的使用門檻會有機會降低，愈來愈多的使用者能夠更簡易的透過 IaC 的方式來管理與維護自身的架構

Benefits and reasons to implement IaC
IaC 帶來的好處是非常顯著的，譬如
1. 將 Config 檔案當作整個環境的 sing source of truth
2. 每次的部署都是基於上述的 Config 來部署，能夠確保每次部署都獲得一樣的結果，避免人為的反覆長期操作帶來的錯誤
3. 透過程式化的方式去建置環境能夠更快速的去應變各種環境需求，對於 testing, developing, production 等各種變化都可以透過 config 的差異來快速搭建
4. Config 也可以透過 Git 的方式去管理來獲得更好的可稽核性與管理性。

Principles and best practices of Infrastructure as code
作者這邊列出了幾個實作上的推薦方式
1. 透過版本控制的方式來管理 IaC 的設定檔案，能夠讓維運人員使用開發者常見的開發合作流程來管理 IaC
2. 將 IaC 的工具整合到 pipeline 的 CI/CD 流程，讓 CI 流程去檢查 IaC 的設定是否符合預期以及 CD 流程來幫忙自動部署修改架構

Infrastructure as code tools
這個區塊作者列出了幾個常見的工具，包含 Terraform, CloudFormation, Puppet, Pulumi 等，接者又透過一張大表格來比較 Terraform/Pulumi/CloudFormation 三者的差異
Pulumi 這工具這一兩年開始聲勢比較多，跟 Terraform 一個最大的差異我想就是撰寫的方式，可以透過 Js, Go, Python...等程式語言來描述架構而並非使用 Terraform 自定義的 DSL 來管理。

最後面作者也列舉了六七個適合 IaC 的使用場景，有興趣的歡迎閱讀全文

本篇文章是ㄧ個 Kubernetes 相關工具經驗分享文，作者認為即使是前端開發工程師也必須要瞭解一下 Kubernetes 這個容器管理平台，作者認為 k8s 基本上已經算是這個領域的標準(de-facto)。

因此作者於本篇文章介紹一些搭建一個 K8s 叢集時需要注意的工具，透過這些自動化工具來減少反覆動作的執行藉此簡化每天的工作流程。

工具包含
1. ArgoCD
2. MetalLB
3. External-secrets
4. Cert-manager
5. External-dns

Simplify deploying of new apps
作者大力推薦使用 ArgoCD 來簡化部署應用程式，作者提到一開始使用 ArgoCD 時也是感到無比煩感，因為心中一直存在要於 `GitLab CI/CD pipeline` 透過 kubectl apply 的方式來部署應用程式，並不想要導入其他的元件來加入更多的複雜性。

然而當作者嘗試 ArgoCD 後，第一眼發現的是其架構不如想像中複雜，完全依賴 GitOps 的原則來簡化整個部署流程，同時透過一個 WebUI 的方式來呈現當前應用程式的部署狀況

Load balancer for your on-prem clusters
地端環境的 Load-Balancer，沒什麼好說就是 MetalLB。

Managing your secrets
Secrets 是 Kubernetes 內一個非常重要的物件，然而大部分的團隊都會思考如何有效且安全的去管理 Kubernetes 內的 Secret 物件。雲端供應商譬如 AWS Secrets Manager, Azure Key Vault 或是廣受熱門的 HashiCorp Vault.

作者推薦使用 external-secrets operator 這個專案來將外部的管理系統給同步到 Kubernetes 內並且產生對於的 secrets。

詳細全文可以參考下列原文

https://chris-blogs.medium.com/tools-that-should-be-used-in-every-kubernetes-cluster-38969ed3e603