По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Виртуальные сети - это, в простейшем виде, создание логических топологий, построенных на основе физической топологии. Эти логические топологии часто называют виртуальными топологиями - отсюда и концепция виртуализации сети. Эти топологии могут состоять из одного виртуального канала в более крупной сети, называемого туннелем, или набора виртуальных каналов, которые кажутся полной сетью поверх физической сети, называемой наложением.
Этот раздел лекций начнется с обсуждения того, почему создаются и используются виртуальные топологии, проиллюстрированные двумя примерами использования. Во втором разделе этих лекций будут рассмотрены проблемы, которые должно решить любое решение виртуализации, а в третьем разделе будут рассмотрены сложности при виртуализации сети. Далее будут рассмотрены два примера технологий виртуализации: сегментная маршрутизация (segment routing-SR) и программно - определяемые глобальные сети (Software-Defined Wide Area Networks- SD-WAN).
Понимание виртуальных сетей
Виртуализация усложняет проектирование протоколов, сетей и устранение неполадок, так зачем же виртуализировать? Причины, как правило, сводятся к разделению нескольких потоков трафика в одной физической сети. Это может показаться подозрительно похожим на другую форму мультиплексирования, потому что это еще одна форма мультиплексирования. Основные различия между рассмотренными до сих пор формами мультиплексирования и виртуализацией заключаются в следующем:
Позволяет нескольким плоскостям управления работать с различными наборами информации о достижимости в рамках одной физической топологии;
Позволяет нескольким наборам достижимых пунктов назначения работать в одной физической топологии без взаимодействия друг с другом;
Рассмотренные до этого момента методы мультиплексирования были сосредоточены на том, чтобы позволить нескольким устройствам использовать одну физическую сеть (или набор проводов), позволяя каждому устройству взаимодействовать с любым другим устройством (при условии, что они знают друг о друге с точки зрения достижимости). Виртуализация направлена на разбиение одной физической сети на несколько доменов достижимости, где каждое устройство в домене достижимости может взаимодействовать с любым другим устройством в том же домене достижимости, но устройства не могут связываться между доменами достижимости (если нет какой-либо точки соединения между достижимостью домены).
На рисунке 1 показана сеть с виртуальной топологией, расположенной поверх физической топологии.
На рисунке 1 виртуальная топология была создана поверх физической сети, с виртуальным каналом [C,H], созданным для передачи трафика по сети. Чтобы создать виртуальную топологию, C и H должны иметь некоторую локальную информацию пересылки, отделяющую физическую топологию от виртуальной топологии, которая обычно проходит либо через E, либо через D. Это обычно принимает форму либо специального набора записей виртуального интерфейса в локальной таблице маршрутизации, либо таблицы виртуальной маршрутизации и пересылки (VRF), содержащей только информацию о виртуальной топологии.
Рассмотрение потока пакетов через виртуальную топологию может быть полезно для понимания этих концепций. Как бы выглядел поток пакетов, если бы C и H имели виртуальные интерфейсы? Рисунок 2 демонстрирует это.
На рисунке 2 процесс пересылки выполняется следующим образом:
A передает пакет к M.
C получает этот пакет и, исследуя свою локальную таблицу маршрутизации, находит, что кратчайший путь к месту назначения лежит через виртуальный интерфейс к H. Этот виртуальный интерфейс обычно называется туннельным интерфейсом; он выглядит с точки зрения таблицы маршрутизации, как и любой другой интерфейс маршрутизатора.
Виртуальный интерфейс, через который необходимо передать пакет, имеет инструкции перезаписи, которые включают добавление нового заголовка, заголовка туннеля или внешнего заголовка в пакет и пересылку полученного пакета. Исходный заголовок пакета теперь называется внутренним заголовком. C добавляет внешний заголовок и обрабатывает новый пакет для пересылки.
Теперь C исследует новый пункт назначения, которым является H (помните, что исходным пунктом назначения был M). H не подключен напрямую, поэтому C необходимо выяснить, как достичь H. Это называется рекурсивным поиском, поскольку C ищет путь к промежуточному месту назначения, чтобы доставить пакет к конечному месту назначения, но не к нему.
Теперь C поместит правильную информацию в пакет в заголовок link local, чтобы перенаправить трафик на E.
Когда E получает этот пакет, он удаляет внешнюю информацию о переадресации, Заголовок link local и пересылает трафик на основе первого заголовка C, помещенного в пакет, во время первоначального поиска. Этот внешний заголовок говорит E переслать пакет в H; E не видит и не включает исходный внутренний заголовок, помещенный на пакет A.
E добавит новый Заголовок link local, чтобы пакет был правильно переадресован в H, и передаст пакет по правильному интерфейсу.
Когда H получает пакет, он удаляет Заголовок link local и обнаруживает внешний заголовок. Внешний заголовок говорит, что пакет предназначен для самого H, поэтому он очистит этот заголовок и обнаружит исходный заголовок пакета или внутренний заголовок.
Теперь H посмотрит в своей локальной таблице маршрутизации и обнаружит, что M локально подключен. H поместит правильный Заголовок link local в пакет и передаст его через правильный интерфейс, чтобы пакет достиг M.
Если C и H используют VRF, а не туннельные интерфейсы, процесс в предыдущем списке изменяется на шагах 2 и 8. На шаге 2 C будет искать M как пункт назначения в VRF, связанном каналом [A, C]. Когда C обнаруживает, что трафик к M должен пересылаться через виртуальную топологию через H, он помещает внешний заголовок в пакет и снова обрабатывает пакет на основе этого внешнего заголовка через базовый VRF или, скорее, таблицу маршрутизации, представляющую физическую топологию. Когда H получает пакет, он удаляет внешний заголовок и снова обрабатывает пакет, используя VRF, к которому подключен M, для поиска информации, необходимой для пересылки трафика в его конечный пункт назначения. В этом случае интерфейс туннеля заменяется отдельной таблицей пересылки; вместо того, чтобы обрабатывать пакет через одну и ту же таблицу дважды с использованием двух разных адресатов, пакет обрабатывается через две разные таблицы пересылки.
Термин туннель имеет много различных определений; в этих статьях туннель будет использоваться для описания виртуального канала, где внешний заголовок используется для инкапсуляции внутреннего заголовка, и:
Внутренний заголовок находится на том же уровне или более низком уровне, чем внешний заголовок (например, заголовок Ethernet, переносимый внутри заголовка IPv6; обычно IPv6 переносится внутри Ethernet).
По крайней мере, некоторые сетевые устройства на пути, будь то виртуальные или физические, пересылают пакет только на основе внешнего заголовка.
Переход от виртуальных интерфейсов к VRFs концептуально отличается достаточно, чтобы породить различные описательные термины. Underlay -это физическая (или потенциально логическая!) топология, через которую туннелируется трафик. Overlay - это набор туннелей, составляющих виртуальную топологию. В большинстве случаев термины Underlay и Overlay не используются с отдельными туннелями или в случае службы, работающей через общедоступный Интернет. Сервис, который создает виртуальную топологию через общедоступный Интернет, часто называют сервисом over-the-top.
Опять же, эти термины используются в некоторой степени взаимозаменяемо и даже очень небрежно в более широком мире сетевой инженерии. На этом фоне пора перейти к вариантам использования, чтобы узнать о наборе проблем, которые необходимо решить виртуализацией.
Предоставление услуг Ethernet по IP-сети.
Хотя приложения не должны создаваться с использованием подключения Ethernet в качестве базового, многие из них это делают. Например:
Некоторые поставщики систем хранения данных и баз данных строят свои устройства с предположением, что подключение Ethernet означает короткое расстояние и короткую задержку, или они проектируют системы поверх проприетарных транспортных протоколов непосредственно поверх кадров Ethernet, а не поверх пакетов интернет-протокола (IP).
Некоторые продукты виртуализации включают в свои продукты предположения о возможности подключения, такие как надежность кеширования Ethernet для IP-адресов для шлюза по умолчанию и других доступных мест назначения.
Для таких приложений требуется то, что выглядит как соединение Ethernet между устройствами (физическими или виртуальными), на которых работают различные узлы или копии приложения. Помимо этого, некоторые сетевые операторы считают, что запуск большого плоского домена Ethernet проще, чем запуск крупномасштабного IP-домена, поэтому они предпочли бы создавать самые большие домены Ethernet, которые они могут ("коммутация, где можно, маршрутизация, где необходимо", была распространенная поговорка в те времена, когда коммутация выполнялось аппаратно, а маршрутизация выполнялась программно, поэтому коммутация пакетов выполнялась намного быстрее, чем их маршрутизация). Некоторые кампусы также построены с основной идеей - никогда не просить устройство коммутировать свой IP-адрес после подключения. Поскольку пользователи могут быть подключены к разным сегментам Ethernet в зависимости от их домена безопасности, каждый сегмент Ethernet должен быть доступен в каждой точке беспроводного доступа и часто на каждом порте Ethernet в кампусе.
Учитывая сеть, основанную на IP, которая предполагает Ethernet как один из многих транспортных средств, поверх которых будет работать IP, как вы можете обеспечить подключение Ethernet к устройствам, связанным по IP-сети? На рисунке 3 показаны задачи, которые необходимо решить.
На рисунке 3 процесс, работающий на A с IP-адресом 2001:db8:3e8:100::1, должен иметь возможность взаимодействовать со службой, работающей на B с IP-адресом 2001:db8:3e8:100::2, как если бы они находились в одном сегменте Ethernet (две службы должны видеть друг друга в обнаружении соседей и т. д.). Чтобы сделать проблему более сложной, служба на A также должна иметь возможность перемещаться в K без изменения своего локального кэша обнаружения соседей или маршрутизатора по умолчанию. Сама сеть, является маршрутизируемой сетью, работающей под управлением IPv6.
Что необходимо для выполнения требований?
Должен быть способ передачи кадров Ethernet по IP-сети, разделяющей серверы. Обычно это будет своего рода туннельная инкапсуляция, как описано в начале этого раздела. Туннелирование позволило бы принимать кадры Ethernet на C, например, инкапсулированные в какой-то внешний заголовок, чтобы их можно было транспортировать по маршрутизируемой сети. Когда пакет, содержащий кадр Ethernet, достигает D, этот внешний заголовок может быть удален, и кадр Ethernet пересылается локально. С точки зрения D, фрейм имеет локальное происхождение.
Должен быть способ узнать о пунктах назначения, доступных через туннель, и привлечь трафик в туннель. На самом деле это две отдельные, но взаимосвязанные проблемы. Привлечение трафика в туннель может включать запуск второй плоскости управления с ее собственными VRFs или добавление дополнительной информации в существующую плоскость управления об адресах Ethernet Media Access Control (MAC), доступных на каждом пограничном маршрутизаторе.
Может потребоваться перенести маркировку качества обслуживания (QoS) из внутреннего заголовка во внешний заголовок, чтобы трафик обрабатывался правильно при его пересылке.
Виртуальный частный доступ к корпоративной сети.
Почти в каждой организации есть какие-то удаленные сотрудники, либо на полную ставку, либо просто люди, которые перемещаются, и у большинства организаций есть какие-то удаленные офисы, где часть сотрудников работает вдали от главного офиса, чтобы напрямую взаимодействовать с местным организациями в некоторых отраслях, например, с покупателями или поставщиками. Все эти люди по-прежнему нуждаются в доступе к сетевым ресурсам, таким как электронная почта, системы путешествий, файлы и т. д. Эти службы, конечно, не могут быть доступны в общедоступном Интернете, поэтому необходимо предоставить какой-то другой механизм доступа. На рисунке 4 показаны типичное проблемное пространство.
В этом варианте использования есть две основные проблемы:
Как можно защитить трафик между отдельным хостом - B - и тремя хостами в небольшом офисе - C, D и E - от перехвата и чтения злоумышленником? Как можно защитить сами адреса назначения от попадания в публичную сеть? Эти проблемы связаны с некоторой защитой, которая, в свою очередь, подразумевает некоторую форму инкапсуляции пакетов.
Как можно управлять качеством работы пользователей в этих удаленных местах для поддержки передачи голоса по IP и других приложений в реальном времени? Поскольку провайдеры в Интернете не поддерживают QoS, необходимо обеспечить другие формы гарантии качества.
Таким образом, задача, которую необходимо решить, включает еще две общие проблемы.
Должен быть способ инкапсулировать трафик, передаваемый по общедоступной сети, без раскрытия исходной информации заголовка и без подвергания информации, содержащейся в пакете, для проверки. Самым простым решением этих проблем является туннелирование (часто в зашифрованном туннеле) трафика от A и F к граничному маршрутизатору в сети организации G, где инкапсуляция может быть удалена, а пакеты перенаправлены на A.
Должен быть способ объявить достижимые пункты назначения от G к удаленным пользователям, а также существование (или достижимость) удаленных пользователей к G и сети позади G. Эта информация о достижимости должна использоваться для привлечения трафика в туннели. В этом случае плоскости управления может потребоваться перенаправить трафик между различными точками входа и выхода в общедоступную сеть и попытаться контролировать путь трафика через сеть, чтобы обеспечить удаленным пользователям хорошее качество работы.
Подведем итоги
Два варианта использования, показанные выше, актуализируют два вопроса, которые должно решить каждое решение сетевой виртуализации:
Как трафик инкапсулируется в туннель, чтобы можно было отделить пакеты и информацию плоскости управления от базовой сети?
Решением этой проблемы обычно является некоторая форма инкапсуляции, в которую помещается исходный пакет, когда он передается по сети. Основное внимание при инкапсуляции - поддержка аппаратной коммутации в базовой сети, чтобы обеспечить эффективную пересылку инкапсулированных пакетов. Второстепенным соображением является размер формата инкапсулирующего пакета; каждый октет дополнительного заголовка инкапсуляции уменьшает объем полезной нагрузки, которую туннель может нести (если нет разницы между максимальной единицей передачи или MTU в сети, предназначенной для учета дополнительной информации заголовка, налагаемой туннелированием).
Примечание
Path MTU Detection (PMTUD) часто плохо определяет MTU инкапсулированных пакетов. Из-за этого часто требуется ручная настройка MTU в точке наложения заголовка туннеля.
Как пункты назначения достигаются через туннель, объявленный через сеть?
В более общих туннельных решениях туннель становится "просто еще одним звеном" в общей топологии сети. Пункты назначения, доступные через туннель, и дополнительная виртуальная связь просто включены как часть плоскости управления, как и любые другие пункты назначения и каналы. В этих решениях существует одна таблица маршрутизации или пересылки в каждом устройстве, и рекурсивный поиск используется для обработки пакета посредством пересылки в точке, где трафик входит в туннель или головной узел туннеля. Трафик привлекается в туннель путем изменения метрик таким образом, чтобы туннель был более желательным путем через сеть для тех пунктов назначения, которые оператор сети хотел бы получить через туннель. Это обычно означает в основном ручные решения проблемы привлечения трафика в туннель, такие как установка метрики туннеля ниже пути, по которому проходит туннель, а затем фильтрация пунктов назначения, объявленных через туннель, чтобы предотвратить объявления пунктов назначения, которые должны быть недоступны через туннель. На самом деле, если пункты назначения, достижимые через туннель, включают конечную точку туннеля (хвост туннеля), может образоваться постоянная петля маршрутизации, или туннель будет циклически переключаться между правильной переадресацией трафика и не переадресацией трафика вообще.
В решениях с overlay и over-the-top развертывается отдельная плоскость управления (или передается отдельная база данных с информацией о доступности для адресатов, достижимых в underlay и overlay в единой плоскости управления). Пункты назначения, доступные через underlay и overlay, помещаются в отдельные таблицы маршрутизации (VRF) на головной станции туннеля, а таблица, используемая для пересылки трафика, основана на некоторой форме системы классификации. Например, все пакеты, полученные на конкретном интерфейсе, могут быть автоматически помещены в оверлейный туннель, или все пакеты с определенным классом обслуживания, установленным в их заголовках пакетов, или весь трафик, предназначенный для определенного набора пунктов назначения. Механизмы полного наложения и верхней виртуализации обычно не полагаются на метрики для привлечения трафика в туннель на головной станции.
Еще одно необязательное требование - обеспечить качество обслуживания либо путем копирования информации QoS из внутреннего заголовка во внешний заголовок, либо путем использования какой-либо формы проектирования трафика для передачи трафика по наилучшему доступному пути.
Предыдущая статья из цикла про устранение неисправностей DHCP на Cisco доступна по ссылке.
Последняя статья будет посвящена некоторым проблемам с FHRP, мы начнем с VRRP!
Урок 1
В сценарии выше у нас есть проблема с HSRP. Сначала разберем топологию. С левой стороны находится клиент (мы используем маршрутизатор, чтобы иметь возможность воссоздать его в GNS3), который использует виртуальный IP-адрес в качестве шлюза по умолчанию. R2 и R3 настроены для HSRP. На правой стороне есть маршрутизатор с IP-адресом 4.4.4.4 на интерфейсе loopback0. К сожалению, наш клиент не может пропинговать 4.4.4.4. Что здесь происходит?
Сначала мы отправим эхо-запрос от клиента на IP-адрес 4.4.4.4. Вы видите символ U (недостижимый), поэтому мы знаем, что получаем ответ от шлюза по умолчанию.
Таблица маршрутизации была отключена на этом клиентском маршрутизаторе (нет ip-маршрутизации), но вы можете видеть, что шлюз по умолчанию был настроен. Давайте посмотрим, доступен ли этот IP-адрес.
Достигнуть шлюза по умолчанию не проблема, поэтому мы можем перенести фокус на R2 или R3.
Мы можем использовать команду show standby, чтобы убедиться, что R3 является активным маршрутизатором HSRP. Давайте проверим, может ли он достичь IP-адреса 4.4.4.4.
Увы ...пинг не проходит.
Его нет в таблице маршрутизации, и если вы посмотрите внимательно, то увидите, что FastEthernet1/0 не находится в таблице маршрутизации как непосредственно подключенный, это указывает на то, что что-то не так с этим интерфейсом.
Ну вот...интерфейс отключен.
R3(config)#interface fastEthernet 1/0
R3(config-if)#no shutdown
Включим его!
Ну вот, теперь он работает.
Проблема устранена ... теперь клиент может пинговать 4.4.4.4! Есть еще одна вещь, хотя ... мы используем HSRP, так что наш шлюз по умолчанию не является единственной точкой отказа, но в этом случае R3 имел сбой соединения...разве R2 не должен взять на себя управление?
interface tracking было включено, и вы можете видеть, что приоритет должен уменьшиться на 10, если интерфейс FastEthernet1/0 перейдет в состояние down. Это означает, что обычно R2 должен взять на себя управление, но preemption is disabled по умолчанию для HSRP.
R2(config)#interface fastEthernet 0/0
R2(config-if)#standby 1 preempt
R3(config)#interface fastEthernet 0/0
R3(config-if)#standby 1 preempt
Прежде чем отпраздновать нашу победу в устранении неполадок, мы должны убедиться, что эта проблема больше не возникнет в будущем. Мы включим приоритет на обоих маршрутизаторах. Теперь все готово!
Итог урока: убедитесь, что preemption включена для HSRP, если вы используете interface tracking
Урок 2
Вот та же топология, но на этот раз мы используем VRRP вместо HSRP. Однако проблема заключается в другом: клиент жалуется, что не все IP-пакеты попадают в 4.4.4.4.
Некоторые из IP-пакетов не поступают в 4.4.4.4.
IP-адрес шлюза: 192.168.123.254.
Шлюз пингуется без проблем.
R2 не может достичь 4.4.4.4, но у R3 нет никаких проблем. Прежде чем мы продолжим проверять, почему R2 не может достичь 4.4.4.4, мы взглянем на конфигурацию VRRP, чтобы увидеть, какой маршрутизатор является главным.
Вывод show vrrp интересен. Оба маршрутизатора считают, что они активны, и, если вы посмотрите внимательно, вы поймете, почему. Аутентификация включена, и в key-string имеется несоответствие. Поскольку оба маршрутизатора активны, половина пакетов окажется в R2, а остальные в R3. Вот почему наш клиент видит, что некоторые пакеты приходят, а другие нет. Давайте исправим нашу аутентификацию:
R2(config)#interface fa0/0
R2(config-if)#vrrp 1 authentication md5 key-string SECRET
Мы сделаем key-string одинаковыми.
Это сообщение в консоли R2 является многообещающим.
R3 был выбран в качестве главного маршрутизатора. Теперь давайте выясним, почему R2 не смог достичь 4.4.4.4, поскольку эта проблема устранена.
Странно, R2 показывает только одну запись в таблице маршрутизации, что-то не так с FastEthernet 1/0.
Кажется, кому-то нравится команда shutdown Имейте в виду, что это может быть что-то еще списки доступа, blocking traffic между R2 и R4, port-security (если был коммутатор в середине), интерфейсы в режиме err-disabled, неправильные IP-адреса и другое. Проверьте все!
R2(config)#interface fastEthernet 1/0
R2(config-if)#no shutdown
Включим интерфейс!
Проблема устранена!
Итог урока: убедитесь, что маршрутизаторы VRRP могут связаться друг с другом.
Было время, когда все, что связано с установкой, конфигурацией, обслуживанием инфраструктуры, выполнялось вручную. Для одной работы привлекались много сотрудников. Все было вручную. Этот процесс имел значительный риск человеческих ошибок, что приводило к понижению доступности, безопасности и производительности приложений. Не стоит забывать и общую стоимость инфраструктуры. Но благодаря современным технологиям и философии, таким как DevOps, это больше не проблема.
Теперь у нас есть несколько инструментов для выполнения задач создания, развертывания и управления инфраструктурой. Используя правильное программное обеспечение, можно автоматизировать всю инфраструктуру приводя участие человека к минимуму. Я говорю не о простых вещах, а о сложных задачах, таких как выделение ресурсов инфраструктуре, полная настройка приложений и т.д.
Автоматизация инфраструктуры - это процесс развертывания аппаратных/программных компонентов, операционной системы, сетевых компонентов, компонентов хранения данных с использованием IaC (Infrastructure as Code). Этот процесс имеет вмешательство человека только для написания такого кода, который будет иметь все детали для создания и развертывания необходимых компонентов.
Вот список наиболее популярных средств автоматизации инфраструктуры, широко используемых в отрасли.
1. Ansible
Ansible - это ядро с открытым исходным кодом, который автоматизирует развертывание приложений, управление конфигурацией, организацию ИТ. Основана в 2012 году и написана на самом трендовом в настоящее время языке - Python. Для реализации всей автоматизации Ansible использует плейбуки, где все конфигурации написаны на удобочитаемом языке - YAML.
Anible имеет безагентную архитектуру, то есть не нужно устанавливать какое-либо программное обеспечение отдельно на всех серверах. Он следует модели на основе push, где необходимо иметь локальную систему со всеми необходимыми конфигурациями, и эти конфигурации перемещаются на целевые серверы.
Доступные функции:
Автоматизация с помощью простого удобочитаемого языка;
Безагентная архитектура позволяет подключаться к серверам через обычный SSH;
Модель push передает конфигурации на сервер с локальной машины, управляемой вами.
Построен на Python, поэтому поддерживает множество библиотек и функциональных возможностей данного скриптового языка;
Кураторская коллекция модулей Ansible инженерной команды Red Hat.
Для больших предприятий Red Hat предлагает Ansible Tower.
2. SaltStack
Stack может с высокой скоростью выполнять управление инфраструктурой, управление конфигурацией и оркестровку. По сравнению с другими подобными инструментами, такими как Chef и Puppet, быстрота SaltStack является существенным отличием. Данное решение было представлено в 2011 году, и так же, как и Anible, он написан на Python.
Он имеет архитектуру master-slave, где Salt Master является главным демоном, который управляет всем, а Salt Minions являются подчиненными демонами, установленными на каждой управляемой системе для выполнения команд, отправленных Salt Master. Salt Master отправляет необходимые настройки и команды Salt Minions, а Salt Minions выполняют их на своей машине, чтобы применить всю IT-автоматизацию.
Функции Stack:
Рассчитанный на масштаб и скорость, один мастер может работать с 10000 миньонов.
Очень прост в настройке, имеет единую архитектуру удаленного выполнения.
Файлы конфигурации в Stack поддерживают все виды языков.
Он может выполнять команды на удаленных системах параллельно, что помогает ускорить автоматизацию.
Предоставляет простой интерфейс программирования с использованием API Python.
3. Chef
Одной из основных причин производственных инцидентов является несогласованность приложения или конфигурации. Это обычная проблема, и Chef стремится исправить это.
Chef - это инструмент управления конфигурацией для управления инфраструктурой. Он был написан на Ruby, а первый релиз состоялся в 2009 году компанией OpsCode.
Продукт Chef Infrastructure Management обеспечивает соответствие всех сред одним и тем же конфигурациям в инфраструктуре. Она предоставляет различные инструменты для управления инфраструктурой вроде Chef Infra, Chef Automate, Chef Enterprise и Chef Community.
Функции Chef Infrastructure Management:
Конфигурации написаны на языке YAML;
Она поставляется с несколькими инструментами разработки для написания книг рецептов (конфигураций), тестирования и разрешения зависимостей;
Корпоративная версия предоставляет возможности совместной работы для упрощения обработки сложных сред.
Поддержка интеграции с сотнями инструментов DevOps, таких как GitHub, Jenkins, Azure Terraform.
4. Bolt
Bolt - один из открытых проектов Puppet.
Это безагентный инструмент для автоматизации ИТ. С помощью Bolt можно автоматизировать все задачи, выполняемые вручную, что необходимо сделать сегодня в соответствии с требованиями. Я говорю о таких задачах, как развертывание приложения, устранение неполадок серверов, остановка и перезапуск службы, исправление и обновление систем и т.д.
Поскольку Bolt не содержит агентов, нет необходимости устанавливать какое-либо программное обеспечение агента на удаленных целевых машинах. Необходимо установить Bolt в локальной системе и подключить удаленные целевые системы с помощью SSH или WinRM.
Основные возможности Bolt:
Запишите план болта (сочетание команд, сценариев и задач) в YAML, простой в использовании и изучении.
Многие существующие планы и рабочие процессы доступны в Puppet Forge (библиотека модулей).
Переместите автоматизацию с Bolt на Puppet Enterprise для лучшей масштабируемости.
5. Terraform
Terraform - это средство выделения ресурсов инфраструктуры с открытым исходным кодом, используемое для создания и развертывания инфраструктуры с использованием инфраструктуры в качестве кода (IaC). Hashicorp представила его в 2014 году.
Terraform довольно хорошо работает с такими поставщиками облачных технологий, как AWS, Azure, GCP, Alibaba. С помощью Terraform можно развертывать инфраструктуру и управлять ею на любом из этих облачных поставщиков. В настоящее время Terraform широко используется многими организациями для управления Kubernetes кластерами.
Преимущества Terraform:
Простое управление конфигурацией неизменяемой инфраструктуры.
Может выполнять полную оркестровку инфраструктуры, а не только управление конфигурацией.
Использует язык конфигурации HashiCorp (HCL), который удобочитаем и очень прост для изучения.
Предоставляет готовые модули и провайдеров для сотен инструментов, и технологий через реестр terraform.
Заключение
Это был мой список самых популярных решений для автоматизации инфраструктуры, которые предлагают продукты для организаций среднего размера на уровне предприятия. Если вы попадаете в домен DevOps и хотите автоматизировать свою инфраструктуру и связанные с ней монотонные задачи, это подходящее время, чтобы выбрать одно из вышеупомянутых решений и начать автоматизацию.