Ansible中怎么實(shí)現網(wǎng)絡(luò )自動(dòng)化

這篇文章給大家介紹Ansible中怎么實(shí)現網(wǎng)絡(luò )自動(dòng)化，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

網(wǎng)絡(luò )自動(dòng)化

隨著(zhù) IT 行業(yè)的技術(shù)變化，從虛擬化到公有云和私有云，以及自服務(wù)能力、容器化應用、平臺即服務(wù)（PaaS）交付，而一直以來(lái)落后的一個(gè)領(lǐng)域就是網(wǎng)絡(luò )。

在過(guò)去的五年多，網(wǎng)絡(luò )行業(yè)似乎有很多新的趨勢出現，它們中的很多被歸入到軟件定義網(wǎng)絡(luò )software-defined networking（SDN）。

注意：

SDN 是新出現的一種構建、管理、操作和部署網(wǎng)絡(luò )的方法。SDN 最初的定義是出于將控制層和數據層（包轉發(fā)）物理分離的需要，并且，解耦合的控制層必須管理好各自的設備。

如今，在 SDN 旗下已經(jīng)有許多技術(shù)，包括基于控制器的網(wǎng)絡(luò )controller-based networks、網(wǎng)絡(luò )設備 API、網(wǎng)絡(luò )自動(dòng)化、白盒交換機whitebox switche、策略網(wǎng)絡(luò )化、網(wǎng)絡(luò )功能虛擬化Network Functions Virtualization（NFV）等等。

出于這篇報告的目的，我們參考 SDN 的解決方案作為我們的解決方案，其中包括一個(gè)網(wǎng)絡(luò )控制器作為解決方案的一部分，并且提升了該網(wǎng)絡(luò )的可管理性，但并不需要從數據層解耦控制層。

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

在 API 之前，用于配置和管理網(wǎng)絡(luò )設備的兩個(gè)主要機制是命令行接口（CLI）和簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議（SNMP）。讓我們來(lái)了解一下它們，CLI 是一個(gè)設備的人機界面，而 SNMP 并不是為設備提供的實(shí)時(shí)編程接口。

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

注意：

隨著(zhù)未來(lái)幾個(gè)月或幾年（LCTT 譯注：本文發(fā)表于 2016 年）的網(wǎng)絡(luò )設備更新，供應商的 API  無(wú)疑應該被做為采購網(wǎng)絡(luò )設備（虛擬和物理）的關(guān)鍵決策標準而測試和使用。如果供應商提供一些庫或集成到自動(dòng)化工具中，或者如果被用于一個(gè)開(kāi)放的標準或協(xié)議，用戶(hù)應該知道數據是如何通過(guò)設備建模的，API  使用的傳輸類(lèi)型是什么。

總而言之，網(wǎng)絡(luò )自動(dòng)化，像大多數類(lèi)型的自動(dòng)化一樣，是為了更快地工作。工作的更快是好事，減少部署和配置改變的時(shí)間并不總是許多 IT 組織需要去解決的問(wèn)題。

包括速度在內，我們現在看看這些各種類(lèi)型的 IT 組織逐漸采用網(wǎng)絡(luò )自動(dòng)化的幾種原因。你應該注意到，同樣的原則也適用于其它類(lèi)型的自動(dòng)化。

簡(jiǎn)化架構

今天，每個(gè)網(wǎng)絡(luò )都是一片獨特的“雪花”，并且，網(wǎng)絡(luò )工程師們?yōu)槟軌蛲ㄟ^(guò)一次性的網(wǎng)絡(luò )改變來(lái)解決傳輸和應用問(wèn)題而感到自豪，而這最終導致網(wǎng)絡(luò )不僅難以維護和管理，而且也很難去實(shí)現自動(dòng)化。

網(wǎng)絡(luò )自動(dòng)化和管理需要從一開(kāi)始就包含到新的架構和設計中去部署，而不是作為一個(gè)二級或三級項目。哪個(gè)特性可以跨不同的供應商工作？哪個(gè)擴展可以跨不同的平臺工作？當使用具體的網(wǎng)絡(luò )設備平臺時(shí)，API  類(lèi)型或者自動(dòng)化工程是什么？當這些問(wèn)題在設計過(guò)程之前得到答案，最終的架構將變成簡(jiǎn)單的、可重復的、并且易于維護 和 自動(dòng)化的，在整個(gè)網(wǎng)絡(luò )中將很少啟用供應商專(zhuān)用的擴展。

確定的結果

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

使用經(jīng)過(guò)驗證的和測試過(guò)的網(wǎng)絡(luò )自動(dòng)化可以幫助實(shí)現更多的可預測行為，并且使執行團隊更有可能實(shí)現確實(shí)性的結果，***在保證任務(wù)沒(méi)有人為錯誤的情況下正確完成的道路上更進(jìn)一步。

業(yè)務(wù)靈活性

不用說(shuō)，網(wǎng)絡(luò )自動(dòng)化不僅為部署變化提供了速度和靈活性，而且使得根據業(yè)務(wù)需要去從網(wǎng)絡(luò )設備中檢索數據的速度變得更快。自從服務(wù)器虛擬化到來(lái)以后，服務(wù)器和虛擬化使得管理員有能力在瞬間去部署一個(gè)新的應用程序。而且，隨著(zhù)應用程序可以更快地部署，隨之浮現的問(wèn)題是為什么還需要花費如此長(cháng)的時(shí)間配置一個(gè)  VLAN（虛擬局域網(wǎng)）、路由器、FW ACL（防火墻的訪(fǎng)問(wèn)控制列表）或者策略呢？

通過(guò)了解在一個(gè)組織內最常見(jiàn)的工作流和 為什么 真正需要改變網(wǎng)絡(luò )，部署如 Ansible 這樣的現代的自動(dòng)化工具將使這些變得非常簡(jiǎn)單。

這一章介紹了一些關(guān)于為什么應該去考慮網(wǎng)絡(luò )自動(dòng)化的高級知識點(diǎn)。在下一節，我們將帶你去了解 Ansible 是什么，并且繼續深入了解各種不同規模的 IT 組織的網(wǎng)絡(luò )自動(dòng)化的不同類(lèi)型。

什么是 Ansible？

Ansible 是存在于開(kāi)源世界里的一種***的 IT 自動(dòng)化和配置管理平臺。它經(jīng)常被拿來(lái)與其它工具如 Puppet、Chef 和  SaltStack 去比較。Ansible 作為一個(gè)由 Michael DeHaan 創(chuàng )建的開(kāi)源項目出現于 2012 年，Michael  DeHaan 也創(chuàng )建了 Cobbler 和 cocreated Func，它們在開(kāi)源社區都非常流行。在 Ansible 開(kāi)源項目創(chuàng )建之后不足  18 個(gè)月時(shí)間， Ansilbe 公司成立，并收到了六百萬(wàn)美金 A 輪投資。該公司成為 Ansible  開(kāi)源項目***的貢獻者和支持者，并一直保持著(zhù)。在 2015 年 10 月，Red Hat 收購了 Ansible 公司。

但是，Ansible 到底是什么？

Ansible 是一個(gè)無(wú)需代理和可擴展的超級簡(jiǎn)單的自動(dòng)化平臺。

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

簡(jiǎn)單

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

例如，下列來(lái)自一個(gè) Ansible劇本playbook的任務(wù)用于去確保在一個(gè) VLAN 存在于一個(gè) Cisco Nexus 交換機中：

- nxos_vlan: vlan_id=100 name=web_vlan

你無(wú)需熟悉或寫(xiě)任何代碼就可以明確地看出它將要做什么！

注意：

這個(gè)報告的下半部分涉到 Ansible 術(shù)語(yǔ)（劇本playbook、劇集play、任務(wù)task、模塊module等等）的細節。在我們使用 Ansible 進(jìn)行網(wǎng)絡(luò )自動(dòng)化時(shí)，提及這些關(guān)鍵概念時(shí)我們會(huì )有一些簡(jiǎn)短的示例。

無(wú)代理

如果你看過(guò)市面上的其它工具，比如 Puppet 和 Chef，你會(huì )發(fā)現，一般情況下，它們要求每個(gè)實(shí)現自動(dòng)化的設備必須安裝特定的軟件。這種情況在 Ansible 上 并不需要，這就是為什么 Ansible 是實(shí)現網(wǎng)絡(luò )自動(dòng)化的***選擇的主要原因。

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

再加上，當使用代理時(shí)，它們需要的 和 NTP 配置更加復雜。這些都是大多數環(huán)境中已經(jīng)配置好的服務(wù)，但是，當你希望快速地獲取一些東西或者只是簡(jiǎn)單地想去測試一下它能做什么的時(shí)候，它將極大地耽誤整個(gè)設置和安裝的過(guò)程。

由于本報告只是為介紹利用 Ansible 實(shí)現網(wǎng)絡(luò )自動(dòng)化，我們希望指出，Ansible 作為一個(gè)無(wú)代理平臺，對于網(wǎng)絡(luò )管理員來(lái)說(shuō)，其比對系統管理員更具有吸引力。這是為什么呢？

正如前面所說(shuō)的那樣，對網(wǎng)絡(luò )管理員來(lái)說(shuō)，它是非常有吸引力的，Linux  操作系統是開(kāi)源的，并且，任何東西都可以安裝在它上面。對于網(wǎng)絡(luò )來(lái)說(shuō)，卻并非如此，雖然它正在逐漸改變。如果我們更廣泛地部署網(wǎng)絡(luò )操作系統，如  Cisco IOS，它就是這樣的一個(gè)例子，并且問(wèn)一個(gè)問(wèn)題， “第三方軟件能否部署在基于 IOS （LCTT 譯注：此處的 IOS，指的是思科的網(wǎng)絡(luò )操作系統 IOS）的平臺上嗎？”毫無(wú)疑問(wèn)，它的回答是 NO。

在過(guò)去的二十多年里，幾乎所有的網(wǎng)絡(luò )操作系統都是閉源的，并且，垂直整合到底層的網(wǎng)絡(luò )硬件中。沒(méi)有供應商的支持，在一個(gè)網(wǎng)絡(luò )設備中（路由器、交換機、負載均衡、防火墻、等等）載入一個(gè)代理并不那么輕松。有一個(gè)像  Ansible  這樣的自動(dòng)化平臺，從頭開(kāi)始去構建一個(gè)無(wú)代理、可擴展的自動(dòng)化平臺，就像是它專(zhuān)門(mén)為網(wǎng)絡(luò )行業(yè)訂制的一樣。我們最終將開(kāi)始減少并消除與網(wǎng)絡(luò )的人工交互。

可擴展

Ansible 的可擴展性也非常的好。從開(kāi)源、代碼開(kāi)始在網(wǎng)絡(luò )行業(yè)中發(fā)揮重要的作用時(shí)起，有一個(gè)可擴展的平臺是必需的。這意味著(zhù)如果供應商或社區不提供一個(gè)特定的特性或功能，開(kāi)源社區、終端用戶(hù)、消費者、顧問(wèn)，或者任何的人能夠 擴展 Ansible 來(lái)啟用一個(gè)給定的功能集。過(guò)去，網(wǎng)絡(luò )供應商或者工具供應商通過(guò)一個(gè) hook 去提供新的插件和集成。想像一下，使用一個(gè)像 Ansible 這樣的自動(dòng)化平臺，并且，你選擇的網(wǎng)絡(luò )供應商發(fā)布了你 真正 需要的一個(gè)自動(dòng)化的新特性。從理論上說(shuō)，網(wǎng)絡(luò )供應商或者 Ansible 可以發(fā)行一個(gè)新的插件去實(shí)現自動(dòng)化這個(gè)獨特的特性，這是一件非常好的事情，從你的內部工程師到你的增值分銷(xiāo)商（VAR）或者你的顧問(wèn)中的任何一個(gè)人，都可以去提供這種集成。

正如前面所說(shuō)的那樣，Ansible 實(shí)際上是***擴展性的，Ansible 最初就是為自動(dòng)化應用程序和系統構建的。這是因為，Ansible  的可擴展性來(lái)自于其集成性是為網(wǎng)絡(luò )供應商編寫(xiě)的，包括但不限于 Cisco、Arista、Juniper、F5、HP、A10、Cumulus 和  Palo Alto Networks。

對于網(wǎng)絡(luò )自動(dòng)化，為什么要使用 Ansible？

我們已經(jīng)簡(jiǎn)單了解除了 Ansible 是什么，以及一些網(wǎng)絡(luò )自動(dòng)化的好處，但是，對于網(wǎng)絡(luò )自動(dòng)化，我們?yōu)槭裁匆褂?Ansible？

大家很清楚，使得 Ansible 成為如此偉大的一個(gè)自動(dòng)化應用部署平臺的許多原因已經(jīng)被大家所提及了。但是，我們現在要深入一些，更多地關(guān)注于網(wǎng)絡(luò )，并且繼續總結一些更需要注意的其它關(guān)鍵點(diǎn)。

無(wú)代理

在實(shí)現網(wǎng)絡(luò )自動(dòng)化的時(shí)候，無(wú)代理架構的重要性并不是重點(diǎn)強調的，特別是當它適用于現有的自動(dòng)化設備時(shí)。如果，我們看一下當前網(wǎng)絡(luò )中已經(jīng)安裝的各種設備時(shí)，從 DMZ 和園區，到分支機構和數據中心，***份額的設備 并不 具有*** API 的設備。從自動(dòng)化的角度來(lái)看，API 可以使做一些事情變得很簡(jiǎn)單，像 Ansible 這樣的無(wú)代理平臺有可能去自動(dòng)化和管理那些 老舊（傳統） 的設備。例如，基于 CLI 的設備，它的工具可以被用于任何網(wǎng)絡(luò )環(huán)境中。

注意：

如果僅支持 CLI 的設備已經(jīng)集成進(jìn) Ansible，它的機制就像是，怎么在設備上通過(guò)協(xié)議如 telnet、SSH 和 SNMP 去進(jìn)行只讀訪(fǎng)問(wèn)和讀寫(xiě)操作。

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

所有的這些解決方案都簡(jiǎn)化了網(wǎng)絡(luò )管理，就像它們可以讓一個(gè)管理員開(kāi)始從“box-by-box”管理（LCTT  譯者注：指的是單個(gè)設備挨個(gè)去操作的意思）遷移到網(wǎng)絡(luò )范圍的管理。這是在正確方向上邁出的很大的一步，這些解決方案并不能消除在變更期間中人類(lèi)犯錯的機率。例如，比起配置 N 個(gè)交換機，你可能需要去配置一個(gè)單個(gè)的 GUI，它需要很長(cháng)的時(shí)間才能實(shí)現所需要的配置改變 —— 它甚至可能更復雜，畢竟，相對于一個(gè) CLI，他們更喜歡 GUI！另外，你可能有不同類(lèi)型的 SDN 解決方案部署在每個(gè)應用程序、網(wǎng)絡(luò )、區域或者數據中心。

在需要自動(dòng)化的網(wǎng)絡(luò )中，對于配置管理、監視和數據收集，當行業(yè)開(kāi)始向基于控制器的網(wǎng)絡(luò )架構中遷移時(shí)，這些需求并不會(huì )消失。

大量的軟件定義網(wǎng)絡(luò )中都部署有控制器，幾乎所有的控制器都提供expose一個(gè)***的 REST  API。并且，因為 Ansible 是一個(gè)無(wú)代理架構，它實(shí)現自動(dòng)化是非常簡(jiǎn)單的，而不僅僅是對那些沒(méi)有 API 的傳統設備，但也有通過(guò) REST  API 的軟件定義網(wǎng)絡(luò )解決方案，在所有的終端上不需要有額外的軟件（LCTT 譯注：指的是代理）。最終的結果是，使用 Ansible，無(wú)論有或沒(méi)有  API，可以使任何類(lèi)型的設備都能夠自動(dòng)化。

自由開(kāi)源軟件（FOSS)

Ansible 是一個(gè)開(kāi)源軟件，它的全部代碼在 GitHub 上都是公開(kāi)可訪(fǎng)問(wèn)的，使用 Ansible  是完全免費的。它可以在幾分鐘內完成安裝并為網(wǎng)絡(luò )工程師提供有用的價(jià)值。Ansible 這個(gè)開(kāi)源項目，或者 Ansible  公司，在它們交付軟件之前，你不會(huì )遇到任何一個(gè)銷(xiāo)售代表。那是顯而易見(jiàn)的事實(shí)，因為它是一個(gè)真正的開(kāi)源項目，但是，作為開(kāi)源的、社區驅動(dòng)的軟件項目在網(wǎng)絡(luò )行業(yè)中的使用是非常少的，但是，也在逐漸增加，我們想明確指出這一點(diǎn)。

同樣需要指出的一點(diǎn)是，Ansible, Inc. 也是一個(gè)公司，它也需要去賺錢(qián)，對嗎？雖然 Ansible 是開(kāi)源的，它也有一個(gè)叫  Ansible Tower 的企業(yè)產(chǎn)品，它增加了一些特性，比如，基于規則的訪(fǎng)問(wèn)控制（RBAC）、報告、 web UI、REST  API、多租戶(hù)等等，（相比 Ansible）它更適合于企業(yè)去部署。并且，更重要的是，Ansible Tower 甚至可以最多在 10 臺設備上 免費 使用，至少，你可以去體驗一下，它是否會(huì )為你的組織帶來(lái)好處，而無(wú)需花費一分錢(qián)，并且，也不需要與無(wú)數的銷(xiāo)售代表去打交道。

可擴展性

我們在前面說(shuō)過(guò)，Ansible 主要是為部署 Linux 應用程序而構建的自動(dòng)化平臺，雖然從早期開(kāi)始已經(jīng)擴展到  Windows。需要指出的是，Ansible 開(kāi)源項目并沒(méi)有“自動(dòng)化網(wǎng)絡(luò )基礎設施”的目標。事實(shí)上是，Ansible 社區更明白如何在底層的  Ansible 架構上更具靈活性和可擴展性，對于他們的自動(dòng)化需要（包括網(wǎng)絡(luò )）更容易成為一個(gè) 擴展 的  Ansible。在過(guò)去的兩年中，部署有許多的 Ansible 集成，許多是有行業(yè)獨立人士進(jìn)行的，比如，Matt Oswalt、Jason  Edelman、Kirk Byers、Elisa Jasinska、David Barroso、Michael Ben-Ami、Patrick  Ogenstad 和 Gabriele  Gerbino，也有網(wǎng)絡(luò )系統供應商的***，比如，Arista、Juniper、Cumulus、Cisco、F5、和 Palo Alto  Networks。

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

Ansible 在 IT 組織中被用于應用程序部署。它被用于需要管理部署、監視和管理各種類(lèi)型的應用程序的運維團隊中。通過(guò)將 Ansible  集成到網(wǎng)絡(luò )基礎設施中，當新應用程序到來(lái)或遷移后，它擴展了可能的范圍。而不是去等待一個(gè)新的頂架交換機（LCTT  譯注：TOR，一種數據中心設備接入的方式）的到來(lái)、去添加一個(gè)  VLAN、或者去檢查接口的速度/雙工，所有的這些以網(wǎng)絡(luò )為中心的任務(wù)都可以被自動(dòng)化，并且可以集成到 IT 組織內已經(jīng)存在的工作流中。

冪等性

術(shù)語(yǔ)冪等性idempotency （讀作 item-potency）經(jīng)常用于軟件開(kāi)發(fā)的領(lǐng)域中，尤其是當使用 REST API 工作的時(shí)候，以及在 DevOps 自動(dòng)化和配置管理框架的領(lǐng)域中，包括 Ansible。Ansible 的其中一個(gè)信念是，所有的 Ansible 模塊（集成的）應該是冪等的。那么，對于一個(gè)模塊來(lái)說(shuō)，冪等是什么意思呢？畢竟，對大多數網(wǎng)絡(luò )工程師來(lái)說(shuō)，這是一個(gè)新的術(shù)語(yǔ)。

答案很簡(jiǎn)單。冪等性的本質(zhì)是允許定義的任務(wù)，運行一次或者上千次都不會(huì )在目標系統上產(chǎn)生不利影響，僅僅是一種一次性的改變。換句話(huà)說(shuō)，如果有一個(gè)要做的改變去使系統進(jìn)入到它期望的狀態(tài)，這種改變完成之后，并且，如果這個(gè)設備已經(jīng)達到這種狀態(tài)，就不會(huì )再發(fā)生改變。這不像大多數傳統的定制腳本和拷貝、黏貼到那些終端窗口中的  CLI  命令。當相同的命令或者腳本在同一個(gè)系統上重復運行，（有時(shí)候）會(huì )出現錯誤。即使是粘貼一組命令到一個(gè)路由器中，也可能會(huì )遇到一些使你的其余的配置失效的錯誤。好玩吧?

另外的例子是，如果你有一個(gè)配置 10 個(gè) VLAN 的文件文件或者腳本，那么 每次 運行這個(gè)腳本，相同的命令命令會(huì )被輸入  10 次。如果使用一個(gè)冪等的 Ansible 模塊，首先會(huì )從網(wǎng)絡(luò )設備中采集已存在的配置，并且，每個(gè)新的 VLAN  被配置后會(huì )再次檢查當前配置。僅僅當這個(gè)新的 VLAN 需要被添加（或者，比如說(shuō)改變 VLAN 名字）是一個(gè)變更，命令才會(huì )真實(shí)地推送到設備。

當一個(gè)技術(shù)越來(lái)越復雜，冪等性的價(jià)值就越高，在你修改的時(shí)候，你并不能注意到 已存在 的網(wǎng)絡(luò )設備的狀態(tài)，而僅僅是從一個(gè)網(wǎng)絡(luò )配置和策略角度去嘗試達到 期望的 狀態(tài)。

網(wǎng)絡(luò )范圍的和臨時(shí)（Ad Hoc）的改變

用配置管理工具解決的其中一個(gè)問(wèn)題是，配置“飄移”（當設備的期望配置逐漸漂移，或者改變，隨著(zhù)時(shí)間的推移，手動(dòng)改變和/或在一個(gè)環(huán)境中使用了多個(gè)不同的工具），事實(shí)上，這也是像 Puppet 和 Chef 所使用的地方。代理商電聯(lián)phone home到前端服務(wù)器，驗證它的配置，并且，如果需要變更，則改變它。這個(gè)方法是非常簡(jiǎn)單的。如果有故障了，需要去排除怎么辦？你通常需要跳過(guò)管理系統，直接連到設備，找到并修復它，然后，馬上離開(kāi)，對不對？果然，在下次當代理電連回來(lái)，這個(gè)修復問(wèn)題的改變被覆蓋了（基于主/前端服務(wù)器是怎么配置的）。在高度自動(dòng)化的環(huán)境中，一次性的改變應該被限制，但是，仍然允許使用它們（LCTT  譯注：指的是一次性改變）的工具是非常有價(jià)值的。正如你想到的，其中一個(gè)這樣的工具是 Ansible。

因為 Ansible 是無(wú)代理的，這里并沒(méi)有一個(gè)默認的推送或者拉取去防止配置漂移。自動(dòng)化任務(wù)被定義在 Ansible  <ruby劇本playbook中，當使用 Ansible 時(shí)，它讓用戶(hù)去運行劇本。如果劇本在一個(gè)給定的時(shí)間間隔內運行，并且你沒(méi)有用  Ansible Tower，你肯定知道任務(wù)的執行頻率；如果你只是在終端提示符下使用一個(gè)原生的 Ansible  命令行，那么該劇本就運行一次，并且僅運行一次。

缺省運行一次的劇本對網(wǎng)絡(luò )工程師是很具有吸引力的，讓人欣慰的是，在設備上手動(dòng)進(jìn)行的改變不會(huì )自動(dòng)被覆蓋。另外，當需要的時(shí)候，一個(gè)劇本所運行的設備范圍很容易被改變，即使是對一個(gè)單個(gè)設備進(jìn)行自動(dòng)化的單次變更，Ansible 仍然可以用，設備的 范圍 由一個(gè)被稱(chēng)為 Ansible清單inventory的文件決定；這個(gè)清單可以是一臺設備或者是一千臺設備。

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

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

為了自動(dòng)化所有的主機，你的劇本中的劇集play定義的一個(gè)片段看起來(lái)應該是這樣的：

hosts: all

并且，要只自動(dòng)化一個(gè)葉子節點(diǎn)交換機，它看起來(lái)應該像這樣：

hosts: leaf1

這是一個(gè)核心交換機：

hosts: core-switches