Ну, опять же, у вас просто еще не те масштабы. И не задача полноценного деплоя.
Что касается «с тем же именем» — не совсем в тему, но вспомнил несколько случаев когда доблестные сетевые инженеры случайно косячили и в сети появлялось устройство с не совсем уникальным IP-адресом. Поскольку использовать DHCP считалось не совсем безопасным, а так же часто требовались статические адреса — все адреса в сети выдавались руками. И коллизии случались.
Иногда проще и быстрее переименовать свой сервер, чем писать заявку на смену IP-адреса у свича, которая будет запланирована через неделю.
Еще вполне может отвалиться вся подсеть, в которой стоит ваш мастер-сервер.
Случиться может что угодно, а статически зашитый адрес мастера на нескольких тысячах устройств, на мой взгляд, не гибко.
Не подумайте что я вас критикую — наоборот, я вам даже плюс поставил.
Моя мысль всегда — для определенных случаев Puppet/Chef вполне подходят.
Но как «silver bullet» надо использовать их с осторожностью.
Соглашусь, но даже для этих целей меня, как администратора, напрягали бы следующие моменты:
* В нагруженной сети из 1000 (или больше машин) время от времени (в случайные моменты времени) сервера тратят время/трафик на бесполезные обращения к мастер-серверу. Два раза в месяц они находят обновления, но в остальное время они работают вхолостую.
* Из этих 1000 серверов внезапно на три не дошли обновления. Неизвестно почему. Агент не запросил. В Foreman мы увидим, конечно, что какие-то агенты долго не отвечали, но, поверьте, в большой сети у вас там скопится достаточное количество старых записей и вы не сразу отловите эти необновленные конфигурации.
* внезапно количество серверов резко возрастает и приходится придумывать схемы с балансированием нагрузки, поскольку сервер начинает трещать даже если не делает ничего.
* обновления накатываются фактически бесконтрольно. Когда-то в течение этих N минут что-то накатится. Если нода была выключена месяц, а потом включилась — она будет тянуть все эти манифесты и применять, даже если сейчас не время…
* адрес мастер-сервера может смениться. Вот полетел raid в ESXi-кластере, мастер паппета недоступен, бэкап есть, но с тем же именем в сети его поднять не получается по каким-то причинам.
В серьезных сетях я предпочел бы контролировать такие вещи более строго.
Я предпочитаю использовать push-схему, когда есть центральный сервер, который обладает знаниями о всей топологии и может принимать решения о порядке запуска обновлений на серверах.
Первоначальное решение «в лоб» мы делали следующим образом — центральный сервер выбирает группу серверов для обновления, пишет в chef-сервер необходимые параметры (роли), затем удаленно коннектится к каждой ноде (параллельно, распределенно) и насильно запускает на них chef-агент с заданным именем chef-сервера. Остальное — стандартно. После завершения работ ноды рапортуют на главный сервер и он выбирает следующую группу.
Позже мы ушли от Chef совсем, написав своего агента и немного упростив-улучшив схему.
Согласен, для обновления независимых друг от друга компьютеров — решение может подойти.
Но, опять же, в своей практике я встречал слишком много случаев когда сервер, поднятый из стандартного образа, лез не на тот master-сервер из-за разных причин. Зашитый на ноде адрес мастера — очередная проблема.
Раз в полчаса — они размазаны по времени или все в одно и то же время?
Вот в этом, на мой взгляд, одна из главных опасных особенностей использования систем с самостоятельным агентом.
Например, мы имеем базу и несколько веб-серверов. Самый простой вариант…
База обновляется миграциями, все по-уму. Пусть даже руками, хотя это тоже хочется автоматически.
Но вот база обновилась, но код на веб серверах обновится хз в какой момент, но в течение получаса.
То есть все эти 30 минут мы не будем точно знать насколько консистентна система? А пользователи идут и получают ошибки либо в базу пишется что-то не то.
Это еще самый простой вариант, когда у вас нет сложной связки сервисов, которые нужно обновлять один-за-другим строго по очереди или обновлять кластер.
Прошу прощения, но у меня зуб на Puppet и Chef — я могу много недостатков перечислить :)
Боюсь, что какие-то количественные оценки вы все-таки должны будете выдать. Качественные оценки не катят.
Бизнес не устроит фраза «будет лучше», их всегда интересует «насколько лучше».
Мы видим что вы слегка троллите, но почему бы и не возразить, тем более, что аргументы еще есть.
Разработчику платят за время — соглашусь. Но разработчик стремится упростить жизнь и себе. Так называемая «чистота кода» — не просто эстетический принцип.
Есть разница как реализовать задачу «добавить кнопку»:
1. Нарисовать кнопку на форме (поиграться со стилями чтоб не съехало из-за таблиц), добавить обработчик на UI, добавить получатель события на бэкенде, захардкодить семь констант, отправить три сообщения и добавить sleep'ов чтоб получить ответ, реализовать саму операцию (документацию читать некогда, сделаю все сам), отладить, мат, починить, отладить, кофе, отладить, мат-кофе-мат-кофе, починить, починить, починить…
2. Просто добавить тип операции «reboot» в массив операций на UI (нарисует кнопку само, отрендерит, добавит стандартный обработчик), а на бэкенде из очереди сам заберет демон и все отработает (эта операция поддерживается движком, еще полгода назад с Серегой сделали).
В результате во втором случае мы помним что все нужно сделать в одном (максимум двух) местах.
А в первом случае мы затронули половину файлов проекта, голова пухнет — все не запомнить, местами лапша из таких же if'ов, которые остались от прошлого разработчика (интересно почему он уволился так быстро?), один тест не проходит (его пока отключим), а в комнату входит Михалваныч с задачей по еще одной кнопке.
В итоге получаем дергающийся глаз и недовольное начальство (первый случай) или грамоту за быструю работу (второй).
То есть вы фактически делаете рефакторинг, но без одобрения руководства и включаете это время в разработку одобренных фич.
Это тоже способ и, наверное, самый спокойный для нервов. Пока не узнает начальство.
В моем опыте Михалваныч был в меру адекватным и раз в год время на рефакторинг по «техническому долгу» нам выделялось — недели три-четыре (целый спринт) на рефакторинг плюс пара мелких фич бонусом.
SD позволяет существенно упростить этот процесс (как именно, пытливый читатель уже думаю догадался)
Вот на этом месте и возникли вопросы. Не могли бы вы подробнее рассказать, чтобы не было недопониманий?
Если это разные вещи, то зачем вы их сравнивали?
Если вы имели в виду отказ от конфигов с помощью авторегистрации в коде — то да, в своем коде мы можем это сделать и это было бы очень удобно. Но что там про mongodb и кластер?
Начал читать и подумал — а идея правильная, SD сейчас актуален в больших сервисах, интересно как они это предлагают…
Но по ходу чтения статьи совершенно не понял в чем преимущество перед системами оркестрации. Нам нужно поменять некоторые параметры в конфигах для 20 серверов, скажем. Причем, не все сразу, а по-очереди, сначала на базах, а потом на веб-серверах. Как нам тут поможет Consul и почему в нем это будет проще?
Представим, что у нас есть сервис с 2000 серверов и уже настроен, скажем, Zabbix с локальными агентами, которые проверяют состояник сервисов. Нам теперь еще надо для каждого сервиса написать конфиг для Consul, который будет делать то же самое?
На мой взгляд такие системы были бы удобнее не как отдельный сервис, а как библиотека, встраиваемая непосредственно в код — особенно для самописных сервисов.
Подтверждаю, это очень сложно со стороны разработчиков продать высокому руководству идею о том чтобы «переписать» какую-то функциональность.
Руководство обычно более опытно в таких разговорах и обычно диалоги сводятся к таким:
— Михалваныч, пора рефакторинг делать!
— Да? А долго?
— Ну за три недели можно успеть.
— У, @$#%! А что поменяется?
— Ну для клиентов ничего, но…
— Так, никакого рефакторинга, давайте баги чините лучше!
Лучше действовать осторожнее:
— Семен, надо добавить кнопку чтоб сервера перезагружать удобнее.
— Михалваныч, три дня.
— @$%%";"%!!! Как три дня? Это ж просто кнопка! А если попрошу просто цвет поменять — ты скажешь что неделю?
— У нас очень сложный код. Если его переписать, то потом можно будет за полчаса все делать.
— Хмм, ну хорошо, сейчас не будем, но я подумаю.
Даже такой диалог полезен — на третий-пятый раз Михалваныч не выдержит и вам может повезти.
Вообще, в общении с начальством надо чтобы идеи приходили в голову ему, даже если первоначально они заходили к вам.
По-моему, этой фиче сто лет в обед. Первым появилось лет 10 назад в gmail, а, возможно, и еще раньше. После этого все остальные сервисы обзавелись подобным.
Я для сбора писем с разных ящиков в один пользуюсь по-старинке обычным форвардингом.
Сам сайт КИК-СССР яростно рекомендую. Случайно наткнулся на него однажды и потратил два дня на чтение статей про оборудование и технику. Не оторваться!
На всякий случай порекомендую известный многим, но, возможно, неизвестный некоторым сайт http://buran.ru/, а особенно Воспоминания Владимира Ермолаева, которые, благодаря хорошему юмору и интересному описанию, можно перечитывать несколько раз.
Что касается «с тем же именем» — не совсем в тему, но вспомнил несколько случаев когда доблестные сетевые инженеры случайно косячили и в сети появлялось устройство с не совсем уникальным IP-адресом. Поскольку использовать DHCP считалось не совсем безопасным, а так же часто требовались статические адреса — все адреса в сети выдавались руками. И коллизии случались.
Иногда проще и быстрее переименовать свой сервер, чем писать заявку на смену IP-адреса у свича, которая будет запланирована через неделю.
Еще вполне может отвалиться вся подсеть, в которой стоит ваш мастер-сервер.
Случиться может что угодно, а статически зашитый адрес мастера на нескольких тысячах устройств, на мой взгляд, не гибко.
Моя мысль всегда — для определенных случаев Puppet/Chef вполне подходят.
Но как «silver bullet» надо использовать их с осторожностью.
* В нагруженной сети из 1000 (или больше машин) время от времени (в случайные моменты времени) сервера тратят время/трафик на бесполезные обращения к мастер-серверу. Два раза в месяц они находят обновления, но в остальное время они работают вхолостую.
* Из этих 1000 серверов внезапно на три не дошли обновления. Неизвестно почему. Агент не запросил. В Foreman мы увидим, конечно, что какие-то агенты долго не отвечали, но, поверьте, в большой сети у вас там скопится достаточное количество старых записей и вы не сразу отловите эти необновленные конфигурации.
* внезапно количество серверов резко возрастает и приходится придумывать схемы с балансированием нагрузки, поскольку сервер начинает трещать даже если не делает ничего.
* обновления накатываются фактически бесконтрольно. Когда-то в течение этих N минут что-то накатится. Если нода была выключена месяц, а потом включилась — она будет тянуть все эти манифесты и применять, даже если сейчас не время…
* адрес мастер-сервера может смениться. Вот полетел raid в ESXi-кластере, мастер паппета недоступен, бэкап есть, но с тем же именем в сети его поднять не получается по каким-то причинам.
В серьезных сетях я предпочел бы контролировать такие вещи более строго.
Первоначальное решение «в лоб» мы делали следующим образом — центральный сервер выбирает группу серверов для обновления, пишет в chef-сервер необходимые параметры (роли), затем удаленно коннектится к каждой ноде (параллельно, распределенно) и насильно запускает на них chef-агент с заданным именем chef-сервера. Остальное — стандартно. После завершения работ ноды рапортуют на главный сервер и он выбирает следующую группу.
Позже мы ушли от Chef совсем, написав своего агента и немного упростив-улучшив схему.
Но, опять же, в своей практике я встречал слишком много случаев когда сервер, поднятый из стандартного образа, лез не на тот master-сервер из-за разных причин. Зашитый на ноде адрес мастера — очередная проблема.
Вот в этом, на мой взгляд, одна из главных опасных особенностей использования систем с самостоятельным агентом.
Например, мы имеем базу и несколько веб-серверов. Самый простой вариант…
База обновляется миграциями, все по-уму. Пусть даже руками, хотя это тоже хочется автоматически.
Но вот база обновилась, но код на веб серверах обновится хз в какой момент, но в течение получаса.
То есть все эти 30 минут мы не будем точно знать насколько консистентна система? А пользователи идут и получают ошибки либо в базу пишется что-то не то.
Это еще самый простой вариант, когда у вас нет сложной связки сервисов, которые нужно обновлять один-за-другим строго по очереди или обновлять кластер.
Прошу прощения, но у меня зуб на Puppet и Chef — я могу много недостатков перечислить :)
Бизнес не устроит фраза «будет лучше», их всегда интересует «насколько лучше».
Разработчику платят за время — соглашусь. Но разработчик стремится упростить жизнь и себе. Так называемая «чистота кода» — не просто эстетический принцип.
Есть разница как реализовать задачу «добавить кнопку»:
1. Нарисовать кнопку на форме (поиграться со стилями чтоб не съехало из-за таблиц), добавить обработчик на UI, добавить получатель события на бэкенде, захардкодить семь констант, отправить три сообщения и добавить sleep'ов чтоб получить ответ, реализовать саму операцию (документацию читать некогда, сделаю все сам), отладить, мат, починить, отладить, кофе, отладить, мат-кофе-мат-кофе, починить, починить, починить…
2. Просто добавить тип операции «reboot» в массив операций на UI (нарисует кнопку само, отрендерит, добавит стандартный обработчик), а на бэкенде из очереди сам заберет демон и все отработает (эта операция поддерживается движком, еще полгода назад с Серегой сделали).
В результате во втором случае мы помним что все нужно сделать в одном (максимум двух) местах.
А в первом случае мы затронули половину файлов проекта, голова пухнет — все не запомнить, местами лапша из таких же if'ов, которые остались от прошлого разработчика (интересно почему он уволился так быстро?), один тест не проходит (его пока отключим), а в комнату входит Михалваныч с задачей по еще одной кнопке.
В итоге получаем дергающийся глаз и недовольное начальство (первый случай) или грамоту за быструю работу (второй).
Это тоже способ и, наверное, самый спокойный для нервов. Пока не узнает начальство.
В моем опыте Михалваныч был в меру адекватным и раз в год время на рефакторинг по «техническому долгу» нам выделялось — недели три-четыре (целый спринт) на рефакторинг плюс пара мелких фич бонусом.
Вот на этом месте и возникли вопросы. Не могли бы вы подробнее рассказать, чтобы не было недопониманий?
Если это разные вещи, то зачем вы их сравнивали?
Если вы имели в виду отказ от конфигов с помощью авторегистрации в коде — то да, в своем коде мы можем это сделать и это было бы очень удобно. Но что там про mongodb и кластер?
Но по ходу чтения статьи совершенно не понял в чем преимущество перед системами оркестрации. Нам нужно поменять некоторые параметры в конфигах для 20 серверов, скажем. Причем, не все сразу, а по-очереди, сначала на базах, а потом на веб-серверах. Как нам тут поможет Consul и почему в нем это будет проще?
Представим, что у нас есть сервис с 2000 серверов и уже настроен, скажем, Zabbix с локальными агентами, которые проверяют состояник сервисов. Нам теперь еще надо для каждого сервиса написать конфиг для Consul, который будет делать то же самое?
На мой взгляд такие системы были бы удобнее не как отдельный сервис, а как библиотека, встраиваемая непосредственно в код — особенно для самописных сервисов.
Руководство обычно более опытно в таких разговорах и обычно диалоги сводятся к таким:
— Михалваныч, пора рефакторинг делать!
— Да? А долго?
— Ну за три недели можно успеть.
— У, @$#%! А что поменяется?
— Ну для клиентов ничего, но…
— Так, никакого рефакторинга, давайте баги чините лучше!
Лучше действовать осторожнее:
— Семен, надо добавить кнопку чтоб сервера перезагружать удобнее.
— Михалваныч, три дня.
— @$%%";"%!!! Как три дня? Это ж просто кнопка! А если попрошу просто цвет поменять — ты скажешь что неделю?
— У нас очень сложный код. Если его переписать, то потом можно будет за полчаса все делать.
— Хмм, ну хорошо, сейчас не будем, но я подумаю.
Даже такой диалог полезен — на третий-пятый раз Михалваныч не выдержит и вам может повезти.
Вообще, в общении с начальством надо чтобы идеи приходили в голову ему, даже если первоначально они заходили к вам.
Я для сбора писем с разных ящиков в один пользуюсь по-старинке обычным форвардингом.
На всякий случай порекомендую известный многим, но, возможно, неизвестный некоторым сайт http://buran.ru/, а особенно Воспоминания Владимира Ермолаева, которые, благодаря хорошему юмору и интересному описанию, можно перечитывать несколько раз.