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-1dc-core-2 [leaf-switches]leaf1leaf2leaf3leaf4

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

hosts: all

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

hosts: leaf1

這是一個核心交換機：

hosts: core-switches

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