缺省運行一次的劇本對網絡工程師是很具有吸引力的，讓人欣慰的是，在設備上手動進行的改變不會自動被覆蓋。另外，當需要的時候，一個劇本所運行的設備範圍很容易被改變，即使是對一個單個設備進行自動化的單次變更，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:

class="lazy" src="//p2.ttnews.xyz/loading.gif" data-original=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

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