Search
使用 Kubernetes 建構、測試和部署 Docker 應用程式，同時學習營運型(production-style)開發工作流程
從這 21.5 小時的課程，你會學到
1 從零開始學習 Docker，不需要以前的經驗
2 掌握 Docker CLI 來檢查和除錯執行中的容器
3 使用 Github，Travis CI 和 AWS 一起從頭開始建構 CI + CD 管道(pipeline)
4 透過開發一個複雜的應用程式來理解 Kubernetes 的用途和理論
5 當程式碼被推送到 Github 時自動部署它
https://softnshare.com/docker-and-kubernetes-the-complete-guide/
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://blog.argoproj.io/argo-workflows-2021-survey-results-d6fa890030ee
這篇是由 Argo 官方所發表的統計文章，該文章主要是探討 Argo Workflows 的使用，總共有效的問券有 60 份
你是誰
1. 32% DevOps Engineer
2. 26% Software Engineer
3. 15% Architect
4. 9% Data Engineer
使用案例(前六大項)
1. Infrastructure Automation
2. Data Processing
3. CI/CD
4. Batch Processing
5. Machine Learning
6. ETL
由於問券內容中大部分都是 DevOps 相關職缺，所以答案會偏向 Infrastructure, CI/CD 也是不太意外。
最受歡迎的功能(按照名次排序)
1. Workflow Template
2. CronWorkflows
3. API
4. Prometheus Metrics
5. Workflow Archive
6. Golang/Java/Python Clients
7. SSO
8. WebHooks
9. Workflow Reports
10. Node Offloading
11. Memoization
12. Semaphores/Mutexes
Argo 官方對於這個評比是有點經驗，本以為會更多人使用(6)與(12)，不過這些功能實際上的釋出也是相對新。
規模
1. 大部分的使用者一天會運行 10~100 個左右的 workflows
2. 有三個使用者每天會運行 1000 個以上的 workflows
3. 大部分使用者每個 workflow 運行的 pod 數量範圍為 10~100
4. 有兩個使用者每個 workflow 運行的 pod 數量超過 10,000
導入生產環境的困境
1. 有七個人表示習慣使用 Python，所以使用 YAML 語法相對困難
2. 有三個人表示需要去熟悉 Cloud-native/Container 的相關用法與概念
為什麼使用 Argo Workflows
1. 28 個人表示因為其是 Cloud Native/Kubernetes 相關專案
2. 有六個人表示 Argo Workflow 是目前最好用的 workflow 專案
3. 有五個人表示輕量與容易上手
4. 有五個人表示與 Argo CD 可以輕鬆整合無煩惱
對 Argo Workflow 有興趣的人可以參考這個專案，其還可以組合出符合 DGA 拓墣的關係圖，讓你的 job 組合變化多端
