建立CI/CD流水線中的IaC前，需要考慮哪些事項？

許多軟體工程團隊通常會遵循相似的方法來交付基礎設施以支援軟體開發生命週期。為了縮小基礎設施配置方式與應用程式環境部署方式之間的差距，許多 DevOps 團隊將其基礎設施即程式碼（IaC）模組直接連線到其 CI/CD 平臺。其目的是建立一個直接融入軟體開發和交付流程的連續基礎設施流水線，類似於用於持續交付應用程式的 CI/CD 流水線。
 

原因很容易理解。開發團隊需要快速部署基礎架構，他們沒有時間瞭解配置的細微差別。許多人根本不熟悉 IaC 工具，因此無法在第一時間進行部署。
 

從理論上講，將 IaC 模組插入 CI/CD 工具應該使開發人員無需瞭解 IaC 配置中使用的語法和邏輯。當開發人員和測試人員在整個流水線中執行其工作時，會部署基礎設施以支援每個步驟。
 

不過在採用這種方法之前，有幾個重要的事項需要明確。
 

如何跟蹤資源利用率？

雖然在 CI/CD 流水線中部署 IaC 可以幫助團隊更快地移動，但它會使運營團隊忽視資源消耗、使用情況和成本應計情況。
 

這對於用於測試、除錯和暫存的臨時環境尤其重要。如果 CI/CD 流水線正在大規模部署雲資源，那麼誰負責在這些階段完成後終止它們？如果您想了解當前正在執行哪些環境、誰啟動了這些環境，以及這些環境給您帶來的實時成本，應該從哪裡開始下手？
 

在急於加速運維的過程中，通常會犧牲可觀測性 。這使得基礎設施資產的端到端管理和成本控制變得困難。
 

團隊是否共享雲帳戶憑據和金鑰以獲取訪問許可權？

面對按時完成任務的壓力，一些團隊可能會走捷徑，將雲帳戶憑據、證書和其他金鑰以硬編碼的形式放到 IaC 模組中，以便為團隊成員提供所需的訪問許可權。
 

僅依靠 IaC 在整個 CI/CD 流水線中交付基礎設施會快速加速 IaC 模組的建立，但並不能更輕鬆地分發對雲基礎設施的安全訪問。這是一個需要避免的嚴重風險。
 

如何確保 IaC 模組是最新的？

在生命週期階段保持一致的配置在較大規模上可能具有挑戰性，導致測試環境過期並需要返工。IaC 工具僅標識何時對原始檔進行配置更改，這可能難以跟蹤。如果實時環境發生更改，開發人員將花費大量時間來嘗試瞭解其部署失敗的原因。
 

DevOps 團隊在預配基礎架構上花費了多少時間？

對於 DevOps 的工作效率而言，基礎設施置備（provisioning） 是一把雙刃劍。一方面，頻繁的環境部署對雲成本效益來說是一個積極的訊號，因為這表明當不再需要短暫環境時，團隊會將其停用。
 

另一方面，對部署的高需求可能意味著您的 DevOps 團隊需要繁忙地處理基礎設施置備工單，這會降低開發速度。
 

即使在使用基礎設施即程式碼時，交付支援 CI/CD 流水線的環境所需的編排工作量也可能相當大。 請務必考慮支援流水線的環境的內容以及交付流水線所需的工作。
 

如何將雲運營標準化？

隨著越來越多的企業採用雲原生開發，複雜性挑戰變得越來越普遍。開發團隊如何在不犧牲對雲資源使用方式的控制的前提下加快速度，成為需對企業需要解決的問題。
 

透過 CI/CD 流水線擴充套件 IaC 可能會導致配置混亂。在 git 倉庫管理的基礎架構缺乏一個執行標準的中心點，因此很難了解團隊是否部署了經批准的雲配置。雲運營也是如此。如果要為臨時環境要求最大執行時，需要考慮在數十甚至數百個 IaC 配置支援的多個流水線中強制實施。
 

參考連結：