Более устоявшиеся системы управления конфигурацией (CM), такие как Puppet и Chef, используют подход по запросу: клиенты периодически опрашивают централизованный главный сервер на предмет обновлений. Некоторые из них предлагают без хозяина подход тоже (то есть на основе push), но заявить, что он «не для производства» (Saltstack) или «менее масштабируемый» (Puppet). Единственная известная мне система, основанная на push с самого начала, - это занявшая второе место Ansible.
В чем заключается конкретное преимущество масштабируемости системы на основе опроса? Почему предположительно легче добавить больше пул-мастеров, чем пуш-агентов?
Например, agiletesting.blogspot.nl пишет:
в «выталкивающей» системе клиенты связываются с сервером независимо друг от друга, поэтому система в целом более масштабируема, чем «проталкивающая» система.
С другой стороны, Rackspace демонстрирует, что они могут обрабатывать системы 15K с моделью на основе push.
infastructures.org пишет:
Мы придерживаемся методологии вытягивания для поддержки инфраструктуры с использованием таких инструментов, как SUP, CVSup, сервер rsync или cfengine. Вместо того, чтобы отправлять изменения клиентам, каждая отдельная клиентская машина должна отвечать за опрос золотого сервера при загрузке и периодически после этого, чтобы поддерживать свой собственный уровень оборотов. Прежде чем принять эту точку зрения, мы разработали обширные сценарии на основе push, основанные на ssh, rsh, rcp и rdist. Проблема, которую мы обнаружили с помощью r-команд (или ssh), заключалась в следующем: когда вы запускаете сценарий на основе r-команд для передачи изменений на целевые машины, велика вероятность, что если у вас более 30 целевых хостов, один из них быть внизу в любой момент. Ведение списка введенных в эксплуатацию машин становится кошмаром. В процессе написания кода, исправляющего это, вы получите тщательно продуманный код оболочки, с которым придется иметь дело: тайм-ауты мертвых хостов; регистрация и повторная попытка мертвых хостов; разветвление и выполнение параллельных заданий, чтобы попытаться поразить множество хостов за разумный промежуток времени; и, наконец, обнаружение и предотвращение использования всех доступных сокетов TCP на исходной машине для всех исходящих сеансов rsh. Тогда у вас все еще есть проблема с включением всего, что вы только что сделали, в установочные образы для всех новых хостов, которые будут установлены в будущем, а также с повторением этого для любых хостов, которые умирают и должны быть восстановлены завтра. После трудностей, которые мы пережили при реализации репликации на основе r-команд, мы обнаружили, что это того не стоит. Мы не планируем снова управлять инфраструктурой с помощью r-команд или любого другого механизма push, если на то пошло. Они не масштабируются так же хорошо, как методы, основанные на вытягивании.
Разве это не проблема реализации, а не архитектурная? Почему сложнее написать поточный push-клиент, чем поточный пул-сервер?
В случае, если это кого-то заинтересует, я думаю, как минимум, я могу предоставить отчет о пользовательском опыте, впервые применив встроенную в Ansible возможность push-уведомлений в контексте управления исправлениями при настройке нескольких узлов критически важных систем. в облаке Amazon. Чтобы понять мои предубеждения или предубеждения, я должен объяснить, что я предпочитаю Ruby на уровне сценариев автоматизации и в прошлом настраивал проекты для использования марионеточной конфигурации мастер-агент для каждого проекта-Vpc. Так что мой опыт опровергает прошлые предрассудки, если таковые были.
Мой недавний опыт был очень благоприятным для динамического продвижения в изменяющееся состояние от десятков до многих сотен серверов, которые могут масштабироваться вверх или вниз, останавливаться и обновляться. В моей ситуации простая специальная команда Ansible 1.7 была всем, что мне нужно для создания патча. Однако, учитывая эффективность настройки AnsibleController (на t2.micro) для каждого Vpc для этой цели, в будущем я намерен расширить эту технику для более сложных требований.
Итак, позвольте мне вернуться к вопросу, заданному в этой ветке: за и против толчка в динамически меняющемся состоянии.
Предположения о типе серверного состояния, на которое я нацелился, были:
Принимая во внимание эти условия, очень просто создать машинный образ AnsibleController для подключения к многочисленным виртуальным ПК и настройки (с учетными данными) на месте в существующих учетных записях сервера. Автоматически в каждом экземпляре, созданном из изображения,
Второй элемент при необходимости можно сделать относительно сложным (с помощью структуры Info в инвентаре Ansible). Но если изощренность не требуется, вот очень простой пример сценария для вычисления всех экземпляров Amazon EC2 на каждом интервале cron и направления результатов в соответствующий файл инвентаризации (например, / etc / ansible / hosts) ...
#!/bin/bash
# Assumes aws-cli/1.3.4 Python/2.6.9 Linux/3.4.73-64.112.amzn1.x86_64 or greater
# http://aws.amazon.com/releasenotes/8906204440930658
# To check yum list aws-cli
# Assumes that server is equipped with AWS keys and is able to access some or all
# instances in the account within it is running.
# Provide a list of host IPs each on a separate line
# If an argument is passed then treat it as the filename, whether local or absolute
# path, to which the list is written
function list-of-ips {
/usr/bin/aws ec2 describe-instances --filters '[ {"Name": "instance-state-code", "Values": [ "16" ] } ]' | grep -w PrivateIpAddress | awk '{x=$2; gsub("\"","", x); gsub(",","", x); if(x && FNR!=1){print x;}}' | uniq
}
if [ -n "$1" ]; then
list-of-ips > "$1"
else
list-of-ips
fi
Единственное предостережение для этого варианта использования заключается в том, что команда patch должна быть идемпотентной. Желательно провести предварительное тестирование, чтобы убедиться, что это удовлетворено, как часть проверки того, что исправление делает именно то, что задумано.
Подводя итог, я проиллюстрировал вариант использования, в котором динамический толчок эффективен против поставленных мной целей. Это повторяемое решение (в том смысле, что оно инкапсулировано в изображение, которое можно развернуть в нескольких учетных записях и регионах). По моему опыту на сегодняшний день, технику динамического проталкивания гораздо проще реализовать - и начать действовать - чем альтернативы, доступные в наборах инструментов, доступных нам в данный момент.
Проблема с системами на основе push-уведомлений заключается в том, что у вас должна быть полная модель всей архитектуры на центральном push-узле. Вы не можете нажать на машину, о которой не знаете.
Конечно, он может работать, но для его синхронизации требуется много работы.
Используя такие вещи, как Mcollective, вы можете преобразовать Puppet и другие CM в систему на основе push. Как правило, преобразовать вытягивающую систему в выталкивающую систему тривиально, но не всегда просто пойти другим путем.
Есть также вопрос об организационной политике. Система, основанная на push, передает все руки центральным администраторам. Таким образом может быть очень сложно справиться со сложностью. Я думаю, что проблема масштабирования - отвлекающий маневр, любой подход масштабируется, если вы просто посмотрите на количество клиентов. Во многих отношениях толчок легче масштабировать. Однако динамическая конфигурация более или менее подразумевает, что у вас есть хотя бы опрашивающая версия регистрации клиента.
В конечном итоге все зависит от того, какая система соответствует рабочему процессу и владению в вашей организации. Как правило, вытяжные системы более гибкие.
Это старый пост, но, что интересно, история повторяется.
Теперь встроенные устройства Интернета вещей нуждаются в управлении конфигурацией, а топология инфраструктуры / сети кажется еще более сложной, если в ней используются брандмауэры, NAT и даже мобильные сети.
Решение, основанное на выталкивании или вытягивании, снова не менее важно, но количество устройств еще больше. Когда мы разработали наш инструмент управления конфигурацией встроенных устройств Интернета вещей qbee.io мы выбрали подход, основанный на вытягивании, с агентом, основанным на теории обещаний. Это означает, что агент извлекает конфигурацию и автономно приближается к желаемому состоянию. Преимущество состоит в том, что конфигурация активно поддерживается, даже если главный сервер не работает, и системе не нужно отслеживать, какое устройство получило какое изменение конфигурации. Кроме того, часто бывает трудно узнать, каковы условия локальной сети для устройства. Поэтому нам все равно, пока устройство не пингует сервер. Дополнительным примером и аргументом в пользу решения на основе опроса в случае встроенного варианта использования является долгий жизненный цикл этих устройств. Если устройство выходит из строя и заменяется запасным устройством (например, на нефтяной вышке), устройство немедленно получает конфигурацию для своей конкретной группы и приближается к ней. Если, например, ssh-ключи меняются по соображениям безопасности каждые 6 месяцев, то автоматически применяется последний действующий ключ для группы запасных устройств.
Будет интересно проследить, как эта дискуссия будет развиваться на протяжении многих лет. Также с контейнерами и одноразовой инфраструктурой в качестве альтернативы системам, которые поддерживают конфигурацию в течение более длительного периода времени.