logo头像

Edward.K Thinking

(學習DevOps系列 10) Infrastructure as Code 和自動化


在前一篇的DevOps中所謂的標準化建置機制,談到標準化的重要性,其中,有提到一點就是Infrastructure as Code的概念。不過,說真的在企業界要實作出這部分的難度是很高的,高的原因不在於技術,而是在這一個名詞,難在被卡在需要兩個部門信任和被制約的責任分工上。把這個詞拆開成InfrastructureCode則是代表兩種含意,一種就是開發者必須了解Infra基礎知識,又或者是Infra必須往開發一方學習,再加上如果大家都把自己的工作領域當作神聖不可侵犯(通常權限都會被後者卡死),要做到這樣就困難重重。在實務上,大部分由開發去偏向學習Infra知識是會比較簡單一些。

Infrastructure as Code & 自動化


Infrastructure as Code(IaC)是一種能夠驗證基礎架構(網路和虛擬機)和自動化實踐方式。可以幫忙系統提供安全、穩定的工作平台。在DevOps的核心之一就是自動化或是手工最小化。通常都可以使用Script進行配置,其目標可以讓兩次以上要執行相同的東西,不須要再透過手動去工作。也因此實施DevOps,是可以優化開發和維運雙方的合作關係。因為是自動化關係,可以讓使用相同流程和工具的雙方訊息可以更清楚,最終結果是雙方工作會更容易。一般來說自動化的好處有下列幾點

  • 讓人們可以不必執行重複性且單調的工作,當然也可以減少人為錯誤
  • 讓人們有更多時間創造公司的商業價值
  • 自動化比手工速度更快
  • 自動化可以提高發布的質量。因為它的佈署的步驟都標準化。可以在確保的環境與流程中,預期後續會產生的結果
  • 從中長期來看,自動化是可以降低成本。

Infrastructure as Code商業價值


IaC從早期平台即代碼演進到解決在系統佈署的環境遷移問題。如果,沒有透過這樣做,團隊都必須去維護每套系統佈署環境和建置。隨著時間久遠,每套系統的環境設置就會如雪花一般,到處分散,又或者是無法自動化再複製一份相同的配置。在佈署過程中,環境之間的不一致會導致許多問題產生,甚至,要重建一套系統時候,環境也無法配置如之前一樣。這些基礎建置的管理和維護,如果都必須透過手工流程或處理,將會很難去追蹤過程,也會容易產生錯誤。


一致性是IaC的原則。所謂一致性,就是佈署命令始終會將目標環境配置相同屬性,無論環境狀態怎樣改變,都可以透過自動化配置現有目標或是拋棄現有目標重新建立新的佈署環境,通過IaC,只要團隊對於佈署環境的進行修改,並搭配版本控制來管理,通常環境配置的Script都是採用一般常用的代碼格式(如JSON)。因此,當有需要環境被修改時候,團隊不該直接去佈署環境修改,而是必須修改代碼。這樣好處,可以在每次佈署新功能或是系統時候,可以確保執行此系統的環境,不管是哪一版本的系統。該環境都是符合系統運作環境。作為Infrastructure as Code,可以讓DevOps團隊能夠在開發的早期階段,就可以在於正式環境一樣配置來進行系統測試。若是需要產生不同配置環境,也可以透過IaC方式輕易產生,做系統驗證和測試,防止常見的佈署環境問題。另外,在雲的解決方案中,可以動態調配環境和拆除環境。另外,有實施IaC的DevOps團隊,是可以快速簡單大規模的提供穩定的環境。且團隊透過程式碼避免手動配置環境,讓環境達到一致性。IaC是可以被重複建置的,並防止配置環境時候缺少依賴相關設定,導致問題的發生。

上一篇