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

Есть ли преимущество перед 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), которые помогут вам достичь этих более сложных целей, а также делать более простые вещи.

Твой выбор.