解讀基礎設施即程式碼

現代軟體開發對基礎設施的管理提出了更苛刻的要求。產品要適應瞬息萬變的市場，要求基礎設施要有更快的響應速度。而持續交付和DevOps的推行要求產品團隊對部署和運維要有更高的自主性。技術的快速進步和演化，也使得基礎設施的配置不得不頻繁變化。在這種快速變化的過程中，要求基礎設施既要靈活，也要安全、可靠。

而傳統的基礎設施運維管理具有以下幾個問題。

被動響應。產品團隊獲取伺服器資源採用的是申請制，中間存在若干審批過程，以及需要等待運維團隊實施，響應不及時。
自動化缺乏串聯。雖然有一定的自動化，但不能做到無人值守，需要執行一些臨時命令介入。由於環境釋放和重建的成本高，因而傾向於不釋放，導致資源利用率低。
和產品團隊脫節。很難根據需求隨時動態增加環境。需要額外的文件來描述環境，可能更新不及時。

產品團隊是實施持續交付的過程中，必須考慮將基礎設施的維護納入進來，作為支援產品執行的一部分。以下是產品團隊的持續交付流水線全景圖。

解讀基礎設施即程式碼

從上圖可以看出，產品團隊除了管理專案本身程式碼外，還要管理環境定義指令碼。環境定義指令碼可以由基礎設施自動化工具執行，動態建立和銷燬和更新產品執行所需的環境（包括伺服器、負載均衡器、防火牆配置、第三方依賴等）。

如果實現了這一點，那麼就實現了基礎設施即程式碼的雛形。Kief在《Infarftruce As Code》一書中對基礎設施即程式碼定義如下：

基礎設施即程式碼是一種使用新的技術來構建和管理動態基礎設施的方式。它把基礎設施、工具和服務以及對基礎設施的管理本身作為一個軟體系統，採納軟體工程實踐以結構化的安全的方式來管理對系統的變更。

基礎設施即程式碼有四項關鍵原則。

再生性。

環境中的任何元素可以輕鬆複製。

一致性。無論何時，建立的環境各個元素的配置是完全相同的。
快速反饋。能夠頻繁、容易地進行變更，並快速知道變更是否正確。
可見性。所有對環境的變更應該容易理解，可審計，受版本控制。

基礎設施即程式碼的目標是：

標準化。以程式碼來定義環境，實現開發環境、測試環境、生產環境的標準化。
自動化。以自動化工具來驅動程式碼準備環境。包括建立環境、更新環境以及銷燬環境。
視覺化。以監控來視覺化環境資訊。環境當前狀態可視、環境變更歷史可視、可追溯。

基礎設施即程式碼實踐會產生高成熟度的持續交付和DevOps。

解讀基礎設施即程式碼

在實施基礎設施即程式碼時，要遵守以下實踐。

使用DSL描述環境。

Ansible、Chef、SaltStack、Terraform等基礎設施自動化工具都有各自的描述性語言實現對基礎設施的定義。使用DSL更容易通過描述性的語言定義基礎設施，也有助於程式碼重用。團隊成員能建立起共同理解，從而維護指令碼。

以下是Ansible的一個playbook示例。

---
- hosts: local
  tasks:
   - name: Install Nginx
     apt: pkg=nginx state=installed update_cache=true
     notify:
      - Start Nginx

  handlers:
   - name: Start Nginx
     service: name=nginx state=started

自測試系統。

在編寫環境程式碼的配置時，也要編寫對環境的測試。確保所有伺服器都正確進行了配置，遵守了所有的安全規則，網路連通性等進行了驗證。我們一般提倡將測試程式碼和配置程式碼放在一起維護。這樣配置程式碼更新的化，能保證測試程式碼也被及時更新。

一些典型的基礎設施自動化測試工具有ServerSpec、Testinfra等。以下是一個ServerSpec的示例。

require 'spec_helper'

describe package('httpd'), :if => os[:family] == 'redhat' do
  it { should be_installed }
end

describe package('apache2'), :if => os[:family] == 'ubuntu' do
  it { should be_installed }
end

describe service('httpd'), :if => os[:family] == 'redhat' do
  it { should be_enabled }
  it { should be_running }
end

describe service('apache2'), :if => os[:family] == 'ubuntu' do
  it { should be_enabled }
  it { should be_running }
end

describe service('org.apache.httpd'), :if => os[:family] == 'darwin' do
  it { should be_enabled }
  it { should be_running }
end

describe port(80) do
  it { should be_listening }
end

一切進行版本化。

一旦採用了環境定義指令碼實現對環境的控制後，需要將環境定義指令碼納入到版本管理中。並且之後所有的環境變更都應該先修改環境定義指令碼，由環境定義指令碼觸發對環境的變更。登入到伺服器執行一些臨時性命令是被堅決禁止的。因為這極有可能會破壞環境的一致性。當重建伺服器時，也不能保證能應用所有需要的變更。

下圖是基礎設施即程式碼的一個典型使用場景。

解讀基礎設施即程式碼

除此之外，如果想要在生產環境中建立可伸縮性的服務的話，也需要藉助機艙設施即程式碼這一實踐。在高峰時期，系統可以根據定義的環境自動建立並加入新的節點實現動態擴容，並在低峰時將其銷燬。當監控發現某節點失敗，系統可以根據定義的環境自動建立新的節點來替換失敗節點，實現自動災難恢復。

最後是我們在某團隊實施基礎設施即程式碼的案例解析。這張圖是某團隊的基礎設施架構圖。

解讀基礎設施即程式碼

該團隊使用AWS作為基礎設施平臺。我們選用ansible作為基礎設施自動化工具，並結合AWS提供的cloudformation服務實現快速建立和銷燬資源。所有網元都有清晰的角色劃分，配套對應的配置指令碼。從網路配置到網元配置以及應用配置都實現了全自動化。所有的配置指令碼都和原始碼一起託管在GitHub。團隊所有成員都可以檢視並修改。

解讀基礎設施即程式碼

相關文章