本文是「如何控制網路基礎設施」系列的第六篇文章。此系列所有文章內容及連結均可找到 .
拋開幾個話題後，我決定開始新的篇章。
稍後我會回到安全區。在這裡，我想討論一種簡單但有效的方法，我相信它以某種形式對許多人有用。這更像是一個關於自動化如何改變工程師生活的小故事。我們將討論使用模板。最後有一個我的項目列表，您可以在其中看到這裡描述的所有內容是如何運作的。
網路 DevOps
使用腳本建立配置、使用 GIT 控制 IT 基礎架構的變更、遠端「上傳」—當您考慮 DevOps 方法的技術實作時，這些想法首先出現。優點是顯而易見的。但不幸的是，也有缺點。
五年多前，當我們的開發人員向我們（網路人員）提出這些建議時，我們並不高興。
我必須說，我們繼承了一個相當雜亂的網絡，由大約 10 個不同供應商的設備組成。透過我們最喜歡的 cli 來配置一些東西很方便，但在其他方面我們更喜歡使用 GUI。此外，長期在「現場」設備上的工作教會了我們即時控制。例如，在進行更改時，我感覺直接透過 cli 工作會更舒服。這樣我就可以快速發現出現問題並回滾更改。這一切都與他們的想法有些矛盾。
還會出現其他問題，例如，不同版本的軟體介面可能會略有不同。這最終會導致您的腳本創建錯誤的“配置”。我不想用生產來「磨合」。
或者，如何了解配置命令是否正確應用以及出現錯誤時該怎麼辦？
我並不是想說所有這些問題都是無法解決的。只說“A”可能也可以說“B”，如果您想使用與開發中相同的流程進行變更控制，那麼除了生產之外，您還需要擁有開發和登台環境。那麼這個方法看起來就完成了。但要花多少錢呢？
但有一種情況是，缺點幾乎被消除，只剩下優點了。我說的是設計工作。
項目
在過去的兩年裡，我一直在參與一個為大型提供者建立資料中心的專案。我在這個專案中負責F5和Palo Alto。從思科的角度來看，這是「第三方設備」。
就我個人而言，這個專案有兩個不同的階段。
第一階段
第一年我無止盡地忙碌，我晚上和週末都工作。我無法抬起頭。來自管理層和客戶的壓力是強大且持續的。在日常工作中，我甚至無法嘗試優化流程。與其說是設備配置，不如說是設計文件的準備。
第一次測試已經開始，我會驚訝於其中出現了多少小錯誤和不準確之處。當然，一切正常，但是名稱中缺少一個字母，命令中缺少一行...測試一直在進行，我已經每天都在與錯誤、測試和文件作鬥爭。
這種情況持續了一年。據我了解，這個專案對每個人來說並不容易，但漸漸地，客戶變得越來越滿意，這使得僱用更多能夠自己承擔部分日常工作的工程師成為可能。
現在我們可以四處看看。
這就是第二階段的開始。
第二階段
我決定使該過程自動化。
我從當時與開發人員的交流中了解到（我們必須讚揚，我們有一個強大的團隊），文字格式雖然乍一看像是來自 DOS 作業系統世界的東西，但它有很多優點。
因此，例如，如果您想充分利用 GIT 及其所有衍生產品，則文字格式將很有用。我也想這麼做。
嗯，看起來您可以簡單地儲存配置或命令列表，但進行更改非常不方便。除此之外，設計過程中還有一個重要的任務。您應該有描述您的整體設計（低階設計）和具體實施（網路實施計劃）的文件。在這種情況下，使用模板看起來是一個非常合適的選擇。
所以，當使用YAML 和Jinja2 時，一個包含IP 位址、BGP AS 號等設定參數的YAML 檔案完美地履行了NIP 的作用，而Jinja2 範本則包含了與設計相對應的語法，也就是說，它本質上是一個LLD 的反映。
花了兩天時間學習了YAML和Jinja2。幾個很好的例子就足以理解它是如何運作的。然後大約花了兩週時間來創建與我們的設計相匹配的所有模板：Palo Alto 一周，F5 又一周。所有這些都發佈在公司 githab 上。
現在更改過程如下所示：
- 更改了 YAML 文件
- 使用範本建立設定檔（Jinja2）
- 保存在遠端儲存庫中
- 將建立的配置上傳到設備
- 我看到一個錯誤
- 更改了 YAML 檔案或 Jinja2 模板
- 使用範本建立設定檔（Jinja2）
- ...
顯然，一開始花了很多時間進行編輯，但一兩週後，這種情況就變得很少見了。
客戶希望更改命名約定，這是一個很好的測試和調試一切的機會。曾與 F5 合作過的人都了解情況的嚴峻性。但對我來說，這一切都很簡單。我更改了 YAML 檔案中的名稱，從裝置中刪除了整個配置，產生了一個新配置並上傳了它。一切，包括 bug 修復，花了 4 天：每種技術需要兩天。之後，我為下一階段做好了準備，即建立 DEV 和 Staging 資料中心。
開發和分期
舞台實際上完全複製了生產。 Dev 是一個主要基於虛擬硬體構建的高度精簡的副本。這是採用新方法的理想情況。如果把我所花的時間從整個過程中分離出來，那麼我認為這項工作只花了不超過2週的時間。主要的時間就是等待對方，一起尋找問題。第三方的實施幾乎沒有被其他人注意到。甚至還有時間學習一些東西並寫幾篇關於哈布雷的文章:)
總結
那麼，我到底有什麼底線呢？
- 要更改配置，我所需要做的就是更改帶有配置參數的簡單、結構清晰的 YAML 檔案。我從不更改 python 腳本，並且很少（僅當出現錯誤時）更改 Jinja2 heatlate
- 從文件的角度來看，這幾乎是理想的情況。您變更文件（YAML 檔案充當 NIP）並將此配置上傳到裝置。這樣您的文件始終是最新的
這一切導致了這樣一個事實：
- 錯誤率幾乎下降到0
- 90%的例行公事都消失了
- 實施速度顯著提高
支付、F5Y、ACY
我說幾個例子就足以理解它是如何運作的。
這是我在工作期間創建的內容的簡短（當然是修改過的）版本。
= 部署 PALO A從 Yaml = 來自 Yaml 的帕洛阿爾托
= 部署 F5 Y氨氮= F5 Yaml（即將推出）
= 部署 AC我來自 Y氨氮= F5 YAML
我將添加一些有關 ACY 的內容（不要與 ACI 混淆）。
那些與 ACI 合作過的人都知道，這個奇蹟（而且是以一種好的方式）絕對不是由網路工作者創造的:)。忘記你所知道的關於網路的一切——它對你沒有用！
雖然有點誇張，但大致傳達了我在過去三年與 ACI 合作中不斷感受到的感受。
在這種情況下，ACY 不僅是建立變更控制流程的機會（這在 ACI 的情況下尤其重要，因為它應該是資料中心的核心和最關鍵的部分），而且還為您提供了用於建立配置的使用者友善介面。
此專案的工程師使用 Excel 來設定 ACI，而不是 YAML，以達到完全相同的目的。當然，使用 Excel 有以下優點：
- 您的 NIP 在一個檔案中
- 美麗的標誌讓顧客賞心悅目
- 你可以使用一些excel工具
但有一個缺點，在我看來，它超過了優點。控制變更和協調團隊工作變得更加困難。
ACY 實際上是我用於第 3 方配置 ACI 的相同方法的應用程式。
來源： www.habr.com