Управление конфигурацией: продвиньте по сравнению с основанной на получении по запросу топологией

В случае, если это кого-то заинтересует, я полагаю, как минимум, я могу предоставить отчет о пользовательском опыте, впервые применив встроенную в Ansible возможность push в контексте управления исправлениями для установок с несколькими хостами критически важных систем в облаке Amazon. Чтобы понять мои предубеждения или предубеждения, я должен объяснить, что я предпочитаю Ruby на уровне сценариев автоматизации и в прошлом настраивал проекты для использования конфигурации марионеток мастер-агент для каждого проекта-Vpc. Таким образом, мой опыт опровергает прошлые предрассудки, если таковые были.

Мой недавний опыт был очень благоприятным для динамического продвижения меняющегося состояния от десятков до многих сотен серверов, которые могут масштабироваться вверх или вниз, останавливаться и обновляться. В моей ситуации простая специальная команда Ansible 1.7 была всем, что мне нужно для создания патча. Однако, учитывая эффективность настройки AnsibleController (на t2.micro) на каждый виртуальный канал для этой цели, в будущем я намерен расширить эту технику для более сложных требований.

Итак, позвольте мне вернуться к вопросу, заданному в этот тред: плюсы и минусы проталкивания в динамически изменяющемся состоянии.

Предположения относительно типа состояния сервера, на который я нацелился, были:

• Нет предположений, что IP-адреса или генерируемые Amazon локальные имена хостов будут долговечными - они могут оба приходят и уходят
• Все экземпляры были созданы из образов машин, которые уже имели возможность сделать доступ по ssh возможным от одного привилегированного пользователя с правами администратора
• Для индивидуализации серверов и потенциального разделения их на группы в соответствии с функцией или в соответствии с на стадии разработки (например, тестирование или продвижение) это будет осуществляться посредством запуска определенных тегов Amazon согласованных традиционных имен
• . Я бы исправил администрирование серверов Linux и Windows отдельно, с помощью различных специальных команд, th Поэтому простое разрешение сбоя входа в систему Linux при подключении к серверу Windows было вполне приемлемым.

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

1. задание cron по распространению патча на работающие серверы через равные промежутки времени, чтобы доступ к требуемому имуществу осуществлялся непрерывно через определенные промежутки времени.
2. Способ вычисления инвентаризации Ansible через каждый такой интервал.

Второй элемент при необходимости можно сделать относительно сложным (с помощью структуры 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 должна быть идемпотентной. Желательно провести предварительное тестирование, чтобы убедиться, что это выполнено, как часть проверки того, что исправление делает именно то, что задумано.

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

Это старый пост, но, что интересно, история повторяется.

Теперь встроенные IoT-устройства нуждаются в управлении конфигурацией, а топология инфраструктуры/сети кажется еще более сложной из-за сочетания брандмауэров, NAT и даже мобильных сетей.
Решение, основанное на выталкивании или вытягивании, снова столь же важно, но количество устройств еще больше. Когда мы разрабатывали наш инструмент управления конфигурацией встроенных устройств IoT qbee.io, мы выбрали подход, основанный на вытягивании, с агентом, основанным на теории обещаний. Это означает, что агент извлекает конфигурацию и автономно переходит к желаемому состоянию. Преимущество заключается в том, что конфигурация активно поддерживается, даже если главный сервер не работает, и системе не нужно отслеживать, какое устройство получило какое изменение конфигурации. Кроме того, часто бывает трудно узнать, каковы условия локальной сети для устройства. Так что нам все равно, пока устройство не пропингует сервер.Дополнительным примером и аргументом в пользу решения на основе извлечения в случае встроенного варианта использования является длительный жизненный цикл этих устройств. Если устройство выйдет из строя и будет заменено запасным устройством (например, на нефтяной вышке), устройство немедленно получит конфигурацию для своей конкретной группы и сходится к ней. Если, например, ключи ssh меняются из соображений безопасности каждые 6 месяцев, то будет автоматически применяться последний действующий ключ для резервной группы устройств.

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