logo头像

Edward.K Thinking

(學習DevOps系列 4) DevOps中所謂的標準化建置機制

在前面幾篇中,大致說明了對於DevOps的推進,大概因該要怎樣去推進,再來就針對一些DevOps技術層面的來說,其實對於DevOps來說,它不算是一個很新的名詞,只是在這幾年卻開始有了起頭,當然文化和人是依舊是最重要因子,但也因為技術的進步,讓DevOps在技術面的輔助下,也更容易落地於企業中。因此,除了BuildDeploying外,DevOps中的Configuration Management也是非常重要的。藉由Configuration Management的幫忙,可以讓整個維運負擔減經不少。

何謂Configuration Management


Configuration Management只要是跟應用程式部署環境有關的設定或是跟應用程式運作設定相關的,都可以被歸納到這個範疇。想像一下,如果當你在UAT階段的環境和正式環境如果不是相同,所造成的系統問題,就會有多少種可能性發生。再加上大多數企業中,一台Server的IIS內的應用系統,絕對不只一個,要是每個應用系統對於環境的配置都不相同,這樣之間的交互影響又會發生多少不同種類問題。所以,會透過一些Script方式來建構配置環境,因為是檔案、是Script,它本身也就可以做版本控制。


在Configuration Management的建置上,會有一些關鍵性特徵

  • 在DevOps的模式中,配置管理的設計模式會比其他傳統的參數配置來得不那麼正規
  • Configuration的參數都會是被用程式碼形式呈現,且這程式碼會是一份文件或式Script
  • 因為大都是屬於檔案格式呈現,所以相對會輕量化,這樣就可以配置參數和環境參數轉化成為程式碼

我們常說的Infrastructure as Code (IaC) 和 configuration as code,在DevOps中都屬於是Configuration Management,且這兩種都是涉及去定義應用程式環境和屬性,同時也可以是用Script方式呈現

  • Infrastructure as Code: IaC內容通常是定義要執行應用程式的環境,並將環境的定義撰寫成Script檔案,環境中會包含網路、機器和其他應用程式運行所需要的資源。同時,這些Scrip本身也是需要做版本控制。就像當我們需要一台可以執行我們應用程式的環境時候,就可以利用Script內的環境配置,建立或是更新需要的執行機器。也因此,藉由這方式,當我們需要增加一台機器執行應用程式,因該就是直接執行Script就可以建立,而不是透過人遠端連入設備去建立
  • Configuration as code: CaC則是針對伺服器、程式碼和其他資源的配置,定義成Script檔案,並且透過建立或是更新Script檔案,來運行環境或應用程式的配置,而不是直接登入到伺服器用人工方式去修改。當然,這些Script檔案也因該是被做版本控制。

此外,透過這樣模式,也可以說是漸進式的團隊知識給累積起來

做Configuration Management的好處


說要做Configuration Management,說起來簡單,但做起來不一定那麼順利。但是,到底如果做到Configuration Management這一環,對於團隊會有甚麼好處。這邊列出五個理由可以參考

  • 更容易維護
    輕易的在不同的層級上,許多不同版本或是不同Release definitions中所需要的變數,可以被儲存在專案或是檔案中。類似共用變數概念。也設計一些變數為了某些特定發布的定義參數和發布環境的組態
  • 要更新的位置更少
    透過儲存在部署工具例如:VSTS中的環境配置或是應用程式參數,如果有任何變數更改時候,在給定的時間內,只要去更新儲存在部署工具內的設定資訊就可以,遠比用Hard-Code方式去更新每個檔案,更簡便
  • 更少的錯誤
    透過部署工具,針對每個環境儲存適當的變數時候,就不容易發生資料庫連線字串的錯誤,把正式區會連線到開發區的資料庫。如果,所有配置都被分散在各個執行環境或是系統中,將讓部署工具很難進行整合
  • 更安全
    透過部署工具中的Configuration Management,可以針對具有資訊安全風險的變數,進行加密,會遠比直接暴露在web.config具有較高的安全性
  • 更可靠
    透過部署工具自動轉換參數的方式,會比人工手動異動參數來的可靠。並且在持續部署過程中,可以確保這些轉換是會被執行的

Infrastructure As Code


在IaC中,最簡單的概念就是當你正在運行的機器壞掉時候,需要更換或是重新建立時候,這期間可能就會發生一些嚴重後過,像是某某安裝沒裝、某某設定沒有弄好,所以,通常最簡單方式就是不斷針對環境進行備份。如果環境設置可以被寫成Code,當機器換掉時候,這要再另一台機器重新執行IaC,就可以立即建立好之前運行的環境。且當我們去設計Script或是變成定義的檔案時候,必須要先確保它能夠被多次運行,且不會出錯才可以,當然也需要確保每次重新運行是一致的


Infrastructure As Code往往可以在開發人員幫忙下建立,因為,市面上有許多的工具都可以透過撰寫程式語言方式建置。有些還可以像是Javascript方式那樣簡單。下圖為手動建置和用Infrastructure As Code的區別

Configuration As Code


Configuration As Code的定義就透過自動化方式讓你運行的環境或是系統的配置是可以保持一致性。Configuration As Code主要也在於當環境啟動的初始狀態不同,也可以透過這樣方式讓環境配置達到一致性。下圖為手動配置和用Infrastructure As Code的區別

使用Infrastructure As Code和Configuration As Code的好處


Infrastructure as Code (IaC)Configuration as code兩者基本上不是互斥事件,反而是相輔相成的夥伴。就我看來就是把只是把原本黑箱的東西變成白箱,且共容易自動化與修改。大部分很少人做configuration as code,相反的,很多情況都會採用IaC方式描述要佈署的目標環境和資源的調配,或者是作為環境設定的腳本,因此,就會出現Infrastructure As Code等於Configuration As Code,這樣基本上是沒有太大問題,但是反過來就會感覺怪怪


假設我們單獨分開使用這兩個模式,要如何去定義說哪一種配置要用哪一種模式去定義,這邊可以用一個簡單的準則去定義,就是Infrastructure of Code就是建立和提供一個可以供應用程式運行的環境,像是建立一個DockerConfiguration As Code只是在這台運行環境上去配置該應用程式可以執行的設定參數或是環境參數


一般來說建立IaC有兩種方式,一種是用Function,另一種是用Procedual,前者是去定義該環境最終是長成怎樣子,當執行時,透過Script或定義檔去初始化環境達到可執行應用程式之狀態,後者則是透過Script逐步說明或是者說執行步驟,以達到該機器的最終可執行用程式之狀態


那麼在IaC中進行配置,會有兩種模式,一種是Push,另一種是Pull,這兩者區分顧名思義上,就是前者把環境從伺服器拉出去進行配置,後者則是直接在把配置參數從伺服器推進到環境內。通常取決團隊或是企業規範來決定

上一篇