Search
[在 Production 環境中測試? 你瘋了嗎?]
在 Production 環境中測試?
這應該是從小被教育不能做的事
如果做了以後, 有問題你負責嗎? 想要被炒嗎?
是的....
這世界都一直這樣想的
包括我也是這樣
但是 DevOps or continuous testing 出現後
這樣的事情越來越多了
Netflix 的 Chaos Engineering
阿里在 production 模擬雙 11 的活動
因為 staging 的環境根本模擬不出來真實的狀況
Test in Production 變成是一個很重要的技能
誰能做到, 代表這家公司工程實踐的水平很高
可是今天被吐嘲了
他說他們公司都是 Test in production
問他怎麼做到的?
他說沒測就上線給用戶測啊
有事就下線啊, 就趕快修啊
這 ......
ref: https://medium.com/flant-com/cert-manager-lets-encrypt-ssl-certs-for-kubernetes-7642e463bbce
這篇文章是個分享文，作者分享如何使用 cert-manager 這個工具透過 lets-encrypts 來獲得一個被認證的 SSL 憑證供 kubernetes 內部應用使用。
根據 CNCF Technology Radar(https://radar.cncf.io/2021-02-secrets-management) 的介紹，目前 Cert-Manager 幾乎是 k8s 內管理憑證最為知名的專案。
本篇文章針對幾個四種不同的使用情境來介紹如何使用 cert-manager，以下針對每個用法給一些摘要。
前期提要：
Kubernetes 會使用 SSL 憑證的大部分情況都是透過 Ingress 這個物件去描述需要使用 Certificate，所以文章的範例都會是基於 Ingress 的使用下手。
譬如說 Ingress 想要使用開啟 TLS 的功能，需要使用一個 secret，而 Cert-Manager 則會基於其設定最後產生出一個符合 Certificate 用法的 Secert 物件給 Ingress 使用。
Self-signed certificate
第一種是最簡單也是最直接的用法，透過 cert-manager 來產生一組自行簽署的簽證
正常情況下產生後的自簽憑證預設是不被信任的，畢竟預設情況下並沒有加入一個 CA，因此簽出來的憑證用瀏覽器打開還是會呈現不可信任
如果環境有事先準備好 CA 的話，是可以將該 CA 加入到 cert-manager 的設定中，這樣就可以簽出一個被信任的憑證了。
Let’s Encrypt certificate with the HTTP/DNS validation
第二個則是最普遍的用法，就是透過 Let's Encrypt 的服務來獲得一個可以被信任的憑證，而 Cert-Manager 目前支持兩種 ACME 的認證方式，分別是 HTTP 以及 DNS，這兩個方式最主要的目的都是要確認
申請者是該申請 domain 的擁有者，所以可以透過不同的方式來驗證。
如果想要使用 DNS 來進行驗證的則必須要確認該域名管理的服務商是否有提供相關的 API 同時該 API 是否 cert-manager 有支援，文章中作者使用 CloudFlare 來當範例展示一下如何使用 DNS 挑戰來驗證相關的 TXT Record.
由於 DNS Record 本身會有 Propagation 延遲傳遞的問題，因此驗證上通常會比使用 HTTP 的方式還來得慢一點。
Cert-Manager 本身也支援兩種方式同時使用。
另外使用 Let's Encrypt 時要特別注意，非常推薦一開始使用 Let's Encrypt Staging 的服務來進行測試，不要一開始就直接使用 Production 的 API，因為 Production 會將短時間內發送大量請求的網域給停權一陣子，要等待一段時間後才可以再次發送。
因此開發測試過程請先使用 Staging 的 API，待一切沒問題後才轉向 Production API。
Using special Ingress annotations
這種方法其實是簡化維運者的工作，Cert-Manager 會有一個額外的 Controller 去監聽所有的 Ingress 物件，如果該 Ingress 物件的 Annotation 有描述跟憑證相關的資訊，該 Controller
就會自動創造 cert-manager 相關的資源，讓管理者減少需要自己部署的物件數量，反而將部分操作轉交給 Controller 去處理。
本文延續前一篇文章，作者探討十五種 Kubernetes 不該使用的部署與維運模式，總共三篇，每篇五種。
Using Kubectl as a debugging tool
作者認為一個良好的 Kubernetes 叢集必定要有一個相對應個可觀測性工具，包含 Metrics/Log/Tracing 等。對於一個維運人說來說，今天要處理事情時，第一件事情如果還是慢慢的用 kubectl 來執行 get, describe ,log 等指令找問題的話就太慢了，這類型的工具都應該只是輔助使用，真正還是要依賴有效的監控系統，不論是常見的系統指標，應用程式狀態甚至是應用程式獨特的指標等，將這些資訊整合到一個方便顯示的儀表板，甚至搭配對應的 Alert 功能來達到主動通知。
Misunderstanding Kubernetes network concepts
Kubernetes 內提供的網路功能很容易被搞混，Service(ClusterIP, NodePort, LoadBalancer) 與 Ingress 的差異到底是什麼，很多初次踏入 Kubernetes 的玩家沒有特別去理解差異，只知道應用程式部署後就可以通了。Service Mesh 這個概念作者也推薦去學習與瞭解，知道這個概念是什麼，以及想要什麼解決問題就好，因為並非不是每個叢集都真的需要一套 Service Mesh 的解決方案，但是理解這個概念未來就有能力知道什麼時候需要導入。
Using permanent staging environments instead of dynamic environments
對於應用程式開發者來說，如何於 Kubernetes 環境上測試新功能一直都是一個困難的問題。大部分的團隊中都會有 QA/Staging/Production/Dev(甚至更多)的環境，假設 Dev 環境可以供開發者測試，這些開發者要如何確保自己的修改沒有問題且通過整合測試。
一個常見的問題是假如多個開發者同事部署自己的程式碼到固定環境中，有可能會造成互相干擾，導致問題發生時沒有辦法正確的判別問題是誰產生的。
作者提到一種作法就是透過預借的概念，確保每個開發者使用叢集時都不會有他人干擾，然而這個問題也會引發其他問題，譬如開發者間要互相協調時間，同時每個人用完環境後都要還原成穩定的狀態，以免干擾下一位的使用。
作者推薦使用動態叢集的方式來進行測試，使用 Github PR 為範例，當 PR 開啟時，動態創建 Kubernetes 叢集供測試，當 PR 合併後就會將該 Cluster 給移除。透過這種範例每個開發者都可以有獨立的環境進行測試彼此不干擾，同時也會隨者程式碼的合併而自動回收環境，也不需要擔心環境污染問題。
Mixing production and non-production clusters
任何團隊一定要有正式生產環境的叢集跟其他叢集分隔開來，千萬不能使用 namespace 的方式於一個叢集中同時維護生產與非生產環境。譬如
1. 任何人操作 Kubernetes 都很容易失誤，譬如指令下錯，指向錯的物件。這類型的操作都有可能導致該叢集上生產環境被誤刪
2. namespace 的隔離性不好，實際上很多物件彼此還是可以互相存與溝通，這部分也有其他的隱憂
詳細原文可以參考下列連結。
https://medium.com/containers-101/kubernetes-deployment-antipatterns-part-2-2af25a710bc0
新增environments/staging.rb. 新增 config/environments/staging.rb 環境設定內容同 config/environments/production.rb ... ... <看更多>
Netflix 的Chaos Engineering. 阿里在production 模擬雙11 的活動. 因為staging 的環境根本模擬不出來真實的狀況. Test in Production 變成是一個很重要的技能. ... <看更多>
staging production環境 在 給開發者的資訊 - GitHub 的推薦與評價
GENERATE_ENV 這個值，生產環境為 'production' ，除此之外為 'development' ... staging, gh-pages, The staging site https://stopcovid19-tokyo-staging.web.app/. ... <看更多>