Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 88
Хорошо бы описать задачу, с которой Chef или Puppet не справились бы и плясать от этого.
Я думаю не стоило разделять, вываливайте на наши головы все сразу!
Очень хочется услышать реализацию, сам проходил по подобному пути от «все делается руками и занимает полчаса» до «Как, на 50 серверах поменять конфиг до вчера?»
Очень хочется услышать реализацию, сам проходил по подобному пути от «все делается руками и занимает полчаса» до «Как, на 50 серверах поменять конфиг до вчера?»
Для затравки даже слишком мало. Пишите продолжение.
Мы сейчас используем связку Puppet и Capistrano. Puppet «готовит» площадки (их несколько, у каждого заказчика своя) и ставит и настраивает вспомогательные сервисы. Capistrano деплоит основное приложение. Первое же ограничение: на puppet-мастере может быть только 1 модуль одной версии. А приложения у разных заказчиков имеют особенность расходиться в версиях (в виду организационных, финансовых и прочих причин). Пока что это доставляет только теоретическое неудобство, но я уже понимаю, что надо мигрировать с Puppet'а куда-нибудь ещё, пока смотрю в сторону Ansible. Ну а что делать с несвязанностью Capistrano и инструмента подготовки площадок (два разных конфига, которые должны быть синхронны) — я ещё и не знаю.
Мы сейчас используем связку Puppet и Capistrano. Puppet «готовит» площадки (их несколько, у каждого заказчика своя) и ставит и настраивает вспомогательные сервисы. Capistrano деплоит основное приложение. Первое же ограничение: на puppet-мастере может быть только 1 модуль одной версии. А приложения у разных заказчиков имеют особенность расходиться в версиях (в виду организационных, финансовых и прочих причин). Пока что это доставляет только теоретическое неудобство, но я уже понимаю, что надо мигрировать с Puppet'а куда-нибудь ещё, пока смотрю в сторону Ansible. Ну а что делать с несвязанностью Capistrano и инструмента подготовки площадок (два разных конфига, которые должны быть синхронны) — я ещё и не знаю.
Да, вот именно множество версий — одна из основных проблем, которую с помощью Chef решить не так просто.
По поводу продолжения — вас понял. Сейчас дописываю третью часть, но, наверное, объединю вторую и третью, а потом постараюсь урезать бьющий поток мыслей и все уместить в последнюю часть.
По поводу продолжения — вас понял. Сейчас дописываю третью часть, но, наверное, объединю вторую и третью, а потом постараюсь урезать бьющий поток мыслей и все уместить в последнюю часть.
Может открою секрет, но у нас это решается использованием r10k
А в чем проблема хранить несколько версий одной кукбуки на chef сервере?
Задавать через chef_environment, который править через berkshelf.
Задавать через chef_environment, который править через berkshelf.
Что конкретно у вас с версиями в Chef не получается?
А использовать enviroment не пробовали?
В каждое окружение можно запихнуть свою версию модуля. Модули которые доступны для всех окружений лежат в /etc/puppet/modules
В каждое окружение можно запихнуть свою версию модуля. Модули которые доступны для всех окружений лежат в /etc/puppet/modules
Сейчас у нас environment'ы — это переменные, задающиеся для нод в site.pp, по этим environment'ам из Hiera подтягиваются площадко-специфичные настройки, но версия модуля одна. Про то, что каждому environment'у можно иметь свою версию модуля, я не знал.
То есть постоянно перебрасывать сервер между environment'ами? Да, выход, для небольшого количества серверов.
Но не очень красиво, особенно если environment'ы уже используются по прямому назначению.
Могут возникнуть вопросы — а что делать если на один сервер нужно поставить два сервиса разных версий (в вашем случае environment'ов)?
Но не очень красиво, особенно если environment'ы уже используются по прямому назначению.
Могут возникнуть вопросы — а что делать если на один сервер нужно поставить два сервиса разных версий (в вашем случае environment'ов)?
Это вам тогда нужно модуль перепиливать, что бы можно было ставить два сервиса разных версий. Я вот так вижу.
Да, скорее всего.
В итоге все меньше преимуществ «из коробки» и все больше самописных костылей.
Кстати, хотелось бы узнать, как обычно у коллег решаются такие вопросы:
* есть вы, кто пытается автоматизировать хаос в деплойменте
* есть программист, который пишет сервис A на Erlang
* есть программист, который пишет сервис B на NodeJS
* есть программист (который работает тут уже 15 лет) на языке C, пишущий сервис C. Он звезда и может сказать вам где этот ваш руби он крутил вместе с вами.
Ну, допустим, есть еще десяток разных сервисов — от MSSQL до Java…
Кто должен описывать скрипты для установки этих сервисов?
В итоге все меньше преимуществ «из коробки» и все больше самописных костылей.
Кстати, хотелось бы узнать, как обычно у коллег решаются такие вопросы:
* есть вы, кто пытается автоматизировать хаос в деплойменте
* есть программист, который пишет сервис A на Erlang
* есть программист, который пишет сервис B на NodeJS
* есть программист (который работает тут уже 15 лет) на языке C, пишущий сервис C. Он звезда и может сказать вам где этот ваш руби он крутил вместе с вами.
Ну, допустим, есть еще десяток разных сервисов — от MSSQL до Java…
Кто должен описывать скрипты для установки этих сервисов?
DevOps/Release/CI инженер, он же — «Вы» из Вашего списка.
Я эти понятия не очень разделяю, возможно я в чём-то не прав, но общая суть — инженер деплоймента — он же админ продакшена, куда никто кроме системы интеграции и деплоймента не лезет.
Я эти понятия не очень разделяю, возможно я в чём-то не прав, но общая суть — инженер деплоймента — он же админ продакшена, куда никто кроме системы интеграции и деплоймента не лезет.
В идеале разработчик с огладкой на админа, в реальности админ с оглядкой на разработчика.
А вы не пробовали вместо Capistrano перейти на сборку пакетов (deb/rpm и т.п.)? Как раз и с версиями, может быть, ситуация упростится. И в puppet вы просто будете ставить native пакет.
Не пробовали, ибо не знаем, как оное делать — хороших туториалов случайно не попадалось, специально сами не гуглили. Я, правда, не представляю, как пакет будет накатывать миграции. И как откатываться в случае чего взад.
Миграции можно завязать с pre-install/post-install скриптами.
Откатываться… Ну, по идее это решение для продакшна, когда всё протестировано на стейдже, то и откатываться не надо :) По крайней мере, в автоматическом режиме.
Вместо ansible возможно вам стоит попробовать chef (пусть даже в бессерверном варианте). На мой взгляд, там можно всякие странные и извращённые вещи достаточно просто сделать.
Откатываться… Ну, по идее это решение для продакшна, когда всё протестировано на стейдже, то и откатываться не надо :) По крайней мере, в автоматическом режиме.
Вместо ansible возможно вам стоит попробовать chef (пусть даже в бессерверном варианте). На мой взгляд, там можно всякие странные и извращённые вещи достаточно просто сделать.
Давайте по делу? Мы же все-таки тут не художественную литературу читаем.
С версиями модулей проблема есть, но это не мешает вам написать модуль, который умеет устанавливать разные версии приложений. Я сталкивался с проблемой версии модулей, когда начинаешь устанавливать кучу готовых модулей из forge и у каждого свои зависимости, но у нас стояла задача установки «попсовых» приложений. Ресурсов и времени для написания своих модулей было мало, поэтому использовали, то что было в паблике.
С версиями модулей проблема есть, но это не мешает вам написать модуль, который умеет устанавливать разные версии приложений. Я сталкивался с проблемой версии модулей, когда начинаешь устанавливать кучу готовых модулей из forge и у каждого свои зависимости, но у нас стояла задача установки «попсовых» приложений. Ресурсов и времени для написания своих модулей было мало, поэтому использовали, то что было в паблике.
Да, поначалу пришлось строить лес с помощью костылей поверх Chef. Но в определенный момент понимаешь что количество своих костылей больше количества полезных фич, которые предлагает тот или иной инструмент.
Проблемы могут приходить и изнутри — версии двух пакетов внезапно могут быть одинаковыми, но разрабатываться в разных бранчах.
А сколько, как вы думаете, может продолжаться разговор о том что нам нужен внутренний репозиторий для каждого окружения?
Проблемы могут приходить и изнутри — версии двух пакетов внезапно могут быть одинаковыми, но разрабатываться в разных бранчах.
А сколько, как вы думаете, может продолжаться разговор о том что нам нужен внутренний репозиторий для каждого окружения?
А сколько, как вы думаете, может продолжаться разговор о том что нам нужен внутренний репозиторий для каждого окружения?
У нас уже год вокруг этого крутится, и всё не получается решить вопрос — когда этим заниматься ))
Так что да — продолжительное решение вопросов с активно используемой инфраструктурой.
Пока статья никак особо не связана с ее темой.
Автор работает в одной компании со мной? ;)
Как я понимаю сейчас транспорт доставки билдов и подготовки серверов у нас puppet, на него навернуты несколько слоев выше, которые обеспечивают более высокоуровневую коммуникацию.
Как я понимаю сейчас транспорт доставки билдов и подготовки серверов у нас puppet, на него навернуты несколько слоев выше, которые обеспечивают более высокоуровневую коммуникацию.
Я уверен, что будет много людей, узнающих что-то из своего процесса, поскольку, как мне кажется, проблемы в больших компаниях одни и те же :)
Собственно, статья и писалась для того, чтобы описать одни грабли и показать с какой стороны на них можно наступать и сколько раз.
Собственно, статья и писалась для того, чтобы описать одни грабли и показать с какой стороны на них можно наступать и сколько раз.
Слишком много совпадений, думаю компания все же одна.
Наступать можно бесконечно, это проверено. Некоторые даже наступают специально, что бы была видимость процесса.
Я бы сказал, что нет смысла писать свою систему автоматизации доставки билдов и управления конфигурации с нуля.
Например можно взять два-три хороших продукта разного уровня и состыковать их небольшим количеством кода под свои задачи.
Наступать можно бесконечно, это проверено. Некоторые даже наступают специально, что бы была видимость процесса.
Я бы сказал, что нет смысла писать свою систему автоматизации доставки билдов и управления конфигурации с нуля.
Например можно взять два-три хороших продукта разного уровня и состыковать их небольшим количеством кода под свои задачи.
Подходящих продуктов может и не быть, процесс компании может не захотеть меняться, а «небольшое количество кода» всегда вырастает в «большое количество кода» и в итоге мы получаем все-таки написанное свое, но с большим количеством костылей вокруг части, которую мы поменять не можем.
Например, для Windows не было и до сих пор не так уж много инструментов для глубокой настройки системы. Несколько лет назад в стандартной поставке появился PowerShell и начали появляться какие-то сниппеты, которые могут облегчить настройку. Но 5 лет назад их не было.
В Chef еще два года назад невозможно было под Windows подмонтировать сетевой ресурс с доменным юзером, например, или без буквы диска. Можно было вызвать «net use» и ловить вывод, да. Но это несерьезно.
Powershell или bash, или Ruby, или C++ для желающих — все части нужно между собой состыковывать. Bash-скрипт, запускающий python-процесс, запускающий ruby-скрипт, который запускает ruby-скрипт, который запускает bash-скрипты, которые вызывают cmd-файл под windows — через это мы проходили. Цепочка была чуть длиннее, а для linux чуть короче, но как программист, я испытываю содрогание от таких вещей, а как системный администратор — начинаю подсчитывать количество пакетов, которые нужно иметь установленными.
Например, для Windows не было и до сих пор не так уж много инструментов для глубокой настройки системы. Несколько лет назад в стандартной поставке появился PowerShell и начали появляться какие-то сниппеты, которые могут облегчить настройку. Но 5 лет назад их не было.
В Chef еще два года назад невозможно было под Windows подмонтировать сетевой ресурс с доменным юзером, например, или без буквы диска. Можно было вызвать «net use» и ловить вывод, да. Но это несерьезно.
Powershell или bash, или Ruby, или C++ для желающих — все части нужно между собой состыковывать. Bash-скрипт, запускающий python-процесс, запускающий ruby-скрипт, который запускает ruby-скрипт, который запускает bash-скрипты, которые вызывают cmd-файл под windows — через это мы проходили. Цепочка была чуть длиннее, а для linux чуть короче, но как программист, я испытываю содрогание от таких вещей, а как системный администратор — начинаю подсчитывать количество пакетов, которые нужно иметь установленными.
Мы вас вычислили по фейсбуку ;) Какое-то время мы работали в одной компании.
Может и не быть, но адаптация существующего продукта выглядит более перспективной с точки зрения развития и поддержки, чем целиком самописный код.
Например поверх той тулзы в разработке которой ты участвовал мы сейчас прикручиваем vRealize от вмвари, и оно, похоже, вполне получается жизнеспособно.
Может и не быть, но адаптация существующего продукта выглядит более перспективной с точки зрения развития и поддержки, чем целиком самописный код.
Например поверх той тулзы в разработке которой ты участвовал мы сейчас прикручиваем vRealize от вмвари, и оно, похоже, вполне получается жизнеспособно.
В статье вообще очень поверхностно это описано, мол «вот мог бы рассказать — рассказал бы, а так просто посокрушаюсь». Ни конкретных проблем ни конкретных решений. Очень бы хотелось услышать конкретику и посмотреть реальные примеры.
Когда серверов меньше десяти, по сути Chef и его аналоги даже и не нужны. Но опять же, смотря в чем конкретно состоит задача.
Вот у мня была задача периодического поднятия площадок под Rails на паре-тройке серверов в полгода. Крутил шефа, паппета, ансиблю — слишком громоздко для моих задач (хотя шеф удобнее всего). Знакомые разработчики посоветовали скрипт «babushka» с github, но он меня не сильно вдохновил. Тем более задача была даже проще. В итоге убил пару выходных, и написал свой маленький велосипед «just for fun» под названием SSKit, исходники на github. Подтянул баш и решил проблему. Код пока корявенький, но есть много TODO которые как будет время буду доделывать.
Когда серверов меньше десяти, по сути Chef и его аналоги даже и не нужны. Но опять же, смотря в чем конкретно состоит задача.
Вот у мня была задача периодического поднятия площадок под Rails на паре-тройке серверов в полгода. Крутил шефа, паппета, ансиблю — слишком громоздко для моих задач (хотя шеф удобнее всего). Знакомые разработчики посоветовали скрипт «babushka» с github, но он меня не сильно вдохновил. Тем более задача была даже проще. В итоге убил пару выходных, и написал свой маленький велосипед «just for fun» под названием SSKit, исходники на github. Подтянул баш и решил проблему. Код пока корявенький, но есть много TODO которые как будет время буду доделывать.
Коллеги, пожалуйста, подождите торопить. Я планировал выкладывать понемногу, но меня уже попросили бахнуть все сразу.
Я сейчас дописываю все идеи и в течение дня-двух выложу остальное.
Мысли копились на протяжение нескольких лет, я не профессиональный писатель и все идет довольно сумбурно, так что, пожалуйста, подождите критиковать.
Если тема интересна, мне кажется, вы вполне пока можете обсудить уже существующие вопросы, я постараюсь учесть замечания по ходу написания.
Я сейчас дописываю все идеи и в течение дня-двух выложу остальное.
Мысли копились на протяжение нескольких лет, я не профессиональный писатель и все идет довольно сумбурно, так что, пожалуйста, подождите критиковать.
Если тема интересна, мне кажется, вы вполне пока можете обсудить уже существующие вопросы, я постараюсь учесть замечания по ходу написания.
У систем управления конфигурацией есть два дополнительных важных свойства:
1) Они заменяют собой бэкап для всего, кроме данных. То есть никаких больше «бэкапов серверов». Если сервер упал, проще накатить заново, а не разворачивать бэкап. Данные при этом в дистиллированном виде отдельно бэкапятся.
2) Они позволяют за короткое время получить тестовую среду, если вдруг приспичило (а вообще говоря, и положено).
Так что даже в контексте одного сервера оно может быть полезным. Хотя порог вхождения в эти штуки очень высокий, да.
1) Они заменяют собой бэкап для всего, кроме данных. То есть никаких больше «бэкапов серверов». Если сервер упал, проще накатить заново, а не разворачивать бэкап. Данные при этом в дистиллированном виде отдельно бэкапятся.
2) Они позволяют за короткое время получить тестовую среду, если вдруг приспичило (а вообще говоря, и положено).
Так что даже в контексте одного сервера оно может быть полезным. Хотя порог вхождения в эти штуки очень высокий, да.
Ну не знаю. Общеизвестный факт, что, например, в Mail.ru админы катят через Puppet. Явно там не 2 сервера стоит.
Синдром «разумеется, наш дизайн окажется лучше и покроет все случаи, с которыми мы столкнёмся лучше, чем у готового решения». Чем лучше? Тем, что написан у нас.
Глупость чистой воды. Многие кукбуки шефа требуют тысяч человеко-часов на написание и сопровождение (тесты, да?), а делая «своё», очевидно, придётся и писать очередные рецепты/пьесы/соннеты самому.
Ин-хаус решения очень часто страдают срезанием углов (так удобнее для нашей архитектуры), что потом больно кусает в неожиданные моменты в будущем.
А главный вопрос: что будет делать компания, когда уволится Главный Архитектор Собственной Системы Деплоя?
Глупость чистой воды. Многие кукбуки шефа требуют тысяч человеко-часов на написание и сопровождение (тесты, да?), а делая «своё», очевидно, придётся и писать очередные рецепты/пьесы/соннеты самому.
Ин-хаус решения очень часто страдают срезанием углов (так удобнее для нашей архитектуры), что потом больно кусает в неожиданные моменты в будущем.
А главный вопрос: что будет делать компания, когда уволится Главный Архитектор Собственной Системы Деплоя?
Вот это хорошо сказано. Приходилось даже как-то болезненно менять всю схему деплоя, чтобы упростить работу с готовыми кукбуками шефа и минимизировать использование своих костылей. По правде говоря, болезненно это было только для нескольких девелоперов, которые накатали кучу странных скриптов и понимали, как это работает, только они сами. Главный их аргумент был знаменитое «не надо чинить то, что не сломано». Но работало это все только в комплекте с авторами этих скриптов. А речи том, чтобы тестировать систему деплоя, тогда вообще не было.
Нам в любом случае пришлось писать рецепты под нас. Готовых мы не нашли.
Универсальность нужна для продажи продукта, а для внутренних целей продукт, заточенный под себя гораздо удобнее.
А что касается «главного вопроса» — я уволился год назад. Система работает и развивается.
Проблема аналогична любой такой же из разработки ПО — качество кода и документации должно позволять другим разработчикам понять как оно работает. Не все идеально, но не все и плохо.
Универсальность нужна для продажи продукта, а для внутренних целей продукт, заточенный под себя гораздо удобнее.
А что касается «главного вопроса» — я уволился год назад. Система работает и развивается.
Проблема аналогична любой такой же из разработки ПО — качество кода и документации должно позволять другим разработчикам понять как оно работает. Не все идеально, но не все и плохо.
Понимаете, «заточенный под себя» означает, что у вас заточенные под себя бизнес-процессы, которые никогда не будут меняться. Каждый раз, когда кто-то срезает угол в архитектуре, бог заставляет котёнка рефакторить код на перле в виде одной функции на 800 строк. Если же условия меняются, появляются новые проекты, меняется структура отделов или особенности бизнеса, то время, за которое «существующий код» будет адаптирован под новую конфигурацию определяется аккуратностью её деления и соблюдения абстракций (утрируя до невозможности, чтобы в главном приложении не было хардкоженного IP сервера базы данных).
Насчёт того, что ни одного рецепта готового у вас не нашлось — просто не верю. Ни пользователей заводить, ни группы, ни устанавливать пакеты, ни конфигурировать всякие веб-сервера — не, ни разу? Или оно пролетело быстро, а вот львиную долю времени ушло на свои рецепты? Если честно, а?
ЗЫ Кривите душой: у вас «своя система», и «готовых рецептов не нашли». Под свою самописную систему не нашли?
Насчёт того, что ни одного рецепта готового у вас не нашлось — просто не верю. Ни пользователей заводить, ни группы, ни устанавливать пакеты, ни конфигурировать всякие веб-сервера — не, ни разу? Или оно пролетело быстро, а вот львиную долю времени ушло на свои рецепты? Если честно, а?
ЗЫ Кривите душой: у вас «своя система», и «готовых рецептов не нашли». Под свою самописную систему не нашли?
Очень много кастомного в сервисе, правда.
Про windows — не было практически ничего для Chef. Абсолютно ничего. Пользователи-группы — не было нужно, а вот поставить галочку в IIS даже руками не сразу найдешь в настройках — видимо.никому не было нужно.
Под Linux — создать пользователя-группу не так сложно даже на bash. Но вы абсолютно правы про срезанные углы — некоторые вещи иногда аукались. Веб-сервера — там больше проблем с настройками, сами пакеты через rpm ставятся довольно просто. А вот настройки в конфигах тоже очень хитровымученные. Девелоперы у нас тоже талантливые были…
Про windows — не было практически ничего для Chef. Абсолютно ничего. Пользователи-группы — не было нужно, а вот поставить галочку в IIS даже руками не сразу найдешь в настройках — видимо.никому не было нужно.
Под Linux — создать пользователя-группу не так сложно даже на bash. Но вы абсолютно правы про срезанные углы — некоторые вещи иногда аукались. Веб-сервера — там больше проблем с настройками, сами пакеты через rpm ставятся довольно просто. А вот настройки в конфигах тоже очень хитровымученные. Девелоперы у нас тоже талантливые были…
А, извините. Волшебный мир windows — кто ж вас тянул-то? В условиях «нам надо удобно под windows» я просто руками развожу. Был на недавнем совещании о том, как собирать image'ы с виндами — ау… страх и ужас.
под windows ничего не было, нет и в ближайшее время пока за это MS не возьмётся — не будет. вся это кнопочно-давительная система только-только разворачивается лицом к администратору-девелоперу. лет пять ещё будет.
Это с одной стороны. А с другой — afaik, тот же Chef как раз из такой системы «для внутреннего употребления» и вырос. Рассуждай его автор так же, было бы одной популярной системой управления меньше. :)
Есть большая разница, когда люди пишут инструмент, потому что его нет, и когда люди пишут инструмент, потому что существующие решения «слишком сложные».
В принципе, да, эволюционно новые системы появляются, когда старые перестают справляться. Но мотивация должна быть очень сильная и обоснованная, то есть претензия должна быть не вида «мы напишем лучше», а указание на архитектурные проблемы, которые каким-то образом создают затруднения.
В принципе, да, эволюционно новые системы появляются, когда старые перестают справляться. Но мотивация должна быть очень сильная и обоснованная, то есть претензия должна быть не вида «мы напишем лучше», а указание на архитектурные проблемы, которые каким-то образом создают затруднения.
Читал и прямо себя видел в недалеком прошлом :))
Мы используем Ansible, разработчикам он очень понравился, и для администрирования понятен.
Мы используем Ansible, разработчикам он очень понравился, и для администрирования понятен.
мимо коммент улетел. habrahabr.ru/post/263595/?reply_to=8516453#comment_8516393
я прям так вот не измерял, но субьективно дискомфорта не ощущаю.
Плейбук из 70 шагов выполнится ну минуты за 2 для хоста.
Для бОльшего кол-ва хостов выезжаем за счет форков.
А сам коннект у вас по ssh долгий? Может быть дело в этом?
Плейбук из 70 шагов выполнится ну минуты за 2 для хоста.
Для бОльшего кол-ва хостов выезжаем за счет форков.
А сам коннект у вас по ssh долгий? Может быть дело в этом?
Ну вот у меня нет ощущения, что 70 шагов за 2 минуты, это нормально. Рядом сидит команда шефоводов, и у них гигантская штука, держащая на себе необъятную мозгом инсталляцию с почти 250к строк в репе с шефом (из них 180к строк — кукбуки), выполняется (в холостом режиме, когда всё уже сконфигурировано и надо только проверить, что не поменялось) секунд за 20-30.
Оно меня настолько впечатлило, что я даже подумываю, что надо-таки сесть и выучить шеф, чтобы самому сравнить с ансиблом.
Оно меня настолько впечатлило, что я даже подумываю, что надо-таки сесть и выучить шеф, чтобы самому сравнить с ансиблом.
Я честно не знаю, как там работает Шэф.
Для меня такая скорость (теоретическая. я могу ошибиться, но не сильно :)) приемлима. Попробуйте увеличить кол-во форков
Вообще ансиб штука последовательная. Пока она не выполнит шаг на всех нодах — дальше не пойдет. Возможно этим выезжают Паппеты и Шэфы
Для меня такая скорость (теоретическая. я могу ошибиться, но не сильно :)) приемлима. Попробуйте увеличить кол-во форков
Вообще ансиб штука последовательная. Пока она не выполнит шаг на всех нодах — дальше не пойдет. Возможно этим выезжают Паппеты и Шэфы
Я про время исполнения на конкретном сервере. Лично для меня время «запустил посмотреть как оно будет» и «отреагировал на опечатку в шаблоне» получается некомфортно большим. Условно, я успеваю заглянуть на 2-3 сайта за это время и написать вам комментарий. Что с одной стороны хорошо для безделия (
xkcd://компилируется), а с другой, если интересует результат работы, начинает мешать.И этим же этот же Puppet не нравится. Когда машинам нужны знания о других машинах, то нужно несколько прогонов Puppet'а на каждой из машин, чтобы полностью «собрать» конфигурацию. Пока Puppet не поставит машину с СУБД, машина с приложением не узнает адрес машины с БД, пока не будет готова машина с приложением, то в СУБД не вставится правило, разрешающее подключаться к базе приложению, и в балансировщик машина с приложением тоже не «пропишется» и так далее. Получается какая-то «eventually configured» парадигма.
Как вы его производительность ощущаете? Меня оно уже бесит, потому что template для двух десятков файлов — это целое Сложное Дело, которое долго выполняется.
Вы про Ansible?
темплейт для 20 файлов… ээ… Что-то в консерватории не так.
Можно подробнее, про задачу то, попробую подумать
темплейт для 20 файлов… ээ… Что-то в консерватории не так.
Можно подробнее, про задачу то, попробую подумать
Обычная конфигурация, десяток приложений, у каждой в среднем 20 файлов. В сумме большую часть времени процесс тупит на обработке этих шаблонов. И это в режиме «без изменений», то есть прогон на всякий случай. Я посмотрел-посмотрел и испытываю некоторое разочарование, потому что шеф за это время успевает прошерстить кратно большее число рецептов.
Какая версия?
1.7.2
Стоит проверить на текущей стабильной 1.9.х
И тут начинается очередная проблема с системами управления конфигурациями: они крайне медленно обновляются в репозиториях.
Вообще-то для всех основных дистрибутивов есть репозитории с последней стабильной версией docs.ansible.com/ansible/intro_installation.html
А еще есть pip и git)
А еще есть pip и git)
просто дистрибутивы в том виде в котором большинство это понимает — позапрошлый век. они удобны как построение ядра. остальное в системе надо держать в своём репозитории.
Вы про сервера или про десктоп? Я очень не хочу жить в условиях «сервер CI для приложений со своего десктопа». Даже если этот CI называется «пересобрать мир».
Вообще, построение своего окружения дело полезное, но дорогое. Есть масса случаев, когда удобно «взял и установил», и оно вполне себе работает.
Вообще, построение своего окружения дело полезное, но дорогое. Есть масса случаев, когда удобно «взял и установил», и оно вполне себе работает.
я про всё. и не вижу проблем в сервере CI для приложений со своего десктопа. что в этом такого? ну и дистрибутив для тесктопа я выбираю поновее — последние 4 года это Fedora. А в данный момент это вообще OS X.
p.s. ну и не забываем — большинство ПО самими разработчиками неплохо собирается под нужный дистрибутив. так что не всё ТАК плохо.
p.s. ну и не забываем — большинство ПО самими разработчиками неплохо собирается под нужный дистрибутив. так что не всё ТАК плохо.
Это значительные затраты времени на сопровождение. Поднять CI — одно дело. Более-менее прилично сопровождать — совсем другое. Ну и сколько приложений человек может сопровождать не теряя компетенции? Ну сотню, не больше. Дальше просто «они все одинаковые» (читай, у человека никакой компетенции в том, что делает). А в чём тогда смысл CI'я? Играть в «генту для серьёзных парней, у меня всё моё компилируется на моём CI'е»?
Вопрос «сборки ПО под дистрибутивы самими разработчиками» — это свой, волшебный мир. Я вот сейчас утилиту пытаюсь донести до апстрима дебиана. У нас она давным-давно в нашей репе и юзается, и всё бело и пушисто. Но в процессе общения с ментором от моего пакетирования мокрого места не оставили — уровень ожидаемого качества сопровождения в дистрибутивах значительно выше, чем просто «собралось, и, вроде бы, ставится без ошибок».
Я при этом даже не затрагиваю вопросы стабильности и добросовестности.
Установка софта «от разработчиков» ничем не отличается от виндузятнического «скачал экзешник — запустил». В этом смысле репозитории дистрибутива — совершенно иной уровень доверия.
Вопрос «сборки ПО под дистрибутивы самими разработчиками» — это свой, волшебный мир. Я вот сейчас утилиту пытаюсь донести до апстрима дебиана. У нас она давным-давно в нашей репе и юзается, и всё бело и пушисто. Но в процессе общения с ментором от моего пакетирования мокрого места не оставили — уровень ожидаемого качества сопровождения в дистрибутивах значительно выше, чем просто «собралось, и, вроде бы, ставится без ошибок».
Я при этом даже не затрагиваю вопросы стабильности и добросовестности.
Установка софта «от разработчиков» ничем не отличается от виндузятнического «скачал экзешник — запустил». В этом смысле репозитории дистрибутива — совершенно иной уровень доверия.
я вообще начал с того что дистрибутивы удобны для постоения ядра. и не призываю пересобирать их целиком.
но вот сделать сборку куда включить IDE которая используется в компании. или метапакет для установки типичных компонент десктопа принятых на предприятии — отчего нет?
но вот сделать сборку куда включить IDE которая используется в компании. или метапакет для установки типичных компонент десктопа принятых на предприятии — отчего нет?
А, понял. Вы «ядром» называете всё, кроме нескольких программ. Ну, в этом контексте «да». Только я тогда не понимаю фразы насчёт «просто дистрибутивы в том виде в котором большинство это понимает — позапрошлый век». Ничего друго-то и нету. И те несколько десятых процента, которые «пересобираются» погоды не меняют.
Вообще странно, все говорят что питон быстрый и все такое, но у меня основной рецепт — обновление кеша репозиториев и пакетов, поэтому там время выполнения отследить сложно — запустил и занимаешься другим. А что с файликами шаблонами вообще происходит? это кейс обновления конфигов сервиса?
Там дело не в том, что «питон быстрый», а в том, как быстро эти данные уползают на удалённый сервер.
Эээ, боюсь спрашивать какой объём этих данных.
Десятки килобайт. Ну килобайт триста в сумме вместе с комментами. И проблема там не в «загруженности канала», а в том, как долго начинается обработка каждого файла.
Можете попробовать сами:
template/foo.j2 может в себе содержать 1-2 {{item}}, этого достаточно, чтобы увидеть тормоза.
Можете попробовать сами:
- name: slow down
template: src=foo.j2 dest=/tmp/{{item}}
with_items:
- one
- two
- three
- four
...
- item19
- item20
template/foo.j2 может в себе содержать 1-2 {{item}}, этого достаточно, чтобы увидеть тормоза.
Как минимум надо использовать SSH c ControlMaster и «pipelining = true» в ansible.cfg
Оно по умолчанию перестало использовать control channel?
Также стоит учитывать, что pipelining может не работать при использовании requiretty в sudoers.
Также стоит учитывать, что pipelining может не работать при использовании requiretty в sudoers.
grep pipe /etc/ansible/ansible.cfg # Enabling pipelining reduces the number of SSH operations required to pipelining = True
ControlMaster yes и ControlPersist 600 у всех хостов.
Всё равно медленно.
Смысл первой части — «нет универсального бесплатного продукта под всё, напишем для себя свой»? ) Chef не подошел скудной поддержкой windows, а чем микрософтовский систем центр не подошел, ценой или отсутствием поддержки linux'a?
И тем, и тем :) А еще Facebook использует Chef — значит и мы можем.
На самом деле отличный аргумент, против которого сложно спорить. Facebook'ом ещё обосновывают использование MySQL и PHP. Вот только первый они полностью переписали, а второй масштабно патчат под свои нужды. Полагаю, c Chef они действуют так же
MySQL и PHP они используют именно потому что слишком сильно с ним связаны — перейти на что-то другое им теперь сложно, поэтому они изобретают костыли с MySQL и патчат PHP.
Спасибо вам за пример, это именно то, о чем я хотел предупредить в статье — сначала подумайте, а потом выберите инструмент, возможно проще сразу написать свое.
Спасибо вам за пример, это именно то, о чем я хотел предупредить в статье — сначала подумайте, а потом выберите инструмент, возможно проще сразу написать свое.
facebook винду не использует
Интригующее начало
только уже больше месяця прошло, продолжения не будет?
только уже больше месяця прошло, продолжения не будет?
Виноват, закрутилось с отпуском и личными проблемами…
Вообще говоря, статья с аргументами опоздала года на три. Хоть Chef и Puppet сильно не поменялись, но сейчас вполне обоснованно мне могут возразить что тот же Ansible похож на описываемый мною подход. Да и очень специфические условия все-таки — во многих организациях нет настолько запутанной legacy-архитектуры.
Продолжение практически написано, но опубликую, всеж попозже, когда снова встретится статья про Chef :)
Вообще говоря, статья с аргументами опоздала года на три. Хоть Chef и Puppet сильно не поменялись, но сейчас вполне обоснованно мне могут возразить что тот же Ansible похож на описываемый мною подход. Да и очень специфические условия все-таки — во многих организациях нет настолько запутанной legacy-архитектуры.
Продолжение практически написано, но опубликую, всеж попозже, когда снова встретится статья про Chef :)
Настал ноябрь… =)
Да, спасибо за напоминание. Но чем больше я смотрю на это все и перечитываю написанное — все больше мне кажется, что это просто моя рефлексия на прошлое и все проблемы, которые я хотел описать — могут быть решены (и решаются) сейчас уже другими инструментами… По сути статья сводилась в конце к описанию разработки собственного агента, который управлялся распределенной системой из деплоймент-серверов по комбинированной push-pull схеме. Около половины составляли размышления о прошлом, которые мало кому интересны, а также придуманное описание процесса некоей несуществующей компании, для которой был бы полезен мой подход.
Статья, действительно, опоздала года на три. Плодить ненужный контент для интернета я не хочу — его и так много.
Лучше уж я выберу время и напишу о чем-нибудь более полезном.
Статья, действительно, опоздала года на три. Плодить ненужный контент для интернета я не хочу — его и так много.
Лучше уж я выберу время и напишу о чем-нибудь более полезном.
вторая часть так и не появилась? )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда Chef и Puppet — не решение. Часть 1