基礎設施即程式碼：你需要知道的一切

基礎設施是軟體開發過程的核心原則之一——它直接負責軟體應用程式的穩定執行。這種基礎設施的範圍從伺服器、負載平衡器、防火牆和資料庫一直到複雜的容器叢集。

對基礎設施的考慮不僅要適用於生產環境，因為它們遍及整個開發過程，還包括工具和平臺，如CI/CD平臺、登臺環境和測試工具。隨著軟體產品複雜度的增加，對這些基礎設施的考慮也要隨之變化。為了滿足DevOps現代快速軟體開發週期的需求，手工管理基礎設施的傳統方法很快就變成了一個無法擴充套件的解決方案。這就是IaC已成為如今開發中事實上的解決方案的原因。

什麼是基礎設施即程式碼？

IaC，Infrastructure as Code，基礎設施即程式碼，是通過程式碼而非手動定義的基礎設施的供應和管理過程。IaC從開發人員那裡拿走了大部分資源調配工作，開發人員可以執行指令碼以準備好基礎設施。這樣一來，應用程式部署就不會因為等待基礎設施而受阻，系統管理員也無需管理耗時的手動流程。

以下是建立IaC環境工作原理的步驟說明：

• 開發人員用特定於域的語言（DSL）定義配置引數。
• 指令檔案被髮送到主伺服器、管理API或程式碼儲存庫。
• IaC平臺按照開發人員的指示建立和配置基礎設施。

通過將基礎設施作為程式碼，使用者不必在每次開發、測試或部署軟體時都配置環境。所有基礎設施引數都以稱為清單的檔案的形式儲存。

與所有程式碼檔案一樣，清單易於重用、編輯、複製和共享，它使構建、測試、準備和部署基礎設施更快、更一致。

開發人員對配置檔案進行編碼，並將其儲存在版本控制中。如果有人編輯了一個檔案，拉取請求和程式碼審查工作流可以檢查更改的正確性。

IaC最佳實踐

基礎設施自動化的實施將需要大量的更改和重構，這對組織來說可能是相當繁重的過程。如果想避免大多數的限制，並使過渡儘可能平滑，請遵循下面的最佳實踐！

為IaC的版本庫使用CI/CD和質量控制

這將幫助您保持程式碼的良好質量，並從您的DevOps團隊或開發人員那裡獲得快速反饋迴圈（在應用更改之後）。幸運的是，有一些測試框架，比如Terratest for Terraform，允許我們編寫實際的測試。越早嘗試用它覆蓋所有內容，就越能從中受益，基礎設施發生的意外問題也就越少。可以肯定的是，在這裡雖無法預測應用程式錯誤，但至少可以對自己的基礎架構更有信心。

讓你的基礎設施成為模組化的程式碼

微服務體系結構是軟體開發中的一種流行趨勢，它通過開發更小、模組化的程式碼單元來構建軟體，這些程式碼單元可以獨立於產品的其他元件進行部署。

同樣的概念也適用於IaC。可以將基礎設施分解為單獨的模組或堆疊，並以自動化的方式將它們組合起來。

這種方法有如下優勢：

• 首先，可以靈活控制基礎結構程式碼各部分的訪問許可權。例如，初級工程師可能不熟悉或不具備基礎設施配置某些部分的專業知識，通過模組化基礎架構程式碼，就可以在初級工程師跟上進度之前，拒絕他們訪問這些元件。
• 此外，模組化基礎設施自然地限制了可以對配置進行的更改數量。較小的更改使bug更容易檢測，並使您的團隊更加靈活。

如果使用IaC來支援微服務體系結構，那麼應該使用配置模板來確保基礎設施擴充套件為大型伺服器叢集時的一致性。這最終將對配置伺服器和指定它們應該如何互動非常有價值。

持續測試、整合和部署

持續的測試、整合和部署過程是管理可能對基礎架構程式碼進行的所有更改的好方法。
測試應該嚴格應用於您的基礎架構配置，以確保沒有部署後問題。根據您的需要，應該執行一系列測試。可以設定自動測試，以便在每次更改配置程式碼時執行。

基礎設施的安全性也應該被持續監控和測試。DevSecOps是一種新興的實踐，安全專業人員與開發人員一起工作，在整個軟體開發生命週期中不斷地整合威脅檢測和安全測試，而不是僅僅在最後投入。通過增加測試、安全和開發團隊之間的協作，可以在開發生命週期的早期識別Bug和威脅，從而在上線時將其最小化。

通過良好的持續整合過程，這些配置模板可以在不同的環境（如開發、測試和質量保證）中多次使用。然後，開發人員就可以在這些環境中使用一致的基礎設施配置。這種持續整合將降低在將基礎架構部署到生產環境中時出現可能對應用程式有害的錯誤的風險。

維護版本控制

這些配置檔案將受版本控制。因為所有配置細節都是用程式碼編寫的，所以對程式碼庫的任何更改都可以進行管理、跟蹤和協調。

與應用程式程式碼一樣，應該使用Git、Mercurial、Subversion等原始碼控制工具來維護IaC程式碼庫的版本。這不僅可以為程式碼更改提供審計跟蹤，還可以在IaC程式碼上線之前進行協作、同行評審和測試。

程式碼分支和合並最佳實踐也應該用於進一步增加開發人員的協作，並確保對IaC程式碼的更新得到正確管理。

如果剛剛開始使用IaC，不要試圖在一開始就將一切自動化。原因是變化的速度很快。一旦您的平臺變得或多或少穩定，您將能夠自動化其資源調配和維護。

IaC的挑戰

IaC的好處很多，但這種模式確實存在一些需要解決的挑戰，可以在實施過程之前瞭解並妥善解決。

配置漂移

無論您配置伺服器的一致性或頻率如何，從長遠來看，都可能出現配置漂移。這就是在建立IaC工作流程後，需確保沒有外部干擾的原因。每次需要修改基礎設施時，必須確保按照預先建立的維護工作流程進。這一原則被稱為基礎設施不變性——即基礎設施應完全按照指定的方式執行，如果需要更改，則會提供一套全新的基礎設施，並完全替換過時的基礎設施。

如果您最終仍然對類似的系統組進行了不一致的更改，其中一些更改將不可避免地與其他更改不同，這可能會導致配置的變化。

錯誤的潛在重複

儘管IaC的實施過程和機器建立在很大程度上依賴於自動化，但整個過程中仍有某些部分需要手動完成。編寫父程式碼是其中一個過程，而且當涉及人工工作時，總是有可能出錯。即使在QA檢查定期且一致的環境中，人們也可能犯錯誤或忽略關鍵的事情。

作為自動化的副作用，這些錯誤可能會在多臺機器上發生，並且可能會造成儘可能多的安全漏洞。請記住，幾乎所有云漏洞都來自錯誤配置。為了確保自始至終的安全，建議仔細檢查生成IaC體系結構的程式碼，這可以通過嚴格且極為一致的測試和徹底的稽核過程來實現。當然，這些額外的工序往往也會增加相應的費用支出。

對於尋求自動化和更快交付的組織來說，作為程式碼的基礎設施正在緩慢但確定地成為常態。只有通過簡化的工作流程和改進的開發環境，才能更快地開發應用程式。