logo头像

Edward.K Thinking

(學習DevOps系列 11) DevOps中談得環境狀態配置


狀態配置的英文是Desired State Configuration,簡稱DSC,前幾篇比較談到是DevOps的文化與流程居多,當團隊對DevOps有了一定認知與實作外,後面就必須靠工具和技術來做推進,不然,如果只是靠人工進行頻繁的發布是相當吃力的。在DevOps中,要求其團隊工作方式是要能很頻繁的交付軟體給最終客戶。而要進行持續性的交付,是相當依賴自動化的基礎建設(Infrastruce)的資源配置,我們都知道傳統方式是可以藉由Script建立我們所需要的運行環境。不過,這方式有缺點就是降低因為要應付商業需求或是其他需求,導致環境必須更改的處理能力。因此,DSC是期望無論現階的環境狀態如何,通過狀態的配置,可以讓整個環境達到所需要之狀態


另外的好處在於可以隨時啟動和卸除目前環境的版本,也可以避免開發與正式環境間差異的麻煩問題。同時,也可以透過程式碼呈現應用程式所執行環境的依賴關係,並且在版本控制中進行管理。簡單來說,可以避免人工過程,並且確保建立一個可以執行應用程式的環境容器。這其中的開發與操作可以透過Script語言和工具,實現自動化。


DSC到底是甚麼呢?DSC其實是一種概念,並非一項技術。市面上已經有一些Open Source或是商業產品已經在DevOps中扮演DSC的角色。而通常應用程式的類型和Host位置是決定要選擇哪個工具的因素之一。目前已經有可以做到工具有Desired State Configuration、Puppet、Chef、Vagrant和Salt。

Microsoft Powershell的DSC


在微軟解決方案中,Microsoft Powershell DSC是眾多DSC框架中的其中一種,同時,也可以被應用在DevOps一環內。如搭配TFS或是VSTS等微軟相關工具使用。無論是用Pull或是Push模式使用DSC方法,或是透過描述性宣告來控制伺服器狀態。Push Mode是單向且即時性的被推送到我們想要的目標環境,配置這些目標環境狀態。Pull Mode是在每個Client端機器的配置是從Pull伺服器取得所需要的配置狀態進行設定。這樣的伺服器通常本身都有建置DSC服務來提供Client所需要的配置設定和資源。


一般建置Pull Mode,除了伺服器本身具有DSC服務外,也會額外建置Local Configuration Manager (LCM),主要在於當第一次需要進行環境配置時候,會先跟LCM驗證目前環境配置狀態是否正確,如果有問題,LCM會再跟DSC確認需要的配置設定,當然前提是在DSC會有Client環境配置的設定,如果沒有就無法運作,如果有,就會把相關配置推送到LCM,交由LCM去執行。


目前在Azure Automation DSC是基於雲端服務的解決方案,是採用Microsoft Powershell DSC架構來執行。藉由Microsoft Powershell DSC可以讓我們來管理和佈署,以及設定虛擬機,如Windows和Linux的VM。 Automation DSC是使用採用宣告式的Powershell設計語法來定義環境配置。透過集中式的Pull伺服器設定每個目標節點的環境設定。

Azure的Automation DSC是怎樣工作的?


從下圖可以知道,採用三步驟來進行

  • 使用配置元素架構,建立Power Shell腳本
  • 將腳本上傳到Azure Automationz服務並且編譯這個Script成為Managed Object Format file (MOF)。檔案將會被儲存到DSC服務中
  • 定義要使用這配置檔案的節點

在Azure就可以使用這樣DSC服務建立環境,如果地端有類似的環境,也可以把這DSC放在雲端,然後與地端進行溝通。


如果要建構混合方式,建議使用Azure Automation並搭配Runbook Worker,讓管理在雲端,透過Runbook Worker讓地端去執行這些動作。其中唯一要注意就是防火牆必須設定443 Port是可以開放給Azure使用。

DSC Configuration的格式


DSC Configuration在微軟解決方案中,就是採用PowerShell Script定義相關功能,換句話說,若是採用微軟解決方案,PowerShell的學習未來是不可以少。其Script架構長的樣子如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Configuration MyDscConfiguration {

param(
[string[]]$ComputerName="localhost"
)
Node $ComputerName {
WindowsFeature MyFeatureInstance {
Ensure = "Present"
Name = "RSAT"
}
WindowsFeature My2ndFeatureInstance {
Ensure = "Present"
Name = "Bitlocker"
}
}
}
MyDscConfiguration -ComputerName $ComputerName

配置最外層為腳本區塊,也代表其腳本的名字,以這上面為例,其配置名稱是MyDscConfiguration。在這裏面可以配置多個節點或是多台虛擬機,上面案例則是在一個節點中配置一台Windwos,有了機器或服務後,再進行配置其服務和機器的相關屬性,由這裡面可以知道,在這機器中又配置兩個WindowsFeature的資源,並同時也加上定義好的參數名稱


要進行這部分的實作,其中重要關鍵和最難的部分,不是如何去撰寫DSC腳本或是選用甚麼工具。而是在誰該寫又是否有權限寫的問題。畢竟,DSC範疇牽扯到程式碼撰寫和對IT基礎建設的了解,另外,在企業中這又牽扯到權限分配問題,有能力寫但不一定有權限可以寫。


如之前提到整個DevOps最終是要探討IT如何持續交付有價值事物給用戶,有價值這件事情不單單只有Appliction,也包含到資訊安全、基礎建設…等等,必須是整個IT都需要思維轉變,Infra或資安團隊不該只能保守與限制,更應該了解商業需求,開發團隊也不能認為資訊安全和基礎建設與我無關。整個環節都是緊緊相依

參考資源


上一篇