Skip to main content

· 5 min read

標題: 「新手閱讀,我踩過的 Terraform 各種雷」 類別: terraform 連結: https://medium.com/contino-engineering/10-things-i-wish-i-knew-before-learning-terraform-f13637a01aa6

本篇文章作者分享自己學習與使用 Terraform 多年來遇過的各種雷,也希望藉由這類型的文章可以讓每個踏入 Terraform 的人都不要走冤枉路

  1. Make sure you have a terraform block in your configuration TF 檔案中可以透過 Terraform 區塊來描述關於 Terraform 本身的一些限制,譬如版本條件,相關的 provider 來源以及版本。 這個區塊非常重要但是本身是一個 optional 選項,所以不寫其實不影響整體功能,但是沒有去限制使用的版本範圍其實就跟任何的軟體環境一樣非常危險, 很容易踩到「昨天還可以,今天就不行的」通靈現象,所以作者希望每個人都好好的將 Terraform 區塊描述清楚,確定當前支援的版本是哪個確保該 TF 能夠用正確的版本於任何環境執行

  2. Statefile 實際上本身是純文字格式,作者想要提醒的是 State 檔案作為 Terraform 同步上最重要的檔案,其本身是一個純文字明碼的格式,這意味你運行過程中的任何帳號密碼其實都是純文字的格式存放於該檔案中。 所以 State 檔案的保存非常重要,需要用很嚴肅的資安態度來保護這個檔案,否則該檔案被人取得則你 TF 中的各種資訊都會被對方取得。 作者直接於文章中展示一個範例,該範例會創建一個 AWS aws_secretsmanager_secret_version,而該物件的 secret_id, secret_string 都會以明碼的方式被存放於 State 檔案中。

  3. Have verbose variables and outputs blocks TF 中的所有變數都可以用非常簡易的方式去宣告,但是如果妥善地利用這些內建的功能將可以使得變數的使用變得更加方便,特別是當該變數要跨 Module 使用時,呼叫者可以透過更輕易的方式 去理解該變數的格式與用法。 其中最為重要的則是 validation 的內容,作者以 AWS image_id 為範例,該變數基本上就是一個字串,所以使用者可以傳遞任何變數到該欄位去使用,但是如果搭配 validation,就可以讓 TF Apply 提早 先觀察到這些變數是否合法,能夠降低與避免不必要的失敗。 所以針對每個變數都好好的撰寫相關敘述與驗證,能夠讓團隊使用上減少無謂的猜想與溝通。

  4. Integrate your environment with a pipeline early Terraform 的入門非常容易,但是當你想要將 Terraform 導入到團隊中並且與其他人共同合作時,整個使用上的複雜度會大幅度增加。 作者認為如果真的要導入 Terraform 到整個團隊中,則要盡快且盡可能地將 Terraform 導入到現有的 pipeline 架構中,譬如 Terraform Cloud 服務 能夠幫你妥善的管理這些 Lock/State 並且透過 Terraform Apply 來執行變化。

作者還有第二篇探討剩下的用法,包含 Keep your code together as much as possible Have clear lines of demarcation on responsibility Use multiple environment files for the same code Familiarise yourself with HCL’s functions and meta-arguments Terraform is not a golden bullet

有興趣的讀者建議兩篇文章都閱讀一下

· 3 min read

標題: 「容器的除錯之路,遇到 Permission Denied 該怎麼辦」 類別: container 連結: https://live-rhes.pantheonsite.io/sysadmin/container-permission-denied-errors

作者提到大部分遇到 Container 權限問題時,最無腦的一招就是 --privileged 直接硬上權限,但是其實大家都不知道自己到底缺少什麼權限,盲目地使用 --privileged 的確可以解決問題 但是實務上卻是犧牲 Security 換來的,因為不知道缺少什麼而直接硬開,其實就是硬生生的將幾乎所有保護功能都關閉。

本篇文章就來探討當遇到權限問題時有可能是什麼造成的,以及應該如何精準地去設定這些權限而不是用一招 --privileged 跳過。 此外由於作者本身就是 Podman 開發團隊,因此文章之後的介紹與範例都會基於 Podman 來完成,

  1. 錯誤定位

如果你的容器問題透過 --privileged 也不能解決,那至少你的問題跟本篇文章的關聯性不大,或是說你的問題其實根本不是安全性方面的設定問題,只有當妳確認你的問題 可以因為 --privileged 而解決時本篇文章的內容才會對你有幫助

  1. Is SELinux the issue?
  2. Is AppArmor the issue?
  3. Test capabilities
  4. Test SECCOMP
  5. Test masked kernel filesystem

除了上述五個安全性設定外,作者也針對 namespace 探討可能會出現的問題,包含

  1. Is user namespace the issue?
  2. Is network namespace the issue?
  3. Is pid namespace the issue?

最後就是不免俗的推薦大家使用看看 rootless container,畢竟大部分的應用程式其實都沒有要寫入系統的需求,理論上來說應該都要可以運行於 rootless 的模式

整篇文章整理的非常的好,每個類別都有指令操作來介紹概念,對於這些資安控管不熟的人來說可以說是一個溫習的好機會

· 3 min read

標題: 「成為軟體架構師的閱讀之路」 類別: others 連結: https://haitham-raik.medium.com/books-for-great-software-architect-34c81fc70e12

作者認為網路上有很多文章分享想要成為一個軟體架構師應該要閱讀哪些書籍來補充知識,但是這些文章都沒有提供一個好的閱讀路徑,沒有告訴你說 這些書有什麼樣的前置條件,這群書有什麼樣的閱讀順序等,這很容易造成讀者沒有系統的四處閱讀,容易導致無聊與沮喪。

作者根據自己的經驗整理特這些書籍,並且從中找到一個閱讀順序,透過這些閱讀順序可以讓你掌握每本書籍的前置知識同時也能夠有更好的知識去思考書本所談論的內容。

作者認為軟體架構實際上還可以根據領域進行二次細分,包含

  1. 應用架構
  2. 整合架構
  3. 資料架構

不同專項其內榮與知識都不同,因此閱讀時的路徑也會不同。所以本篇文章實際是個系列文,總共會有四篇 本篇是一個探討大綱的文章,探討一下基本概念,而後續系列文則是會針對上述三個不同面向去深度探討該怎麼閱讀

要認真踏入軟體架構前,必須要先掌握基本概念,如相關技術與工具,而作者認為學習這些基本概念的路徑就是所謂的 Design Path. Design Path 中將會學習到

  1. Domain-Driver Design(DDD)
  2. Object-Oriented Design Patterns
  3. Basic agile Development conecpts
  4. Modeling using UML
  5. Respoinsiblity-driven design(RDD)
  6. ..等

針對這 Design Path,作者推薦依照順序閱讀下列書籍

  1. Applying UML and Patterns, by Larman
  2. Head First Design Patterns, by Freeman
  3. bject Design: Roles, Responsibilities and Collaboration, by Ivar
  4. Domain-Driven Design Tackling Complexity in the Heart of Software, by Eric

掌握好 Design Path 後,下一個就是 Architecture Fundamentals 的技術掌握,該過程要學習關於架構的基本概念,原則,模式與實踐方式,閱讀書籍如下

  1. Fundamentals of Software Architecture, by Mark Richards
  2. Clean Architecture, by Robert Martin
  3. Documenting Software Architecture, by Paul Clements

· 3 min read

標題: 「使用 serverless 5年後的心酸經驗談」 類別: usecases 連結: https://dev.to/brentmitchell/after-5-years-im-out-of-the-serverless-compute-cult-3f6d

本文作者想要分享自己過去五年來使用 Serveless 的經驗談,從不同角度切入導入 Serveless 後的痛點。 作者的 serverless 環境是基於 AWS 環境,使用了包含

  1. API GAteway
  2. Cognito
  3. Lambda
  4. DynamoDB
  5. DAX
  6. SQS/SNS/EventBridge

作者提及了幾個痛點,包含

  1. Testing
  2. Account Chaos
  3. Security
  4. No Fundamental Enforcement
  5. DNS Migration Failures
  6. Microservice Hell
  7. API Respones 回傳不一致

這篇文章最有趣的點不是文章本身,而是底下的留言討論,雖然有少數留言是支持作者但是大部分的人都是秉持反對的意見來看這篇文章。 我自己的角度是這篇文章提出非常多問題,但是這些問題我看不太出來跟 Serveless 的關係是什麼,更多的是公司的文化,工程品質與開發工具有關 譬如作者說團隊內有很多非資深工程師會因為 serveless 的易用而依賴自己的想法去攥寫,譬如光 Auth 就有十種不同方式。 但是仔細思考這個問題,似乎 server-based 的架構也會有這問題,完全是公司的文化與規範問題。 其他問題還有很多寫 serveless 的人都沒有 HTTP 的深厚底子,所以 200,400,500 想回就回,然後回傳格式也都沒有統一固定 這些東西其實跟 serverless 也沒有直接關係,更多依然是 Code Review 的問題,工程師品質的問題。

所以有時候看文章除了單純閱讀外,也要思考一下作者講的東西自己是否認同,同時也可以看下留言處,來自不同文化與團隊的留言往往能夠帶來更大的啟發,也是閱讀網路文章上我覺得非常有價值的地方

· 3 min read

標題: 「istio 下因為YAML 與 Go template 結合產生的 CVE」 類別: others
連結: https://paper.seebug.org/1882/

熟悉 Kubernetes 的使用者一定對於各式各樣的資源格式感到不陌生,譬如描寫一個 Pod 需要準備些關於 containers 的基本資料,其餘還有 Label, Annotation 等 各種資料需要填寫。

Kubernetes 內透過 apimachinery 的方式來驗證每個欄位是不是合法,譬如最常見的就是創建資源名稱時有時候會因為等出現格式不符合,準確來說是 Pod 的方式來驗證每個欄位是不是合法,譬如最常見的就是創建資源名稱時有時候會因為等出現格式不符合,準確來說是 透過 DNS RFC 1123 來驗證 Pod 是否合法。 部分的數值資料可能會於 Controller 中額外去檢查,至於自定義的 CRD(Customer Resource Definition) 則是創建時可以透過 openAPIV3Schema 去定義每個欄位的合法數值。

今天這篇文章要介紹的問題是跟 istio 環境的問題,當使用者創建一個名為 Gateway 的資源到叢集中時, istio 會去讀取該 Gateway 資料並且轉換為 Service/Deployment 兩個底層資源。 作者仔細研究發現創建 Service 時會從 Gateway 中的 Annotation 找到名為 "networking.istio.io/service-type" 的資料,並用其作為 Serivce 的 type.

然而 Annotation 的數值沒有並沒有任何檢查機制,所以使用者可以於該欄位 "networking.istio.io/service-type" 填入各種數值,因此作者就嘗試撰寫一個非常長的 Annotation,譬如

  annotations:
networking.istio.io/service-type: |-
"LoadBalancer"
apiVersion: apps/v1
kind: Deployment
metadata:
name: pwned-deployment
namespace: istio-ingress
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.3
ports:
- containerPort: 80
securityContext:
privileged: true

結果非常順利的, isio 最終創造了一個作者故意描述的 deployment,而該 deployment 還特別的設定 privileged: true 的選項並且透過這次的測試證明該 YAML 的檢查問題導致使用者有機會插入任何想要的資源到環境中 對本文有興趣的可以觀看一下

· 4 min read

標題: 「三座獨立 k8s cluster 還是一個跨三個地區的 k8s cluster ?」 類別: kubernetes 連結: https://itnext.io/3-reasons-to-choose-a-wide-cluster-over-multi-cluster-with-kubernetes-c923fecf4644

講到多套 kubernetes 的情況下,目前大部分的文章都會推薦用三套獨立的 kubernetes 叢集而非架設一套同時管理三個地點的 kubernetes 叢集。 本篇文章作者從不同的面向分享為什麼要選擇一個 kubernetes 管全部,而不是要架設三套 kubernetes 叢集。

Latency

一套 kubernetes 最令人詬病且很難處理的就是 Latency 的問題,作者提到 Latency 的問題會影響 ETCD ETCD 被影響後會影響整個叢集的運作,甚至連應用程式相關的處理都會變慢。

作者提到其實這個問題能夠採取兩個步驟來解決

  1. 重新安排 etcd 的節點位置,或是使用 non-etcd 的解決方案
  2. 透過 node labels 讓要使用 etcd 的服務跟 etcd 盡量靠近

註: 我是覺得這說法不能解決問題,一般應用程式要是被分散到不同地區你的存取還是有機會跨地區,除非要很認真地針對不同地區去設計 label,讓應用程式的部屬都只會固定同個地區,但是要這樣搞跟我直接搞三套不覺得後者會比較累。

Security

作者一直強調使用 mesh VPN 來打通底層所有網路封包處理,讓你一個大 k8s 管理多個地區,就不用擔心底層網路問題

單套 k8s 的好處有什麼?作者認為有

No Complicated tooling

作者提到 2021 年的 KubeConf 有各種管理多套 k8s 叢集的工具,如 KubeEdge, OpenShift Edge, Akri, Baetyl, Kubermatic, Rancher, KubeFed... 等,如果用一套大 k8s 就可以不使用這些工具,直接減少與這類型複雜工具的依賴性 一套 k8s 叢集可以讓你使用最簡單也是最習慣的方式來管理所有環境

No extra overhead

每套 K8s 環境中都會有如監控,日誌, registry 等各種工具,多套 k8s 的架構就是每個叢集都要安裝一份,但是如果採用一個大 k8s 的架構就只要維護一份即可 所以可以減少很多不必要的重複安裝。

Ultimate Flexibility

這段其實不很理解,為什麼作者這麼想要推廣 mesh VPN ...

註: 這篇文章底下有留言說探討到說 RBAC 等相關權限問題是個很大的問題,你一套 k8s 很難處理這些,事情沒有想像的這麼簡單

· 7 min read

標題: 「新一代 Helm Chart 的管理套件 helmwave」 類別: tools 連結: https://medium.com/wriketechclub/new-wave-for-helm-b9800733587f

Helm 作為現在包裝與安裝 Kubernetes 應用服務的主流方式,單單使用 Helm 很多時候不能滿足部署需求,譬如公司的業務是由多套 Helm Chart 同時組成的,這時候可能會有幾種做法

  1. 使用 Helm Dependency 的方式來產生一個 Umbrella charts 讓你可以安裝一個 Helm 實際上會把相關的服務一起搞定
  2. 透過 Helmfile 等相關工具以更上層的概念來管理你的應用,用多套 Helm Chart 來管理與部屬你的應用程式

而作者長期使用 Helmfile 來管理各種 Helm 的安裝方式,而今天作者終於發現一個相對於 Helmfile 來說更容易使用,而且整體使用方式更為簡潔的解決方案,helmwave.

Helmwave 的官方介紹很簡單, Helmwave is like docker-compoose for helm.

其本身的實作更為簡潔,直接使用 Helm Library 於整個實作中,所以下載單獨的 binary 即可,不需要如同 helmfile 一樣還要於系統中先安裝 helm 等相關工具。 文章中透過範例來示範如何滿足

  1. 服務需要安裝多套 Helm chart
  2. 有兩個不同環境, prod 與 stage 有不同的 values 要使用

整個使用的方式跟 docker-compose 有點類似,可以透過 helmwave up, helmwave down 的概念來啟動與停止服務,只不過所有的服務都是基於 k8s + helm-charts 來完成。

有使用 helmfile 的人可能會對這類型的工具比較有感覺,也許可以看看其差異性是否真的有如作者所提這麼好


標題: 「DevOps 的 2022 學習之路」 類別: others
連結: https://medium.com/faun/devops-roadmap-2022-340934d360f9

本篇文章是作者根據自己的觀察與經驗,列出 2022 需要繼續學習與觀察的 13 項技能與概念,希望讓每個 DevOps(SRE) 相關領域的人有一個方向去精進自己。

  1. Network Technologies 網路的概念短時間內很難被顛覆,所以掌握基本的 L4/L7, HTTP2/, HTTP3/(QUIC), DNS, BGP, Load-Balancing 等基本網路概念絕對不吃虧,作為一個熟悉架構的專家,能夠描述環境中的封包流向是不可缺少的能力。

  2. OS, particularly Linux Linux 很重要,請學習系統上的各種基本概念, CPU/Memory 基本概念, Init, cgroup 等

  3. CI/CD Jenkins 作為老牌的解決方案,能夠使用其實也很好,不過要注意的是現在有愈來愈多的環境嘗試使用其他的 pipeline 來搭建,所以有時間的話也可以學習一下其他的解決方式,讓自己能夠有能力去面對各種需求

  4. Containerlization/Virtualization 除了最知名的 Docker 環境外,也嘗試看看 containerd, podman 等不同專案,同時也考慮如何將 container security 的概念給導入到日常生活中

  5. Container Orchestration K8s 幾乎變成容器管理維運的 de facto 標準,單純的 k8s 叢集還不足以面對所有正式環境的問題,所以還需要搭配各個面向的概念將其整合才可以打造出一個適合團隊的 k8s 叢集。

  6. Observability at Scale 除了最基本常見的 Prometheus 之外,也看一下其他基於 Prometheus 所打造更適合大規模的架構,如 Thanos, Cortex, VictoriaMetrics 等 此外可以試試看 Continuous Profiling 等持續觀察系統效能的工具,如 Parca, Pyroscope, hypertrace 以及順便試試看導入 Open Telemetry。

  7. Platform team as a Product team 稍微有規模的團隊可能會慢慢的感覺到 Platform 逐漸轉型成為一個 Product 的概念,只不過該 Product 的面向對象是內部開發與測試人員而並非外部使用者。 整體目標就是打造一個更好的協同平臺,讓開發與測試人員能夠更有效地去滿足日常工作需求,同時 Platform team 除了維護產品之外也要教授使用人員讓他們有能力去使用該平台來滿足需求 而不是所有問題都要一直讓 Platform 的人來幫忙處理,這種模式小團隊可行,但是當團隊過大時就沒有辦法處理。

  8. Security

  9. Programming

  10. Infrastructure as Code

  11. Cloud

  12. Technical Writing

  13. Site Reliability Engineering

剩下的內容就留給有興趣的人自行到文章去觀看,每個類別都有舉出幾個趨勢與值得關注的專案,其中特別注意的是 Technical Writing 這項技能非常重要 遠端工作的趨勢使得透過文字交流的機會比過往多很多,所以如何寫出一個有效不會浪費彼此時間的設計文件,架構,開發文件等則是一個很重要的技能,所以即使是個開發人員也要努力練習 將腦中的想法有系統地呈現出來

· 3 min read

標題: 「強化 Kubernetes 叢集的必備工具」 類別: kubernetes 連結: https://medium.com/mycloudseries/must-haves-for-your-kubernetes-cluster-to-be-production-ready-dc7d1d18c4a2

作者本篇文章想要分享一個其用來讓一個 Kubernetes 變得能夠真正上戰場的相關工具,因此文章中特別強調是 Production-Ready 的情況。 一個 Production Ready 的 K8s 叢集必須對於下列每個大項目都要有相關處理方式,譬如

  1. Reliability and Availability
  2. Security
  3. Network, Monitoring & Observability
  4. Backup/Recovery
  5. Cost Optimization
  6. Cluster Visualization

Reliability and Availability: 該領域的兩個指標代表的意義不太一樣,但是對於一個提供服務的叢集來說都一樣重要

這邊作者列舉了幾個工具譬如

  1. K8s 內建的 HPA
  2. AWS 的 karpenter,讓你針對基於節點為單位來擴充
  3. Cluster-Autoscaler
  4. Goldilocks

Backup/Recovery 有不少人團隊都對於對於叢集的備份與還原感到頭痛,目前最知名的開源專案莫過於 Velero,其支援不同的儲存設備如 Cloud Storage 等來存放,讓不同環境的 k8s 使用者都有辦法去備份其叢集內的資料

Cost Optimization

對於雲端架構來說,基本上雲端業者的內建功能已經可以針對如 VM, 底層架構等各種服務去列舉出各自的花費金錢,將此概念套入到 Kubernetes 本身大抵上只能理解到 Master Node, Worker Node 等之類的花費, 因此透過 Kubecost 之類的專案來將成本的洞察範圍擴充到 Kubernetes 內部,以 namespace, pod 等各種 k8s 的資源為單位來列舉實際花費的金額,能夠讓團隊更有效地去管理相關花費

· 4 min read

標題: 「你真的有正確使用 SSH 嗎?」 類別: tools 連結: https://smallstep.com/blog/use-ssh-certificates/

SSH 基本上是每個系統管理員都熟悉不過的工具,而本文的作者指出 SSH 使用上有一些小缺陷,譬如

  1. 使用者體驗很差,每一個新使用 SSH 的人如果不熟悉其概念,每次連線到新機器都會看到一次 Yes/No 的選擇,就因為不熟大部分的人都會直接選擇 Yes 來通過, 背後實際發生什麼事情都不清楚,只知道會動就好
  2. 大規模的管理 SSH 非常麻煩且花費時間,Hostname 如果前後有出現重複的還會出現問題,需要重新處理 known_hosts 等相關資料
  3. 透過 Key 的管理聽起來很安全,但是其架構使得使用者通常不太會換 key,會一直重富使用固定的那把 Key 來避免重新處理一切問題

舉了一些問題後,作者點出能夠真正駕馭 SSH 的應該是採取 SSH Certificate 而非使用 SSH Public Key 來進行身份驗證。 作者團隊開發了些許工具來幫助其他人能夠更輕鬆的使用 SSH Certificate 但是卻發現這類型的工具卻沒有受到歡迎與採用,因此也針對這個現象 進行問卷調查,想瞭解這類型的工具為什麼不受青睞,原因包含

  1. 根本沒聽過 SSH Certificate
  2. Certificate 以及 PKI 架構對人們來說不容易理解,很難理解其好處
  3. 轉換中間有一些陣痛期,所以與其花時間去學習這些不如就繼續使用本來的 Public Key 機制

文章後半開始介紹 SSH Public Key 與 SSH Certificate 的差異 Public Key 的概念非常簡單,就是透過一組 Private/Public Key 並且將 Public Key 給寫入到目標節點帳戶上的 ~/.ssh/authorrized_keys. 節點數量爆炸多的情況下要如何有效率的去管理這些檔案則是一個非常麻煩但是又不能不處理的事情,這也是作者為什麼要推廣 SSH Certificate 的原因之一

SSH Certificate 的方式移除了關於 SSH Public Key 不停重複上傳與設定的情境,相反的則是將自身的 Public Key 給綁到 Certificate 內,同時也包含如過期時間,名稱等其他資料。 目標 Certificate 本身會由一個 CA 簽署,而每台 Server 都需要去修改 /etc/ssh/sshd_config 來指定相關的 CA Key 讓該 SSH 能夠信任。 文章後半部分介紹更多關於 SSH Certificate 的好處以及用法

· 2 min read

標題: 「透過 Kubernetes Event-Driver Autoscaler(KEDA) 來根據各種指標動態擴充容器」 類別: kubernetes 連結: https://medium.com/@casperrubaek/why-keda-is-a-game-changer-for-scaling-in-kubernetes-4ebf34cb4b61

Kubernetes 內已經有 HPA 的物件可以讓 K8s 根據一些基本的指標來動態調整 Pod 的數量,而 KEDA 這款 CNCF 的孵化專案則是完全強化 HPA 的效果 KEDA 的概念很簡單,就是應用程式應該要可以有更多的指標來幫忙動態擴充,除了最基本的 CPU/Memory 等基本指標外, KEDA 來支援了下列各種不同指標,讓 k8s 可以使用更為廣泛的指標,譬如

  1. Redis 內某個 Queue 的長度
  2. K8s 內其他 Pod 的數量
  3. PostgreSQL Query 的結果
  4. Elasticsearch Query 的結果
  5. 各種雲端服務,如 Azure Event Hubs, AWS CloudWatch, GCP Pub/Sub
  6. Kafka ... 等各種不同指標

使用方式很單純,一切的規則都是基於 K8s 的 CRD 來描述與管理,因此團隊可以使用 YAML 的方式來定義這些擴充的規則 文章中有基於 CPU/Memory 的基本介紹使用,同時文章中也有官方的連結來介紹各種不同指標的示範用法