十張圖帶你了解 實施DevOps的錦囊妙計

思科渠道微情報 思科聯天下

思科架構師 黃兆基

作者:黃兆基

在《誰說魚與熊掌不能兼得? 》一文中,我們介紹瞭如何運用DevOps大幅簡化複雜的手工操作,把從思科的異構多雲環境安全解決方案(原 Tetration)精準梳理出來的應用分組結構和安全訪問需求快速地部署到如ACI等基於意圖的網絡(IBN)上,讓企業在數字化轉型中,敏捷和安全能夠魚與熊掌兼得,開了個好頭。接下來的維護又如何呢?

前陣子為兩家大型企業構建IBN時,他們不約而同地選擇在網絡上使用大量的靜態路由(按:在沒有IBN或零信任的環境下,某些企業會通過配置靜態路由來控制數據的轉發);因此每次對這些路由修改的時候都小心翼翼,如臨大敵。 DevOps在這種場景便可以發揮它的作用,令每次變更的流程執行更加自動化。

然而,自動化也可導致另一個問題:如靜態路由的參數被錯誤地編入,自動化會令錯誤頓時大量複製。一般較理想的做法是把出參數放到數據文檔如Excel內,經第三方核對資料無誤,最後才讓程序讀取執行。

圖二:把靜態路由的參數先放到數據文檔中單獨核對,再讓程序讀取

图三:执行Python代码快速完成部署

可是用Python等語言去實現網絡配置對大部分網絡工程師來說比較陌生,且許多客戶也擔心編程本身會帶來其他問題,比如需長時間調試,將來維護會非常費時,很可能得不償失。

儘管有點懷疑,但在數字化轉型和多雲架構高速發展的驅使下,基礎設施即代碼(Infrastructure-As-Code,簡寫IaC)已成大趨勢;敏捷的需求不再局限於應用軟件本身;計算、存儲、網絡及其相關L4-L7的基礎設施同樣需要代碼化,企業網絡管理還是希望踏上DevOps之旅,關鍵是從何入手。

傳統的編程多是採取命令式(Imperative)方法;編碼時需要以一步一步的方式把所需要的對基礎設施的部署詳細按序編寫下來;步驟是否完整、排序是否正確直接影響部署,需要耗費大量時間精力來調試。最新的IaC部署多了一個使用名為聲明式編程 (Declarative Programming)的選擇;只需把終極部署以聲明式列出,其翻譯器在運行時便會把所需參數代入,然後透過應用程序接口向對應的基礎設施控制器發出指令完成部署。

Ansible或Terraform都是常見的聲明式編程語言。

圖四:以Ansible部署靜態路由為例

這類聲明式編程語言不單讓網絡工程師省去逐行編碼的煩惱,同時把所需要的部署參數也以聲明的形式在相關的變量(Variable)文件內列出,將來任何加減改動無須重寫代碼。

很多廠家都為他們的基礎設施提供聲明式編程語言支持,思科在這方面更可說是領頭羊。以Terraform為例,Cisco與HashiCorp深度合作,提供了高質量的Provider和Agent,比如下面就是利用Terraform在ACI上快速配置並隨意更改靜態路由而無須開發代碼的典型例子。

圖五:以Terraform聲明式編程定義所需要的靜態路由

图六:把需要的参数放在Terraform的变量文件内

图七:透过Terraform Apply执行完成配置

图八:APIC上显示配置已成功部署

将来如果有任何改动,只需简单地更新变量文件内的相关参数,再启动Terraform Apply一次便可以了。

比如我们需要把原来的路由从10.10.12.0/24改成为10.10.13.0/24。

我們只需要更新變量文件,然後再運行Terraform Apply一次。 Terraform的翻譯器會自動以先減後加的方法完成配置,無需任何編程改動。

圖九:Terraform上顯示將會啟動的加減操作

图十:改动完毕

APIC上显示的静态路由已改动完成,原来的10.10.12.0/24也被自动删去。

執行IaC除了從操作員終端啟動之外,也可以從雲平台由上而下部署到不同地方的私有云,再配合代碼託管和版本管理平台如GitHub等,可以完善整個CI/CD流程。

思科作為全球最大的中立多雲基礎架構提供商,各大IaC工具廠商和開源組織與思科有極強的合作意願,在後續文章中我們將會更深的體會到思科與它們深度合作後為多雲用戶創造的價值。