Почему люди используют Puppet / Chef с Amazon Cloud Formation, а не просто CloudInit?

Мы планируем использовать инстансы AMI EC2 без предварительной запекания. Т.е. когда они раскручиваются, они представляют собой голые установки AWS linux. Наш процесс начальной загрузки включает различные необходимые нам установки, например, python, tomcat. У нас будет минимум 3 экземпляра и максимум 8.

Учитывая эти требования, будет ли полезно использовать Puppet / Chef вместо использования Amazon Cloud Formation (CloudInit)?

Лучшее, что я вижу, это то, что если бы мы использовали Puppet, то у нас было бы декларативное программирование, которое было бы легче контролировать, чтобы увидеть, что происходит, по сравнению со сценарием. Также CloudInit имеет ограничение на размер скрипта 16 КБ, с которым мы можем или не можем столкнуться.

Кто-нибудь перешел с CloudInit на Puppet или Chef по определенной причине, которую они могут указать здесь в ответ на мой вопрос?

Есть ли преимущество перед CloudInit? Да, конечно, их много!

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

CloudInit - это не управление конфигурацией. Если вы решите начать использовать программное обеспечение для управления конфигурацией, используйте cloud init только для одной задачи: для загрузки Puppet / Chef / другого агента.

Puppet не просто помогает автоматизировать установку пакетов, настройку ключей ssh ​​или настройку кучи Tomcat. Это обеспечивает положение вещей. Когда разработчик устраняет неполадки в приложении Java в 3 часа ночи и изменяет вашу конфигурацию Tomcat, Puppet вернет ее обратно. Вы можете быстро изменить версию Python для всех или групп узлов, и если кто-то установит другую версию, Puppet вернет ее обратно.

Когда ваш стек приложений изменяется и вы начинаете использовать, скажем, RabbitMQ, или Jetty, или новую СУБД, вы можете легко протестировать и развернуть изменения на десятках или тысячах серверов.

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

Вся суть управления конфигурацией заключается в предсказуемом и последовательном раскрутке машин. CloudFormation и cloudinit хороши, когда вы ограничены только AWS (хотя отладка шаблонов CloudFormation - жалкое занятие ), но как насчет приложений, которые используют как ресурсы центра обработки данных, так и AWS, или локальные среды тестирования, или машины для разработки?

Если вы существуете исключительно в AWS, я полагаю, вам сойдет с рук cloudinit и ничего больше, но я не уверен, что это реалистично для приложений любого масштаба (Netflix, например, предварительно запекает свои AMI с использованием технологий OSS, которые они написали и выпущен в мир; подробности смотрите в этом видео ). Приложения с высокой доступностью являются межрегиональными, часто базируются в VPC, как правило, для резервного копирования в центры обработки данных через VPN, и это даже не касается демонстрационных, промежуточных, тестовых или сред разработки. Как человек, отвечающий за подготовку машин, последнее, что я хочу делать, - это повторять работу или застревать в отладке нескольких методов подготовки.

Отсюда Chef или Puppet. Они работают для AWS так же хорошо, как и для моего центра обработки данных, и так же хорошо для моей машины разработки, на которой работает Vagrant, так и для демонстрационных сред, которые мне иногда требуются на лету. Я бы предпочел запустить Chef или Puppet из cloudinit, чем поддерживать и cloudinit, и Chef или Puppet.

Для выбрасываемых серверов, скажем, работающих за группой автомасштабирования, я бы сказал, что cloudinit, вероятно, достаточно. Сценарии оболочки linux или сценарии Windows PowerShell должны помочь.

Если вы планируете управлять длительным сервером, возможно, шеф-повар, марионетка или докер могут дать вам преимущество, как указано в принятом ответе. Если вы не видите преимущества после их использования, значит, инструмент вам, вероятно, не нужен.

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

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

Твой выбор.