ref: https://vivek-singh.medium.com/system-design-cheat-sheet-318ba2e34723
本篇文章是一個筆記文,紀錄關於 System Design 路上常遇到的架構與元件,譬如
1. LoadBalancer
2. Caches
3. Queues
4. Configuration Service
5. API Gateway
6. Service Mesh
7. CDN
8. Cassandra
9. Snowflake
10. Numbers
每個概念都還會附上一些相關影片與文章,也因為是個筆記內容,因此每個元件的介紹都不會非常詳細,都是小小段落介紹每個元件的最基本概念。
譬如 LoadBalancer 的筆記有
1. L4/L7 兩種的差異
2. AWS 上 ELB/ALB/NLB 的三種差異
3. LB 的演算法, Round Robin,Weighted RR, Least Connection/Response Time/Resource based 等
Caches
1. 實作有 Memcached, Redis 等相關專案
2. 什麼時候會使用 Memcached:
a. 需求簡單,譬如單純 Key/Value 字串,可以輕易地透過調整 cores/threads 來調整效能。
b. Volatile,沒有儲存機制
c. 只有 LRU 的 Cache 演算法
d. Key 最多 250B, Value 最多 1MB
3. 什麼時候使用 Redis
a. 需要儲存 object,而非單純 string
b. 支援多種演算法
c. 支援 data store,可以達到 non-volatile 效果
d. 可以支援 Set/Hash/List/Sorted Set 不同型態
這類型的文章對於踏入 System Design 能夠提供一個簡易的入門介紹,先有哪些類別需要學習,再針對每個類別獨立學習也是一個不錯的學習路徑。
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
「configuration 介紹」的推薦目錄:
- 關於configuration 介紹 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
- 關於configuration 介紹 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
- 關於configuration 介紹 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於configuration 介紹 在 コバにゃんチャンネル Youtube 的最佳貼文
- 關於configuration 介紹 在 大象中醫 Youtube 的最讚貼文
- 關於configuration 介紹 在 大象中醫 Youtube 的精選貼文
- 關於configuration 介紹 在 OF-Config 函式庫— Ryubook 1.0 說明文件 的評價
- 關於configuration 介紹 在 AutoIndex Configuration Generator 的評價
configuration 介紹 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
本篇文章是個經驗分享系列文,作者探討 Kubernetes 內 15 種不被建議的部署策略與模式。
作者之前曾經撰寫過 Contianer 架構底下的部署模式探討,而本系列文(三篇)則是著重於如何將這些 containers 透過 Kubernetes 給部署到生產環境,總共會探討十五種不推薦的模式,接下來的三篇文章將會介紹各五種不好的模式。
Using containers with the latest tag in Kubernetes deployments
任何 container 的 image 都不應該使用 latest,因為 latest 本身沒有任何意義,這會使得維運人員沒有辦法掌握到底當前部署的版本是什麼,更嚴重的情況適當 latest 搭配 PullPolicy:Always 時會產生更為嚴重的問題。因為 Always 的策略導致每次 Pod 部署時都會重新抓取 image,所以一個 deployment 中,多個使用 latest tag 的 Pod 但是其實使用的 image hash 是不同的。
作者認為比較好的做法有
1. 所有 container image 都是不可修改的,一旦建立就禁止覆蓋,有任何改動就進版
2. 部署用的 image tag 使用有意義的版本名稱
補充: 實際上 pull image 也可以使用 sha256,譬如 "docker pull hwchiu/kubectl-tools@sha256:acfb56059e6d60bf4a57946663d16dda89e12bfb1f8d7556f277e2818680e4c8"
Baking the configuration inside container images
任何 contaienr image 建置的時候應該都要往通用的方向去設計,而不是參雜各種設定在裡面。著名的 12-factor app 裡面也有提到類似個概念,建置好的 image 應該要可以 build once, run everywhere,動態的方式傳入不同的設定檔案,而不是把任何跟環境有關的資訊都寫死
舉例來說,如果 image 內包含了下列設定(舉例,包含不限於)
1. 任何 IP 地址
2. 任何帳號密碼
3. 任何寫死的 URL
作者認為比較好的做法有
1. 透過動態載入的方式來設定運行時的設定,譬如Kubernetes configmaps, Hashicorp Consul, Apache Zookeeper 等
2. 根據不同程式語言與框架甚至可以做到不需要重啟容器就可以載入新的設定
Coupling applications with Kubernetes features/services for no reason
作者認為除了很明確專門針對 Kubernetes 使用,或是用來控制 Kubernetes 的應用程式外,大部分的 應用程式包裝成 Container 時就不應該假設只能運行在 Kubernetes 內。作者列舉了幾個常見的使用範例,譬如
1. 從 K8s label/annotation 取得資訊
2. 查詢當前 Pod 運行的資訊
3. 呼叫其他 Kubernetes 服務(舉例,假設環境已經存在 Vault,因此直接呼叫 vault API 來取得資訊)
作者認為這類型的綁定都會使得該應用程式無法於沒有 Kubernetes 的環境運行,譬如就沒有辦法使用 Docker-compose 來進行本地開發與測試,這樣就沒有辦法滿足 12-factor 中的精神。
對於大部分的應用程式測試,除非其中有任何依賴性的服務是跟外部 Kubernetes 綁定,否則這些測試應該都要可以用 docker-compose 來叫起整個服務進行測試與處理。
服務需要使用的資訊應該是運行期間透過設定檔案,環境變數等塞入到 Container 內,這樣也呼應上述的不要將與環境有關的任何資訊都放入 image 內。
Mixing application deployment with infrastructure deployment (e.g. having
Terraform deploying apps with the Helm provider)
作者認為近年來伴隨者 IaC 概念的熱門,愈來愈多的團隊透過 Terraform/Pulumi 這類型的工具來部署架構,作者認為將部署架構與部署應用程式放到相同一個 Pipeline 則是一個非常不好的做法。
將基礎架構與應用程式同時放在相同 pipeline 可以降低彼此傳遞資訊的困難性,能夠一次部署就搞定全部,然而這種架構帶來的壞處有
1. 通常應用程式改動的頻率是遠大於基礎架構的改變,因此兩者綁在一起會浪費許多時間在架構上
假如部署基礎架構需要 25 分鐘而應用
https://codefresh.io/kubernete.../kubernetes-antipatterns-1/
configuration 介紹 在 矽谷牛的耕田筆記 Facebook 的最佳解答
這篇文章要介紹的是 Jenkins Operator 這個有趣的應用程式,Operator 的概念先前有不少文章再探討其架構與意義,因此本篇文章會專注於 Jenkins Operator 這個應用程式能夠為 Jenkins 的環境與應用帶來什麼樣的變化。
首先本文開始前,要先準備三個東西
1. Kubernetes Cluster
2. Helm 安裝環境
3. 一個放有你 Jenkins pipeline 與 script 的 SCM(Source Code Management),通常都是 Git
接下來作者透過 Helm 安裝了 Jenkins Operator 該控制器到 Kubernetes 內並且準備了相關的 CRD 用來控制 Jenkins.
範例中的 CRD 主要會做兩件事情
1. 設定 Jenkins 本身,包含要安裝哪些 Plugin 等
2. SeedJobs: 可以將外部 SCM 內所描述的 Job 內容給直接設定到 Jenkins 內
當該 CRD 給套用到 Kubernetes 後,該 Jenkins Operator 就會幫忙初始化整個 Jenkins 以及相關的 Plugin。最後將 SeedJobs 內所描述的資訊給整合到 Jenkins 中來創建相關的 Job.
透過這整個 CRD 操作帶來的好處我認為有
1. 整個過程盡量減少手動操作,全部都依賴 Yaml 與 Pipeline 等程式碼的方式去維護
2. 與 Kubernetes 整合,對於熟悉 Kubernetes 的操作人員來說,學習過程不會太痛苦。
3. 把 Jenkins 變得稍微簡單一些,一些繁瑣過程讓 Jenkins Operator 去操作
我自己看完後,目前看到的壞處有
1. Jenkins 功能太多,生態系太複雜,我懷疑這種 Operaotr 只是一時的專案,沒有一直保持更新的話一定會有些功能終究還是要手動操作
2. 設定的內容我認為不如 Jenkins 生態系中的 Configuration as Code 這套 Plugin 來的專業與強大
3. Job 的設定部分我個人還是偏好使用 Jenkins Job Builder 這套基於 YAML 的解決方案來管理與定義全部
結論:
1. 我個人是當作一個新東西看看,但是不會有想要嘗試的慾望,因為覺得事情其實沒有變得簡單多少,甚至擔心引入一個半成品,導致多一個東西要維護..
https://medium.com/swlh/introduction-to-jenkins-operator-f4cb7ebc2e0b
configuration 介紹 在 AutoIndex Configuration Generator 的推薦與評價
Icon Path: This is the path to the icon image files (the path web browsers will access them from). The included icon sets are apache, kde, osx, and winxp. ... <看更多>
configuration 介紹 在 OF-Config 函式庫— Ryubook 1.0 說明文件 的推薦與評價
本章將介紹Ryu 內建的OF-Config 客戶端函式庫。 ... OF-Config 是用來管理OpenFlow 交換器的一個通訊協定。 ... Ryu 提供的函式庫完全相容于OF-Config 1.1.1 版本. ... <看更多>