Ansible中怎么實現(xiàn)網(wǎng)絡自動化

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

網(wǎng)絡自動化

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

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

注意：

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

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

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

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

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

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

注意：

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

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

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

簡化架構(gòu)

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

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

確定的結(jié)果

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

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

業(yè)務靈活性

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

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

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

什么是 Ansible？

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

但是，Ansible 到底是什么？

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

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

簡單

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

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

- nxos_vlan: vlan_id=100 name=web_vlan

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

注意：

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

無代理

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

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

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

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

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

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

可擴展

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

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

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

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

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

無代理

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

注意：

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

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

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

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

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

自由開源軟件（FOSS)

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

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

可擴展性

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

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

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

冪等性

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

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

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

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

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

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

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

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

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

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

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

hosts: all

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

hosts: leaf1

這是一個核心交換機：

hosts: core-switches

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