不可變基礎設施:拒絕 SSH
什麼是不可變基礎設施
在開始本文之前,先介紹下什麼是不可變基礎設施。不可變基礎設施(Immutable Infrastructure)是由Chad Fowler於2013年提出的一個很有前瞻性的構想:在這種模式中,任何基礎設施的例項(包括伺服器、容器等各種軟硬體)一旦建立之後便成為一種只讀狀態,不可對其進行任何更改。如果需要修改或升級某些例項,唯一的方式就是建立一批新的例項以替換。這種思想與不可變物件的概念是完全相同的。(來自InfoQ)
當然在很多年以前這個概念是得不到技術支援的,我們很難在不同的物理機上實現軟體的不可變。不過隨著虛擬化技術以及雲端計算的發展,現在這已經變得可能了。我們更多的時候,面對的不是一臺臺的物理主機,更多的是雲主機例項。安裝一個作業系統也不需要幾小時,而只需要滑鼠點幾下,等上兩三分鐘即可。重灌系統這個概念已經不存在,刪掉一個主機例項我們也不會心疼(來自個人部落格)。
實現這種模式的好處是顯而易見的,這意味著配置工作可實現重複性,減少了配置管理工作的負擔,讓持續整合與持續部署過程變得更流暢。同時它也更易於應對部署環境間的差異及版本管理,包括在部署出錯時可進行快速回滾 —— 只要舊版本的映象檔案還有備份,就可以快速地生成舊版本的例項進行替換。否則的話,就只能老老實實地重新構建舊版本的例項,並且祈禱能夠趕在老闆掀桌之前完成回滾。
不可變基礎設施令人興奮的事情之一是:它讓我們有機會重新審視一些舊的方式,並改進它們。其中之一是“漂移”——不同機器間的差異。造成這一問題主因有兩個:延遲配置與更新。二者都會隨著時間加劇。不同機器被設定的時間越久、存在的越久,就越有可能碰到漂移的問題。讓我們依次來看看這些問題。
為什麼漂移是個問題?
首先要回答的是:為什麼漂移自身是個問題?或者換個說法:為什麼擁有一模一樣的機器很重要?
在軟體系統中,減少風險的主要方式之一是測試。手工和自動測試都依賴於相同的三個步驟:
- 將系統置於一個已知狀態
- 執行一個動作
- 將結果與預期做比較
將系統置於一個已知狀態不僅適用於資料,也適用於所有安裝的軟體元件版本。一旦系統被正確設定,測試將驗證X版本程式碼執行於Y版本平臺且具有Z版本庫的正確性。所有其他組合都是未知的,必須單獨驗證。也就是說,無法保證同一版本程式碼與舊版或新版平臺和庫組合時能同樣工作,因為舊版本可能存在BUG,而新版本可能有迴歸或細微的變化。
為了讓測試中的投入有所價值,必須保證系統及所有元件版本處於已知狀態,以便能簡單且安全地在機器和環境間複製。
簡單而言,要保證東西能工作,必須在生產環境中執行在測試環境中所測試的東西。
這同樣適用於單一環境。如果在負載均衡器後有多臺機器為客戶端提供服務,要保持工作正常,這些機器必須完全一致。
延遲配置的問題
你可能會覺得這很容易通過使用一些可靠的配置機制來解決。不管你喜歡什麼指令碼或配置管理工具,這並沒有看起來那麼容易。問題在於包管理器的常見使用模式及中央倉庫的更新時機。當你使用類似這樣的命令時,問題就出現了:
> sudo apt-get install mypkg
為了更好的展示為什麼這是個問題,請看這個簡單的例子:三臺機器在不同時間使用同一配置指令碼進行設定:
正如你所見,雖然所有機器都安裝了A和B包,配置時間的不同造成了同一指令碼將同一個包的不同版本拉取到不同機器上。系統的穩定性與中心倉庫裡每個包的更新計劃密切相關!
映象是解決之道
解決這個問題的辦法之一是將所有包及其依賴項固定到一個特定版本上。雖然這讓你得以重新控制系統的更新計劃,也帶來了高昂的維護成本。
一個更簡單、更可靠的辦法是聽從真言:只做一次構建。
要消除環境間的差異(即造成失敗的潛在因素),構建的產物應在儘可能低的層次上捕獲應用及其依賴項。在虛擬基礎設施中,儘可能低的層次可以簡單的是整個機器的映象。然後,你就能建立出你所需要的完全一致的例項:
映象使得建立相同主機變得簡單,但並沒有解決所有問題。一旦有機會登入,你就失去了這些主機不隨時間發散的保證:
這些主機存在的越久,東西被修改的可能性就越高,也就越難被完全的重建。這在很大程度上消減了其帶來的益處。
強制不可變性
那麼,如何彌補這點?那就是禁止登入。這不僅解決了漂移問題,還能減少受攻擊面從而提高安全性。在此之上,它還強制你遵循一個乾淨的以映象為基礎的工作流,杜絕後門。歡迎加入拒絕SSH的運動來推廣所有這些優勢:
現在,你的基礎設施已經不可變了。所有的修改都要求通過常規的自動化構建與部署管道來重新構建新的映象。作為回報,系統的簡單性和可靠性將大幅提升。非常值得一試。
結論
漂移通過侵蝕測試中得到的保證,降低了系統的可靠性。而這點在依賴傳統配置工具時非常容易發生。
遷移到能在儘可能低層次捕獲應用及其依賴的構建與部署管道上,你將重獲這種信心。在處理虛擬硬體時,達成這點最好的方式是產出整個系統的映象。要保證這個過程的可靠性,你需要消除SSH和登入能力。映象和基礎設施不再可變。所有的修改都會觸發新映象的產生,且針對所有環境只構建一次。
相關文章
- MacBook上使用ssh localhost被拒絕Maclocalhost
- Terraform入門 - 3. 變更基礎設施ORM
- 基於Kubernetes和OpenKruise的可變基礎設施實踐UI
- 即時基礎設施:以業務速度發展的基礎設施
- Ubuntu ssh伺服器拒絕密碼(使用root登入)Ubuntu伺服器密碼
- 回首23展望24:智慧化正加速IT基礎設施變革
- Linux基礎命令---accept/reject 允許拒絕傳送列印請求Linux
- 拒絕完美
- Python基礎(一)可變與不可變資料型別Python資料型別
- 解讀雲原生基礎設施
- Terraform: 基礎設施即程式碼ORM
- EasyAndroid基礎整合元件庫之:EasyActivityResult 拒絕臃腫的onActivityResult程式碼Android元件
- [Java基礎]String 為什麼是不可變的?Java
- IDC釋出:4Q18雲IT基礎設施收入低於傳統IT基礎設施收入
- canvas動畫教程-2 基礎設施Canvas動畫
- Coinbase如何改造基礎設施中Kafka?Kafka
- Python中可變物件和不可變物件的區別?Python基礎Python物件
- 網際網路後端基礎設施後端
- Flutter系列:3.APP基礎設施搭建FlutterAPP
- Pyinfra:使用Python自動化基礎設施Python
- RPKI-資源公鑰基礎設施
- Terraform入門 – 4. destroy 基礎設施ORM
- 什麼是基礎設施專案管理?專案管理
- 全球 IT 基礎設施市場:雲、企業
- 德勤:全球基礎設施的未來
- Uber如何安全保護Kafka基礎設施?Kafka
- Linux基礎:ssh與scpLinux
- 基於雲基礎設施快速部署 RocketMQ 5.0 叢集MQ
- java基礎鞏固-淺析String原始碼及其不可變性Java原始碼
- 拒絕遊戲創業遊戲創業
- 拒絕使用 rm -rf 命令 ?
- 域伺服器基礎設施設定與安全加固伺服器
- 邊緣計算正在改變IT專業人員對基礎設施的思考方式
- 2.0 解析系列 | OceanBase的重要基礎設施——DBReplay
- 《基礎設施即程式碼》讀書筆記筆記
- ChatGPT 背後基礎設施的算力概念ChatGPT
- 現代IT基礎設施管理(2):Terraform進階ORM
- 360 秒瞭解 SmartX 超融合基礎設施
- 做個清醒的程式設計師之拒絕工作程式設計師