Рекомендации шеф-повара и кукол

Я хотел бы спросить, когда и при каких обстоятельствах вы будете использовать марионетку и когда будете использовать шеф-повара. Я также нашел rump, который является типом кукольного соло, где вы перебираете один сервер в свою конфигурацию, а затем серия серверов, позволяющая напрямую видеть изменения.

Мой вопрос: какой из вышеперечисленных я должен использовать и каким образом? Может кто-нибудь мне помочь?

Моя цель заключается в непрерывной интеграции, непрерывном развертывании в среде mono/.Net с rake и git. Я хотел бы легко упаковать, обновить и развернуть веб-приложения и хотел бы использовать приемные устройства для балансировки нагрузки для нескольких веб-серверов. Быть способным быстро снять их и не простоя между обновлениями.

Ответы

Ответ 1

Я бы использовал Puppet, но я немного предвзято, потому что написал книгу об этом и там работал.:) В дополнение к Rump вы также можете использовать Puppet в своем режиме применения - это то же самое, что и у шеф-повара. Хотя Rump обертывает некоторую доброту вокруг процесса, который стоит попробовать.

Я дал бы Puppet выстрел здесь, используя Rump как обертывание - вы можете использовать Puppet DSL OR Ruby DSL (у шеф-повара только есть Ruby DSL). Очень просто создавать "среды" с помощью Puppet и интегрировать рабочий процесс git/CI с вашими развертываниями. Он также легко интегрируется с задачами Rake или т.д.

Ответ 2

Используя оба, я бы сказал, что это зависит от того, что вы ищете. По-моему:

  • Шеф-повар более ориентирован на разработчиков. Если вы рубиновый гуру, вам понравится.

  • Puppet более ориентирован на sysadmin. Он имеет нерубинный DSL, поэтому сложнее распространять ошибки на ваших машинах (imho).

Puppet создает более читаемый и стабильный код, но также замедляет развертывание новых функций. Вероятно, что вы захотите в большой корпоративной структуре, которая сильно верит в вашу DevOps.

С шеф-поваром вы можете выполнять сложные задачи с меньшим количеством кода, затрачивать время. Вы можете использовать всю рубиновую магию без создания кукольной конструкции. Это хорошо, например, когда ваша компания не верит в ценность DevOps, и вы постоянно боретесь со временем, чтобы доказать, что ваш менеджер ошибается:-) Я лично считаю, что Puppet немного медленнее выполнять, когда вы разрабатываете новые функции, которые может быть немного боль.

Мое предложение: если вы - системный администратор с некоторыми навыками развития, пойдите для Puppet. Если вы хорошо разбираетесь в Ruby (или Python), идите за шеф-поваром.

Я также пробовал rump, и я играю с ним. Это помогает, это круто, но я до сих пор не вижу огромной ценности, кроме ленивого ввода крупу, вместо марионетки. -vd --modulepath =. модуль/манифесты/init.pp.:)

Ответ 3

В конце концов я закончил с марионеткой + vagrant, которая позволяет мне запускать/повторять/тестировать кукольные манифесты:

сначала установите VirtualBox, затем:

gem install puppet
gem install vagrant

то

vagrant box add base http://files.vagrantup.com/lucid32.box
vagrant init

затем отредактируйте. /Vagrantfile, чтобы сказать:

Vagrant::Config.run do |config|

  config.vm.box = "base"
  config.vm.provision :puppet do |puppet|
    puppet.manifests_path = "manifests"
    puppet.module_path = "modules"
  end

  # rest here
end

затем добавьте определение node в manifests/default.pp, например:

group { "puppet":
  ensure => "present",
}
file { '/etc/motd':
    content => "Welcome to your Vagrant-built virtual machine!\n"
}

затем выполните:

vagrant up

Теперь у вас есть управляемая марионеткой виртуальная машина, с которой вы можете играть, и любой манифест, который вы меняете, переходит в исходный контроль. И вы можете быстро итеративно, не прибегая к крупу.

Ответ 4

Если вы знакомы с Ruby, я предлагаю вам попробовать шеф-повара, чем Puppet. Используя chef & ruby, вы можете выполнять очень сложную задачу. Однако марионетка более чистая, чем у шеф-повара. Хорошо или нет, все зависит от вашей реальной работы.

Ответ 5

Еще одна большая разница между Puppet и Chef, о которой не упоминалось, заключается в том, что Puppet выполнит всю сборку манифеста на сервере, тогда как шеф-повар (и cfengine) будет выполнять некоторые или все работы с клиентом.

Это означает, что * Меньше процессорного следа на вашем клиенте от запуска марионетки, и * Модули надстройки, написанные в Puppet, запускаются только на сервере.

Вторая часть важна, потому что гораздо проще интегрировать Puppet с вашей другой архитектурой. Например, если вы хотите извлекать данные через API из другого приложения, в Puppet вам нужно только установить необходимые модули API на Puppetmaster, и только нужно предоставить серверу доступ к API. Любые учетные данные, необходимые также, остаются на кукольном мастере - гораздо безопаснее.

Мы интегрируем Puppet и SecretServer (для автоматического поворота корневых паролей с помощью марионетки и сохранения их в SecretServer). Это не было бы возможно или безопасно при Шеф-поваре, поскольку я понимаю модель.