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

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

創(chuàng)新互聯(lián)專注于樂東黎族網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供樂東黎族營銷型網(wǎng)站建設(shè)，樂東黎族網(wǎng)站制作、樂東黎族網(wǎng)頁設(shè)計(jì)、樂東黎族網(wǎng)站官網(wǎng)定制、微信小程序服務(wù)，打造樂東黎族網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供樂東黎族網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

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

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

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

注意：

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

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

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

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

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

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

注意：

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

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

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

簡化架構(gòu)

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

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

確定的結(jié)果

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

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

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

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

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

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

什么是 Ansible？

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

但是，Ansible 到底是什么？

Ansible 是一個(gè)無需代理和可擴(kuò)展的超級(jí)簡單的自動(dòng)化平臺(tái)。

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

簡單

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

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

- nxos_vlan: vlan_id=100 name=web_vlan

你無需熟悉或?qū)懭魏未a就可以明確地看出它將要做什么！

注意：

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

無代理

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

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

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

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

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

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

可擴(kuò)展

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

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

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

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

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

無代理

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

注意：

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

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

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

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

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

自由開源軟件（FOSS)

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

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

可擴(kuò)展性

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

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

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

冪等性

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

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

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

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

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

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

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

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

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

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

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

hosts: all

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

hosts: leaf1

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

hosts: core-switches

關(guān)于Ansible中怎么實(shí)現(xiàn)網(wǎng)絡(luò)自動(dòng)化就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。