Спасибо за комментарий. Статья была написана 4-ре года назад и, естественно, с тех пор много чего поменялось в таком динамично развивающемся продукте как SaltStack. К сожалению следить за изменениями и подгонять статью под современную версию Солта нету времени, да и необходимости — тоже: статья задумывалась как обзорная, — просто для подачи концепта.
Надеюсь Ваш комментарий будет полезен всет тем, кто читает статью в 19-году.
Как раз деплоить Mesos очень просто — для большинства популярных операционных Linux систем уже если репозиторий от Mesosphere — простая установка пакета + указание ZooKeeper ссылки на Mesos мастер — всего-то делов.
Другой вопрос именно в функционировании: его нельзя использовать как средство для решения проблем текущей инфраструктуры, — под использование Mesos необходимо переделывать много всего. Плюс пока не решенные проблемы с persistent storage (точнее в 0.25 — уже должны анонсировать таковое для отдельного фреймворка) оставляют использование Mesos для энтузиастов. Однако, я считаю, что за подобными системами будущее.
Нет, — Mesos это в двух словах это кластерная операционка. Cisco (и Mesosphere в качестве их партнеров) используют для обозначения DCOS (DataCenter OperationSystem) для обозначения Mesos и его окружения (Marathon, Aurora, Cronos, Consul, etc). Почитайте обязательно — очень внушительный шаг в сторону упрощения деплоймента и эксплуатации кластерных систем.
Consul-Template хорошая вещь, но не забывайте, что её мониторинг и поддержание в рабочем состоянии не такая уже и простая задача, если учесть, что поддержка High Availability в нем не реализована. В любом случае мы используем его в связке с HAProxy для реализации прозрачного изменения к-ва бэкендов. В связи с тем, что Mesos и подобные ему платформы (Nomad, к примеру) будут набирать обороты и все чаще появляться в качестве опций для деплоймента приложений, рекомендую тратить время на разработку архитектуры с учетом возможного использования этих средств — здорово сэкономите себе время/затраты впоследствии.
Ну, не все так печально, если вспомнить, что REST запросы идут к localhost (думаю Вы добавите 1-2 мс к времени генерации страницы и да, — DNS резолвинг занимает значительно больше времени), а памятуя, что указанные Вами фреймворки достаточно тяжелы сами по себе, влияние задержек на запросы к Consul будет минимальным. На худой конец Вы можете воспользоваться кешем и делать запросы к Consul, скажем, каждый 100-й запрос к странице (в любом случае если база по указанному адресу станет недоступной Вам придется обрабатывать исключение и запрашивать данные из Consul заново).
Все верно — DNS работать будет но, только в том случае, если запрашиваемые сервисы будут использовать стандартные порты. К примеру, MySQL прописанный в Consul на таком-то хосте и использующий стандартный порт 3306, можно будет указать в виде `mysql.service.consul` (если Вы зарегистрировали сервис базы используя mysql в качестве имени сервиса) как хост для подключения к базе. Однако нюанс №1 — не забываете, что DNS резолвер Consul не используется по умолчанию в системе (обратите внимание на вызовы типа: dig 127.0.0.1 -p 8600 ...); нюанс №2 если Вы используете ресурс менеджеры (к примеру Mesos) для поднятия баз данных, то порт для сервиса базы не будет соответствовать стандартному и Вам придется делать SRV запрос к Consul для получения порта.
Сразу оговорюсь, что опыта использования php библиотеки для Consul у меня лично нету. В Вашем конкретном случае в связи с тем, что ни Symphony ни Zend Framework (насколько мне известно) не поддерживают напрямую обращение к Consul, Вам придется написать что-то вроде плагина для указанных платформ который бы запрашивал необходимую информацию в Consul и передавал ее непосредственно ядру фреймворка.
Теперь пишем в конфиг discoveryUrl = localhost:8500/v1/catalog/service/mongo-db
Фишка в том, что discoveryUrl фиксирован (он на всегда localhost и формат запроса стабилизирован) и описывать в конфиг-файле сервиса его не имеет смысла. Единственное что нужно — соглашение об именовании сервисов.
а если нужно будет не один mongo-db а несколько (тестовый, промышленный)
И тут не проблема — просто нужно зарегистрировать разные версии с разными именами или использовать механизм тегирования при объявлении сервиса.
По поводу того какая база или коллекция должна быть использована — Consul KV может быть использован для прозрачной передачи каких-либо настроек. Подробнее в документации.
Дело в том, что Вы не найдете гайдов по Consul — весь гайд это описание API и пара несложных примеров его использования. Да и не может быть гайдов в принципе (равно как и условий в которых можно использовать только Consul) и причина этого очень проста: Consul это не самостоятельный программный продукт, а один из строительных кирпичиков MSA (при чем не обязательно незаменимый). Consul достаточно трудно натянуть на уже работающую систему без структурных изменений ее архитектуры, мало того — многим системам совершенно и не нужны микросервисы, SD и все, что с этим связано. Но, если Вы системный архитектор и в данный момент проектируете систему которая должна легко масштабироваться, быстро разрабатываться и меняться под новые потребности, — без подходов заложенных в MSA Вам вряд ли обойтись. И вот тут уже приходит на помощь Consul — как часть микросервисной архитектуры отвечающая за SD компонентов.
Как таковым гайдом/примером использования может служить полное описание распределенной системы использующей Consul, но подобное описание вряд ли разрешат предоставить владельцы таких систем.
Отличное замечание. Можно и так, однако мне кажется, что предпочтительнее принудительно дерегистрировать сервис не прошедший health check, во избежание накопления мусора в Consul.
Не хотелось бы превращать обзорную статью в полноценный гайд по использованию SD. Но можно попробовать кратенько. Итак методология простенького сценария такова:
1. запускаем MongoDB и регистрируем ее в Consul
2. запускаем микросервис(ы) который использует MongoDB как хранилище. Сервис вместо того, чтобы лезть в свой конфиг-файл (где указано системой оркестровки адрес MongoDB сервера и его порт), делает запрос в Consul (по ссылке localhost:8500/v1/catalog/service/mongo-db) и получает данные о том, куда ему подключаться.
3. проходит некоторое время и MongoDB сервер меняет хост (достаточно частый случай для облачных сред, Mesos кластеров и прочих IaaS сервисов; и удержимся от описания того, как данные будут мигрировать)
4. В обычных случаях (без SD), начинаем: zabbix рапортует о том, что монга умерла, запускаем оркестратор — генерим новую монгу, генерим куче сервисов новый конфиг файл с атрибутами коннекта к новой монге, перезапускаем их. В случае с SD, приложение получает connection drop с сервером MongoDB и переходит в состояние некое состояние standby во время которого периодически опрашивает Consul на предмет регистрации нового инстанса MongoDB. Получив данные о регистрации — переподключается.
Очевидная выгода в том, что не используются сторонние по отношению к системе компоненты (системы мониторинга и оркестровки, — но я не призываю не использовать их вообще), сервисы не рестартуют продолжая выполнять какие-то запросы не зависящие от наличия подключения к MongoDB, и таки — отсутствие конфигурационных файлов (не в общем как таковых, но в данном конкретном случае можно без них).
В любом случае — интеграция Consul это не просто «поставил-настроил-работает», — это серьезный архитектурный шаг и не факт, что он подойдет в любом случае.
Ну, во первых Consul — это не замена для систем оркестровки — это разные вещи. Определенно одна из причин Вашего недовольства очень проста: это попытка натянуть на текущую спроектированную и отлаженную систему Consul и попытаться его как-то использовать. Да — это ни к чему хорошему не приведет, скорее даже наоборот — добавит массу неудобств и «костылей» чтобы все это запустить.
Внедрение Consul и SD больше подходит для систем которые находятся в состоянии начального проектирования, либо для таких, архитектура которых себя исчерпала и требуется рефакторинг (читай перепроектировать систему и переделать ее компоненты).
В примере с Zabbix-ом — тоже разночтение: Consul использует health-check проверки для того, чтобы дерегистрировать сервис, который более не может выполнять свои функции и не может быть больше использован другими компонентами системы. Consul ни в коем случае не заменит мониторинговую систему.
Собственно, а где-же попытка собрать докер в докере? Вот интересно было бы, чтобы докер-сборщик собирал бы собственно имедж другого контейнера как артефакт.
Абсолютно согласен с тем, что Вы описали по части реквизитов, — все верно. Каюсь: на момент написания статьи и сам Salt и автор были еще не столь глубоко знакомы. :) Но все меняется со временем и остальные статьи — тому пример.
Но, на самом деле, соль статьи была как раз в описании мало документированного примера использования модуля cp. И стейты в статье описывались не как пример для «copy-paste» себе в дерево, а как рассмотрение шагов модернизации от самого простого проходя более комплексный (всегда рабочий, но не всегда элегантный!) до последнего, описывающего собственно то, что удалось выкопать автору и то, чем хотелось бы поделится.
Естественно, как мне кажется, каждый должен применять голову к тому или иному материалу изложенному на Хабре.
В любом случае — буду рад прочесть и обсудить Вашу статью на тему SaltStack, — вполне возможно, что мне будет чему поучится.
Идея с consul звучит прекрасно и очень подходит для уже существующих систем которым необходимы модификации в живую инфраструктуру. Конкретно в моем случае — все создается «с нуля» и в уже подготовленной конфигурации — т.е. масштабирование не входит в задачу для SaltStack. В любом случае — использовать или нет service discovery очень специфичный вопрос во многом зависящий от того, какую инфраструктуру оно будет обслуживать. К примеру, CHD (одна из реализаций стека Apache Hadoop от Cloudera) управляет своим кластером не требуя внешних приложений.
приветствую! да, действительно *_in реквизиты достаточно сильно упрощают жизнь, но, по сути, делают то же самое, что и собственно реквизиты описанные в самих зависимых стейтах, потому оба способа — приемлемы. По поводу file.recurse — этот стейт еще не входил в поставку salt stack на момент написания статьи :) (вышел только в 2014.7.0) В любом случае — советы правильные, спасибо.
Судя по живому интересу сетевого сообщества к последним разработкам в области систем управления и автоматизации (я имею ввиду SaltStack и Ansible — как флагманы, также недавно переработанный Chef) таки есть удачные внедрения и, думается, достаточно много.
Из своего личного опыта могу сказать, что пределов применения подобных систем почти нету, к примеру, — сейчас я использую SaltStack для создания тестовых окружений для приложения работающего с BigData провайдерами (Apache Hadoop, Horton Works, MapR) с применением автоматизированного создания этих окружений в публичных/приватных облачных провайдерах (Amazon, GoGrid, OpenStack). Если слышали что-то про указанные технологии, то понимаете, сколько административной работы пришлось бы затратить на создание этого «добра» в ручном режиме. С помощью грамотно созданных автоматизаций этот процесс занимает 20-30 минут для кластера из 10 машин.
В любом случае — каждый выбирает для себя что автоматизировать. Можно даже, банально накладывать security патчи на 100 серверов одновременно и в этом уже большой профит от таких систем.
Вполне может показаться, что его (я про Python) тут и нету, но, как говорят, дьявол кроется в мелочах: любое описание стейта для SaltStack — микс YAML/Jinja2/Python funcs — что неразрывно связанно с языком Python. Конечно же, в этом материале не будет описаний революционных методик написания кода на питоне, но связь в любом случае присутствует.
Спасибо за признательность. Действительно — почти все приходится делать с самого нуля т.к. реально работающих примеров и техник не так уже и много найдется среди гигабайтов сырых перепечаток документации и туториалов.
Надеюсь Ваш комментарий будет полезен всет тем, кто читает статью в 19-году.
Другой вопрос именно в функционировании: его нельзя использовать как средство для решения проблем текущей инфраструктуры, — под использование Mesos необходимо переделывать много всего. Плюс пока не решенные проблемы с persistent storage (точнее в 0.25 — уже должны анонсировать таковое для отдельного фреймворка) оставляют использование Mesos для энтузиастов. Однако, я считаю, что за подобными системами будущее.
Фишка в том, что discoveryUrl фиксирован (он на всегда localhost и формат запроса стабилизирован) и описывать в конфиг-файле сервиса его не имеет смысла. Единственное что нужно — соглашение об именовании сервисов.
И тут не проблема — просто нужно зарегистрировать разные версии с разными именами или использовать механизм тегирования при объявлении сервиса.
По поводу того какая база или коллекция должна быть использована — Consul KV может быть использован для прозрачной передачи каких-либо настроек. Подробнее в документации.
Как таковым гайдом/примером использования может служить полное описание распределенной системы использующей Consul, но подобное описание вряд ли разрешат предоставить владельцы таких систем.
1. запускаем MongoDB и регистрируем ее в Consul
2. запускаем микросервис(ы) который использует MongoDB как хранилище. Сервис вместо того, чтобы лезть в свой конфиг-файл (где указано системой оркестровки адрес MongoDB сервера и его порт), делает запрос в Consul (по ссылке localhost:8500/v1/catalog/service/mongo-db) и получает данные о том, куда ему подключаться.
3. проходит некоторое время и MongoDB сервер меняет хост (достаточно частый случай для облачных сред, Mesos кластеров и прочих IaaS сервисов; и удержимся от описания того, как данные будут мигрировать)
4. В обычных случаях (без SD), начинаем: zabbix рапортует о том, что монга умерла, запускаем оркестратор — генерим новую монгу, генерим куче сервисов новый конфиг файл с атрибутами коннекта к новой монге, перезапускаем их. В случае с SD, приложение получает connection drop с сервером MongoDB и переходит в состояние некое состояние standby во время которого периодически опрашивает Consul на предмет регистрации нового инстанса MongoDB. Получив данные о регистрации — переподключается.
Очевидная выгода в том, что не используются сторонние по отношению к системе компоненты (системы мониторинга и оркестровки, — но я не призываю не использовать их вообще), сервисы не рестартуют продолжая выполнять какие-то запросы не зависящие от наличия подключения к MongoDB, и таки — отсутствие конфигурационных файлов (не в общем как таковых, но в данном конкретном случае можно без них).
В любом случае — интеграция Consul это не просто «поставил-настроил-работает», — это серьезный архитектурный шаг и не факт, что он подойдет в любом случае.
Внедрение Consul и SD больше подходит для систем которые находятся в состоянии начального проектирования, либо для таких, архитектура которых себя исчерпала и требуется рефакторинг (читай перепроектировать систему и переделать ее компоненты).
В примере с Zabbix-ом — тоже разночтение: Consul использует health-check проверки для того, чтобы дерегистрировать сервис, который более не может выполнять свои функции и не может быть больше использован другими компонентами системы. Consul ни в коем случае не заменит мониторинговую систему.
Но, на самом деле, соль статьи была как раз в описании мало документированного примера использования модуля cp. И стейты в статье описывались не как пример для «copy-paste» себе в дерево, а как рассмотрение шагов модернизации от самого простого проходя более комплексный (всегда рабочий, но не всегда элегантный!) до последнего, описывающего собственно то, что удалось выкопать автору и то, чем хотелось бы поделится.
Естественно, как мне кажется, каждый должен применять голову к тому или иному материалу изложенному на Хабре.
В любом случае — буду рад прочесть и обсудить Вашу статью на тему SaltStack, — вполне возможно, что мне будет чему поучится.
Из своего личного опыта могу сказать, что пределов применения подобных систем почти нету, к примеру, — сейчас я использую SaltStack для создания тестовых окружений для приложения работающего с BigData провайдерами (Apache Hadoop, Horton Works, MapR) с применением автоматизированного создания этих окружений в публичных/приватных облачных провайдерах (Amazon, GoGrid, OpenStack). Если слышали что-то про указанные технологии, то понимаете, сколько административной работы пришлось бы затратить на создание этого «добра» в ручном режиме. С помощью грамотно созданных автоматизаций этот процесс занимает 20-30 минут для кластера из 10 машин.
В любом случае — каждый выбирает для себя что автоматизировать. Можно даже, банально накладывать security патчи на 100 серверов одновременно и в этом уже большой профит от таких систем.