認識“基礎設施即程式碼”（Infrastructure as Code）

http://devops.com/blogs/meet-infrastructure-code/

May 5, 2014 Posted By Chris Riley In Blogs, Doin' DevOps Tagged Devops, Infrastructure As Code, It, Operations, Programmable Infrastructure 0 Comments

也許你早就聽說過“可程式設計的基礎設施”（Programmable Infrastructure）或者“基礎設施即程式碼”（Infrastructure as Code）這些新詞兒了。不過，就算你之前沒聽說過，只要對DevOps感興趣，你一定也會有興趣瞭解它們。我這個人對大多數新名詞都不感冒，但這次卻不一樣，這完全可以說是一個新概念。除了讓技術宅覺得談吐不俗之外，這些名詞確實代表了一種看待應用構成的新思路。這個新名詞很恰當地概括了過去幾年人類文明進步所取得的一些成果。一般來說，我使用某個術語的目的只是為了讓人知道自己沒有跑題，比如我提到“Web”“雲”之類的，僅僅是為了輔助我跟他人溝通。有時候我也會對某個術語感到奇怪，於是就會花時間去弄明白它的真正含義。但真正能讓我覺得是顛覆三觀的術語並不多見。“可程式設計的基礎設施”和“基礎設施即程式碼”就是。

“基礎設施即程式碼”的形象展示

並不全新的術語

自動化並不是新鮮事物。從最早使用BAT檔案到最近使用PowerShell指令碼在我的基礎設施中做事情，算起來已經很多年了。但當這種自動化與虛擬化相遇，當人們設計出了專門用來描述基礎設施編排的語言，情況就不同了。這時候，我們說的不再是給某種技術換個包裝，然後起個新名字。而是一個全新的概念，這個概念決定了誰來做什麼事，怎麼做，效率如何。那什麼是“可程式設計的基礎設施”呢？這個詞跟“基礎設施即程式碼”是一個意思。“可程式設計的基礎設施”我最早是聽Gartner的一位分析師說的，很可能也是那個人創造的，“基礎設施即程式碼”則是在某一篇部落格裡看到的。後者使用的“某某即某某”的句式一直很流行，還帶點神祕感。這兩個詞到底是什麼意思呢，就是告別手工配置基礎設施的時代，用自定義指令碼來配置基礎設施。當然不限於指令碼，還可以把配置整合到應用程式碼中。這種做法很早之前就有，但一直有侷限性。無論做什麼，總有一些事不能自動化。可今天，我們有了Vagrant、Ansible、Docker、Chef和Puppet，它們可以單獨起作用，也可以配合起來把原來手工能做的一切都自動化，包括基礎設施層和作業系統層。即便是已經存在的基礎設施，通過這些工具也一樣可以再執行指令碼，甚至可以在新建立的基礎設施中執行原來的老BAT和ps1檔案。這是基礎設施編排的一種新思路。

開發人員全程可控

有人會說，這不就是配置管理嗎。某種意義上說，它就是全自動化。但它跟配置管理有一個非常大的區別，那就是開發人員可以全權負責。過去，這種編排和自動化工作得交給系統管理員去幹。今天，開發人員至少可以提建議了，甚至在很多情況下完全都可以自己動手了。這樣一來，應用程式碼與底層基礎設施之前的關係就更加緊密了，有時候根本就分不開了。今天的開發人員不光可以寫應用程式碼，還可以寫執行應用的基礎設施。就拿Web開發領域來說吧，開發人員寫一個deploy.php檔案來自動配置執行應用的基礎設施，這種事已經很常見了。這種指令碼開始會建立VM，最後會向原始碼倉庫傳送下載請求。我建議相關機構應該成立自己的小團隊專門負責這些指令碼的維護，因為開發人員應該花時間去改錯和實現新功能。但無論如何，IT運維與開發都無法截然分開了。

到底有什麼好處

除了讓配置管理高效可複用之外，基礎設施即程式碼還帶來了其他好處。首先，指令碼本質上都可以作為應用基礎設施的文件。這個附帶的好處很有用。因為你已經投入時間和精力把指令碼寫好了，那麼把它當成基礎設施的網路關係圖來看其實也挺好。有人可能並不滿足於此，還會基於指令碼生成外行都能看懂的內容、圖表和文件。其次，因為一切肇始於指令碼，那麼所有部署都將源於同一個檔案。自然地，每個部署都將具備相同的基礎設施特性。這只是理論上，實踐中我發現很多機構會在已有基礎設施上執行指令碼，或者在指令碼自動執行後再手工修改配置檔案，導致指令碼喪失了作為追溯依據的價值。另外，指令碼還是基礎設施中立的。只要把指令碼寫好，就可以在任何雲上執行，公有、私有、混合，都沒問題。等到軟體定義網路即SDN統治了全世界的路由器，現在90%的中立就會變成100%中立。這種中立性對雲使用者至關重要，可以避免被某家供應商鎖定，也可以在多個雲中執行以增加冗餘。不僅如此，不同的用例還可以執行在特定的雲上。比如，有一個用於整合測試的雲，還有一個產品開發雲，還有一個beta版本雲，它們都相對獨立。但由於指令碼可複用，部署就不僅僅是複製資源和可執行程式碼了。部署還包含了基礎設施。這樣每一次部署，都會有一套新的基礎設施和一套程式碼。這樣就避免了交叉汙染。QA就不必再回答“在我的電腦上可以執行”之類的問題了。增加了新功能的測試套件可以在全新的基礎設施中執行。而在出現問題時，也能夠取得部署、程式碼和基礎設施的完整快照。與以往模糊的快照和對錯誤的文字描述相比，簡單天壤之別。更吸引人的是，大多數公有云都提供有限或全功能的REST API，支援使用者對自己的雲進行程式設計。這樣在把程式碼從Github下載到前端和資料庫伺服器之前，我只要向自己的產品雲傳送一個REST請求就可以啟動它們。

面臨的挑戰

基礎設施即程式碼或可程式設計的基礎設施要想普及，還面臨一些挑戰。

1. 微軟的產品仍居壟斷地位。Linux基礎設施是最靈活的。雖然也可以對微軟產品做一些定製，但能到40%就不錯了。一方面是因為Windows天生封閉，另一方面也是沒人願意專門給它寫工具。不過Azure PaaS則是另外一回事。如果你對可程式設計的基礎設施感興趣，又選擇了微軟的服務，願意多花錢，那麼將會面臨新一輪的鎖定，即使用VMware的VIX或者SCOM（System Center Operations Manager）。

2. 多層應用會導致指令碼極速複雜化。如果再加上網路和安全元件，那就更復雜了。如果你要面對聯網VM，要考慮vLAN的設定和安全問題，那麼用指令碼來部署就會變得異常複雜。vLAN可以看成VM，但編排語言並沒有成熟到支援這種抽象。在我看來，趨勢是從應用系統架構中砍掉這種變數。

3. 必須先想好基礎設施工具的基礎設施。這個問題很怪異，你得先想好不同的編排工具在哪裡、如何執行，這也需要基礎設施，或者需要基礎設施規劃。雞生蛋，蛋生雞……。有時候，在VM中安裝監控程式和代理，確保VM的安全訪問真的很煩人。這件事說起來很簡單，就像新設立一個監督部門，或者在Azure或AWS中選擇一款VM模板，沒啥難的。但有時候開發團隊就是缺少使用理想工具的條件。

4. 很多工具仍然需要專業化。今天，可以選擇的工具仍然需要投入大量時間去掌握，包括原理、語言的語法等。相應的時間和金錢對很多機構來說仍然是不小的障礙。

5. 如果你的應用全部部署在PaaS上，或者有PaaS也有云和on-prem，那麼統一的指令碼就是個大難題，必須考慮多個指令碼。多個指令碼協同執行又是問題。

以上是今後兩年我預期會出現重大變革的一些領域。我相信這些問題會越來越容易解決。到最後你都不會相信還有人要自己手工配置基礎設施。記得我最初接觸虛擬化的時候，很喜歡說“機器都變成文件了”。現在其實也可以說一切都是應用，也就是一組檔案，這些檔案要按照既定的順序執行。最終，所謂應用程式碼與執行它的基礎設施要分開的想法，將會被人拋到九霄雲外。不知道“可程式設計的基礎設施”或者“基礎設施即程式碼”最終會不會演變成“一切應有盡有”。但有一點可以確定，那就是應用可以包含執行它的基礎設施的思想促進了DevOps運動，同時也帶來了人們想象不到的靈活性。