標準化和自動化在IT行業中并不是什么新概念。那么，為什么基礎設施自動化如今成為一個熱門話題?
其答案是：容器、編排和其他現代化技術已使基礎設施自動化功能得到了擴展，除了提供其他好處之外，這些功能還使標準化得以實施。
RedHat公司的首席技術官GordonHaff解釋說，“有人可能說在使用容器之前，基礎設施及其自動化的標準化是一項臨時的措施。當然組織擁有的標準操作環境(SOE)和配置管理工具，可以自動配置這些標準操作環境(SOE)及其持續監控。但是，完成特定任務仍然需要很多服務器，即使配置管理軟件試圖使它們保持合規性，部署的容器映象仍會隨時間推移而轉移。”
他指出，在長期追求有效的基礎設施自動化的過程中，容器化和編排為這一旅程注入了新的活力。
現代基礎設施自動化的三個基礎知識
以下介紹了現代基礎設施自動化的三個基礎知識，這些基礎知識主要針對仍在快速掌握使用云原生技術實現基礎設施自動化新方法背后的概念(適用于混合云或多云場景)的IT領導者和團隊，并提供了一些入門建議。
(1)關鍵概念：容器和編排
盡管云原生生態系統已經非常龐大(并且仍在增長)，但是在這種情況下談論基礎設施自動化時，有兩個主要方面值得關注：容器和Kubernetes。有多個容器運行時和多個編排選項，但對于后者，將使用Kubernetes作為默認選擇，因為它已成為容器編排的明確領導者，而容器編排是現代基礎設施自動化的重要組成部分。
不變的基礎設施
這些以云計算為中心的技術為Haff先前提到的不變的基礎設施鋪平了道路。這意味著一旦部署了基礎設施，就不會在生產中對其進行更改，而是根據需要將其替換為新版本。并且可以使用Kubernetes之類的工具自動啟動(或關閉)這一功能，這樣管理員就可以為自己的應用程序和基礎結構聲明所需的狀態，然后編排平臺以高度自動化的方式管理這些狀態。
微服務架構
這里的另一個關鍵概念是微服務架構，它本質上意味著將應用程序分解為更小的離散組件，這些組件可以作為較大系統的一部分協同工作。除了獲得其他好處之外，微服務使團隊可以獨立管理那些較小的服務，而不必在每次更改時都必須重新進入(并重新部署)整個應用程序。微服務與容器非常匹配，因為每個服務都可以獨立地實現容器化。應該注意的是，并不是每個應用程序都非常適合微服務架構，但這無關緊要。
有些人提出一些建議：如果組織是從單一的應用程序組合開始的，則不要將基礎設施自動化視為短期項目。與其相反，可以將其視為逐個過程，尤其是當組織要將現有應用程序分解為微服務時。
OpsRamp公司產品經理MichaelFisher說，“通向不變的基礎設施的道路可能會花費一些時間，特別是對于那些擁有比基于容器的應用程序的擴散和普及更早的應用程序的組織來說。但是，這并不意味著架構規劃和開發處于停滯狀態，直到將應用程序配置為可以在獨立的微前端和后端上運行。組織的團隊應該迭代地對服務進行優先級劃分和容器化，直到整個應用程序完成轉換為止。”
基礎設施自動化的現代方法取決于向云平臺和工具的相應轉變。但是并不是一蹴而就的事情。
Fisher表示，他將這個階段視為一個創新過程，而不僅僅將其視為技術過程：人們要理解容器化的內容，就需了解應用程序的核心服務和構建塊。
對于容器化的正確路徑有許多觀點，特別是當組織將一個應用程序(或多個應用程序)重構為微服務時。
Fisher說：“實現這一點的最好方法之一是了解終端用戶在用戶界面(UI)/用戶體驗(UX)中最常訪問的位置，然后向下移動。這種方法通常被稱為‘微前端’，一旦了解了什么需要實現容器化，就有大量的工具可以幫助組織橫向擴展運行服務的基礎設施，而Kubernetes是最流行的工具。”
(2)關鍵概念：持續集成(CI)/持續交付(CD)、構建管道和構建工件
即使組織已經開始將合適的工作負載實現容器化并學習Kubernetes或使用商業Kubernetes平臺，仍然有很多工作要做。
對于不變的基礎設施，需要停止使用服務器等傳統術語，即使它們在技術上仍然相關。與其相反，組織需要開始考慮構建管道以及另一方面的問題：構建工件。這是組織自動部署、停用和/或用不變的基礎設施替換的內容。
持續集成(CI)/持續交付(CD)已經成為這方面的關鍵實踐和工具。構建階段實質上是強大的持續集成(CI)/持續交付(CD)管道的基礎。
一般來說，管道概念是考慮基礎設施自動化的一種有用方法：一旦部署到位，組織代碼以及正確運行所需的一切都應貫穿管道的每個階段(從構建到測試再到安全再到部署)，只有在組織指定的步驟中，或者當某些內容不符合標準時，才會有人積極參與。
從本質上來說，持續集成(CI)/持續交付(CD)管道是容器化應用程序如何從代碼到存儲庫或生產的過程，而無需花費太多人力。
SnowSoftware公司首席設施師JesseStockall解釋了管理容器化應用程序和不可變基礎設施的一些重要方法。這些方法都說明了容器和編排如何防止即使在標準操作環境(SOE)中仍然可能存在的轉移。
Stockall說：“容器映像應該使用可重復的、自動化的構建管道從可信的基本容器構建，該管道使用私有映像存儲庫作為構建輸出。為了獲得更多控制，基本映像也可以復制到私有注冊表，并阻止對公共注冊表的訪問。構建系統還應該檢測何時有較新版本的基礎映像可用，以便可以審查更改并更新映像配置。”
持續集成(CI)/持續交付(CD)管道的其他關鍵要素包括測試和驗證/合規性。如果做得好，安全性對于每個階段都是不可或缺的。
Stockall說：“組織的容器注冊表應該對已知的易受攻擊的軟件執行掃描，并阻止不良圖像被上傳。應該使用對映像配置和部署清單的靜態分析來檢測常見的錯誤配置和遺漏，例如基本映像的版本丟失或部署的資源限制。”
(3)關鍵概念：云原生工具
雖然有些原則保持不變，但單一的工具和流程不一定能讓組織在基礎設施自動化方面達到其想要的目的。
這有點像安全性：如果組織使用與十年前運行的相同的外圍防火墻和終結點防病毒軟件，并且根本沒有更新，那么只能順其自然。
基礎設施也是如此。如今越來越多的組織使用混合云，既可以解決云原生開發問題，又可以解決許多更適合私有云和內部部署基礎設施的工作負載。并且有大量成熟的工具可以幫助組織管理這一切。
Haff說：“這一巨變導致了對基礎設施自動化的重新思考。Kubernetes已經成為容器編排的標準。這反過來又產生了專門為容器化世界設計的各種自動化工具。”
“生態系統”這個術語在科技界往往使用得很寬松。但是，在云計算時代，從構建到安全再到部署，一個項目或平臺依賴于另一個項目或平臺，特別是當它們是開源的時候。這給基礎設施自動化帶來了“滾雪球”效應。
Haff說：“持續集成(CI)/持續交付(CD)領域的項目正在考慮使用Kubernetes原生開發模式和流程來構建和部署管道。這其中包括Tekton管道以及專門針對部署自動化的較新項目，例如ArgoCD和Keptn。組織還會采用許多新的安全工具(例如Aqua和Snyk)，它們針對這種相對較新的基礎設施進行了優化。”
