用 Ansible 實現網路自動化

了解 Ansible 的功能，這是一個無代理的、可擴展的配置管理系統。

網路自動化

隨著 IT 行業的技術變化，從伺服器虛擬化到公有雲和私有雲，以及自服務能力、容器化應用、平台即服務（PaaS）交付，而一直以來落後的一個領域就是網路。

在過去的五年多，網路行業似乎有很多新的趨勢出現，它們中的很多被歸入到 軟體定義網路 software-defined networking （SDN）。

注意：

SDN 是新出現的一種構建、管理、操作和部署網路的方法。SDN 最初的定義是出於將控制層和數據層（包轉發）物理分離的需要，並且，解耦合的控制層必須管理好各自的設備。

如今，在 SDN 旗下已經有許多技術，包括 基於控制器的網路 controller-based networks 、網路設備 API、網路自動化、 白盒交換機 whitebox switche 、策略網路化、 網路功能虛擬化 Network Functions Virtualization （NFV）等等。

出於這篇報告的目的，我們參考 SDN 的解決方案作為我們的解決方案，其中包括一個網路控制器作為解決方案的一部分，並且提升了該網路的可管理性，但並不需要從數據層解耦控制層。

這些趨勢的之一是，網路設備的 API 作為管理和操作這些設備的一種方法而出現，真正地提供了機器對機器的通訊。當需要自動化和構建網路應用時 API 簡化了開發過程，在數據如何建模時提供了更多結構。例如，當啟用 API 的設備以 JSON/XML 返回數據時，它是結構化的，並且比返回原生文本信息 —— 需要手工去解析的僅支持命令行的設備更易於使用。

在 API 之前，用於配置和管理網路設備的兩個主要機制是命令行介面（CLI）和簡單網路管理協議（SNMP）。讓我們來了解一下它們，CLI 是一個設備的人機界面，而 SNMP 並不是為設備提供的實時編程介面。

幸運的是，因為很多供應商爭相為設備增加 API，有時候 只是因為 它被放到需求建議書（RFP）中，這就帶來了一個非常好的副作用 —— 支持網路自動化。當真正的 API 發布時，訪問設備內數據的過程，以及管理配置，就會被極大簡化，因此，我們將在本報告中對此進行評估。雖然使用許多傳統方法也可以實現自動化，比如，CLI/SNMP。

注意：

隨著未來幾個月或幾年（LCTT 譯註：本文發表於 2016 年）的網路設備更新，供應商的 API 無疑應該被做為採購網路設備（虛擬和物理）的關鍵決策標準而測試和使用。如果供應商提供一些庫或集成到自動化工具中，或者如果被用於一個開放的標準或協議，用戶應該知道數據是如何通過設備建模的，API 使用的傳輸類型是什麼。

總而言之，網路自動化，像大多數類型的自動化一樣，是為了更快地工作。工作的更快是好事，減少部署和配置改變的時間並不總是許多 IT 組織需要去解決的問題。

包括速度在內，我們現在看看這些各種類型的 IT 組織逐漸採用網路自動化的幾種原因。你應該注意到，同樣的原則也適用於其它類型的自動化。

簡化架構

今天，每個網路都是一片獨特的「雪花」，並且，網路工程師們為能夠通過一次性的網路改變來解決傳輸和應用問題而感到自豪，而這最終導致網路不僅難以維護和管理，而且也很難去實現自動化。

網路自動化和管理需要從一開始就包含到新的架構和設計中去部署，而不是作為一個二級或三級項目。哪個特性可以跨不同的供應商工作？哪個擴展可以跨不同的平台工作？當使用具體的網路設備平台時，API 類型或者自動化工程是什麼？當這些問題在設計過程之前得到答案，最終的架構將變成簡單的、可重複的、並且易於維護 和 自動化的，在整個網路中將很少啟用供應商專用的擴展。

確定的結果

在一個企業組織中， 改變審查會議 change review meeting 會評估面臨的網路變化、它們對外部系統的影響、以及回滾計劃。在人們通過 CLI 來執行這些 面臨的變化 的世界上，輸入錯誤的命令造成的影響是災難性的。想像一下，一個有 3 位、4 位、5位，或者 50 位工程師的團隊。每位工程師應對 面臨的變化 都有他們自己的獨特的方法。並且，在管理這些變化的期間，一個人使用 CLI 或者 GUI 的能力並不會消除和減少出現錯誤的機率。

使用經過驗證的和測試過的網路自動化可以幫助實現更多的可預測行為，並且使執行團隊更有可能實現確實性的結果，首次在保證任務沒有人為錯誤的情況下正確完成的道路上更進一步。

業務靈活性

不用說，網路自動化不僅為部署變化提供了速度和靈活性，而且使得根據業務需要去從網路設備中檢索數據的速度變得更快。自從伺服器虛擬化到來以後，伺服器和虛擬化使得管理員有能力在瞬間去部署一個新的應用程序。而且，隨著應用程序可以更快地部署，隨之浮現的問題是為什麼還需要花費如此長的時間配置一個 VLAN（虛擬區域網）、路由器、FW ACL（防火牆的訪問控制列表）或者負載均衡策略呢？

通過了解在一個組織內最常見的工作流和 為什麼 真正需要改變網路，部署如 Ansible 這樣的現代的自動化工具將使這些變得非常簡單。

這一章介紹了一些關於為什麼應該去考慮網路自動化的高級知識點。在下一節，我們將帶你去了解 Ansible 是什麼，並且繼續深入了解各種不同規模的 IT 組織的網路自動化的不同類型。

什麼是 Ansible？

Ansible 是存在於開源世界裡的一種最新的 IT 自動化和配置管理平台。它經常被拿來與其它工具如 Puppet、Chef 和 SaltStack 去比較。Ansible 作為一個由 Michael DeHaan 創建的開源項目出現於 2012 年，Michael DeHaan 也創建了 Cobbler 和 cocreated Func，它們在開源社區都非常流行。在 Ansible 開源項目創建之後不足 18 個月時間， Ansilbe 公司成立，並收到了六百萬美金 A 輪投資。該公司成為 Ansible 開源項目排名第一的貢獻者和支持者，並一直保持著。在 2015 年 10 月，Red Hat 收購了 Ansible 公司。

但是，Ansible 到底是什麼？

Ansible 是一個無需代理和可擴展的超級簡單的自動化平台。

讓我們更深入地了解它的細節，並且看一看那些使 Ansible 在行業內獲得廣泛認可的屬性。

簡單

Ansible 的其中一個吸引人的屬性是，使用它你 不 需要特定的編程技能。所有的指令，或者說任務都是自動化的，以一個標準的、任何人都可以理解的人類可讀的數據格式的文檔化。在 30 分鐘之內完成安裝和自動化任務的情況並不罕見！

例如，下列來自一個 Ansible 劇本 playbook 的任務用於去確保在一個 VLAN 存在於一個 Cisco Nexus 交換機中：

- nxos_vlan: vlan_id=100 name=web_vlan

你無需熟悉或寫任何代碼就可以明確地看出它將要做什麼！

注意：

這個報告的下半部分涉到 Ansible 術語（ 劇本 playbook 、 劇集 play 、 任務 task 、 模塊 module 等等）的細節。在我們使用 Ansible 進行網路自動化時，提及這些關鍵概念時我們會有一些簡短的示例。

無代理

如果你看過市面上的其它工具，比如 Puppet 和 Chef，你會發現，一般情況下，它們要求每個實現自動化的設備必須安裝特定的軟體。這種情況在 Ansible 上 並不需要，這就是為什麼 Ansible 是實現網路自動化的最佳選擇的主要原因。

這很好理解，那些 IT 自動化工具，包括 Puppet、Chef、CFEngine、SaltStack、和 Ansible，它們最初構建是為管理和自動化配置 Linux 主機，以跟得上部署的應用程序增長的步伐。因為 Linux 系統是被配置成自動化的，要安裝代理並不是一個技術難題。如果有的話，它也只會延誤安裝過程，因為，現在有 N 多個（你希望去實現自動化的）主機需要在它們上面部署軟體。

再加上，當使用代理時，它們需要的 DNS 和 NTP 配置更加複雜。這些都是大多數環境中已經配置好的服務，但是，當你希望快速地獲取一些東西或者只是簡單地想去測試一下它能做什麼的時候，它將極大地耽誤整個設置和安裝的過程。

由於本報告只是為介紹利用 Ansible 實現網路自動化，我們希望指出，Ansible 作為一個無代理平台，對於網路管理員來說，其比對系統管理員更具有吸引力。這是為什麼呢？

正如前面所說的那樣，對網路管理員來說，它是非常有吸引力的，Linux 操作系統是開源的，並且，任何東西都可以安裝在它上面。對於網路來說，卻並非如此，雖然它正在逐漸改變。如果我們更廣泛地部署網路操作系統，如 Cisco IOS，它就是這樣的一個例子，並且問一個問題， 「第三方軟體能否部署在基於 IOS （LCTT 譯註：此處的 IOS，指的是思科的網路操作系統 IOS）的平台上嗎？」毫無疑問，它的回答是 NO。

在過去的二十多年裡，幾乎所有的網路操作系統都是閉源的，並且，垂直整合到底層的網路硬體中。沒有供應商的支持，在一個網路設備中（路由器、交換機、負載均衡、防火牆、等等）載入一個代理並不那麼輕鬆。有一個像 Ansible 這樣的自動化平台，從頭開始去構建一個無代理、可擴展的自動化平台，就像是它專門為網路行業訂製的一樣。我們最終將開始減少並消除與網路的人工交互。

可擴展

Ansible 的可擴展性也非常的好。從開源、代碼開始在網路行業中發揮重要的作用時起，有一個可擴展的平台是必需的。這意味著如果供應商或社區不提供一個特定的特性或功能，開源社區、終端用戶、消費者、顧問，或者任何的人能夠 擴展 Ansible 來啟用一個給定的功能集。過去，網路供應商或者工具供應商通過一個 hook 去提供新的插件和集成。想像一下，使用一個像 Ansible 這樣的自動化平台，並且，你選擇的網路供應商發布了你 真正 需要的一個自動化的新特性。從理論上說，網路供應商或者 Ansible 可以發行一個新的插件去實現自動化這個獨特的特性，這是一件非常好的事情，從你的內部工程師到你的增值分銷商（VAR）或者你的顧問中的任何一個人，都可以去提供這種集成。

正如前面所說的那樣，Ansible 實際上是極具擴展性的，Ansible 最初就是為自動化應用程序和系統構建的。這是因為，Ansible 的可擴展性來自於其集成性是為網路供應商編寫的，包括但不限於 Cisco、Arista、Juniper、F5、HP、A10、Cumulus 和 Palo Alto Networks。

對於網路自動化，為什麼要使用 Ansible？

我們已經簡單了解除了 Ansible 是什麼，以及一些網路自動化的好處，但是，對於網路自動化，我們為什麼要使用 Ansible？

大家很清楚，使得 Ansible 成為如此偉大的一個自動化應用部署平台的許多原因已經被大家所提及了。但是，我們現在要深入一些，更多地關注於網路，並且繼續總結一些更需要注意的其它關鍵點。

無代理

在實現網路自動化的時候，無代理架構的重要性並不是重點強調的，特別是當它適用於現有的自動化設備時。如果，我們看一下當前網路中已經安裝的各種設備時，從 DMZ 和園區，到分支機構和數據中心，最大份額的設備 並不 具有最新 API 的設備。從自動化的角度來看，API 可以使做一些事情變得很簡單，像 Ansible 這樣的無代理平台有可能去自動化和管理那些 老舊（傳統） 的設備。例如，基於 CLI 的設備，它的工具可以被用於任何網路環境中。

注意：

如果僅支持 CLI 的設備已經集成進 Ansible，它的機制就像是，怎麼在設備上通過協議如 telnet、SSH 和 SNMP 去進行只讀訪問和讀寫操作。

作為一個獨立的網路設備，像路由器、交換機、和防火牆正在持續去增加 API 的支持，SDN 解決方案也正在出現。SDN 解決方案的其中一個常見主題是，它們都提供一個單點集成和策略管理，通常是以一個 SDN 控制器的形式出現。這對於 Cisco ACI、VMware NSX、Big Switch Big Cloud Fabric 和 Juniper Contrail，以及其它的 SDN 提供者，比如 Nuage、Plexxi、Plumgrid、Midokura 和 Viptela，是一個真實的解決方案。這甚至包含開源的控制器，比如 OpenDaylight。

所有的這些解決方案都簡化了網路管理，就像它們可以讓一個管理員開始從「box-by-box」管理（LCTT 譯者註：指的是單個設備挨個去操作的意思）遷移到網路範圍的管理。這是在正確方向上邁出的很大的一步，這些解決方案並不能消除在變更期間中人類犯錯的機率。例如，比起配置 N 個交換機，你可能需要去配置一個單個的 GUI，它需要很長的時間才能實現所需要的配置改變 —— 它甚至可能更複雜，畢竟，相對於一個 CLI，他們更喜歡 GUI！另外，你可能有不同類型的 SDN 解決方案部署在每個應用程序、網路、區域或者數據中心。

在需要自動化的網路中，對於配置管理、監視和數據收集，當行業開始向基於控制器的網路架構中遷移時，這些需求並不會消失。

大量的軟體定義網路中都部署有控制器，幾乎所有的控制器都 提供 expose 一個最新的 REST API。並且，因為 Ansible 是一個無代理架構，它實現自動化是非常簡單的，而不僅僅是對那些沒有 API 的傳統設備，但也有通過 REST API 的軟體定義網路解決方案，在所有的終端上不需要有額外的軟體（LCTT 譯註：指的是代理）。最終的結果是，使用 Ansible，無論有或沒有 API，可以使任何類型的設備都能夠自動化。

自由開源軟體（FOSS)

Ansible 是一個開源軟體，它的全部代碼在 GitHub 上都是公開可訪問的，使用 Ansible 是完全免費的。它可以在幾分鐘內完成安裝並為網路工程師提供有用的價值。Ansible 這個開源項目，或者 Ansible 公司，在它們交付軟體之前，你不會遇到任何一個銷售代表。那是顯而易見的事實，因為它是一個真正的開源項目，但是，作為開源的、社區驅動的軟體項目在網路行業中的使用是非常少的，但是，也在逐漸增加，我們想明確指出這一點。

同樣需要指出的一點是，Ansible, Inc. 也是一個公司，它也需要去賺錢，對嗎？雖然 Ansible 是開源的，它也有一個叫 Ansible Tower 的企業產品，它增加了一些特性，比如，基於規則的訪問控制（RBAC）、報告、 web UI、REST API、多租戶等等，（相比 Ansible）它更適合於企業去部署。並且，更重要的是，Ansible Tower 甚至可以最多在 10 台設備上 免費 使用，至少，你可以去體驗一下，它是否會為你的組織帶來好處，而無需花費一分錢，並且，也不需要與無數的銷售代表去打交道。

可擴展性

我們在前面說過，Ansible 主要是為部署 Linux 應用程序而構建的自動化平台，雖然從早期開始已經擴展到 Windows。需要指出的是，Ansible 開源項目並沒有「自動化網路基礎設施」的目標。事實上是，Ansible 社區更明白如何在底層的 Ansible 架構上更具靈活性和可擴展性，對於他們的自動化需要（包括網路）更容易成為一個 擴展 的 Ansible。在過去的兩年中，部署有許多的 Ansible 集成，許多是有行業獨立人士進行的，比如，Matt Oswalt、Jason Edelman、Kirk Byers、Elisa Jasinska、David Barroso、Michael Ben-Ami、Patrick Ogenstad 和 Gabriele Gerbino，也有網路系統供應商的領導者，比如，Arista、Juniper、Cumulus、Cisco、F5、和 Palo Alto Networks。

集成到已存在的 DevOps 工作流中

Ansible 在 IT 組織中被用於應用程序部署。它被用於需要管理部署、監視和管理各種類型的應用程序的運維團隊中。通過將 Ansible 集成到網路基礎設施中，當新應用程序到來或遷移後，它擴展了可能的範圍。而不是去等待一個新的頂架交換機（LCTT 譯註：TOR，一種數據中心設備接入的方式）的到來、去添加一個 VLAN、或者去檢查介面的速度/雙工，所有的這些以網路為中心的任務都可以被自動化，並且可以集成到 IT 組織內已經存在的工作流中。

冪等性

術語 冪等性 idempotency （讀作 item-potency）經常用於軟體開發的領域中，尤其是當使用 REST API 工作的時候，以及在 DevOps 自動化和配置管理框架的領域中，包括 Ansible。Ansible 的其中一個信念是，所有的 Ansible 模塊（集成的）應該是冪等的。那麼，對於一個模塊來說，冪等是什麼意思呢？畢竟，對大多數網路工程師來說，這是一個新的術語。

答案很簡單。冪等性的本質是允許定義的任務，運行一次或者上千次都不會在目標系統上產生不利影響，僅僅是一種一次性的改變。換句話說，如果有一個要做的改變去使系統進入到它期望的狀態，這種改變完成之後，並且，如果這個設備已經達到這種狀態，就不會再發生改變。這不像大多數傳統的定製腳本和拷貝、黏貼到那些終端窗口中的 CLI 命令。當相同的命令或者腳本在同一個系統上重複運行，（有時候）會出現錯誤。即使是粘貼一組命令到一個路由器中，也可能會遇到一些使你的其餘的配置失效的錯誤。好玩吧?

另外的例子是，如果你有一個配置 10 個 VLAN 的文件文件或者腳本，那麼 每次 運行這個腳本，相同的命令命令會被輸入 10 次。如果使用一個冪等的 Ansible 模塊，首先會從網路設備中採集已存在的配置，並且，每個新的 VLAN 被配置後會再次檢查當前配置。僅僅當這個新的 VLAN 需要被添加（或者，比如說改變 VLAN 名字）是一個變更，命令才會真實地推送到設備。

當一個技術越來越複雜，冪等性的價值就越高，在你修改的時候，你並不能注意到 已存在 的網路設備的狀態，而僅僅是從一個網路配置和策略角度去嘗試達到 期望的 狀態。

網路範圍的和臨時（Ad Hoc）的改變

用配置管理工具解決的其中一個問題是，配置「飄移」（當設備的期望配置逐漸漂移，或者改變，隨著時間的推移，手動改變和/或在一個環境中使用了多個不同的工具），事實上，這也是像 Puppet 和 Chef 所使用的地方。代理商 電聯 phone home 到前端伺服器，驗證它的配置，並且，如果需要變更，則改變它。這個方法是非常簡單的。如果有故障了，需要去排除怎麼辦？你通常需要跳過管理系統，直接連到設備，找到並修復它，然後，馬上離開，對不對？果然，在下次當代理電連回來，這個修復問題的改變被覆蓋了（基於主/前端伺服器是怎麼配置的）。在高度自動化的環境中，一次性的改變應該被限制，但是，仍然允許使用它們（LCTT 譯註：指的是一次性改變）的工具是非常有價值的。正如你想到的，其中一個這樣的工具是 Ansible。

因為 Ansible 是無代理的，這裡並沒有一個默認的推送或者拉取去防止配置漂移。自動化任務被定義在 Ansible <ruby劇本playbook中，當使用 Ansible 時，它讓用戶去運行劇本。如果劇本在一個給定的時間間隔內運行，並且你沒有用 Ansible Tower，你肯定知道任務的執行頻率；如果你只是在終端提示符下使用一個原生的 Ansible 命令行，那麼該劇本就運行一次，並且僅運行一次。

預設運行一次的劇本對網路工程師是很具有吸引力的，讓人欣慰的是，在設備上手動進行的改變不會自動被覆蓋。另外，當需要的時候，一個劇本所運行的設備範圍很容易被改變，即使是對一個單個設備進行自動化的單次變更，Ansible 仍然可以用，設備的 範圍 由一個被稱為 Ansible 清單 inventory 的文件決定；這個清單可以是一台設備或者是一千台設備。

下面展示的一個清單文件示例，它定義了兩組共六台設備：

[core-switches]
dc-core-1
dc-core-2

[leaf-switches]
leaf1
leaf2
leaf3
leaf4

為了自動化所有的主機，你的劇本中的 劇集 play 定義的一個片段看起來應該是這樣的：

hosts: all

並且，要只自動化一個葉子節點交換機，它看起來應該像這樣：

hosts: leaf1

這是一個核心交換機：

hosts: core-switches

注意

正如前面所說的那樣，這個報告的後面部分將詳細介紹劇本、劇集、和清單。

因為能夠很容易地對一台設備或者 N 台設備進行自動化，所以在需要對這些設備進行一次性變更時，Ansible 成為了最佳的選擇。在網路範圍內的變更它也做的很好：可以是關閉給定類型的所有介面、配置介面描述、或者是在一個跨企業園區布線的網路中添加 VLAN。

使用 Ansible 實現網路任務自動化

這個報告從兩個方面逐漸深入地講解一些技術。第一個方面是圍繞 Ansible 架構和它的細節，第二個方面是，從一個網路的角度，講解使用 Ansible 可以完成什麼類型的自動化。在這一章中我們將帶你去詳細了解第二方面的內容。

自動化一般被認為是速度快，但是，考慮到一些任務並不要求速度，這就是為什麼一些 IT 團隊沒有認識到自動化的價值所在。VLAN 配置是一個非常好的例子，因為，你可能會想，「創建一個 VLAN 到底有多快？一般情況下每天添加多少個 VLAN？我真的需要自動化嗎？」

在這一節中，我們專註於另外幾種有意義的自動化任務，比如，設備準備、數據收集、報告和遵從情況。但是，需要注意的是，正如我們前面所說的，自動化為你、你的團隊、以及你的精確的更可預測的結果和更多的確定性，提供了更快的速度和敏捷性。

設備準備

為網路自動化開始使用 Ansible 的最容易也是最快的方法是，為設備的最初投入使用創建設備配置文件，並且將配置文件推送到網路設備中。

如果我們去完成這個過程，它將分解為兩步，第一步是創建一個配置文件，第二步是推送這個配置到設備中。

首先，我們需要去從供應商配置文件的底層專用語法（CLI）中解耦 輸入。這意味著我們需要對配置參數中分離出文件和值，比如，VLAN、域信息、介面、路由、和其它的內容等等，然後，當然是一個配置的模塊文件。在這個示例中，這裡有一個標準模板，它可以用於所有設備的初始部署。Ansible 將幫助提供配置模板中需要的輸入和值之間的部分。幾秒鐘之內，Ansible 可以生成數百個可靠的和可預測的配置文件。

讓我們快速的看一個示例，它使用當前的配置，並且分解它到一個模板和單獨的一個（作為一個輸入源的）變數文件中。

這是一個配置文件片斷的示例：

hostname leaf1
ip domain-name ntc.com
!
vlan 10
   name web
!
vlan 20
   name app
!
vlan 30
   name db
!
vlan 40
   name test
!
vlan 50
   name misc

如果我們提取輸入值，這個文件將被轉換成一個模板。

注意：

Ansible 使用基於 Python 的 Jinja2 模板化語言，因此，這個被命名為 leaf.j2 的文件是一個 Jinja2 模板。

注意，下列的示例中，雙大括弧（{{}}） 代表一個變數。

模板看起來像這些，並且給它命名為 leaf.j2：

!
hostname {{ inventory_hostname }}
ip domain-name {{ domain_name }}
!
!
{% for vlan in vlans %}
vlan {{ vlan.id }}
  name {{ vlan.name }}
{% endfor %}
!

因為雙大括弧代表變數，並且，我們看到這些值並不在模板中，所以它們需要將值保存在一個地方。值被保存在一個變數文件中。正如前面所說的，一個相應的變數文件看起來應該是這樣的：

hostname: leaf1
domain_name: ntc.com
vlans:
  - { id: 10, name: web }
  - { id: 20, name: app }
  - { id: 30, name: db }
  - { id: 40, name: test }
  - { id: 50, name: misc }

這意味著，如果管理 VLAN 的團隊希望在網路設備中添加一個 VLAN，很簡單，他們只需要在變數文件中改變它，然後，使用 Ansible 中一個叫 template 的模塊，去重新生成一個新的配置文件。這整個過程也是冪等的；僅僅是在模板或者值發生改變時，它才會去生成一個新的配置文件。

一旦配置文件生成，它需要去 推送 到網路設備。推送配置文件到網路設備使用一個叫做 napalm_install_config的開源的 Ansible 模塊。

接下來的示例是一個 構建並推送 一個配置文件到網路設備的簡單劇本。同樣地，該劇本使用一個名叫 template 的模塊去構建配置文件，然後使用一個名叫 napalm_install_config 的模塊去推送它們，並且激活它作為設備上運行的新的配置文件。

雖然沒有詳細解釋示例中的每一行，但是，你仍然可以看明白它們實際上做了什麼。

注意：

下面的劇本介紹了新的概念，比如，內置變數 inventory_hostname。這些概念包含在 Ansible 術語和入門 中。

  - name: BUILD AND PUSH NETWORK CONFIGURATION FILES
    hosts: leaves
    connection: local
    gather_facts: no

    tasks:
      - name: BUILD CONFIGS
      template:
        src=templates/leaf.j2
        dest=configs/{{inventory_hostname }}.conf

      - name: PUSH CONFIGS
        napalm_install_config:
          hostname={{ inventory_hostname }}
          username={{ un }}
          password={{ pwd }}
          dev_os={{ os }}
          config_file=configs/{{ inventory_hostname }}.conf
          commit_changes=1
          replace_config=0

這個兩步的過程是一個使用 Ansible 進行網路自動化入門的簡單方法。通過模板簡化了你的配置，構建配置文件，然後，推送它們到網路設備 — 因此，被稱為 BUILD 和 PUSH 方法。

注意：

像這樣的更詳細的例子，請查看 Ansible 網路集成。

數據收集和監視

監視工具一般使用 SNMP —— 這些工具拉取某些管理信息庫（MIB），然後給監視工具返回數據。基於返回的數據，它可能多於也可能少於你真正所需要的數據。如果介面基於返回的數據統計你正在拉取的內容，你可能會返回在 show interface 命令中顯示的計數器。如果你僅需要 interface resets 並且，希望去看到與重置相關的鄰接 CDP/LLDP 的介面，那該怎麼做呢？當然，這也可以使用當前的技術；可以運行多個顯示命令去手動解析輸出信息，或者，使用基於 SNMP 的工具，在 GUI 中切換不同的選項卡（Tab）找到真正你所需要的數據。Ansible 怎麼能幫助我們去完成這些工作呢？

由於 Ansible 是完全開源並且是可擴展的，它可以精確地去收集和監視所需要的計數器或者值。這可能需要一些預先的定製工作，但是，最終這些工作是非常有價值的。因為採集的數據是你所需要的，而不是供應商提供給你的。Ansible 也提供了執行某些條件任務的直觀方法，這意味著基於正在返回的數據，你可以執行子任務，它可以收集更多的數據或者產生一個配置改變。

網路設備有 許多 統計和隱藏在裡面的臨時數據，而 Ansible 可以幫你提取它們。

你甚至可以在 Ansible 中使用前面提到的 SNMP 的模塊，模塊的名字叫 snmp_device_version。這是在社區中存在的另一個開源模塊：

  - name: GET SNMP DATA
    snmp_device_version:
      host=spine
      community=public
      version=2c

運行前面的任務返回非常多的關於設備的信息，並且添加一些級別的發現能力到 Ansible中。例如，那個任務返回下列的數據：

{"ansible_facts": {"ansible_device_os": "nxos", "ansible_device_vendor": "cisco", "ansible_device_version": "7.0(3)I2(1)"}, "changed": false}

你現在可以決定某些事情，而不需要事先知道是什麼類型的設備。你所需要知道的僅僅是設備的只讀通訊字元串。

遷移

從一個平台遷移到另外一個平台，可能是從同一個供應商或者是從不同的供應商，遷移從來都不是件容易的事。供應商可能提供一個腳本或者一個工具去幫助你遷移。Ansible 可以被用於去為所有類型的網路設備構建配置模板，然後，操作系統用這個方法去為所有的供應商生成一個配置文件，然後作為一個（通用數據模型的）輸入設置。當然，如果有供應商專用的擴展，它也是會被用到的。這種靈活性不僅對遷移有幫助，而且也可以用於 災難恢復 disaster recovery （DR），它在生產系統中不同的交換機型號之間和災備數據中心中是經常使用的，即使是在不同的供應商的設備上。

配置管理

正如前面所說的，配置管理是最常用的自動化類型。Ansible 可以很容易地做到創建 角色 role 去簡化基於任務的自動化。從更高的層面來看，角色是指針對一個特定設備組的可重用的自動化任務的邏輯分組。關於角色的另一種說法是，認為角色就是相關的 工作流 workflow 。首先，在開始自動化添加值之前，需要理解工作流和過程。不論是開始一個小的自動化任務還是擴展它，理解工作流和過程都是非常重要的。

例如，一組自動化地配置路由器和交換機的任務是非常常見的，並且它們也是一個很好的起點。但是，配置在哪台網路設備上？配置的 IP 地址是什麼？或許需要一個 IP 地址管理方案？一旦用一個給定的功能分配了 IP 地址並且已經部署，DNS 也更新了嗎？DHCP 的範圍需要創建嗎？

你可以看到工作流是怎麼從一個小的任務開始，然後逐漸擴展到跨不同的 IT 系統？因為工作流持續擴展，所以，角色也一樣（持續擴展）。

遵從性

和其它形式的自動化工具一樣，用任何形式的自動化工具產生配置改變都被視為風險。手工去產生改變可能看上去風險更大，正如你看到的和親身經歷過的那樣，Ansible 有能力去做自動數據收集、監視、和配置構建，這些都是「只讀的」和「低風險」的動作。其中一個 低風險 使用案例是，使用收集的數據進行配置遵從性檢查和配置驗證。部署的配置是否滿足安全要求？是否配置了所需的網路？協議 XYZ 禁用了嗎？因為每個模塊、或者用 Ansible 返回數據的整合，它只是非常簡單地 聲明 那些事是 TRUE 還是 FALSE。然後接著基於 它 是 TRUE 或者是 FALSE， 接著由你決定應該發生什麼 —— 或許它只是被記錄下來，或者，也可能執行一個複雜操作。

報告

我們現在知道，Ansible 也可以用於去收集數據和執行遵從性檢查。Ansible 可以根據你想要做的事情去從設備中返回和收集數據。或許返回的數據成為其它的任務的輸入，或者你想去用它創建一個報告。從模板中生成報告，並將真實的數據插入到模板中，創建和使用報告模板的過程與創建配置模板的過程是相同的。

從一個報告的角度看，這些模板或許是純文本文件，就像是在 GitHub 上看到的 markdown 文件、放置在 Web 伺服器上的 HTML 文件，等等。用戶有權去創建一個她希望的報告類型，插入她所需要的真實數據到報告中。

創建報告的用處很多，不僅是為行政管理，也為了運營工程師，因為它們通常有雙方都需要的不同指標。

Ansible 怎麼工作

從一個網路自動化的角度理解了 Ansible 能做什麼之後，我們現在看一下 Ansible 是怎麼工作的。你將學習到從一個 Ansible 管理主機到一個被自動化的節點的全部通訊流。首先，我們回顧一下，Ansible 是怎麼 開箱即用 out of the box 的，然後，我們看一下 Ansible 怎麼去做到的，具體說就是，當網路設備自動化時，Ansible 模塊是怎麼去工作的。

開箱即用

到目前為止，你已經明白了，Ansible 是一個自動化平台。實際上，它是一個安裝在一台單個伺服器上或者企業中任何一位管理員的筆記本中的輕量級的自動化平台。當然，（安裝在哪裡？）這是由你來決定的。在基於 Linux 的機器上，使用一些實用程序（比如 pip、apt、和 yum）安裝 Ansible 是非常容易的。

注意：

在本報告的其餘部分，安裝 Ansible 的機器被稱為 控制主機 control host 。

控制主機將執行定義在 Ansible 的 劇本 playbook （不用擔心，稍後我們將講到劇本和其它的 Ansible 術語）中的所有自動化任務。現在，我們只需要知道，一個劇本是簡單的一組自動化任務和在給定數量的主機上執行的指令。

當一個劇本創建之後，你還需要去定義它要自動化的主機。映射一個劇本和要自動化運行的主機，是通過一個被稱為 Ansible 清單 inventory 的文件。這是一個前面展示的示例，但是，這裡是同一個清單文件的另外兩個組：cisco 和 arista：

[cisco]
nyc1.acme.com
nyc2.acme.com

[arista]
sfo1.acme.com
sfo2.acme.com

注意：

你也可以在清單文件中使用 IP 地址，而不是主機名。對於這樣的示例，主機名將是通過 DNS 可解析的。

正如你所看到的，Ansible 清單文件是一個文本文件，它列出了主機和主機組。然後，你可以在劇本中引用一個具體的主機或者組，以此去決定對給定的 劇集 play 和劇本在哪台主機上進行自動化。下面展示了兩個示例。

展示的第一個示例它看上去像是，你想去自動化 cisco 組中所有的主機，而展示的第二個示例只對 nyc1.acme.com 主機進行自動化：

  - name: TEST PLAYBOOK
    hosts: cisco

    tasks:
      - TASKS YOU WANT TO AUTOMATE

  - name: TEST PLAYBOOK
    hosts: nyc1.acme.com

    tasks:
      - TASKS YOU WANT TO AUTOMATE

現在，我們已經理解了基本的清單文件，我們可以看一下（在控制主機上的）Ansible 是怎麼與 開箱即用 的設備通訊的，和在 Linux 終端上自動化的任務。這裡需要明白一個重要的觀點就是，需要去自動化的網路設備通常是不一樣的。（LCTT 譯註：指的是設備的類型、品牌、型號等等）

Ansible 對基於 Linux 的系統去開箱即用自動化工作有兩個要求。它們是 SSH 和 Python。

首先，終端必須支持 SSH 傳輸，因為 Ansible 使用 SSH 去連接到每個目標節點。因為 Ansible 支持一個可拔插的連接架構，也有各種類型的插件去實現不同類型的 SSH。

第二個要求是，Ansible 並不要求在目標節點上預先存在一個 代理，Ansible 並不要求一個軟體代理，它僅需要一個內置的 Python 執行引擎。這個執行引擎用於去執行從 Ansible 管理主機發送到被自動化的目標節點的 Python 代碼。

如果我們詳細解釋這個開箱即用工作流，它將分解成如下的步驟：

1. 當執行一個 Ansible 劇集時，控制主機使用 SSH 連接到基於 Linux 的目標節點。
2. 對於每個任務，也就是說，Ansible 模塊將在這個劇集中被執行，通過 SSH 發送 Python 代碼並直接在遠程系統中執行。
3. 在遠程系統上運行的每個 Ansible 模塊將返回 JSON 數據到控制主機。這些數據包含有信息，比如，配置改變、任務成功/失敗、以及其它模塊特定的數據。
4. JSON 數據返回給 Ansible，然後被用於去生成報告，或者被用作接下來模塊的輸入。
5. 在劇集中為每個任務重複第 3 步。
6. 在劇本中為每個劇集重複第 1 步。

是不是意味著每個網路設備都可以被 Ansible 開箱即用？因為它們也都支持 SSH，確實，網路設備都支持 SSH，但是，第一個和第二要求的組合限制了網路設備可能的功能。

剛開始時，大多數網路設備並不支持 Python，因此，使用默認的 Ansible 連接機制是無法進行的。換句話說，在過去的幾年裡，供應商在幾個不同的設備平台上增加了 Python 支持。但是，這些平台中的大多數仍然缺乏必要的集成，以允許 Ansible 去直接通過 SSH 訪問一個 Linux shell，並以適當的許可權去拷貝所需的代碼、創建臨時目錄和文件、以及在設備中執行代碼。儘管 Ansible 中所有的這些部分都可以在基於 Linux 的網路設備上使用 SSH/Python 在本地運行，它仍然需要網路設備供應商去更進一步開放他們的系統。

注意：

值的注意的是，Arista 確實也提供了原生的集成，因為它可以無需 SSH 用戶，直接進入到一個 Linux shell 中訪問 Python 引擎，它可以允許 Ansible 去使用其默認連接機制。因為我們調用了 Arista，我們也需要著重強調與 Ansible 默認連接機制一起工作的 Cumulus。這是因為 Cumulus Linux 是原生 Linux，並且它並不需要為 Cumulus Linux 操作系統使用供應商 API。

Ansible 網路集成

前面的節講到過 Ansible 默認的工作方式。我們看一下，在開始一個 劇集 之後，Ansible 是怎麼去設置一個到設備的連接、通過拷貝 Python 代碼到設備、運行代碼、和返回結果給 Ansible 控制主機來執行任務。

在這一節中，我們將看一看，當使用 Ansible 進行自動化網路設備時都做了什麼。正如前面講過的，Ansible 是一個可拔插的連接架構。對於 大多數 的網路集成， connection 參數設置為 local。在劇本中大多數的連接類型都設置為 local，如下面的示例所展示的：

  - name: TEST PLAYBOOK
    hosts: cisco
    connection: local

    tasks:
      - TASKS YOU WANT TO AUTOMATE

注意在劇集中是怎麼定義的，這個示例增加 connection 參數去和前面節中的示例進行比較。

這告訴 Ansible 不要通過 SSH 去連接到目標設備，而是連接到本地機器運行這個劇本。基本上，這是把連接職責委託給劇本中 任務 task 節中使用的真實的 Ansible 模塊。每個模塊類型的委託權利允許這個模塊在必要時以各種形式去連接到設備。這可能是 Juniper 和 HP Comware7 的 NETCONF、Arista 的 eAPI、Cisco Nexus 的 NX-API、或者甚至是基於傳統系統的 SNMP，它們沒有可編程的 API。

注意：

網路集成在 Ansible 中是以 Ansible 模塊的形式帶來的。儘管我們持續使用術語來吊你的胃口，比如，劇本、劇集、任務、和講到的關鍵概念模塊，這些術語中的每一個都會在 Ansible 術語和入門 和 動手實踐使用 Ansible 去進行網路自動化 中詳細解釋。

讓我們看一看另外一個劇本的示例：

  - name: TEST PLAYBOOK
    hosts: cisco
    connection: local

    tasks:
      - nxos_vlan: vlan_id=10 name=WEB_VLAN

你注意到了嗎，這個劇本現在包含一個任務，並且這個任務使用了 nxos_vlan 模塊。nxos_vlan 模塊是一個 Python 文件，並且，在這個文件中它是使用 NX-API 連接到 Cisco 的 NX-OS 設備。可是，這個連接可能是使用其它設備 API 設置的，這就是為什麼供應商和用戶像我們這樣能夠去建立自己的集成的原因。集成（模塊）通常是以 每特性 per-feature 為基礎完成的，雖然，你已經看到了像 napalm_install_config 這樣的模塊，它們也可以被用來 推送 一個完整的配置文件。

主要區別之一是使用的默認連接機制，Ansible 啟動一個持久的 SSH 連接到設備，並且對於一個給定的劇集而已該連接將持續存在。當在一個模塊中發生連接設置和拆除時，與許多使用 connection=local 的網路模塊一樣，對發生在劇集級別上的 每個 任務，Ansible 將登入/登出設備。

而在傳統的 Ansible 形式下，每個網路模塊返回 JSON 數據。僅有的區別是相對於目標節點，數據的推取發生在本地的 Ansible 控制主機上。相對於 每供應商 per vendor 和模塊類型，數據返回到劇本，但是作為一個示例，許多的 Cisco NX-OS 模塊返回已存在的狀態、建議狀態、和最終狀態，以及發送到設備的命令（如果有的話）。

作為使用 Ansible 進行網路自動化的開始，最重要的是，為 Ansible 的連接設備/拆除過程，記著去設置連接參數為 local，並且將它留在模塊中。這就是為什麼模塊支持不同類型的供應商平台，它將與設備使用不同的方式進行通訊。

Ansible 術語和入門

這一章我們將介紹許多 Ansible 的術語和報告中前面部分出現過的關鍵概念。比如， 清單文件 inventory file 、 劇本 playbook 、 劇集 play 、 任務 task 和 模塊 module 。我們也會去回顧一些其它的概念，這些術語和概念對我們學習使用 Ansible 去進行網路自動化非常有幫助。

在這一節中，我們將引用如下的一個簡單的清單文件和劇本的示例，它們將在後面的章節中持續出現。

清單示例 ：

# sample inventory file
# filename inventory

[all:vars]
user=admin
pwd=admin

[tor]
rack1-tor1   vendor=nxos
rack1-tor2   vendor=nxos
rack2-tor1   vendor=arista
rack2-tor2   vendor=arista

[core]
core1
core2

劇本示例 ：

# sample playbook
# filename site.yml

  - name: PLAY 1 - Top of Rack (TOR) Switches
    hosts: tor
    connection: local

    tasks:
      - name: ENSURE VLAN 10 EXISTS ON CISCO TOR SWITCHES
        nxos_vlan:
          vlan_id=10
          name=WEB_VLAN
          host={{ inventory_hostname }}
          username=admin
          password=admin
        when: vendor == "nxos"

      - name: ENSURE VLAN 10 EXISTS ON ARISTA TOR SWITCHES
        eos_vlan:
          vlanid=10
          name=WEB_VLAN
          host={{ inventory_hostname }}
          username={{ user }}
          password={{ pwd }}
        when: vendor == "arista"

  - name: PLAY 2 - Core (TOR) Switches
    hosts: core
    connection: local

    tasks:
      - name: ENSURE VLANS EXIST IN CORE
        nxos_vlan:
          vlan_id={{ item }}
          host={{ inventory_hostname }}
          username={{ user }}
          password={{ pwd }}
        with_items:
          - 10
          - 20
          - 30
          - 40
          - 50

清單文件

使用一個清單文件，比如前面提到的那個，允許我們去為自動化任務指定主機、和使用每個劇集頂部節中（如果存在）的參數 hosts 所引用的主機/組指定的主機組。

它也可能在一個清單文件中存儲變數。如這個示例中展示的那樣。如果變數在同一行視為一台主機，它是一個具體主機變數。如果變數定義在方括弧中（[ ]），比如，[all:vars]，它的意思是指變數在組中的範圍 all，它是一個默認組，包含了清單文件中的 所有 主機。

注意：

清單文件是使用 Ansible 開始自動化的快速方法，但是，你應該已經有一個真實的網路設備源，比如一個網路管理工具或者 CMDB，它可以去創建和使用一個動態的清單腳本，而不是一個靜態的清單文件。

劇本

劇本是去運行自動化網路設備的頂級對象。在我們的示例中，它是 site.yml 文件，如前面的示例所展示的。一個劇本使用 YAML 去定義一組自動化任務，並且，每個劇本由一個或多個劇集組成。這類似於一個橄欖球的劇本。就像在橄欖球賽中，團隊有劇集組成的劇本，Ansible 的劇本也是由劇集組成的。

注意：

YAML 是一種被所有編程語言支持的數據格式。YAML 本身就是 JSON 的超集，並且，YAML 文件非常易於識別，因為它總是三個破折號（連字元）開始，比如，---。

劇集

一個 Ansible 劇本可以存在一個或多個劇集。在前面的示例中，它在劇本中有兩個劇集。每個劇集開始的地方都有一個 頭部，它定義了具體的參數。

示例中兩個劇集都定義了下面的參數：

name

文件 PLAY 1 - Top of Rack (TOR) Switches 是任意內容的，它在劇本運行的時候，去改善劇本運行和報告期間的可讀性。這是一個可選參數。

hosts

正如前面講過的，這是在特定的劇集中要去進行自動化的主機或主機組。這是一個必需參數。

connection

正如前面講過的，這是劇集連接機制的類型。這是個可選參數，但是，對於網路自動化劇集，一般設置為 local。

每個劇集都是由一個或多個任務組成。

任務

任務是以聲明的方式去表示自動化的內容，而不用擔心底層的語法或者操作是怎麼執行的。

在我們的示例中，第一個劇集有兩個任務。每個任務確保存在 10 個 VLAN。第一個任務是為 Cisco Nexus 設備的，而第二個任務是為 Arista 設備的：

tasks:
  - name: ENSURE VLAN 10 EXISTS ON CISCO TOR SWITCHES
    nxos_vlan:
      vlan_id=10
      name=WEB_VLAN
      host={{ inventory_hostname }}
      username=admin
      password=admin
    when: vendor == "nxos"

任務也可以使用 name 參數，就像劇集一樣。和劇集一樣，文本內容是任意的，並且當劇本運行時顯示，去改善劇本運行和報告期間的可讀性。它對每個任務都是可選參數。

示例任務中的下一行是以 nxos_vlan 開始的。它告訴我們這個任務將運行一個叫 nxos_vlan 的 Ansible 模塊。

現在，我們將進入到模塊中。

模塊

在 Ansible 中理解模塊的概念是至關重要的。雖然任何編輯語言都可以用來寫 Ansible 模塊，只要它們能夠返回 JSON 鍵/值對即可，但是，幾乎所有的模塊都是用 Python 寫的。在我們示例中，我們看到有兩個模塊被運行： nxos_vlan 和 eos_vlan。這兩個模塊都是 Python 文件；而事實上，在你不能看到劇本的時候，真實的文件名分別是 eos_vlan.py 和 nxos_vlan.py。

讓我們看一下前面的示例中第一個劇集中的第一個任務：

  - name: ENSURE VLAN 10 EXISTS ON CISCO TOR SWITCHES
    nxos_vlan:
      vlan_id=10
      name=WEB_VLAN
      host={{ inventory_hostname }}
      username=admin
      password=admin
    when: vendor == "nxos"

這個任務運行 nxos_vlan，它是一個自動配置 VLAN 的模塊。為了使用這個模塊，包含它，你需要為設備指定期望的狀態或者配置策略。這個示例中的狀態是：VLAN 10 將被配置一個名字 WEB_VLAN，並且，它將被自動配置到每個交換機上。我們可以看到，使用 vlan_id 和 name 參數很容易做到。模塊中還有三個其它的參數，它們分別是：host、username、和 password：

host

這是將要被自動化的主機名（或者 IP 地址）。因為，我們希望去自動化的設備已經被定義在清單文件中，我們可以使用內置的 Ansible 變數 inventory_hostname。這個變數等價於清單文件中的內容。例如，在第一個循環中，在清單文件中的主機是 rack1-tor1，然後，在第二個循環中，它是 rack1-tor2。這些名字是進入到模塊的，並且包含在模塊中的，在每個名字到 IP 地址的解析中，都發生一個 DNS 查詢。然後與這個設備進行通訊。

username

用於登入到交換機的用戶名。

password

用於登入到交換機的密碼。

示例中最後的片斷部分使用了一個 when 語句。這是在一個劇集中使用的 Ansible 的執行條件任務。正如我們所了解的，在這個劇集的 tor 組中有多個設備和設備類型。使用 when 基於任意標準去提供更多的選擇。這裡我們僅自動化 Cisco 設備，因為，我們在這個任務中使用了 nxos_vlan 模塊，在下一個任務中，我們僅自動化 Arista 設備，因為，我們使用了 eos_vlan 模塊。

注意：

這並不是區分設備的唯一方法。這裡僅是演示如何使用 when，並且可以在清單文件中定義變數。

在清單文件中定義變數是一個很好的開端，但是，如果你繼續使用 Ansible，你將會為了擴展性、版本控制、對給定文件的改變最小化而去使用基於 YAML 的變數。這也將簡化和改善清單文件和每個使用的變數的可讀性。在設備準備的構建/推送方法中講過一個變數文件的示例。

在最後的示例中，關於任務有幾點需要去搞清楚：

• 劇集 1 任務 1 展示了硬編碼了 username 和 password 作為參數進入到具體的模塊中（nxos_vlan）。
• 劇集 1 任務 1 和 劇集 2 在模塊中使用了變數，而不是硬編碼它們。這掩飾了 username 和 password 參數，但是，需要值得注意的是，（在這個示例中）這些變數是從清單文件中提取出現的。
• 劇集 1 中為進入到模塊中的參數使用了一個 水平的 的 key=value 語法，雖然劇集 2 使用了垂直的 key=value 語法。它們都工作的非常好。你也可以使用垂直的 YAML 「key: value」 語法。
• 最後的任務也介紹了在 Ansible 中怎麼去使用一個循環。它通過使用 with_items 來完成，並且它類似於一個 for 循環。那個特定的任務是循環進入五個 VLAN 中去確保在交換機中它們都存在。注意：它也可能被保存在一個外部的 YAML 變數文件中。還需要注意的一點是，不使用 with_items 的替代方案是，每個 VLAN 都有一個任務 —— 如果這樣做，它就失去了彈性！

動手實踐使用 Ansible 去進行網路自動化

在前面的章節中，提供了 Ansible 術語的一個概述。它已經覆蓋了大多數具體的 Ansible 術語，比如劇本、劇集、任務、模塊和清單文件。這一節將繼續提供示例去講解使用 Ansible 實現網路自動化，而且將提供在不同類型的設備中自動化工作的模塊的更多細節。示例中的將要進行自動化設備由多個供應商提供，包括 Cisco、Arista、Cumulus、和 Juniper。

在本節中的示例，假設的前提條件如下：

• Ansible 已經安裝。
• 在設備中（NX-API、eAPI、NETCONF）適合的 APIs 已經啟用。
• 用戶在系統上有通過 API 去產生改變的適當許可權。
• 所有的 Ansible 模塊已經在系統中存在，並且也在庫的路徑變數中。

注意：

可以在 ansible.cfg 文件中設置模塊和庫路徑。在你運行一個劇本時，你也可以使用 -M 標誌從命令行中去改變它。

在本節中示例使用的清單如下。（刪除了密碼，IP 地址也發生了變化）。在這個示例中，（和前面的示例一樣）某些主機名並不是完全合格域名（FQDN）。

清單文件

[cumulus]
cvx  ansible_ssh_host=1.2.3.4 ansible_ssh_pass=PASSWORD

[arista]
veos1

[cisco]
nx1  hostip=5.6.7.8 un=USERNAME pwd=PASSWORD

[juniper]
vsrx hostip=9.10.11.12 un=USERNAME pwd=PASSWORD

注意：

正如你所知道的，Ansible 支持將密碼存儲在一個加密文件中的功能。如果你想學習關於這個特性的更多內容，請查看在 Ansible 網站上的文檔中的 Ansible Vault 部分。

這個清單文件有四個組，每個組定義了一台單個的主機。讓我們詳細回顧一下每一節：

Cumulus

主機 cvx 是一個 Cumulus Linux (CL) 交換機，並且它是 cumulus 組中的唯一設備。記住，CL 是原生 Linux，因此，這意味著它是使用默認連接機制（SSH）連到到需要自動化的 CL 交換機。因為 cvx 在 DNS 或者 /etc/hosts 文件中沒有定義，我們將讓 Ansible 知道不要在清單文件中定義主機名，而是在 ansible_ssh_host 中定義的名字/IP。登陸到 CL 交換機的用戶名被定義在 playbook 中，但是，你可以看到密碼使用變數 ansible_ssh_pass 定義在清單文件中。

Arista

被稱為 veos1 的是一台運行 EOS 的 Arista 交換機。它是在 arista 組中唯一的主機。正如你在 Arista 中看到的，在清單文件中並沒有其它的參數存在。這是因為 Arista 為它們的設備使用了一個特定的配置文件。在我們的示例中它的名字為 .eapi.conf，它存在在 home 目錄中。下面是正確使用配置文件的這個功能的示例：

[connection:veos1]
host: 2.4.3.4
username: unadmin
password: pwadmin

這個文件包含了定義在配置文件中的 Ansible 連接到設備（和 Arista 的被稱為 pyeapi 的 Python 庫）所需要的全部信息。

Cisco

和 Cumulus 和 Arista 一樣，這裡僅有一台主機（nx1）存在於 cisco 組中。這是一台 NX-OS-based Cisco Nexus 交換機。注意在這裡為 nx1 定義了三個變數。它們包括 un 和 pwd，這是為了在 playbook 中訪問和為了進入到 Cisco 模塊去連接到設備。另外，這裡有一個稱為 hostip 的參數，它是必需的，因為，nx1 沒有在 DNS 中或者是 /etc/hosts 配置文件中定義。

注意：

如果自動化一個原生的 Linux 設備，我們可以將這個參數命名為任何東西。ansible_ssh_host 被用於到如我們看到的那個 Cumulus 示例（如果在清單文件中的定義不能被解析）。在這個示例中，我們將一直使用 ansible_ssh_host，但是，它並不是必需的，因為我們將這個變數作為一個參數進入到 Cisco 模塊，而 ansible_ssh_host 是在使用默認的 SSH 連接機制時自動檢查的。

Juniper

和前面的三個組和主機一樣，在 juniper 組中有一個單個的主機 vsrx。它在清單文件中的設置與 Cisco 相同，因為兩者在 playbook 中使用了相同的方式。

劇本

接下來的劇本有四個不同的劇集。每個劇集是基於特定的供應商類型的設備組的自動化構建的。注意，那是在一個單個的劇本中執行這些任務的唯一的方法。這裡還有其它的方法，它可以使用條件（when 語句）或者創建 Ansible 角色（它在這個報告中沒有介紹）。

這裡有一個劇本的示例：

  - name: PLAY 1 - CISCO NXOS
    hosts: cisco
    connection: local

    tasks:
      - name: ENSURE VLAN 100 exists on Cisco Nexus switches
        nxos_vlan:
          vlan_id=100
          name=web_vlan
          host={{ hostip }}
          username={{ un }}
          password={{ pwd }}

  - name: PLAY 2 - ARISTA EOS
    hosts: arista
    connection: local

    tasks:
      - name: ENSURE VLAN 100 exists on Arista switches
        eos_vlan:
          vlanid=100
          name=web_vlan
          connection={{ inventory_hostname }}

  - name: PLAY 3 - CUMULUS
    remote_user: cumulus
    sudo: true
    hosts: cumulus

    tasks:
      - name: ENSURE 100.10.10.1 is configured on swp1
        cl_interface: name=swp1  ipv4=100.10.10.1/24

      - name: restart networking without disruption
        shell: ifreload -a

  - name: PLAY 4 - JUNIPER SRX changes
    hosts: juniper
    connection: local

    tasks:
    - name: INSTALL JUNOS CONFIG
      junos_install_config:
        host={{ hostip }}
        file=srx_demo.conf
        user={{ un }}
        passwd={{ pwd }}
        logfile=deploysite.log
        overwrite=yes
        diffs_file=junpr.diff

你將注意到，前面的兩個劇集是非常類似的，我們已經在最初的 Cisco 和 Arista 示例中講過了。唯一的區別是每個要自動化的組（cisco and arista) 定義了它們自己的劇集，我們在前面介紹使用 when 條件時比較過。

這裡有一個不正確的或者是錯誤的方式去做這些。這取決於你預先知道的信息是什麼和適合你的環境和使用的最佳案例是什麼，但我們的目的是為了展示做同一件事的幾種不同的方法。

第三個劇集是在 Cumulus Linux 交換機的 swp1 介面上進行自動化配置。在這個劇集中的第一個任務是去確認 swp1 是一個三層介面，並且它配置的 IP 地址是 100.10.10.1。因為 Cumulus Linux 是原生的 Linux，網路服務在改變後需要重啟才能生效。這也可以使用 Ansible 的操作來達到這個目的（這已經超出了本報告討論的範圍），這裡有一個被稱為 service 的 Ansible 核心模塊來做這些，但它會中斷交換機上的網路；使用 ifreload 重新啟動則不會中斷。

本節到現在為止，我們已經講解了專註於特定任務的 Ansible 模塊，比如，配置介面和 VLAN。第四個劇集使用了另外的選項。我們將看到一個 pushes 模塊，它是一個完整的配置文件並且立即激活它作為正在運行的新的配置。這裡將使用 napalm_install_config 來展示前面的示例，但是，這個示例使用了一個 Juniper 專用的模塊。

junos_install_config 模塊接受幾個參數，如下面的示例中所展示的。到現在為止，你應該理解了什麼是 user、passwd、和 host。其它的參數定義如下：

file：

這是一個從 Ansible 控制主機拷貝到 Juniper 設備的配置文件。

logfile：

這是可選的，但是，如果你指定它，它會被用於存儲運行這個模塊時生成的信息。

overwrite：

當你設置為 yes/true 時，完整的配置將被發送的配置覆蓋。（默認是 false）

diffs_file：

這是可選的，但是，如果你指定它，當應用配置時，它將存儲生成的差異。當應用配置時將存儲一個生成的差異。當正好更改了主機名，但是，仍然發送了一個完整的配置文件時會生成一個差異，如下的示例：

# filename: junpr.diff
[edit system]
-  host-name vsrx;
+  host-name vsrx-demo;

上面已經介紹了劇本概述的細節。現在，讓我們看看當劇本運行時發生了什麼：

注意：

-i 標誌是用於指定使用的清單文件。也可以設置環境變數 ANSIBLE_HOSTS，而不用每次運行劇本時都去使用一個 -i 標誌。

ntc@ntc:~/ansible/multivendor$ ansible-playbook -i inventory demo.yml

PLAY [PLAY 1 - CISCO NXOS] *************************************************

TASK: [ENSURE VLAN 100 exists on Cisco Nexus switches] *********************
changed: [nx1]

PLAY [PLAY 2 - ARISTA EOS] *************************************************

TASK: [ENSURE VLAN 100 exists on Arista switches] **************************
changed: [veos1]

PLAY [PLAY 3 - CUMULUS] ****************************************************

GATHERING FACTS ************************************************************
ok: [cvx]

TASK: [ENSURE 100.10.10.1 is configured on swp1] ***************************
changed: [cvx]

TASK: [restart networking without disruption] ******************************
changed: [cvx]

PLAY [PLAY 4 - JUNIPER SRX changes] ****************************************

TASK: [INSTALL JUNOS CONFIG] ***********************************************
changed: [vsrx]

PLAY RECAP ***************************************************************
           to retry, use: --limit @/home/ansible/demo.retry

cvx                        : ok=3    changed=2    unreachable=0    failed=0
nx1                        : ok=1    changed=1    unreachable=0    failed=0
veos1                      : ok=1    changed=1    unreachable=0    failed=0
vsrx                       : ok=1    changed=1    unreachable=0    failed=0

你可以看到每個任務成功完成；如果你是在終端上運行，你將看到用琥珀色顯示的每個改變的任務。

讓我們再次運行 playbook。通過再次運行，我們可以校驗所有模塊的 冪等性；當我們這樣做的時候，我們看到設備上 沒有 產生變化，並且所有的東西都是綠色的：

PLAY [PLAY 1 - CISCO NXOS] ***************************************************

TASK: [ENSURE VLAN 100 exists on Cisco Nexus switches] ***********************
ok: [nx1]

PLAY [PLAY 2 - ARISTA EOS] ***************************************************

TASK: [ENSURE VLAN 100 exists on Arista switches] ****************************
ok: [veos1]

PLAY [PLAY 3 - CUMULUS] ******************************************************

GATHERING FACTS **************************************************************
ok: [cvx]

TASK: [ENSURE 100.10.10.1 is configured on swp1] *****************************
ok: [cvx]

TASK: [restart networking without disruption] ********************************
skipping: [cvx]

PLAY [PLAY 4 - JUNIPER SRX changes] ******************************************

TASK: [INSTALL JUNOS CONFIG] *************************************************
ok: [vsrx]

PLAY RECAP ***************************************************************
cvx                        : ok=2    changed=0    unreachable=0    failed=0
nx1                        : ok=1    changed=0    unreachable=0    failed=0
veos1                      : ok=1    changed=0    unreachable=0    failed=0
vsrx                       : ok=1    changed=0    unreachable=0    failed=0

注意：這裡有 0 個改變，但是，每次運行任務，正如期望的那樣，它們都返回 「ok」。說明在這個劇本中的每個模塊都是冪等的。

總結

Ansible 是一個超級簡單的、無代理和可擴展的自動化平台。網路社區持續不斷地圍繞 Ansible 去重整它作為一個能夠執行一些自動化網路任務的平台，比如，做配置管理、數據收集和報告，等等。你可以使用 Ansible 去推送完整的配置文件，配置具體的使用冪等模塊的網路資源，比如，介面、VLAN，或者，簡單地自動收集信息，比如，領居、序列號、啟動時間、和介面狀態，以及按你的需要定製一個報告。

因為它的架構，Ansible 被證明是一個在這裡可用的、非常好的工具，它可以幫助你實現從傳統的基於 CLI/SNMP 的網路設備到基於 API 驅動 的現代化網路設備的自動化。

在網路社區中，易於使用和無代理架構的 Ansible 的佔比持續增加，它將使沒有 APIs 的設備（CLI/SNMP）的自動化成為可能。包括獨立的交換機、路由器、和 4-7 層的服務應用程序；甚至是提供了 RESTful API 的那些軟體定義網路控制器。

當使用 Ansible 實現網路自動化時，不會落下任何設備。

作者簡介：

Jason Edelman，CCIE 15394 & VCDX-NV 167，出生並成長於新澤西州的一位網路工程師。他是一位典型的 「CLI 愛好者」 和 「路由器小子」。在幾年前，他決定更多地關注於軟體、開發實踐、以及怎麼與網路工程融合。Jason 目前經營著一個小的諮詢公司，公司名為：Network to Code（http://networktocode.com/ ），幫助供應商和終端用戶利用新的工具和技術來減少他們的低效率操作…

via: https://www.oreilly.com/learning/network-automation-with-ansible

作者：Jason Edelman 譯者：qhwdw 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive