IaC Part 2 — 原則

建置過資料中心的人都有過經歷，這是一個要把所有相關的硬體集中並設置在同一個空間的工作。這一時期的作業其實很像水電工。但是在雲端時代(尤其是公有雲)，我們最後運行在網路上的服務卻跟我們的工作沒有關係了。實體機房依然存在，但是哪已經是CSP的責任。由於實體設備已經跟我們的工作沒有關係，所以我們必須轉變我們傳統資料中心的思維，朝向虛擬資源的建立、複製、變更與刪除的工作思維。

在雲端平台上設計和實施基礎設施有幾個原則。 這些原則闡明了使用三個核心實踐的理由。 本文還列出了團隊使用動態基礎設施時容易犯的幾個陷阱。 這些原則和陷阱是本文中關於實施IaC實踐的更具體建議的基礎。

原則一:要假設系統是不可靠的

在傳統資料中心時代，我們假設我們的系統是跑在可靠的硬體上(因為每台設備都是貴貴的)。但在雲端時代我們必須假設是相反，因為CSP會因經濟規模採用便宜的硬體，再機器一多故障的機率當然變高。

在傳統資料中心時代，我們經常因為很多原因需要對系統做出停機的決定。但是在雲端時代，這通常是不允許的。尤其現今越來越來產業的運作是7x24小時運作。停機，代表企業的營收損失。

因此，我們不能將系統運行的雲端基礎設施視為穩定的。 相反的，我們必須設計在雲端服務底層資源發生變化時不會中斷的服務。

原則二: 讓一切都可重現的

使系統可恢復的一種方法是確保我們可以很容易並可靠地重建系統。 不費力(Effortlessly)意味著無需就如何構建系統做出任何決定。 我們應該將"configuration setting、軟體版本和dependencies"等內容定義為代碼。 重建就是一個簡單的“Yes or No”的決定。 可重複性不僅使恢復系統變得容易，而且還可以幫助我們：

• 讓測試環境跟生產環境是一致的
• 可以在任何雲端機房重現系統
• 當負載變重時可以依需求增加資源
• 還可以給特定的客戶給於特定的系統與資源

當然，系統會生成資料、content和logs， 我們需要識別這些並找到方法將它們作為複製策略的一部分。 執行此操作可能就像將資料複製或串流資料到備份地點。

不費力的構建和重建基礎設施任何部分的能力是強大的。 它消除了做出變更的風險和恐懼，我們可以很有自信地處理故障，可以快速配置新的服務和環境。

原則三:建立可拋棄的系統(是牛群而非寵物)

構建一個能夠應對動態基礎設施的系統是一個等級。 下一個等級是構建一個本身是動態的系統。 我們可以更親易的加入、刪除、啟動、停止、更改和移動系統的各個部分。 這樣做可以建立操作的"靈活性、可用性和可擴展性"。 它還簡化了變更並降低了風險。

讓系統的各個部分具有可塑性是雲原生軟體的主要思維。 雲端從物理硬件中抽象基礎設施資源（運算、網路和存儲）。 雲原生軟體將應用程式功能與其運行的基礎設施完全解耦(decouples)。

如果我們的系統是動態的，那麼用來管理它們的工具就需要應對這一狀況。 例如，每次重建部分系統時，監控不應發出告警。 但是，如果某些重要部分進入自我重建的loop，它就應該發出告警。

原則四: 最小的差異

系統通常會越長越大，它會變得更難理解、更難改變、更難修復。 所涉及的作業隨著系統各部件類型與數量的成長而成長。 因此，保持系統可管理性的一個有效方法是減少部件類型，以保持較低的差異。 管理一百台完全相同的伺服器比管理五台完全不同的伺服器更容易。

重現性原則補充了這一想法。 如果我們定義一個簡單的部件並創建它的許多相同的instance，那麼我們可以容易地理解、更改和修復它。

要實現此目標，我們必須將所做的任何變更應用到部件的所有insatnce。否則，會產生configuration drift。以下是我們的系統中可能存在的一些類型的差異：

• 多種OS、application runtimes、DB和其他技術。 其中每一項都需要團隊中的人員來保有相關的技能和知識。
• 軟體的多個版本，例如OS或DB。 即使我們只有一種OS，每個OS版本也可能需要不同的配置和工具。
• 一個Package的不同版本。 當某些server具有比其他server更新版本的package、utility或library時，我們就會面臨風險。 操作指令可能無法在它們之間一致的運作，或者舊版本可能存在漏洞或錯誤。

組織在允許每個團隊選擇適合其需求的技術和解決方案與將組織中的差異保持在可管理的水準之間會存在著衝突。

原則五: 確保我們可以重複任何流程

基於可重複性原則，我們應該能夠重複對雲端基礎設施所做的任何操作。 使用scripts和configuration management tool重複操作比手動執行更容易。 但自動化可能需要大量前置作業，尤其是在我們與團隊都不習慣的情況下。

例如，企業需要一群相同的Web server，我們要對這些web server的硬碟進行partition。 編寫和測試scripts比login進統並執行 fdisk 命令要復雜得多。 所以大家都會直接敲命令列。

而當團隊中的其他人需要對另一個硬碟做partition時，問題就出現了。 另一個人得出了與我們相同的結論，並且手動完成工作而不是編寫scripts。 然而，她對於如何對硬碟進行partition做出了稍稍不同的決定。 我們在我們的server上建立了 100 GB /var ext3 partition，但 另一個人在他的server上建立了 /var 120 GB xfs partition。 我們正在造成configuration drift，這將削弱我們自信地實現自動化的能力。

高效的infra team擁有強大的scritps文化。 如果我們可以為日常作業編寫scripts，那就編寫它。 如果很難編寫scritps，請深入挖掘。 也許有一種技術或工具可以提供幫助，或者我們可以簡化作業或以不同的方式處理它。 將作業分解為可編寫scripts的任務通常會使工作變得更簡單、更清晰、更可靠。

陷阱:雪花式系統

雪花系統是自然現象。 當我們第一次使用新工具構建系統時，我們會有lesson learn，其中包括犯錯。 但是，如果團隊的其他人依賴我們所構建的系統，我們就可能沒有時間運用我們所學到的知識來回去重建或改進系統。 如果我們沒有可以輕易、安全地進行變更的機制和實踐，那麼改進我們所構建的系統就特別困難。

造成雪花系統的另一個原因是當我們對系統的一個instance進行了他們沒有對其instance進行的變更時。 他們可能面臨解決只出現在系統中一小部分問題的壓力，或者他們可能在測試環境中開始重大升級，但沒有時間將這個變更複製到其他環境的系統。

當我們不確定可以安全地變更或升級系統時，我們就知道系統就像雪花一樣。 更糟糕的是，如果系統確實掛了，就很難修復它。 因此，人們避免對系統進行變更，使其過時、不補丁，甚至可能部分毀損。

雪花系統會帶來風險並浪費管理團隊的時間。 用可重複的系統來取代它們幾乎總是值得的。 如果一個雪花系統不值得改進，那麼它存在就是沒有價值的。

消除雪花系統的最佳方法是編寫可以複製系統的代碼，並運作到新系統是ready。 使用自動化測試和pipeline來證明它是正確的和可重複的，並且我們可以輕易的更改它。