Я новичок в шеф-поваре (использую размещенный сервер шеф-повара), и я не понимаю, и в основном понимаю, как предоставлять отдельные серверы. У меня проблемы с выяснением того, как интегрировать различные подготовленные серверы в функциональный кластер.
В моем текущем варианте использования я использую Amazon EC2. Я использую балансировщик нагрузки с несколькими серверами Varnish, которые передают запросы нескольким интерфейсным серверам приложений, подключенным к серверу RDS. У меня также есть внутренний служебный сервер, который иногда должен синхронизировать некоторые файлы с серверами приложений FE.
Как бы вы склеили все это вместе? Серверы FE должны знать об экземпляре rds и сервере Redis, но сервер служебных программ UTLITY и узлы varnish должны знать о серверах приложений FE. В идеале серверы приложений будут реализовывать какое-то автомасштабирование, при котором при необходимости предоставляется больше узлов.
Наконец, добавьте к этому также необходимость иметь среды разработки и сцены, где часто серверы Varnish находятся на той же виртуальной машине, что и сервер приложений.
Используете ли вы теги для сортировки регистрации узлов FE, а затем запрашиваете эти значения при последнем запуске рецептов на серверах Varnish и BE?
Я просто ищу некоторые передовые практики в том, что, как я полагаю, является довольно распространенным вариантом использования n-уровневого веб-кластера.
В вашем вопросе не указано, используете ли вы chef-client или chef-solo, поэтому я предполагаю первое.
К вашему вопросу особенно подходят две конструкции Chef: поиск и окружающая среда.
Поскольку сервер Chef индексирует все известные атрибуты ваших узлов, вы можете использовать поиск для поиска узлов на основе любого атрибута, например содержимое их списков выполнения или любые теги, которые вы назначили узлу. Предполагая, что у вас есть рецепт (или роль), который настраивает ваш сервер Redis, рецепт, который настраивает описанные вами серверы приложений FE, может искать узлы, у которых есть рецепт Redis в их списке выполнения, и использовать атрибуты этого узла для заполнения файл конфигурации. Точно так же рецепт, который настраивает ваши серверы Varnish, может найти ваши серверы приложений и заполнить файл конфигурации Varnish их адресами.
Среды можно рассматривать как особый вид тега, который можно использовать для ограничения объема ваших поисковых запросов, когда вы хотите знать только об узлах, принадлежащих к одному и тому же логическому набору. Помимо работы в качестве тега, среды Chef также могут использоваться для переопределения атрибутов узлов и принудительной блокировки версий поваренной книги.
Ни одна из этих конструкций не применима напрямую для обнаружения частей вашей инфраструктуры, таких как RDS, где вы не можете напрямую запускать Chef, но поскольку вы можете использовать «сырой» рубин в своих рецептах, библиотеках, таких как туман или right_aws позволит вам запрашивать у AWS API подробную информацию о предоставленных вами ресурсах (например, какие экземпляры RDS существуют и каковы их адреса), и вы можете фильтровать результаты, используя любые примененные вами теги.
Объединив такую библиотеку, как туман, с возможностью поиска Chef, вы сможете найти свой путь к нирване автоматизации облачной интеграции. До следующего крупного отключения электричества на востоке США.