Chef - шаблон для установки роли специфических атрибутов

Question

Мы специализированной кулинарной с тремя рецептами

• Рецепт 1. Создание хранилища на сервере

• Рецепт 2. Установить ngnix

• Рецепт 3. Установка JBOSS

Рецепт 1 необходим ttributes, чтобы рассказать, сколько логических томов он должен создать для ngnix и Jboss вместе с размером.

У нас также есть три роли, называемые веб-сервер, приложение-сервер и автономные. автономная роль сходится по всем 3 рецептам на одной виртуальной машине. Но мы хотим использовать роли веб-сервера и приложения-сервера в Production.

Вопросы теперь о том, как разделить атрибуты хранения, потому что мы не хотим предоставлять Jboss FS для роли веб-сервера.

Мы хотим поместить атрибуты хранения в роли, но это, по-видимому, анти-шаблон.

Внесение атрибутов в рецепты означает, что мы должны включать рецепт 1 внутри рецептов 2 и 3, который не является элегантным, потому что рецепт Jboss просто должен установить Jboss, не беспокоясь о хранении, не так ли?

Есть ли хороший способ достичь этого?

Answer 1

Предполагая web-server, app-server и standalone все отдельные кулинарные книги, просто поместить данные в файлах атрибутов для web-server и app-server.

В web-server вы бы что-то вроде:

# attributes/default.rb 
default['mystorage']['nginxdata'] = 2 # Some size 

# recipes/default.rb 
include_recipe 'myapp::storage' 
include_recipe 'myapp:nginx' 

и app-server Вы могли бы иметь что-то вроде:

# attributes/default.rb 
default['mystorage']['jboss1'] = 2 # Some size 
default['mystorage']['jboss2'] = 2 # Some size 

# recipes/default.rb 
include_recipe 'myapp::storage' 
include_recipe 'myapp:jboss' 

В рецепте хранения просто итерацию над данными для создания томов:

node['mystorage'].each do |volume_name, size| 
    # Something ... 
end 

Answer 2

Дать это как ответ как комментарий не будет достаточно ясным в форматировании.

Я очень сомневаюсь, что метод установки nginx или jboss варьируется в зависимости от ваших приложений, поэтому вам просто нужно переопределить атрибуты в своей куковой книге приложения.

Таким образом, вы в конечный итоге с coderanger ответа: 1 поваренных за работу инфраструктуры (Nginx, JBoss, хранение)

А затем 1 приложение поваренные которые - атрибуты питания значения для этого приложения к поваренной инфраструктуре. - зависит от поваренных книг для инфраструктуры в конкретных версиях - есть 3 рецепта: - 1 включая хранение и nginx - 1 включая хранение и jboss - 1 включая оба предыдущих (не беспокоить, 2 include_recipe для того же самого не будет будь то проблема, шеф-повар достаточно умен, чтобы включить только один раз)

На вашем узле вы установите список с одним из этих рецептов. Вы получаете контроль над тем, какая версия jboss или nginx фактически настроена с вашим приложением в определенное время (которое у вас не может быть с ролью)

Атрибут загрузки атрибутов и составления рецептов сделает ваши атрибуты cookbook вашей заявки переопределить атрибуты из кулинарной книги nginx (например), а затем скомпилировать рецепт для nginx.

Просто убедитесь, что include_recipe nginx/jboss находится перед кодом развертывания вашего приложения, поэтому вы уверены, что nginx/jboss настроен, прежде чем пытаться его развернуть.

Выставить мой случай (не так далеко от твоего я думаю):

У нас есть 53 в домашних приложениях, 53 настройки кулинарных книг атрибутов (параметры Jvm для Exemple). У нас есть 20 пар серверов приложений, поэтому примерно 60 кулинарных книг (1 для кластера и 1 для каждого экземпляра в кластере)

В каждой кулинарной книге каждого экземпляра задано имя сервера и каталог развертывания. Каждая кластерная кулинарная книга зависит от кулинарных книг и включает их рецепты (которые используют ранее описанный каталог развертывания)

Существуют некоторые инструменты, такие как berkshelf, которые помогут вам поддерживать целую цепочку с ограничением версии.

Сначала это звучит сложнее, но со временем это избавит вас от непреднамеренных изменений в производстве, потому что вы сделали изменение для постановки и забыли, что оно будет распространено (с ролью).