Глава 12. Автоматизация сетевой среды

Ознакомьтесь с видеоматериалами Code in Action.

Сетевые устройства ядра, такие как коммутаторы, маршрутизаторы и межсетевые экраны, уже давно имеют интерфейсы управления, в особенности в профессиональных средах. В этих устройствах всегда популярным было взаимодействие на основе командной строки, так как они поддерживали сценарии, а следовательно, как вы могли уже предвосхитить, это влекло их самих к тому что они чрезвычайно хорошо автоматизируются с помощью Ansible.

Исторически управляющие этими устройствами команды сталкивались с мириадами проблем, включая сопровождение конфигурации, копирование с отказавшего/ утраченного устройства и получение поддержки при возникновении некой проблемы. Зачастую компании обнаруживают себя привязанными к определённому сетевому производителю (или в лучшем случае к их ограниченному числу) чтобы применять частный инструментарий управления сетевой средой. Как и в любом ином случае когда вы привязаны к некой технологии, это имеет как преимущества, так и недостатки. Добавьте к этому сложность программно- определяемых сетевых сред, которые быстро изменяются и развиваются, и данная проблема становится ещё более комплексной. В данном разделе текущей главы мы рассмотрим как Ansible решает данные проблемы.

Как мы это уже наблюдали на протяжении данной книги, Ansible был разработан для того чтобы сделать код автоматизации переносимым и повторно применяемым во всех случаях когда это только возможно. В нашей главе по упроавлению инфраструктурой мы применяли практически идентичные плейбуки для настройки инфраструктуры различных поставщиков и все приводимые примеры были достаточно простыми; мы можем их в последующем применяя роли или удаляя имеющиеся повторы такого большого кода.

Короче говоря, Ansible делает возможным написание плейбуков, которые работают во множестве сред для достижения в точности тех же самых вещей с минимальными усилиями, которые мы проделали при самом первом определении. То же самое справедливо и в отношении сетевых сред; если вы посетите индекс сетевых модулей в документации Ansible, вы обнаружите поддержку более 50 типов систем и она растёт с каждым новым выпуском.

При таком широком (и растущем) диапазоне поддерживаемых устройств, некому сетевому администратору становится проще управлять всеми его устройствами из одного централизованного места без необходимости в проприетарных инструментах. Однако получаемые преимущества намного больше чем только это.

Как мы уже обсуждали, код Ansible обладает высокой степенью переносимости. Это чрезвычайно ценится в мире сетевой автоматизации. Для начала, это означает, что вы можете раскручивать изменение конфигурации в некой среде разработки (или имитации) и проверять его, а затем иметь возможность раскрутить тот же самый код для различных описей (например, для промышленной) раз уж данная конфигурация, как кажется, была успешно проверена.

Имеющиеся выгоды не останавливаются на этом, тем не менее. Исторически, в случае возникновения проблем с обновлением программного обеспечения или изменения конфигурации, основной задачей для сетевого инженера было привлечение самого производителя для успешной поддержки и содействия. Это требовало отправки достаточной детализации самому производителю чтобы позволить ему по крайней мере понять имеющуюся проблему, а скорее всего и воспроизвести её (в особенности в случае проблем со встроенным программным обеспечением - firmware). Когда определённая конфигурация для сетевой среды задаётся в Ansible, можно отправлять надлежащему производителю имеющиеся плейбуки сами по себе чтобы позволить ему быстро и в точности понять имеющуюся сетевую топологию и выявить возникшую проблему. На самом деле, я проходил варианты при которых сетевые производители теперь начинают настаивать на плейбуках Ansible для сетевых настроек при выдаче билетов поддержки, поскольку это позволяет им разрешать возникающую проблему быстрее чем это было ранее.

Действенное применение ansible-vault обеспечивает что чувствительные данные хранятся вне самих основных плейбуков и, тем самым, могут быть легко удалены перед отправкой третьей стороне (и даже если это и произойдёт, их будет невозможно прочесть).

Несмотря на то что большинство предприятий имеют надёжные процедуры контроля изменений, нет никакой гарантии что они будут выполняться на протяжении 100% времени, а люди, как известно, настраивают конфигурации без точной записи внесённых ими изменений. Перемещение конфигурирования имеющейся сетевой среды в Ansible устраняет эту проблему, поскольку конкретная конфигурация является известным состоянием, определённым теми плейбуками, которые можно запросто сопоставить с рабочей конфигурацией при помощи выполнения check.

Но возможно не только это, но и то что конфигурации запросто резервно копируются и восстанавливаются. Скажем, к примеру, некий коммутатор отказал и был заменён. Если он заменён тем же самым типом, он может быть быстро настроен и введён в рабочее состояние запуском плейбуков Ansible, возможно с ограничением исключительно на саму замену коммутатора в случае такой необходимости.

Это также делает возможным управление версиями - плейбуки сетевых настроек могут отправляться в репозиторий управления исходными кодами, что позволяет отслеживать версии настроек и со временем легко анализировать отличия.

Зачастую незначительные изменения в некой сетевой среде могут требовать собственной раскрутки некого нового проекта - возможно некой новой VLAN или VXLAN, либо неких ранее не применявшихся портов, которые были введены в службу. Такие параметры конфигурации будут чётко определяться запросом на изменение и/ или архитектурой сети и скорее всего это не лучшее применение высококвалифицированного сетевого инженера для внесения простых изменений. Такие задачи, как правило, являются рутинными в смысле того, что такие изменения конфигурации могут быть сведены в шаблоны в неком плейбуке Ansible с передаваемыми в него переменными, которые определяются самим запросом на изменение (например, подробности о номерах портов и сведений об участии в VLAN).

Это затем высвобождаем время инженеров для более важной работы, например такой как проектирование новых архитектур, а также исследования и тестирования новых продуктов.

На самом деле, совместно с применением такого пакета как AWX (как мы уже обсуждали это ранее в данной книге), простые и хорошо выверенные изменения могут быть полностью автоматизированы или переданы группе взаимодействия для безопасного их осуществления путём простой передачи требуемых параметров. В таком случае значительно снижается риск человеческих ошибок вне зависимости от навыков того персонала, который выполняет данное изменение.

После того как эти преимущества стали доступны и понятны, давайте перейдём к рассмотрению того как мы могли бы начать написание плейбуков для обработки сетевых сред со множеством устройств.

В неком мире, в котором мы не замкнуты на отдельного производителя, важно знать как мы можем обрабатывать различные сетевые устройства в некой инфраструктуре. В своей последней главе мы установили, что при различных поставщиков инфраструктуры, для каждого из них был установлен аналогичный процесс в терминах получения взаимодействия с ними Ansible. Это может быть слегка иным в случае коммутаторов, поскольку не все интерфейсы командной строки коммутаторов созданы одинаковыми. Некоторые, такие как коммутаторы Cumulus Networks применяют непосредственное соединение SSH, что означает, что всё что мы изучали ранее в этой книге до сих пор относительно подключения к некому устройству с возможностями SSH всё ещё можно применять. Тем не менее, прочие устройства, такие как F5 BIG-IP, не применяют подобное взаимодействие, а следовательно требуют надлежащего модуля, запускаемого в вашем хосте Ansible, а также передачи настройки параметров непосредственно в этот модуль в противоположность применению переменных хоста, таких как ansible_ssh_user.

Мы не ожидаем что многие читатели этой книги будут иметь доступ к широкому разнообразию сетевого оборудования для применения в примерах этой главы. Вместо этого в данной части этой главы мы углубимся в некие подробности того процесса, который будет применяться при автоматизации нового сетевого устройства в самый первый раз, чтобы вы знали как его применять в вашей собственной ситуации.

При работе с любым сетевым устройством вашей первой задачей будет выяснение того какие модули вам необходимо применять в Ansible. Это будет функцией двух моментов:

Вооружившись этой информацией, вы можете проконсультироваться в тех модулях, которые перечисляются в документации Ansible и определить имеется ли там ваше устройство и поддерживаются ли требуемые вам задачи. Допустим, например, что у вас имеется устройство F5 BIG-IP и вы желаете сохранить и загрузить конфигурацию этого устройства.

Быстрый просмотр перечня существующих модулей показывает, что имеющийся модуль bigip_config это именно то что вам требуется, поэтому мы можем продолжить работу настройкой конфигурации (см. следующий раздел), а затем написать нужный нам плейбук на основании этого модуля.

Что произойдёт если, тем не менее, для вашего устройства нет подходящего модуля? В таком случае у вас имеется два варианта. Во- первых вы можете написать некий новый модуль Ansible для выполнения требующихся вам задач. Это нечто, что вы сможете затем внести в имеющееся сообщество, и в Главе 9, Расширение Ansible, имелись все подробности которые вам потребуются чтобы начать эту задачу.

В качестве альтернативы, если вы пожелаете получить нечто для быстрого запуска, помните, что Ansible имеет возможность отправки команд в исходном виде для большинства транспортных методов, которые он поддерживает. Например, в установке лаборатории автора имеется управляемый коммутатор TP-link. Для него не существует собственных модулей Ansible - тем не менее, помимо GUI на основе веб- интерфейса, этот коммутатор также имеет некий интерфейс управления SSH. Если мне потребуется нечто быстро включённое и запущенное, я бы мог воспользоваться модулями Ansible shell или command для отправки исходных команд в этот коммутатор поверх SSH. Естественно, такое решение не блещет элегантностью и делает сложным написание плейбуков, которые были бы идемпотентными {повторяемыми при повторном применении}, однако тем не менее, это делает для меня возможным быстро включить и запустить для этого устройства Ansible.

Это пленяет прелестью Ansible - та простота, с которой новые устройства могут управляться с применением минимальных усилий, а также как с небольшими затратами его можно расширять на благо всего сообщества.

Ранее в книге мы уже обсуждали применение модулей shell и command, а также расширение Ansible, и мы продолжим продвижение неким вариантом, при котором мы обнаружили некий модуль, с которым мы бы желали работать. Как вы могли уже заметить в более ранних главах, хотя Ansible и содержит множество модулей сразу после установки, не все из них заработают сразу.

Ansible написан на Python и, в большинстве случаев, там где существуют зависимости, они будут модулями Python. Самый важный момент заключается в просмотре документации. Например, остановимся на модуле bigip_config, который мы выбрали в самом последнем разделе. Беглый обзор раздела Требований (Requirements) в соответствующей доккументации показывает, что он требует (на момент написания книги) модуля Python f5-sdk, причём с версией 3.0.16 или более новой.

Имеется множество способов его установки - некоторые операционные системы могут иметь собственные встроенные пакеты, и, если это возможно, тогда предоставьте им возможность соответствовать требованиям версии, и они исключительно подойдут для использования. На самом деле, это может быть выгодно с точки зрения поддержки поставщиками. Тем не менее, если такой пакет не доступен, модули Python можно запросто устанавливать при помощи инструмента pip. Допустим, что он уже имеется в вашей системе, тогда установка состоит просто в выполнении такой команды:

sudo p ip install f5-sdk
		

Кроме того, не забудьте просмотреть раздел Замечаний (Notes) в соответствующей документации. Продолжая данный пример, мы можем увидеть, что он поддерживает только прогаммное обеспечение BIG-IP версий 12 и выше, поэтому если вы обладаете некой более ранней версией, вам придётся найти иной способ автоматизации своего устройства (либо обновить установленное программное обеспечение чтобы воспользоваться этим вариантом).

После того как ваши модули настроены, и установлены соответствия вашим требованиям (будь то зависимости модуля Python или само программное обеспечение устройства), настало время написания вашего плейбука. Следуя документации по этому модулю, это должно быть простой задачей. Давайте предположим, что мы желаем сбросить установленную конфигурацию некого устройства F5 BIG-IP. Согласно документации, мы можем обнаружить, что параметры аутентификации передаются непосредственно в сам модуль. Кроме того, имеющийся образец кода отображает применение ключевого слова задачи delegate_to; обе эти подсказки наводят нас на мысль что данный модуль не применяет стандартный SSH транспорт Ansible, а вместо того он определяется в самом данном модуле. Следовательно, некий плейбук сброса настроек конфигурации отдельного устройства мог бы выглядеть как- то так:

---
- name: reset an F5
  hosts: localhost
  gather_facts: false

  tasks:
    - name: reset my F5
      bigip_config:
        reset: yes
        save: yes
        server: lb.mastery.example.com
        user: admin
        password: mastery
        validate_certs: no
 	   

В данном случае мы применяем некий имеющийся в тексте документации пример для сброса своей конфигурации. Обратите внимание, что наш параметр hosts определяет лишь localhost, нам не требуется ключевое слово delegate_to, так как в этом плейбуке наш модуль bigip_config будет исполняться лишь localhost.

Таким образом, мы автоматизировали простой, но в противном случае повторяющуюся задачу, которую приходится выполнять вручную. Выполнение данного плейбука состояло бы просто в исполнении такой команды:

ansible-playbook -i mastery-hosts reset-f5.yaml
		

Естественно, чтобы проверить данный плейбук, вам придётся иметь некое устройство F5 BIG-IP, чтобы выполнить это в нём. не каждому оно будет доступно, а потому в следующем разделе нашей главы мы перейдём к демонстрации примера из реальной жизни, с которым сможет работать любой читатель данной книги. Однако намерение данной части книги состоит в предоставлении вам полного обзора интеграции Ansible с вашими сетевыми устройствами, какими бы они не были. Таким образом, имеется надежда, что даже когда у вас имеется не упомянутое здесь устройство, вы осознаёте основы того как заставить его работать.

Большинство сетевых устройств исполняют проприетарное программное обеспечение, которое вы можете получать лишь от самого производителя когда вы у себя имеете в наличии активную подписку. Это может сделать сложным тестирование и изучение данного программного обеспечения, даже когда доступен некий эмулятор для таких сетевых устройств {Прим. пер.: подробнее в нашем переводе Полного руководства работы с сетями на Python Эрика Чоу}. К счастью для нас, имеется Cumulus Linux. Cumulus Linux (от Cumulus Networks) является некой сетевой операционной системой с открытым исходным кодом, которая способна работать на голом железе разнообразных коммутаторов, предлагая подход с открытым исходным кодом для сетевой среды центра обработки данных.

Что ещё лучше, они предлагают свободно распространяемую версию своего программного обеспечения, которая будет работать под гипервизором по вашему выбору для целей тестирования и оценки, с названием Cumulus VX. Все примеры из этой главы основываются на Cumulus VX версии 3.7.3.

Беглый осмотр показывает что Cumulus VX будет применять стандартный метод транспорта SSH в Ansible. Более того, имеется всего лишь единственный модуль, определённый для работы с данной системой - nclu. Для использования этого модуля не требуются никакие предварительно устанавливаемые модули, а потому мы можем продолжить сразу определением своей инвентаризации.

По умолчанию Cumulus VX загружается с интерфейсом управления, настроенным на получение некого IP адреса от DHCP. Он также имеет для нас три порта виртуального коммутатора чтобы выполнить проверку настроек и пограть с ним. Некий образец описи для работы с ним выглядит как- то так:

[cumulus]
mastery-switch1 ansible_host=192.168.81.142

[cumulus:vars]
ansible_user=cumulus
ansible_ssh_pass=CumulusLinux!
 	   

Отметим следующее:

Теперь давайте проверим связь при помощи модуля ping:

Как мы уже обсуждали ранее в этой книге, модуль ping Ansible выполняет полную повсеместную проверку связи, включая аутентификацию на транспортном уровне. В результате, когда вы получаете результаты об успешном тестировании, как те что показаны ранее, мы можем продолжать в полной уверенности и написать свои первые плейбуки.

Все образы Cumulux VX поставляются совершенно не настроенными (за исключением настроек для клиента DHCP по порту управления eth0). Они имеет три порта коммутатора, а именно, swp1, swp2 и swp3. Давайте запросим один из этих интерфейсов на предмет того имеется ли там некая конфигурация. Мы можем воспользоваться неким образцом плейбука с названием switch-query.yaml для запроса swp1:

---
- name: query switch
  hosts: mastery-switch1

  tasks:
  - name: query swp1 interface
    nclu:
      commands:
        - show interface swp1
    register: interface

  - name: print interface status
    debug:
      var: interface
 	   

Когда мы его выполним (ровно также, как мы запускали прочие плейбуки), тогда мы обнаружим нечто подобное следующему:

Это подтверждает наше начальное утверждение относительно данного образа ВМ - мы можем видеть, что данный порт маршрутизатора не настроен. Очень просто превратить эту ВМ в некий простейший коммутатор 2 уровня при помощи Ansible и имеющегося модуля nclu. Наш следующий плейбук, с названием switch-l2-configure.yaml, делает именно это:

---
- name: configure switch
  hosts: mastery-switch1

  tasks:
  - name: bring up ports swp[1-3]
    nclu:
      template: |
        {% for interface in range(1,4) %}
        add interface swp{{interface}}
        add bridge bridge ports swp{{interface}}
        {% endfor %}
      commit: true

  - name: query swp1 interface
    nclu:
      commands:
        - show interface swp1
    register: interface

  - name: print interface status
    debug:
      var: interface
 	   

Обратите внимание, что мы воспользовались неким искусным втроенным шаблоном Jinja2 для запуска циклом for по всем трём интерфейсам, экономя на создании повторяющегося и громоздкого кода. Эти команды поднимают три интерфейса коммутации и добавляют их в имеющийся по умолчанию мост уровня 2.

Наконец, строка commit: true применяет эти изменения непосредственно в самом коммутаторе. Теперь, когда мы запустим это, мы обнаружим иное состояние для swp1:

Как мы можем видеть, наш интерфейс swp1 теперь поднят и выступает частью общего моста, причём готов коммутировать обмен. Обратите внимание, что эта задача по настройке порта была помечена как changed, так как соответствующая конфигурация была применена здесь впервые. Что произойдёт если мы запустим свой плейбук снова без выполнения каких- либо прочих шагов в этом коммутаторе? Давайте посмотрим:

На этот раз состоянием данной задачи является ok, что означает, что наш модуль nclu не выявил никаких изменений, применённых к этому коммутатору. Таким образом, плейбуки, которые автоматизируют соответствующую конфигурацию нашего коммутатора Cumulus Linux являются идемпотентными и получают в результате некое согласованное состояние, даже когда они выполняются многократно. Это также означает, что если данная конфигурация коммутатора снесена (к примеру, из- за вмешательства пользователя), очень просто обнаружить что нечто было изменено. К сожалению, имеющийся модуль nclu в настоящее время не поддерживает режим проверки ansible-playbook, однако, тем не менее, он всё- таки представляет мощный способ настройки настройки и управления вашими коммутаторами.

Автоматизация Cumulux Linux при помощи Ansible на самом деле настолько проста - дальнейшие примеры выходят за рамки предмета книги, поскольку они повлекут за собой более сложное применение команды nclu. Тем не менее, надеемся, что с помощью этих простейших примеров можно увидеть, что автоматизация сетевой инфраструктуры с применением Ansible теперь не сложнее автоматизации чего бы там не было ещё.

При автоматизации сетевых устройств с Ansible используются все имеющиеся обыкновенные наилучшие практические приёмы его применения. Например, никогда не храните пароли в открытом виде и, в случае необходимости, применяйте ansible-vault. Несмотря на это, когда дело касается Ansible, сетевые устройства являются своим собственным классом устройств, а их поддержка действительно начала расцветать с выпуска 2.5 Ansible и последующих версий. Таким образом, когда дело доходит до автоматизации сети при помощи Ansible, есть несколько особых рекомендаций, о которых стоит упомянуть.

Опись

Когда мы рассматриваем организацию вашей сетевой инфраструктуры, будет лучше применять ту структуру описи, которую поддерживает Ansible, причём особое внимание уделяйте группированию. Это значительно облегчит разработку вашего плейбука. Например, допустим что у вас в вашей сетевой среде имеются два коммутаторы- один является коммутатором Linux Cumulus, который мы изучали ранее, а другой это устройство на основе IOS Cisco. Ваша опись может выглядеть так:

[switches:children]
ios
cumulus

[ios]
ios01 ansible_host=ios01.mastery.example.com

[cumulus]
cumulus01 ansible_host=cumulus01.mastery.example.com
 	   

Мы знаем, что мы не можем запускать модуль nclu на чём- то отличающемся от некого коммутатора Cumulus, а потому при неком аккуратном применении оператора when мы можем собирать задачи в плейбуки чтобы гарантировать что мы запускаем верную команду в правильном устройстве. Вот некая задача, которая будет запускаться лишь на устройствах из группы cumulus, которую мы задали в предыдущей описи:

- name: query swp1 interface
    nclu:
      commands:
        - show interface swp1
    register: interface
    when: inventory_hostname in groups['cumulus']
 	   

Аналогично, надлежащее применение группирований делает возможным устанавливать переменные на основе устройств. Хотя вы и не помещаете пароли в открытом виде в свои описи, может так случиться, что все ваши коммутаторы определённого типа применяют одно и то же самое имя пользователя (например, cumulus в случае устройств Linux Cumulus). В качестве альтернативы, может оказаться что ваши устройства IOS требуют для своей работы особых установленных для соединения переменных хоста и для получения эскалации полномочий, которая необходима при осуществлении настройки. Таким образом, мы можем расширить свой предыдущий пример описи добавив такой код:

[cumulus:vars]
ansible_user=cumulus

[ios:vars]
ansible_network_os=ios
ansible_become=yes
ansible_become_method=enable
 	   

Хорошие структура описи и определения переменных сделают гораздо более простой разработку ваших плейбуков, а в результате код будет более управляемым и с ним будет проще работать.

Сбор фактов

Ansible содержит ряд особых модулей обретения фактов для сетевых устройств и они могут быть достаточно полезными для запуска задач по условию, либо просто возвращая обратно данных относительно ваших устройств. Эти модули особых для устройств фактов не запускаются при запуске в самом начале исполнения определённого плейбука, так как на этом этапе Ansible не знает с каким видом устройств он взаимодействует. Тем самым, мы обязаны сообщить ему о необходимости получения для всех устройств надлежащим образом.

Нет никаких особенных модулей фактов для коммутаторов Linux Cumulus (хотя , поскольку он основан на Linux, все факты стандартного хоста всё ещё могут быть собраны). Забегая вперёд относительно примера нашего устройства IOS, мы бы намеренно запустили этот модуль фактов в своём плейбуке на основе некого уникального ключа в нашей описи. Мы знаем, что в своём примере описи, который мы определили в своём последнем разделе, наши коммутаторы IOS Cisco находятся в группе ios, а также имеет ansible_network_os установленным в значение ios. Мы можем применять и то, и другое в качестве условия в операторе when для запуска модуля ios_facts в наших комутаторах - поэтому самое начало нашего плейбука может выглядеть так:

---
- name: "gather device facts"
  hosts: all
  gather_facts: false

  tasks:
  - name: gather ios facts
    ios_facts:
    when: ansible_network_os == 'ios'
  - name: gather cumulus facts
    setup:
    when: inventory_hostname in groups['cumulus']
 	   

Обратите внимание, что мы установили gather_facts в значение false в самом начале этого плейбука. Это делается именно таким образом так как модуль стандартных фактов предназначен для хостов на основе Linux и он бы получил отказ в случае запуска в неком сетевом устройстве, таком как коммутатор IOS Cisco.

Переходные хосты

Наконец, пара слов относительно хостов перехода. Как правило, сетевые устройства расположены за бастионом переходных хостов некого вида по важным причинам безопасности. Ansible предоставляет ряд механизмов для осуществления этого в зависимости от самого транспорта лежащей в основе сетевой среды. Например, связь через SSH (такая как с коммутаторами Linux Cumulus) может применять возможность посредничества команд SSH. Существует ряд способов достижения этого, однако проще всего добавить некую дополнительную переменную группы в данной описи. Скажем, если мы желаем выполнять доступ лишь к своему коммутатору Linix Cumulus через хост с названием bastion01, раздел переменных нашей описи выглядел бы как- то так:

[cumulus:vars]
ansible_user=cumulus
ansible_ssh_pass=CumulusLinux!
ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"'
 	   

Предыдущая команда посредника (proxy) предполагает, что для bastion01 аутентификация без пароля уже настроена и работает.

Подобные этой команды Proxy SSH будут работать для прочих режимов ansible_connection, которые также применяются при управлении сетевыми устройствами, включая netconf и network_cli, предлагая поддержку для хостов перехода для обработки широкого диапазона сетевых устройств. Как всегда, наилучший способ увериться в самом способе для обработки конкретного типа связи состоит в проверке именно ту документацию, которая описывает конкретно ваше сетевое устройство и следовать указанным в ней особым руководствам.

Поскольку всё большая и большая часть нашей инфраструктуры определяется и управляется программно ещё более важным становится действенная автоматизация со стороны Ansible имеющимся сетевым уровнем. С момента выпуска последней редакции данной книги именно в этой области была проделана огромная работа, в особенности с момента выпуска Ansible 2.5. Благодаря этим усовершенствованиям теперь стало просто строить плейбуки для автоматизации сетевых задач, причём начиная с изменения простого устройства, вплоть до раскрутки всей сетевой архитектуры с применением Ansible. Все те преимущества Ansible, которые связаны с повторным применением кода, переносимостью и тому подобному теперь доступны и тем, кто управляет сетевыми устройствами.

В этой главе мы изучили как Ansible делает возможным управление сетевой средой. Вы изучили действенные стратегии обработки различных типов устройств внутри своей инфраструктуры и того как писать для них плейбуки, а затем вы расширили это на некоторые особенные примеры для Linux Cumulus. Наконец, вы изучили некоторые наилучшие практические приёмы, которые могут применяться при использовании Ansible для сетевой инфраструктуры.

Это подводит нас к завершению данной книги. Я надеюсь что вы нашли её полезной, а также что она предоставила вам стратегии и инструменты для управления всем что пожелаете, начиная с небольших изменений конфигурации вплоть до полного развёртывания инфраструктуры с применением Ansible.