本文翻譯自老馬(MARTIN FOWLER)的博客，該譯文現已被博客原文收錄在其下方中文翻譯處。

“基礎設施即代碼”是一種通過代碼來定義計算和網絡基礎設施的方法，它可以應用于任何軟件系統中。這樣的代碼放在代碼版本控制系統中，具有可審查性、可重用性，并且符合測試慣例，還完全遵從持續交付的原則。該方法已經在過去的十年內廣泛應用于快速增長的云計算平臺中了，而且也將會成為接下來管理計算機基礎設施的主要方式。

??我（Martin）出生在Iron Age時期（喻指軟件開發起步早期），那時發布一款新的服務器應用程序，意味著需要找一些實際可以運行它的硬件，并且配置硬件使其支持應用需求，以及把應用程序部署到硬件上。而得到這些硬件的成本往往很高，而且獲取它們的周期也很長，通常需要幾個月的時間。但是現在我們生活在云的時代，只要有網絡連接和一張信用卡，幾秒鐘就可以啟動一臺新的服務器。這些動態的基礎設施實際上是通過一些程序命令來創建服務器（通常是虛擬機，當然也可以是裸機），并可以對它們進行分區、銷毀，完成這些你甚至都不需要動用一個螺絲刀。

實踐慣例

基礎設施即代碼基于以下一些實踐慣例：

• 使用解釋型文件：?所有的配置信息都被定義于可執行的配置解釋文件中，比如說shell腳本，ansible的playbooks，Chef的recipes，或者Puppet的manifests。人們無需登入服務器，就可以做出實時的動態調整。開發時，這些代碼可以作為持續的定義，來減少任何生成雪花服務器（SnowflakeServer）的風險。這也意味著更新代碼的頻率要快。幸運的是，計算機可以快速執行程序，并可以準備數百個服務器，速度比任何人類都快。
• 自歸檔的系統和過程：?相比于人們使用文檔中的指示來執行操作（人工級別的可靠性），代碼更加清晰準確并且可以不斷的被執行。而且如果有必要的話，根據這些代碼也可以生成一些更具有可讀性的文檔。
• 給所有代碼做版本控制：?要讓所有的代碼都處于版本控制之中。這樣每次配置以及每個修改都會有記錄可以查詢的到，而且還可以利用可重用的構建（ReproducibleBuild）來診斷問題。
• 持續地測試系統和過程：?測試可以幫助計算機快速地找到基礎設施配置中的諸多錯誤。在現代軟件系統中，你可以搭建用于基礎設施代碼的“部署流水線”，這能夠讓你實踐針對基礎設施變化的持續交付流程。
• 小步改變，避免批處理：?基礎設施改變的動作越大，就越可能包含錯誤，也更難去診斷錯誤，特別是如果有多個錯誤交織在一起。小步更新就會讓發現和改正錯誤更加容易。所以頻繁地修改基礎設施（小步）可以減少這種事情的發生。
• 保證服務持續可用：?持續增長的系統負擔不起更新或者修復時的宕機。一些技術，比如說藍綠部署和ParallelChange，可以不失可用性地進行小步的更新。

益處：

所有這些都讓我們可以利用動態的基礎設施來簡單地搭建新的服務器，以及安全地處理那些被新的配置代替或者配置重新加載的服務器。只需要執行一個腳本完，就可以成所需的所有服務器的搭建。這種方法非常適合鳳凰服務器(PhoenixServers)和不可變服務器(ImmutableServers）。
用代碼來定義服務器配置意味著服務器之間具有更高的一致性。人為的操作會根據不準確的指導（先不管其中有沒有錯誤）產生不同的理解，導致產生具有細微不同配置的雪花（snowflakes，同前文snowflakeServer），也會經常出現一些稀奇古怪、難以調試的錯誤。不一致的監控往往會讓出錯的情況更加糟糕，而使用代碼也保證了監控的一致性。
最重要的是，使用配置性代碼可以使改變更加安全，能夠用很小的風險來升級應用程序和系統軟件。錯誤可以很快地被發現和修復，至少修改能夠退回到上一次有用的配置狀態上。
將基礎設施代碼版本控制，有助于提升代碼的可塑性和可審查性。配置中的每一次更改都會被記錄，不容易受到錯誤的紀錄所影響。
如果你正計劃使用微服務架構，那這些就很重要了，因為你需要處理更多的服務器，實現“基礎設施即代碼”就顯得尤其必要?！盎A設施即代碼”技術針對大型集群服務器十分地有成效，包括配置服務器以及制定它們之間交互的方式。

總結

以上是生活随笔為你收集整理的Infrastructure AS Code基础设施即代码简述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。