По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Все маршрутизаторы добавляют подключенные маршруты. Затем в большинстве сетей используются протоколы динамической маршрутизации, чтобы каждый маршрутизатор изучал остальные маршруты в объединенной сети. Сети используют статические маршруты - маршруты, добавленные в таблицу маршрутизации посредством прямой настройки - гораздо реже, чем динамическая маршрутизация. Однако статические маршруты иногда могут быть полезны, и они также могут быть полезными инструментами обучения.
Статические сетевые маршруты
IOS позволяет назначать отдельные статические маршруты с помощью команды глобальной конфигурации ip route. Каждая команда ip route определяет пункт назначения, который может быть сопоставлен, обычно с идентификатором подсети и маской. Команда также перечисляет инструкции пересылки, обычно перечисляя либо исходящий интерфейс, либо IP-адрес маршрутизатора следующего перехода. Затем IOS берет эту информацию и добавляет этот маршрут в таблицу IP-маршрутизации.
Статический маршрут считается сетевым, когда пункт назначения, указанный в команде ip route, определяет подсеть или всю сеть класса A, B или C. Напротив, маршрут по умолчанию соответствует всем IP-адресам назначения, а маршрут хоста соответствует одному IP-адресу (то есть адресу одного хоста).
В качестве примера сетевого маршрута рассмотрим рисунок 1. На рисунке показаны только детали, относящиеся к статическому сетевому маршруту на R1 для подсети назначения 172.16.2.0/24, которая находится справа. Чтобы создать этот статический сетевой маршрут на R1, R1 настроит идентификатор и маску подсети, а также либо исходящий интерфейс R1 (S0/0/0), либо R2 в качестве IP-адреса маршрутизатора следующего перехода (172.16.4.2).
Схема сети устанавливает соединение между двумя маршрутизаторами R1, R2 и двумя хостами 1 и 2. Порт G0/0 .1 R1 подключен к шлейфу слева, который, в свою очередь, подключен к хосту 1, имеющему подсеть 172.16. 1.9. Интерфейс S0/0/0 R1 последовательно подключен к R2 с IP-адресом 172.16.4.2. Интерфейс G0/0.2 на R2 подключен к шлейфу, который, в свою очередь, подключен к хосту 2 с IP-адресом 172.16.2.0.9. Здесь маршрутизатор R1 предназначен для адреса 172.16.2.0/24 в подсети. Пакеты должны перемещаться либо с интерфейса S0/0/0 маршрутизатора R1, либо с маршрутизатора R2 с IP-адресом 172.16.2.0/24.
В примере 1 показана конфигурация двух примеров статических маршрутов. В частности, он показывает маршруты на маршрутизаторе R1 на рисунке 2 для двух подсетей в правой части рисунка.
При настройке сети маршрутизатор R1 имеет соединение с двумя маршрутизаторами R2 и R3 справа. Интерфейс G0/0 .1 маршрутизатора R1 подключен к заглушке слева и, в свою очередь, подключен к хосту A, имеющему подсеть 172.16.1.9 с маской подсети 172.16.1.0 /24. Справа-интерфейс S0/0/1.1 из R1 с маской подсети 172.16.4.0 / 24 подключается к интерфейсу S0/0/1.2 из R2 с маской подсети 172.16.2.0 / 24 через последовательную линию. Кроме того, интерфейс G0/1/ 0.1 из R1 с маской подсети 172.16.5.0 / 24 подключается к интерфейсу G0/0/0 .3 из R3 с маской подсети 172.16.3.0 / 24 через глобальную сеть. Заглушка подключается к интерфейсу G0/0 .2 из R2, где маска подсети равна 172.16.2.0 / 24 и, в свою очередь, подключена к хосту B, имеющему подсеть 172.16.2.9. Заглушка подключается к интерфейсу G0/0 .3 из R3, где маска подсети равна 172.16.3.0 / 24 и, в свою очередь, подключена к хосту C, имеющему подсеть 172.16.3.9.
ip route 172.16.2.0 255.255.255.0 S0/0/0
ip route 172.16.3.0 255.255.255.0 172.16.5.3
Пример 1 Добавление статических маршрутов в R1
В двух примерах команд ip route показаны два разных стиля инструкций пересылки. Первая команда показывает подсеть 172.16.2.0, маска 255.255.255.0, которая находится в локальной сети рядом с маршрутизатором R2. Эта же первая команда перечисляет интерфейс S0 / 0/0 маршрутизатора R1 как исходящий интерфейс. Этот маршрут в основном гласит: Чтобы отправить пакеты в подсеть с маршрутизатора R2, отправьте их через мой собственный локальный интерфейс S0/0/0 (который подключается к R2).
Второй маршрут имеет такую же логику, за исключением использования различных инструкций пересылки. Вместо того, чтобы ссылаться на исходящий интерфейс R1, он вместо этого перечисляет IP-адрес соседнего маршрутизатора на WAN-канале в качестве маршрутизатора следующего прыжка. Этот маршрут в основном говорит следующее:чтобы отправить пакеты в подсеть с маршрут.
Маршруты, созданные этими двумя командами ip route, на самом деле выглядят немного иначе в таблице IP-маршрутизации по сравнению друг с другом. Оба являются статическими маршрутами. Однако маршрут, который использовал конфигурацию исходящего интерфейса, также отмечается как подключенный маршрут; это всего лишь причуда вывода команды show ip route.
В примере 2 эти два маршрута перечислены с помощью статической команды show ip route. Эта команда выводит подробную информацию не только о статических маршрутах, но также приводит некоторые статистические данные обо всех маршрутах IPv4. Например, в этом примере показаны две строки для двух статических маршрутов, настроенных в примере 2, но статистика утверждает, что этот маршрутизатор имеет маршруты для восьми подсетей.
IOS динамически добавляет и удаляет эти статические маршруты с течением времени в зависимости от того, работает исходящий интерфейс или нет. Например, в этом случае, если интерфейс R1 S0/0/0 выходит из строя, R1 удаляет статический маршрут к 172.16.2.0/24 из таблицы маршрутизации IPv4. Позже, когда интерфейс снова открывается, IOS добавляет маршрут обратно в таблицу маршрутизации.
Обратите внимание, что большинство сайтов используют протокол динамической маршрутизации для изучения всех маршрутов к удаленным подсетям, а не статические маршруты. Однако если протокол динамической маршрутизации не используется, сетевому администратору необходимо настроить статические маршруты для каждой подсети на каждом маршрутизаторе. Например, если бы маршрутизаторы имели только конфигурацию, показанную в примерах до сих пор, ПК А (из рис. 2) не смог бы получать пакеты обратно от ПК В, потому что маршрутизатор R2 не имеет маршрута для подсети ПК А. R2 понадобятся статические маршруты для других подсетей, как и R3.
Наконец, обратите внимание, что статические маршруты, которые будут отправлять пакеты через интерфейс Ethernet - LAN или WAN, - должны использовать параметр IP-адреса следующего перехода в команде ip address, как показано в примере 2. Маршрутизаторы ожидают, что их интерфейсы Ethernet смогут достичь любого количества других IP-адресов в подключенной подсети. Ссылка на маршрутизатор следующего перехода определяет конкретное устройство в подключенной подсети, а ссылка на исходящий интерфейс локального маршрутизатора не определяет конкретный соседний маршрутизатор.
Статические маршруты хоста
Ранее в этой лекции маршрут хоста определялся как маршрут к одному адресу хоста. Для настройки такого статического маршрута команда ip route использует IP-адрес плюс маску 255.255.255.255, чтобы логика сопоставления соответствовала только этому одному адресу.
Сетевой администратор может использовать маршруты хоста для направления пакетов, отправленных одному хосту по одному пути, а весь остальной трафик - в подсеть этого хоста по другому пути. Например, вы можете определить эти два статических маршрута для подсети 10.1.1.0 / 24 и Хоста 10.1.1.9 с двумя различными адресами следующего перехода следующим образом:
ip route 10.1.1.0 255.255.255.0 10.2.2.2
ip route 10.1.1.9 255.255.255.255 10.9.9.9
Обратите внимание, что эти два маршрута перекрываются: пакет, отправленный в 10.1.1.9, который поступает на маршрутизатор, будет соответствовать обоим маршрутам. Когда это происходит, маршрутизаторы используют наиболее конкретный маршрут (то есть маршрут с наибольшей длиной префикса). Таким образом, пакет, отправленный на 10.1.1.9, будет перенаправлен на маршрутизатор следующего прыжка 10.9.9.9, а пакеты, отправленные в другие пункты назначения в подсети 10.1.1.0/24, будут отправлены на маршрутизатор следующего прыжка 10.2.2.2.
Плавающие статические маршруты
Затем рассмотрим случай, когда статический маршрут конкурирует с другими статическими маршрутами или маршрутами, изученными протоколом маршрутизации. То есть команда ip route определяет маршрут к подсети, но маршрутизатор также знает другие статические или динамически изученные маршруты для достижения этой же подсети. В этих случаях маршрутизатор должен сначала решить, какой источник маршрутизации имеет лучшее административное расстояние, а чем меньше, тем лучше, а затем использовать маршрут, полученный от лучшего источника.
Чтобы увидеть, как это работает, рассмотрим пример, проиллюстрированный на рисунке 3, который показывает другую конструкцию, чем в предыдущих примерах, на этот раз с филиалом с двумя каналами WAN: одним очень быстрым каналом Gigabit Ethernet и одним довольно медленным (но дешево) Т1. В этом проекте сеть Open Shortest Path First Version 2 (OSPFv2) по первичному каналу, изучая маршрут для подсети 172.16.2.0/24. R1 также определяет статический маршрут по резервному каналу к той же самой подсети, поэтому R1 должен выбрать, использовать ли статический маршрут или маршрут, полученный с помощью OSPF.
Сетевая диаграмма показывает интерфейс G0 / 0 маршрутизатора R1, который подключен к маршрутизатору R2 через ethernet через облако MPLS. Интерфейс S0 / 0 / 1 R1 соединен с маршрутизатором R3 по последовательной линии. R2 и R3 соединены в ядре облака корпоративной сети, имеющего подсеть 172.16.2.0/24. Маршрутизатор R1 достигает подсети либо по OSPF v1 по основному каналу, либо по статическому маршруту по резервному каналу.
По умолчанию IOS отдает предпочтение статическим маршрутам, чем маршрутам, изученным OSPF. По умолчанию IOS предоставляет статическим маршрутам административное расстояние 1, а маршрутам OSPF-административное расстояние 110. Используя эти значения по умолчанию на рисунке 3, R1 будет использовать T1 для достижения подсети 172.16.2.0 / 24 в этом случае, что не является удачным решением. Вместо этого сетевой администратор предпочитает использовать маршруты, изученные OSPF, по гораздо более быстрому основному каналу и использовать статический маршрут по резервному каналу только по мере необходимости, когда основной канал выходит из строя.
Чтобы отдавать предпочтение маршрутам OSPF, в конфигурации необходимо изменить настройки административного расстояния и использовать то, что многие сетевики называют плавающим статическим маршрутом. Плавающий статический маршрут перемещается в таблицу IP-маршрутизации или перемещается из нее в зависимости от того, существует ли в настоящее время лучший (меньший) маршрут административного расстояния, полученный протоколом маршрутизации. По сути, маршрутизатор игнорирует статический маршрут в то время, когда известен лучший маршрут протокола маршрутизации.
Чтобы реализовать плавающий статический маршрут, вам необходимо использовать параметр в команде ip route, который устанавливает административное расстояние только для этого маршрута, делая значение больше, чем административное расстояние по умолчанию для протокола маршрутизации. Например, команда ip route 172.16.2.0 255.255.255.0 172.16.5.3 130 на маршрутизаторе R1 будет делать именно это - установив административное расстояние статического маршрута равным 130. Пока основной канал остается активным, а OSPF на маршрутизаторе R1 изучает маршрут для 172.16.2.0/24, с административным расстоянием по умолчанию 110, R1 игнорирует статический маршрут.
Наконец, обратите внимание, что хотя команда show ip route перечисляет административное расстояние большинства маршрутов в виде первого из двух чисел в двух скобках, команда show ip route subnet явно указывает административное расстояние. В примере 3 показан образец, соответствующий этому последнему примеру.
Статические маршруты по умолчанию
Когда маршрутизатор пытается маршрутизировать пакет, он может не совпадать с IP-адресом назначения пакета ни с одним маршрутом. Когда это происходит, маршрутизатор обычно просто отбрасывает пакет.
Маршрутизаторы могут быть сконфигурированы таким образом, чтобы они использовали либо статически настроенный, либо динамически изучаемый маршрут по умолчанию. Маршрут по умолчанию соответствует всем пакетам, так что, если пакет не соответствует какому-либо другому более конкретному маршруту в таблице маршрутизации, маршрутизатор может, по крайней мере, переслать пакет на основе маршрута по умолчанию.
Классический пример, когда компании могут использовать статические маршруты по умолчанию в своих корпоративных сетях TCP / IP, - это когда компания имеет много удаленных узлов, каждый из которых имеет одно относительно медленное WAN-соединение. Каждый удаленный узел имеет только один возможный физический маршрут для отправки пакетов в остальную часть сети. Таким образом, вместо использования протокола маршрутизации, который отправляет сообщения по глобальной сети и использует драгоценную полосу пропускания глобальной сети, каждый удаленный маршрутизатор может использовать маршрут по умолчанию, который направляет весь трафик на центральный сайт, как показано на рисунке 4.
Соединение состоит из трех маршрутизаторов: Core, B1 и B1000. Последовательные соединения показаны между маршрутизаторами Core - B1 и Core - B1000. Все эти маршрутизаторы подключены к подсети индивидуально. Маршрутизатор B1 отправляет все нелокальные пакеты в Core через интерфейс S0/0/1. Существует также связь между B1 и B1000.
IOS позволяет настроить статический маршрут по умолчанию, используя специальные значения для полей подсети и маски в команде ip route: 0.0.0.0 и 0.0.0.0. Например, команда ip route 0.0.0.0 0.0.0.0 S0/0/1 создает статический маршрут по умолчанию на маршрутизаторе B1-маршрут, который соответствует всем IP-пакетам-и отправляет эти пакеты через интерфейс S0/0/1.
В примере 4 показан пример статического маршрута по умолчанию с использованием маршрутизатора R2 с рисунка 1. Ранее на этом рисунке вместе с примером 3 был показан маршрутизатор R1 со статическими маршрутами к двум подсетям в правой части рисунка. Пример 4 завершает настройку статических IP-маршрутов путем настройки R2 в правой части рисунка 1 со статическим маршрутом по умолчанию для маршрутизации пакетов обратно к маршрутизаторам в левой части рисунка.
Вывод команды show ip route содержит несколько новых и интересных фактов. Во-первых, он перечисляет маршрут с кодом S, что означает статический, но также со знаком *, что означает, что это кандидат в маршрут по умолчанию. Маршрутизатор может узнать о нескольких маршрутах по умолчанию, и затем маршрутизатор должен выбрать, какой из них использовать; * означает, что это, по крайней мере, кандидат на то, чтобы стать маршрутом по умолчанию. Чуть выше "шлюз последней надежды" относится к выбранному маршруту по умолчанию, который в данном случае является только что настроенным статическим маршрутом с исходящим интерфейсом S0/0/1.
BGP (Border Gateway Protocol) - это протокол граничного шлюза, предназначенный для обмена информацией о маршрутизации и доступности между автономными системами (AS) в Интернете. Пока не пугайся - к тому, что такое автономная система мы еще вернемся.
Упрощая: BGP - это метод маршрутизации, который позволяет интернету функционировать. Без него вы бы не смогли выполнять поиск в гугле, даже посмотреть эту статью. Можно уверенно сказать, что BGP, наряду с DNS, являются самыми важными для Интернета протоколами.
Существует 2 типа BGP - iBGP для маршрутизации внутри сети, где i обозначает Internal и eBGP для внешней (External) маршрутизации, хотя его обычно называют просто - BGP.
Немного истории
Когда-то во всем интернете было всего лишь несколько сетей, связанных друг с другом статичными маршрутами. То есть админы вручную на роутерах прописывали маршрут до нужной сети - такой маршрут и называется статичным.
Но интернет недолго оставался маленьким. Стало появляться все больше и больше сетей, что потребовало динамического метода обмена информацией о маршрутах. Так появился EGP (Exterior Gateway Protocol) - протокол внешнего шлюза.
Это был простой протокол маршрутизации, который работал по древовидной иерархической топологии, то есть как веточки у дерева. Это когда чтобы добраться до точки E или F, A должен пройти через B, C и D.
Другими словами - при EGP, ни о какой интеллектуальной, как видосы на нашем канале, маршрутизации не могло быть и речи. И когда Интернет стал ещё больше, недостатки EGP стали очевидны всем. Так и появился BGP.
Autonomous System
В самом начале мы обещали вернуться к автономным системам: так вот Autonomous System или AS это сеть или набор подсетей, которые объединены общей внутренней политикой маршрутизации.
Внутри этих подсетей работает свой протокол маршрутизации, например OSPF или EIGRP. Это мы и называем внутренней политикой маршрутизации.
Автономными системами управляют отдельные организации, как правило - интернет-провайдеры, различные ВУЗы, коммерческие компании или крупные корпорации типа Google или Facebook.
Даже ты сейчас сидишь в какой-то AS. Вот например AS в которой находится наша база знаний wiki.merionet.ru.
Каждая AS имеет свой уникальный номер - AS Number (ASN) и диапазон IP адресов, то есть подсеть. А BGP обеспечивает обмен информацией о маршрутах между этими системами.
BGP в деталях
Так как на BGP возложена великая задача – соединение автономных систем во всем Интернете, то он должен быть очень надежным. Так что в самом начале работы, BGP-маршрутизатор инициирует установление TCP сессии на 179 порт к своему соседу
Если TCP-сессия установлена успешно, то BGP-маршрутизаторы начинают обмен сообщениями OPEN в котором сообщают свои номер автономной системы (ASN), идентификатор маршрутизатора, который называется RouterID и Hold timer.
Hold timer это время, в течение которого будет поддерживаться TCP-сессия. Если одному роутеру что-то не понравится, например не совпадёт информация о номере AS, то сообщением NOTIFICATION он уведомит об этом своего соседа и сбросит TCP-сессию.
Соединение по BGP должно быть абсолютно согласовано администраторами автономных систем, желающих организовать стык.
Если, скажем, администратор AS1 запустил процесс BGP на маршрутизаторе R1 указав в качестве соседа R2 и его ASN, а администратор AS2 ничего не настроил, то TCP-сессия не поднимется и системы так и останутся несвязными. Да, все верно, администраторы настраивают BGP вручную.
Если же все условия соблюдаются, то маршрутизаторы, с определенным интервалом, начинают слать друг другу сообщения KEEPALIVE, означающие “Я ещё жив и со мной можно работать!”
Наконец, маршрутизаторы могут приступать к обмену маршрутной информацией по средствам сообщения UPDATE. Структура данного сообщения делится на две части:
Path Attributes (Атрибуты пути) - здесь указывается из какой AS поступил маршрут, его происхождение и следующий маршрутизатор для данного пути.
NRLI (Network Layer Reachability Information) - здесь указывается информация о сетях, которые нужно добавить в таблицу маршрутизации, т.е IP-адрес сети и ее маска.
Сообщение UPDATE будет передаваться каждый раз, когда один из маршрутизаторов получит информацию о новых сетях, а сообщение KEEPALIVE на протяжении всей TCP-сессии.
BGP принимает решения о наилучшем пути на основе текущей сложности маршрута, количестве хопов (то есть точек маршрутизации) и других характеристик пути. BGP анализирует все данные и устанавливает одного из своих соседей в качестве следующей остановки для пересылки пакетов в определенную сеть.
Каждый узел управляет таблицей со всеми известными ему маршрутами для каждой сети и передает эту информацию своим соседним автономным системам. Таким образом, BGP позволяет роутерам собирать всю информацию о маршрутизации из соседних автономных систем и далее анонсировать эту информацию соседям.
Именно таким образом и работает маршрутизация во всем Интернете.
Сбои в работе BGP ни раз приводили к недоступности целых частей Интернета. Помнишь как в октябре 2021 во всем мире прилёг Facebook, а с ним и остальные его сервисы - Instagram, WhatsApp?
Это случилось потому, что из-за ошибки инженеров, информация о маршрутах к серверам Facebook, которая рассылается, как ни странно, по протоколу BGP, была удалена, а это вызвало невозможность разрешения доменного имени Facebook по DNS. Дошло до того, что инженерам FB пришлось выпиливать двери в серверную, чтоб всё починить, потому что система пропусков тоже была завязана на их сервисы и не работала!
Как и множество других инструментов для управления и автоматизации на рынке программного обеспечения, Ansible был изначально open – source проектом (с открытым исходным кодом), который предназначался для автоматизации настройки и деплоймента (развертывания) ПО в сетевых контурах компаний. Чего скрывать, продукт «стрельнул» - когда компания AnsibleWorks это поняла, начала активную монетизацию через коммерческую поддержку продукта для корпоративных заказчиков.
/p>
В настоящее время их продуктовая линейка состоит из двух направлений - Ansible и Ansible Tower, причем последний обладает полноценным интерфейсом управления (UI) и возможностью реализации дашбордов.
Ansible - новые ребята в DevOps направлении, по сравнению, например, с Chef или Puppet, но успели круто зарекомендовать себя в сообществе профессионалов за простоту и скоуп возможностей. Его playbooks понятны и легко читаемы, даже без особых знаний.
Так к чему это все? В «правильных руках», где присутствует полное понимание плюсов и минусов продукта Ansible может работать еще круче :) Поэтому, хотим рассказать про 5 лучших и 5 худших свойств Ansible.
Playbooks в Ansible это файл в формате YAML, который содержит последовательность состояния ресурсов системы, задач, которые позволяет запустить то или состояние сервера.
Что такое DevOps, что нужно знать и сколько получают DevOps - специалисты?
5 лучших качеств Ansible
Легкость в изучении
По правде говоря, это одно из самых крутых качеств Ansible – изучить его можно за один вечер и уже запускать веб – сервер из YAML, например. Ansible задачи запускаются последовательно, что сильно облегчает траблшутинг конфигураций. Например, можно сделать Playbook для Ansible, который позволит получить минимальный веб сервер примерно так:
Создаем файл формата .yml и наполняем командами;
Установить через yum apache;
Запустить apache как сервис в операционной системе;
Скопировать в корень веб – сервера html страничку с заглушкой («Мы готовим информацию по сайту, скоро здесь все будет, бла бла бла..»);
Скорректировать iptables, открыв порты и сохранить конфигурацию;
Не сложно, не правда ли?
Написан на Python
Я, как автор статьи, подметил следующее: если мы возьмем 10 программистов, вероятность, что кто-то из них знает Python гораздо выше, чем то, что кто – то из них знает Ruby. Именно это делает Ansible крутым – он написан на питоне в отличие от Ruby – based конкурентов. Так же отмечу, что Python библиотека, обычно, по умолчанию присутствует в любом Linux дистрибутиве, чего не сказать о Ruby.
Продолжая экскурсию – Ansible поддерживает написание модулей на любом языке программирования. Единственное требование – формат ответа. Это должен быть JSON.
Не нужно ставить клиента (агента) на машину
Для управления узлами, Ansible обрабатывает все коммуникации между мастер – узлами и узлами – агентами по стандартному SSH, или через модуль Paramiko, который является частью Python SSH второй версии.
Не нужно ставить агентское ПО на удаленные машины – только SSH подключение. Как следствие, упрощение обслуживания и траблшутинга.
YAML плейбуки
Как мы писали ранее, плейбуки в Ансибл невероятно просты и читаемы. Все DevOps инженеры, с которыми мы обсуждали его, освоили их за один вечер. Они даже проще чем JSON :)
Портал Ansible Galaxy
Портал, на котором вы наверняка найдете решение для своей задачи. Это объединение Ansible сообщества, где люди делятся наработками и решениями той или иной задачи. Знаете, это как ответ на мэйл.ру - чтобы вам не пришло реализовать на Ансибл, то как правило, кто – то эту задачу уже решил :). Тонны плейбуков, фреймворков, дистрибутивов и сопутствующего ПО.
5 худших качеств Ansible
Настало время хорошенько пройтись по Ansible и выделить минусы продукта. Пожестим.
Проблемы с интерфейсом (UI)
Изначально Ansible разработан для работы с командной строкой. Первые наметки в сторону визуализации конфигурации Ансибл начались через AWX – графический интерфейс пользователя, который являлся первой попыткой упрощения конфигураций через интерфейсную составляющую. В последствии, AWX превратился в Anbile Tower, который дает возможность через GUI управлять Ansible, рисовать workflow и так далее.
Несмотря на улучшение Tower перед AWX, он все равно позволяет делать только 85% рабочего функционала Ansible, который можно делать через командную строку. В добавок, конфигурации внесенный через интерфейс зачастую не синхронизируются с CLI – конфигами.
Ansible Tower находится на стадии разработки и пока весьма сыроват.
Нет работы с состоянием машин/процессов
Если сравнивать с тем же Puppet, Ansible не имеет понятия «состояние» и, соответственно, не отслеживает его. Ансибл не смотрит на зависимости, а просто выполняет последовательный ряд задач/процессов. Для кого – то это нормально и удовлетворяет поставленным задачам, но есть и другие пользователи, у которых от такой работы, мягко говоря, «подгорает» :)
Слабая поддержка совместимости с Windows
С версии 1.7 Ansible умеет работать с Unix и Windows узлами, но надо признаться, работа с первыми реализована гораздо лучше. Взаимодействие с Windows машинами происходит через PowerShell, и, что важно, вам все равно потребуется Linux хост (управляющая тачка) для такой коммуникации.
Ждем, когда Ansible разрабы разгребут бэклог по работе продукта с Windows.
Поддержка крупного бизнеса
Ansible Enterprise Tower и Premiun Tower имеют 8х5х4 и 24х7х2 SLA соответственно, но имеют меньше опыта поддержки крупняков, в сравнении, например, с Chef и Puppet.
Новизна продукта
Ansible находится на рынке меньше своих конкурентов и, само собой, баги будут всплывать. К тому же, комьюнити Ансибл только растет и развивается, в отличие от более крупных игроков, упомянутых в этой статье.
Итоги
Подведем черту: Ansible это просто, гибкий и мощный инструмент, для управления конфигами и автоматизацией. Ansible Tower имеет графический веб – интерфейс, REST API, с помощью которого вы можете интегрировать свой сторонние приложения и поддержку, которая только учится и осваивает азы сопровождения крупного энтерпрайза.
Ansible – новинка, которая имеет своих ранних последователей, противников, сторонников. Сочетая в себе большое количество плюсов, он, конечно, имеет ряд недостатков или так сказать «ранних болезней», через которые уже прошли более крупные конкуренты.
Но кто знает, что покажет нам Ansible завтра?