если не пользоваться только доступными метриками CloudWatch и вместе с ними использовать кастомные — уже не так опасен :) понятное дело — зависит от цели и оправдывают ли расходы ее.
Спасибо, но там для начинающих сокрыт процесс того, что делает этот плагин (если не вникать в код cookbook-а). Я считаю, что один раз нужно увидеть как оно работает, step by step. А плагинов и gem-ов всегда будет достаточно для пользования (я не уверен, что knife ec2 фиксит проблему с тем, что Amazon Linux в ohai идет как amazon, так что ручное вмешательство по-любому было бы необходимо).
Кто говорит за 1-3 инстанса? Мы же не о production env тут ведем речь. По-моему, Auto Scaling решает. Группы — роли и environment'ы. Умея написать такой шаблон — развернуть 90 хостов — не составит сложности. Вникнет ли человек в структуру CloudFormation и параметры стеков, использую OpsWorks? Не думаю, т.к. готовые решения уже доступны для него.
Спасибо за совет и комментарии, но 1 — статьи были для начинающих, 2 — и без opsworks все работает тоже нормально. А про него мы расскажем в другой статье, если ручки дойдут.
Идентификация узлов лежит на нас, поэтому каждому из них — назначался атрибут (он же метка, упомянутая в статье). Назначался он путем конфигурации клиента и параметра json_attribs. В итоге узел знал, кто он, но не знал, что с этой меткой делать — пока не регистрировался на сервере.
Спасибо большое, полезная информация, действительно. У меня она частично запланирована на другую часть. Думаю, что люди, жаждущие разобраться — все равно придут к berkshelf и vagrant, ибо удобно решать зависимости и быстро разворачивается. С другой стороны — как уже упоминал я в статье — AWS это реально интересно и востребовано. Спасибо еще раз за собирательный комментарий.
1. Сервер это в данном случае — chef-сервер. Еще там упоминается master — но это уже конкретный пример различия между нодами на определенной задаче, озвученной мной.
2-3. Процесс chef-client, который при bootstrap — устанавливает клиента на узел, можно запускать по расписанию (используя cron или windows scheduler), соответственно он периодически связывается с сервером и проверяет изменения. Cookbook-и скачиваются этим же процессом.
Честно, я начинал знакомится с Puppet и на этом все закончилось — я не смог упорядочить директивы. Потом я только понял, что там есть зависимости — но было поздно, были написаны первые рецепты Чефа.
С Шефом все может быть :)
А если серьезно — полностью согласен по поводу инфраструктуры.
Сделано это намеренно — дабы статьи не приобретали узконаправленный характер по компании, в которой все сделано на UNIX или Windows или Linux.
Поэтому я трезво отношусь к спорам, мне, как начинающему, очень интересно услышать другие идеи, но комментарии — чем «хуже/лучше» не несут идей, это просто спор.
В дальнейших частях будет изложен глобальный подход. Отдельным рядом пойдут статьи про решение кастомных задач, с которыми приходится встречаться.
Никогда не понимал таких холиварных сравнений. Умеешь делать автоматизацию на Puppet — делай. Умеешь на Chef — делай. Удобно? Ну и ок. Не умеет Puppet что-то — переползай на Chef или выдумывай костыль. Все предельно просто — кому нужны сравнения. Это же не спорт, это IT технологии.
А это дело личное. Например, язык манифестов/рецептов. Мне удобно было использовать Ruby. Хорошее комьюнити Chef — предостаточно готовых кукбуков, вокруг которых можно писать свои wrapper-ы. Да и просто сравнил свой небольшой опыт использования Puppet vs Chef. Chef оказался более удобным. Вышла совокупность впечатлений.
На самом деле, каждому свое. Chef — автоматизация процесса конфигурации. Это же не просто инструмент для запуска скриптов. Он умеет гораздо больше. Также как и основное назначение Jenkins — совсем не заменяет Chef. То, что он умеет ранить external job — это хорошо. Уместно ли в упомянутом случае это делать? Возможно Вы достигнете цели. Вопрос будет ли это оптимизированная автоматизация?
Спасибо за совет и комментарии, но 1 — статьи были для начинающих, 2 — и без opsworks все работает тоже нормально. А про него мы расскажем в другой статье, если ручки дойдут.
все-таки статьи направлены на начинающих.
Например, docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts_micro_instances.html
Показатели далеко не оптимальны, скорее всего.
2-3. Процесс chef-client, который при bootstrap — устанавливает клиента на узел, можно запускать по расписанию (используя cron или windows scheduler), соответственно он периодически связывается с сервером и проверяет изменения. Cookbook-и скачиваются этим же процессом.
А если серьезно — полностью согласен по поводу инфраструктуры.
Сделано это намеренно — дабы статьи не приобретали узконаправленный характер по компании, в которой все сделано на UNIX или Windows или Linux.
Поэтому я трезво отношусь к спорам, мне, как начинающему, очень интересно услышать другие идеи, но комментарии — чем «хуже/лучше» не несут идей, это просто спор.
В дальнейших частях будет изложен глобальный подход. Отдельным рядом пойдут статьи про решение кастомных задач, с которыми приходится встречаться.