Может ли CHEF иметь разные теги данных в разных центрах обработки данных
В Chef 12 есть понятие organizations, и environments.
Как бы вы логически смоделировали разные центры обработки данных?
Например, если у вас два центра обработки данных с 2 средами.
us-datacenter
\_ production
\_ stage
eu-datacenter
\_ production
\_ stage
В каждой среде есть веб-серверы, которые должны указывать на разные базы данных.
us-prod-web01 => us-prod-db01
eu-prod-web01 => eu-prod-db01
us-stage-web01 => us-stage-db01
eu-stage-web01 => eu-stage-db01
Очевидным ответом было бы создание вложенных тегов данных, содержащих IP-адреса правильной базы данных.
$datacenter/$environment/web
$datacenter/$environment/database
Однако в пакетах данных есть строгая двухуровневая иерархия, и я не могу найти концепцию «центра обработки данных».
Как это лучше всего смоделировать? Я могу придумать два подхода.
Используйте двухуровневые бэги данных
$ среда / us-web
$ среда / us-база данных
$ environment / eu-web
$ environment / eu-database
Обратной стороной этого является размещение большого количества тегов данных в одном каталоге. Даже если вы используете графический интерфейс с размещенным на хосте CHEF, это все равно сложно прокручивать теги данных. (8 data centers * 4 environments * 6 types of webservers + 2 types of database servers = a lot )
- Поместите переменную центра обработки данных в атрибуты роли / узла и напишите вспомогательный метод для поиска правильного тега данных.
Это было предложено в IRC, однако написание вспомогательного метода кажется очень сложным (шеф-повар в новинку и никогда не делал ничего подобного). Также кажется, что нужно много изобретать колесо для варианта использования, который должен быть очень распространенным. Например, это можно сделать просто в марионетке + hiera
Конечно, я не первый человек, использующий chef для разных настроек в разных дата-центрах.
Если вы планируете отдельные центры обработки данных, вы, вероятно, столкнетесь с двумя проблемами:
Одна установка Chef слишком медленная, чтобы поддерживать все - вы, вероятно, получите одну на каждый DC.
Много пакетов данных различного назначения. На этом этапе графический интерфейс и ручное редактирование перестают быть проблемой. Будет проще просто синхронизировать весь репозиторий при каждом изменении вместо того, чтобы работать с отдельными файлами или делать что-либо в графическом интерфейсе.
Что может оказаться полезным (если у вас есть аналогичные службы в каждом DC), так это использовать полные имена для каждой среды - например, «eu-test», «eu-prod» и т. Д. И инвертировать иерархию, чтобы закончить вверх с
/ database
- eu-stage
- eu-prod
- us-prod
/ web
...
и доступ /service/$environment.
Я считаю, что пакеты данных разделены между организациями, поэтому, если вы us и eu совершенно разные, тогда да, может быть полезно. Если они похожи, то в таком разделении, наверное, нет смысла.
PS: Если вы только начинаете работать с шеф-поваром, не называйте свою службу «сетью» - вы, вероятно, скоро получите другой веб-сервер с другой ролью ... Дайте ему более значимое имя. То же самое для «базы данных».
Решение, которое я реализовал, это задокументировано в моем блоге
В основном у меня есть 3 роли и 2 среды. Я применяю к серверу несколько ролей в зависимости от его местоположения и типа.
- служебные роли (roleA)
- переопределить роли (override-roleA)
- роли центра обработки данных (датацентр-США-запад)
- производственная среда (прод, сцена)
В итоге иерархия выглядит так:
