基礎設施即代碼：從手工到自動化的躍遷
IT系統運行離不開服務器、網絡和存儲這些底層硬件基礎設施的支持，因此需要對這些基礎設施進行管理，比如，設備的啟停、網絡的配置、軟件的安裝和升級等，這些工作復雜而且瑣碎，一旦出錯，很可能導致其支持的各種業務系統無法正常運行。
很長時間以來，基礎設施這些管理工作依賴于管理員通過命令行或其他界面進行操作。隨著IT設備數量的不斷增加，IT系統越來越復雜，變化越來越頻繁，停止和啟動它們的頻率也越來越高。如果繼續采用手動，意味著管理員可能每天要人工登錄和修改數百次，這是不現實的，根本適應不了大規模部署的要求。特別是當單體數據中心規模從幾十臺增加到上萬臺、10萬臺甚至更多之后，以自動化替代傳統手工方式成為必然。這正是基礎設施即代碼(Infrastructure as Code，IaC)出現最重要的原因。當然，IaC不止是以自動化替代手工提高了工作效率，它還帶來了環境一致性、可復制性以及可追溯性等諸多優點。可以說，IaC開啟了基礎設施管理的一個新世界，它讓基礎設施的管理也像軟件開發一樣，是基礎設施管理和運維從手工到自動化最終到無人化這一進化路徑上的一次重要躍遷。
為了幫助大家了解IaC，IaC到底有哪些好處，它和時下流行的DevOps、AIOps是否有關系？我們邀請了專家景顯強對此相關話題進行了解答。
景顯強是紅帽資深解決方案架構師、RHCA認證。曾就職華為、SUSE等企業，有多年操作系統研發及運維經驗，同時在數據中心運維方面有多年經驗。目前，景顯強在紅帽軟件（北京）有限公司負責紅帽軟件的相關產品及解決方案，主要針對Linux操作系統、分布式存儲、IaaS云、PaaS云、自動化運維等領域提供技術和方案建設規劃，為企業提供以紅帽產品為中心的解決方案建設指導，幫助企業實現數字化轉型。
以下為本次訪談內容。
紅帽資深解決方案架構師景顯強
1. 何謂基礎設施即代碼（IaC），為什么會提出這個概念？它要解決什么問題？
基礎設施即代碼 (IaC) 是通過代碼的方式來管理和配置基礎設施，取代以往的手工操作基礎設施。提出這個概念的靈感來自軟件開發的最佳實踐經驗。傳統的基礎設施管理方法是人工的手動處理模式，不僅僅效率低下，而且還有很多人為操作的風險，比如誤操作。同時，對基礎設施的配置更改需要文檔記錄，如果沒有做好配置更改記錄，可能帶來另外一些重復性操作的風險。另外，隨著虛擬化和云平臺的引入，企業的基礎設施變得很復雜，也引入了很多工具和平臺，雖然能在基礎設施的提供和管理上增加部分效率，但是對于環境的一致性保證以及在數分鐘內實現特定場景下基礎設施就緒是很難實現的。因此需要一種全新的管理方法，而IaC借助了軟件開發中的代碼管理經驗，通過代碼描述基礎設施的配置及變更，再執行代碼完成配置和變更。
只要我們編寫好一套代碼來描述對基礎設施的操作，便可以對這些代碼進行管理和維護，比如將其存放在代碼版本管理工具git中，這樣只要需要用到這段代碼的時候，就從git中將其check out出來使用。如果需要對這段代碼進行更改，git也會記錄代碼更改的所有記錄，實現了版本控制。通過這種方式來管理基礎設施，能保證部署的環境一致性，實現了同一代碼部署多套相同環境的要求。
IaC主要解決的問題就是基礎設施提供的效率和一致性問題。我們可以將基礎設施作為代碼來部署，可以實現版本跟蹤，也能在很短的時間內提供一套全新的相同環境。如果我們的操作需求很復雜，可以將基礎設施劃分為模塊，然后對每個模塊分別實現代碼方式描述，在需要使用的時候，可以通過自動化以不同方式組合這些模塊，進而實現復雜場景的快速響應。
2. IaC的主要客戶是哪些，它能帶來哪些好處？
對于擁有大量IT基礎設施環境的企業都可以考慮IaC，比如擁有大量服務器、存儲、網絡設備、操作系統、虛擬化平臺、私有云平臺、公有云平臺、容器云平臺甚至是混合云架構下的混合平臺的企業都應該考慮IaC，尤其是在這些基礎設施上有頻繁操作需求的，比如對變更、新業務系統上線、基礎環境制備要求更高響應速度的企業更應該考慮使用IaC。
使用IaC能帶來以下幾方面的好處：
1) 提高開發速度。開發業務代碼需要依賴基礎設施環境，如果基礎設施能快速就位，快速響應變更，并行執行任務，就會使開發效率得到提高。
2) 保證環境一致性。使用相同的代碼部署出來的環境一定是相同的，對所納管的環境變更也一定是一致的。
3) 自動化的處理。當代碼借助自動化工具開始執行，執行期間不需要人為干預，完全自動化，避免了人工手動操作帶來的弊端。
4) 降低成本。對于運維成本，環境使用成本，人力成本都能降低。
5) 降低錯誤發生率。由于是自動化方式處理，代碼的變更和版本控制有審核，會大大降低人為操作的失誤。
6) 進行多元化整合。對于復雜場景下的基礎設施提供，需要依賴很多組件或者軟件，通過IaC能將多系統、多平臺在統一代碼中進行描述，實現多系統、多平臺的整合。
7) 操作過程可審計。在經過測試后的代碼上線使用時，擁有執行過程記錄，可回溯以往的執行事件。
8） 可以實現自服務。開發人員處理業務需求的時候，可以通過自服務門戶集成IaC，這樣只需要審核通過后，開發人員即可以自我實現環境的上線，大大降低了對基礎設施管理員的依賴。
3. 實現IaC需要做哪些準備工作？IaC落地的主要障礙有哪些？
如果要采用IaC，這里有些最佳實踐經驗可以分享給大家。最好提前做好以下準備：
1) 使用具有可分支管理、安全、集成的源代碼管理 (SCM)，可以考慮使用git。
2) 選擇經過仔細研究和理解的工具，為編寫的基礎設施代碼組成自動化引擎，例如ansible或者terraform 等。最終用戶團隊能夠理解和使用這些工具。
3) 使用相關工具后，要在執行后能快速獲得基礎設施狀態反饋，以便了解執行狀態。
4) 制定開發人員和基礎設施團隊協作流程，制定雙方認可的標準，使提供的基礎設施環境能保證業務成功上線。
5) 有良好的測試環境，保證生產和測試場景下的環境一致性。
6) 要有一個安全的前端，包括帶有憑證管理的權限管理（RBAC）。
7) 可以迭代完善代碼，測試一次，快速失敗，然后繼續小步快跑前進。
IaC落地的主要障礙有以下幾個：
1) 企業服務器規模較小，管理工作相對較少，需求不強烈。
2) 害怕自動化，執行過程不放心。
3) 團隊害怕學習新技術或者編寫代碼維護基礎設施。
4) 企業內部管理流程限制，權限不足，審計要求，無法打通多組件。
4. IaC如何工作的？有哪些工具可以幫忙？
IaC的本質是通過代碼去調用管理工具提供的API接口來對設備進行操作。最簡單的IaC工作過程如下圖所示。主要分為5個步奏：1. 編寫代碼（分支并行開發）；2. 功能測試; 3. 提交代碼; 4. 變更申請；5. 批準后執行代碼進行環境部署。
常見的IaC工具有如下幾個：Ansible、Terraform、AWS cloudformation、Azure Resource Manager、Google Cloud Deployment Manager、Chef、Puppet、SaltStack。
5. IaC與自動化運維、AIOps、DevOps有什么關系？
IaC是針對基礎設施進行管理，它的落地是需要采用自動化工具對基礎設施環境進行操作，具體的操作方法是通過編寫代碼的方式實現，對基礎設施的變更操作只需要修改代碼即可完成。而自動化運維的維度不僅僅局限在基礎設施上，因此他們是兩個不同的維度，IaC的落地要借助自動化運維的方法。
AIOps是在傳統運維的基礎上引入人工智能，通過大數據分析或者機器學習等方法來提前感知運維狀態，進而采用動態的方式調整相關組件或者基礎設施。因此其維度更廣，IaC可以被AIOps利用，例如在發現業務性能瓶頸時，需要對其后端服務器進行擴容，這樣可以提前寫好IaC針對基礎設施擴容的代碼，然后AIOps將這段代碼調用起來，配合其他的后續自動化處理任務，共同完成一次業務擴容的智能運維操作。
DevOps是近年來非常受歡迎的一套方法論，追求的是開發和運維一體化，從而加入軟件上線速度。在DevOps流程中IaC的作用是支持開發環境和生產環境的快速交付。
6. 業務全部上公有云后，是否還需要IaC？
公有云提供了業務運行環境和通用運維場景的管理，比如保證了服務器的可用性等，但是并不具備快速提供特定應用的一致的運行環境，IaC正好解決了公有云上的不足之處，提前規劃好IaC，有利于用戶更好地使用公有云環境。
7. 紅帽在IaC的落地上能發揮什么作用？
紅帽在IaC建設上能提供全球一流的產品（Red Hat Ansible Automation Platform）和技術服務，同時能提供全球的經驗并指導用戶落地和掌握IaC方案，包括IaC的整體方案設計及落地及后續的維護和相關培訓，保證用戶能順利掌握IaC。
8. 您認為目前市場對這個概念的認可程度如何？
從國內市場來看，對IaC的采納有行業屬性的區分，金融行業相對制造行業要更超前一些，雖然沒有全面開展IaC的落地，但是在某些場景下已經通過自動化的方式向IaC邁進，一些IaC工作正是以自動化的名義在進行。紅帽在當前國內市場上所推廣的自動化方案中，大部分都是基于IaC思想，旨在幫助客戶更高效的管理基礎設施，同時為客戶提供培訓，保證能力掌握。
