Назад | Перейти на главную страницу

Chef Server vs Chef Solo

Я собираю структуру для запуска приложения Rails. Само приложение работает на Heroku. Однако он делает запросы к кластеру, который выполняет вызов через программу на C.

Чтобы иметь возможность быстрее восстанавливаться после сбоев, я хочу создать процедуру с помощью Chef. Мне удалось написать «кулинарную книгу», в которой установлено все необходимое, и она отлично работает, когда я использую виртуальную машину Vagrant.

Однако когда я подаю заявку на реальный сервер, это не удается. Кроме того, я использую Chef Solo, и мне нужно вручную установить некоторые вещи на машину перед запуском скрипта, что не очень практично.

Не знаю, брать ли в этом случае Chef Server. Боюсь, что это «отличный» инструмент для «небольших» потребностей.

Этот кластер состоит всего из трех машин, это не должно сильно увеличиваться. Однако приложение также делает запросы к другому кластеру немного большего размера (6 машин), который, несмотря на очень быструю установку, также может использовать Chef Server.

Что лучше: Chef или Chef Solo Server? Есть ли по этому поводу дидактическое руководство? Документация разработчика очень запутанная.

Этот вопрос кажется субъективным, но я постараюсь подойти к нему объективно.

Chef Server предоставляет систему публикации и поисковый индекс с помощью RESTful API.

Это означает, что вы можете:

  1. Распространяйте кулинарные книги для узлов через одно место, где есть API, и примитивы для создания ограничений версии, извлечения, всего того, что вы, вероятно, ожидаете от системы публикации.

  2. Храните данные (атрибуты) об узлах, которыми вы управляете. Будь то одна или тысяча, вы можете получить информацию об узлах напрямую через API. Вы также можете использовать его, чтобы указать узлам запускать разные рецепты.

  3. Храните произвольную информацию о вашей инфраструктуре в том, что Opscode называет «пакетами данных». Это любая информация, которая вам нравится, такая как информация о пользователях, информация о приложении или что-то еще, что вы можете придумать о своей инфраструктуре.

  4. Запросите у сервера информацию об узлах, «какие веб-серверы работают?»

Чем это отличается от Chef Solo? Рад, что ты спросил!

С Chef Solo вы должны сами доставить на узлы кулинарные книги, атрибуты узлов, пакеты данных и т. Д. Это означает публикацию их где-нибудь, чтобы их могли получить несколько узлов, или rsync / scp репозиторий для каждого управляемого узла. Нет ни централизованного хранилища данных узла, ни индекса поиска для любого из них.

Вначале все очень мало, и их легко распространять. Между 1, 3 или даже 5 узлами это часто не проблема. Но тогда большинство людей сталкиваются с некоторыми проблемами.

  • «Конечно, было бы неплохо иметь способ проще загружать кулинарные книги на узлы»
  • «Чувак, каждый раз, когда мы обновляем кулинарную книгу, производство падает, потому что мы не хотели, чтобы в ней вносились изменения»
  • «Как мы можем собрать все данные узла в одном месте и запросить их?»

Этот список можно продолжить. Что происходит, так это то, что многие люди не хотят «запускать сервер шеф-повара», поэтому они создают свои собственные на основе репозиториев git, http-серверов и т.п.

Вариант использования, о котором вы говорите (примерно 5 узлов), является целью для плана Opscode Hosted Chef «5 узлов бесплатно», тогда вам не нужно управлять специальной системой, чтобы быть вашим Chef Server, по крайней мере, чтобы проверить, что-то, что будет работать для вашей инфраструктуры. Затем вы можете продолжить переход к более крупным платным планам или перенести свои данные (легко через API) на свой собственный Chef Server в будущем.