什麼是基礎設施代碼(IAc)?

基礎架構即程式碼 (IaC) 是一個自動設定和管理雲端資源的流程。IaC 軟體採用一些描述所需狀態的輸入腳本,然後通常透過應用程式開發介面與雲端供應商進行通信,以使現實與所需狀態相符。

本文將介紹 IaC 的重要方面,從它如何實現(即解決了哪些問題)開始,然後介紹 IaC 的好處,最後如何將 IAC 整合到您的組織中。

申請示範 Read Whitepaper

什麼是基礎設施代碼(IAc)?

對 IAc 的需求

曾幾何時,當企業想要運行軟體時,唯一的選擇就是從網路供應商訂購一些實體設備和網路存取。這些是現場資料中心,公司必須根據預期流量提前幾週甚至幾個月訂購伺服器和網路設備,然後在現場手動配置它們。這需要一個具有冷卻系統的實體位置,並且無數小時才能執行安裝和維護作業。

但後來,公共資料中心出現了,可以管理其他企業的伺服器。

營運資料中心成為一項獨立可行的業務,為客戶帶來了巨大的優勢:

  1. 無需專用且昂貴的伺服器房
  2. 可能縮短一般伺服器和網路項目的前置時間
  3. 由資料中心提供者處理的伺服器/設備的實體管理
  4. 釋放寶貴的資源

虛擬化的出現帶來了另一種演進:雲端。在公有(或私有)雲中,實體設備位於雲端廠商的資料中心,仍需要手動處理。虛擬伺服器可透過 Web 介面供企業使用,讓他們在幾秒鐘內 (或數分鐘) 為最大資源佈建伺服器和其他資源。 在此階段,儘管虛擬化允許非常快速佈建,但大部分操作仍然是手動的。

最終的開發是隨著 IAc 概念和工具的出現。 一旦可以透過應用程式開發介面存取程式雲端,資源的配置和管理就可以由腳本和自動化工具而不是人類來處理。所以現在,一旦實體設備安裝並連接(仍然是手動操作),其他所有內容都可以自動化,包括配置所有虛擬硬件資源。

以程式方式存取公有雲端的能力促進了 IaC 的興起。在 IAC 的出現之前,系統工程師必須手動瀏覽 Web 介面來佈建和設定資源。 使用 IaC,資源的供應和配置在腳本中描述,這些腳本由與公共雲端應用程式開發介面通訊的工具讀取,以確保現實與所需狀態相符。

IaC 的好處

如上所述,IaC 工具使用來自腳本的輸入;這些腳本由人類編寫,描述給定雲端資源的所需狀態。這些工具透過其應用程式開發介面與雲端供應商進行通信,以建立、更新或刪除資源,以便實際情況與輸入腳本中描述的所需狀態相符。與手動佈建和配置相比,IAc 提供了單一真實來源(輸入腳本),從而消除大多數人為錯誤。

執行 IAc 腳本是一項可重複的操作,每次都會產生完全相同的結果。 這可以在許多方面提供幫助,例如:

  • 在不同的位置和/或為不同的專案部署相同的工作負載
  • 建立獨立但相同 (或幾乎相同) 環境 (暫存、生產、測試等)
  • 從 IaC 指令碼和生產環境的最後備份快速建立新的相同環境來執行災難復原

IaC 腳本可以保存在 git 存儲庫中,為您提供基礎架構的歷史記錄。 作為一個額外的獎勵,由於腳本只是文本,因此可以比較版本以查看已添加,更改或刪除的內容。

另一個好處是,IAc 允許初級系統管理員或非技術人員在沒有技術知識的情況下創建整個工作負載。 如果正確配置雲端帳戶,甚至可以允許具有有限權限的使用者透過 IaC 工具建立此類工作負載,即使該使用者沒有直接建立資源的權限。您也可以利用額外的工具和範本來確保安全策略早實施,以限制任何人實例化 IaC 堆疊的人造成安全洩漏和設定錯誤的機會。

除了精確的重複性之外,IaC 與手動操作相比的最大優勢之一是可擴展性。 事實上,您只需要編寫 IaC 腳本一次,然後工作負載可以根據需要的多次實例化,幾乎立即。 最後,通過花更多時間在 IaC 腳本中製作正確的權限,可以避免手動工作授予角色和資源過多權限的典型缺點。

如何開始

通常,您希望自動執行目前正在手動執行的某些作業。 因此,第一步是記錄建立工作負載所需的基礎架構所需的手動步驟。 這些是您將通過 IAc 自動化的步驟。

然後,您需要選擇一個 IAC 軟件。 這應該不是一個困難的選擇,因為只有少數,而且三大雲端供應商都有自己的:Amazon Web Services 提供CloudFormation ,Microsoft Azure 提供Azure Resource Manager ,Google Cloud Platform 提供Google Cloud Deployment Manager 。最著名的獨立於供應商的選項是Terraform ,它不僅支援上面提到的三個雲端供應商,還支援更多雲端供應商。

接下來,您將需要為您選擇的 IaC 工具編寫一些腳本,以重現您記錄的手動步驟。 通常在您進行時測試這些是一個好主意。 換句話說:編寫一些 IaC 代碼,部署它,測試它,當您滿意時它看起來很好,轉到下一個代碼。 如果您一次編寫所有內容,則代碼中可能會出現重大缺陷,您只會在多小時工作後才會發現這些缺陷,這意味著您可能需要重寫大部分腳本。

向左移動

此外,左移主題繼續趨勢。 這基本上意味著您盡早開始測試,並專注於預防問題(而不是在問題發生後檢測和解決它們)。 這個想法是,整體質量和安全性將因此提高。

理想情況下,這個向左移應盡可能地利用自動化。 事實上,有多種工具可用於自動化編寫 IaC 腳本的某些方面,例如安全性和合規性。這些工具會在部署之前掃描程式碼,以減少錯誤配置、過於寬鬆的設定和已知脆弱性等問題的發生率。有關此的一些使用案例可在此處供您閱讀。

集中式團隊的需求

為了正確使用 IaC,編寫 IaC 腳本的人員必須對所使用的雲端平台有深入的了解。因此,建議確保 IaC 工作中最關鍵的部分由高級開發營運工程師完成。

讓一支(或至少一名)高級開發營運工程師團隊負責領導 IaC 工作通常是個好主意。這個團隊將能夠專注於最佳實踐和安全性,從而為更多的初級工程師提供藍圖。 它還能夠編寫一般模塊,這些模塊可以在組織內的 IaC 指令碼中重複使用,從而為更多初級工程師提供預先審查的構建塊可以隨時使用。

如果嚴格的安全性很重要,而且很可能是這個團隊也可以負責審查公開可用的模塊和軟件。 在線找到一些 IAc 模塊非常容易;Terraform 甚至有這些模塊的官方存儲庫。 但是,這些公開可用的模組可能不符合您組織或專案中套用的安全性標準。 因此,確保您的 IAc 團隊僅使用經過審核的模塊非常重要。

此外,您的 SecOps 團隊與您的開發營運團隊合作也是一個好主意。這種合作將使開發營運流程能夠在專案早期的安全方面得到最佳化。生產部署後偵測到的錯誤可能會造成高昂的代價,特別是在客戶關係方面。在過程中早期確保高質量將有助於避免任何此類災難。

結論

雖然 IaC 是最近的發展,但現在應該成為任何需要雲端資源的組織的配置策略的重要組成部分,並且至少應該進行評估以將其納入您的團隊中。無論您的組織規模如何,您很可能都希望 IaC 至少管理部分工作負載。

×
  反映意見
由於 Cookie 有其功能且可供我們用於資料分析和行銷等相關業務,本網站是有使用 Cookie 的。繼續瀏覽本網站即表示您同意我們使用 Cookie。若欲了解更多相關資訊,請參閱我們的 Cookie 聲明