什麼叫作IaC,與DevOps有什麼關係？如何實現？

　　互聯網時代  ，Development應運而生，用戶高併發  ，Operations 因勢而動，用戶終體驗  Dev + Operations = DevOps。茫茫IT大江湖，創新鑽研的人總會相遇，接頭暗號：敏捷、持續、穩定、交付，探討DevOps趨勢，今天要給你們普及的是IaC，那麼什麼叫作IaC,與F5的DevOps有什麼關係？如何實現呢？

　　Infrastructure as Code：基礎設施即代碼(如下均簡稱IaC)是一種用描述性的方式來管理基礎設施（包括網絡，虛擬機，存儲，負載均衡等），IaC模型在每次應用時都生成相同的環境，它是與DevOps結合的關鍵時間，與持續交付(Continue Delivery)結合使用。
　　

　　IaC的發展，解決了CD流水線中的環境飄移問題。若是沒有IaC，團隊必須維護各個環境的設置。隨着時間的推移，每一個環境都會成爲了信息孤島，沒法自動複製相同的配置。環境之間的不一致會致使部署期間出現問題，最後會致使基礎設施的管理，變得很是難以跟蹤，而且只能經過手動進行單獨的維護。
　　

　　與DevOps的關係

　　IaC是成爲在DevOps中實現最佳實踐的關鍵屬性，開發人員能夠更多地參與定義配置，Ops團隊在開發過程的早期階段就參與其中。利用IaC的工具能夠提升服務器狀態和配置的可見性，最終爲企業內的用戶提供可視性，旨在將團隊彙集在一塊兒，最大限度地發揮他們的做用。自動化一般旨在解決手動過程當中的混亂和容易出錯的問題，並使其更高效，更高效。容許建立更好的軟件和應用程序，靈活，減小停機時間，併爲公司提供總體成本效益的方式。IaC旨在下降從手動配置中帶來的複雜性。自動化和協做被認爲是DevOps的核心要點，基礎架構自動化工具一般做爲DevOps工具鏈的重要一環。

　　IaC的特色

　　1版本控制和歷史管理

　　2全部操做能夠追溯和進行審計

　　3快速簡單，容易回滾

　　4方面團隊協做，共同維護

　　5冪等性(Idempotence)

　　而冪等性是這裏面一個很重要的規範原則，不管環境的起始狀態如何，這個部署指令執行了多少次，它均可以保證環境最終的狀態是一致的。所以，經過IaC，團隊對環境描述進行更改並對配置模型進行版本化，一般會採用標準化並容易理解的代碼格式（如JSON，YAML）。持續交付Pipeline以IaC方式配置目標環境。若是團隊須要進行更改，他們會編輯源，而不是目標。記住，Source of the truth!

　　IaC主要帶來三個主要的價值

　　1成本（減小）

　　2速度（更快的執行）

　　3風險（人爲的操做錯誤所帶來的安全隱患）

　　實施IaC的團隊能夠快速，大規模地提供穩定的環境。團隊經過代碼表示環境的最終指望狀態，從而避免手動配置環境並強制實現一致性。使用IaC進行基礎架構部署都是可重複的，可防止因配置誤差或缺乏依賴性而致使的運行時問題。
DevOps團隊能夠與統一的實踐和工具協同工做，快速，可靠，大規模地交付應用程序及其支持基礎架構。

　　實現IaC一般有兩種方法

　　1Imperative（命令式）

　　2Declarative（聲明式）
　　

　　命令式的特色很是明顯，若是須要達到最終的目的，你要以適當的順序執行特定的命令，好比你執行的順序是123，就絕對不能是321。而且每一步操做，你都須要執行對應的API或者指令應該在哪裏。
　　

　　而聲明式就很是簡單了，只須要描述你所需環境的最終狀態，而後經過少許的API任務，post過去，最終環境就能夠根據你所須要的描述，生成最終的狀態，因此也很是受開發者喜好。
　　

　　而f5有4種聲明式的組件來匹配在持續交付流水線中的每個環節：部署，上線，配置，監控。