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

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

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

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

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

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

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

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

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

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

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

Если вы планируете управлять долго работающим сервером, возможно, chef, puppet или docker дадут вам преимущество, как упоминалось в принятом ответе. Если вы не видите преимущества после их использования, то, вероятно, вам не нужен этот инструмент.

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

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

Ваш выбор.