如果你正在學習或剛開始接觸DevOps和基礎設施自動化，這篇文章將幫助你詳細了解不可變基礎設施（Immutable infrastructure）模型。

在進入技術解釋之前，首先，你應該對可變和不可變這兩個詞的字面意思有一個清晰的認識。

• 可變的（Mutable）： 可以被改變的東西。意味著你可以在它被創建后繼續對它進行修改。
• 不變的（Immutable）： 不能改變的東西。一旦它被創建，你就不能改變其中的任何東西。

現在讓我們看一個真實世界的例子，即一所房子。在一所房子里，有一些你可以改變的對象（可變的），也有一些必須被替換的對象（不可變的），如果它們發生了什么變化。例如，你可以給一扇門涂上不同的顏色，更換門把手，給它一個不同的外觀。在這里門是一個可變的對象。同時，一個洗臉盆是一個不可變的對象。如果你想改變臉盆的顏色，你需要用一個新的臉盆來替換它。這一點也適用于地磚。

在IT界，我們在軟件工程和DevOps中都有可變性和不可變性的概念。在軟件工程中，這一概念被應用于面向對象的編程，而在DevOps中，它被應用于基礎設施自動化。在本指南中，我們將從DevOps的角度重點討論不可變的基礎設施。

什么是不可變的基礎設施？

要理解不可變的基礎設施，首先，你應該知道服務器的生命周期。

下面是一個帶有應用程序的服務器的簡略的生命周期（僅供參考，各組織的流程有所不同）。

1. 部署一個服務器。
2. SSH進入服務器。
3. 安裝所需的工具。
4. 配置安全代理、防火墻和實用程序以保證安全。(安全加固)
5. 安裝和配置所需的應用程序。
6. 修改應用程序和服務器配置，以提高應用程序的性能。
7. 使服務器用于生產工作。
8. 每個月登錄服務器，為服務器打上安全補丁（服務器更新）。
9. 在應用程序可用時進行升級。

正如你所看到的，上面提到的步驟是一個可變的模型。這是因為我們正在根據要求對服務器進行修改。因此，當你使用Ansible、Puppet或Chef等配置管理工具來管理服務器時，你遵循的是可變模式。

「不可變」，就像它的字面意思一樣，不可變的基礎設施是一個概念，在你部署服務器之后，你不會對它做任何改變。意思是說，服務器在部署的時候已經預先配置好了配置、安裝好了工具和應用程序。服務器出現的那一刻，應用程序就開始運行。

如果您想進行任何更改，則應銷毀現有服務并用新服務替換。更改可能是打補丁、應用程序升級、服務器配置更改等。

圖片

你可以為大多數現代應用遵循不可變的基礎設施模型，包括數據庫集群。

例如，如果你有應用程序在自動縮放組中運行，而你遵循的是不可變的服務器部署模型。每當你想部署新的代碼時，你需要銷毀現有的虛擬機，這樣由自動縮放啟動的新虛擬機就會下載最新的代碼。另一種方法是，你需要用帶有代碼的最新鏡像來改變啟動模板。

在一個不可變的模型中，在配置方面應遵循標準的最佳實踐。

例如，使用配置存儲或服務發現工具，將經常改變的配置外部化。一個典型的例子是Nginx的upstream配置。

這樣一來，你就不必為小的變化和配置而重新生成服務器。

如果你知道容器，它是不可變基礎設施的最好例子。除了外部化的配置，對容器的任何改變都會導致重建。

用于CI/CD的不可變的基礎設施模型

那么，不可變的基礎設施模式如何用在CI/CD過程？

當你在虛擬機環境的CI管道中遵循不可變的基礎設施模式時，可部署的工件將是一個虛擬機鏡像或一個docker鏡像。

例如，一旦CI完成，利用Docker或packer等工具，你可以把程序代碼塞到容器或虛擬機鏡像（AWS AMI）中，并使用它在相關環境中進行部署。

當涉及到部署時，你可以遵循藍綠部署或金絲雀部署。讓我們來看看這兩種方法。

• 藍綠模式： 在這種模式下，使用最新的應用程序鏡像，你將一組新的服務器（藍色）與生產服務器（綠色）一起部署，但它不會提供流量。當藍色服務器被驗證OK之后，流量將被重定向到新的（藍色）服務器組，舊的（綠色）服務器將被銷毀。
• 金絲雀模型： 在這個模型中，不是將全部流量導到新的服務器集上，而是只將流量的一個子集導到新的服務器上。流量切換是根據團隊制定的時間節奏逐漸發生的。一旦流量完全切換到新的服務器集，舊的服務器就會被刪除。

鏡像生命周期管理和補丁

在不可改變的基礎設施模型中，虛擬機或容器鏡像的創建和修補起到了關鍵作用。你需要利用CI/CD工具，制定良好的鏡像生命周期管理。

在云和容器環境中，首先我們需要一個基礎鏡像。之后基于這個基礎鏡像創建應用鏡像。在實際的項目環境中，這個過程會比較復雜。

下面我們來聊一下這一切在實際項目環境中是如何發生的，以及如何根據公司的安全策略建立應用程序鏡像。

因此，這里列出了在安全的項目環境中遵循的通用鏡像生命周期管理（虛擬機和容器）步驟。

注意：該列表是為了給你一個關于鏡像生命周期管理的總體情況。它在每個組織中都是不同的。

圖片

1. 在一個安全、合規的環境中，你不允許使用云提供商提供的基礎鏡像或docker hub等公共容器注冊處提供的docker基礎鏡像。
2. 每個組織都會用標準的安全工具（各種agent）、DNS/Proxy、LDAP配置等創建虛擬機/容器基礎鏡像（它根據每個組織的安全政策而改變）。通常，這種鏡像是由中央平臺團隊或安全團隊創建和維護的。你可以叫它黃金鏡像。
3. 經過批準和認證的基本鏡像將與組織中的所有團隊共享。它可以是一個單一的云賬戶或與組織內的多個子賬戶共享。
4. 然后，每個團隊可以在批準的基礎鏡像上創建自己的應用鏡像。（這里使用像Docker和Packer這樣的工具）。
5. 團隊創建的新鏡像將被測試并部署到生產中。
6. 現在，當基礎鏡像得到新的更新或補丁時，平臺或企業安全團隊會發布新版本的基礎鏡像并通知所有項目團隊。
7. 每個組織都有一個打補丁的生命周期。意思是說，安全團隊對VMS的更新和補丁的應用有一定的準則。例如，它可能是一個月或三個月一次。
8. 對于虛擬機，補丁可以是 “就地” 的，也就是對現有實例進行補丁，也可以是不可更改的，也就是用新的鏡像替換現有的鏡像。容器在本質上是不可變的。
9. 基于補丁的生命周期，每個團隊都會用新的基礎鏡像更新現有的應用鏡像，并將其部署到生產中，而不管應用的代碼是否有變化。這同時適用于虛擬機和容器。

結論

我們已經看了不可變的基礎設施的關鍵概念。

作為一名DevOps工程師，你應該在構建和部署不可變鏡像時遵循所有標準的最佳實踐，以減少攻擊面。

如果你正在使用容器或容器編排工具（如Kubernetes），你已經在遵循應用程序部署的不可變模式。

原文：https://devopscube.com/immutable-infrastructure/ 

譯者：秦曉輝