За последние лет пять я вижу очень много статей по «удачным» рецептам построения систем деплоймента и управления конфигурацией на базе Chef/Puppet/Vagrant/Ansible. Я потратил около 7 лет на решение задач автоматического деплоймента в компании, в которой я в то время работал, и теперь считаю, что имею достаточно опыта, чтобы покритиковать многие распространенные инструменты.
Я не могу раскрыть очень много подробностей в силу NDA и еще не прошедшего срока о неразглашении, хотя мне и очень бы хотелось детально описать мой подход. В этой статье мне бы хотелось обрисовать общий принцип и идеи и получить конструктивную критику в комментариях. Описанные ниже примеры конечно же не относятся ни к какой конкретной компании и имеют своей целью просто привести примеры.
Статья задумывалась довольно конкретной, но внезапно получилась довольно большой, поэтому я решил разбить ее на несколько частей для удобства восприятия, а заодно для того, чтобы получить комментарии к конкретным частям.
Я бы хотел сейчас обратиться к читателям, у которых в продакшене 5-10 серверов и все они ограничиваются моделью «вебсервер — база — пара application серверов». Поскольку тема в этой статье может быть очень холиварной — пожалуйста, учтите мои особенности. Я согласен с тем, что для небольших компаний решение с Chef/Puppet/Vagrant/Ansible/еще-что-то может хорошо работать. Оно может. Я не пытаюсь рассказать насколько плохи эти инструменты вообще. Я пытаюсь предостеречь от чрезмерного увлечения модными решениями и перед внедрением подумать насколько хорошо реально это может помочь и нет ли других вариантов.
Основная моя мысль, которую я собираюсь объяснить далее: для крупной компании наступает тот момент, когда разработка собственного решения для деплоймента получается более выгодной и удобной, чем использование готовых инструментов или даже адаптирование их под свои процессы.
Если ваша компания достаточно крупная, но, тем не менее, не может себе позволить выделить одного-двух, а лучше 5-6 разработчиков на разработку собственного решения этой задачи — лучше возьмите готовое. Либо можете попробовать убедить начальство во вреде (именно вреде!) сторонних решений. Я в свое время был недостаточно убедителен и, на мой взгляд, из-за этого мы потеряли года три.
Я замечаю, что большинство презентаций и видео-лекций по введению в автодеплоймент начинаются с чего-то вроде «давайте посмотрим как просто задеплоить php-файл на локалхост». Внезапно, заканчиваются они именно этим успешно задеплоенным файлом, а в лучшем случае — еще показывается как просто установить apache и mysql на два сервера с назначенными им ролями. На этом впечатленный зритель решает что это действительно просто и давайте все будем использовать этот крутой шмаппет на нашем продакшене прямо сейчас.
Но стоило бы задуматься…
К сожалению, что-то похожее произошло и у нас и я не смог воспрепятствовать попытке использовать Chef, хотя со стороны нас, здравомыслящих людей было очень много опасных вопросов к инициаторам внедрения. Вовремя подключившись к задаче, я смог немного сгладить негативный эффект и в дальнейшем избавиться от Chef. Правда, к тому времени не уследил и к нам пробрался Puppet.
Environment. «Краткое» вступление.
Давайте представим себе некую компанию, предоставляющую SaaS услуги. Компания на рынке лет 5-10 и у нее уже есть неплохо работающий и продающийся сервис со счастливыми пользователями. В какой-то момент их счастье переливается через край и привлекает гораздо больше пользователей и партнеров. То есть компания начинает стремительно расти.
Допустим, раньше было 20 серверов в продакшене и они работали, и правка 5 конфигов на 6 серверах считалась довольно обычным делом, как и outage на 3-4 часа по выходным для обновления серверов. Сервера разные — около 80% это Windows Server с ASP через IIS5 или самописными сервисами — мы же не просто хостим сайт, у нас телефония, сообщения, может быть поддержка факсов или всякие решения для интеграции со скайпом и другими сервисами. Не забываем про биллинг. Все, конечно же, завязано на базу данных. Она, вроде, справляется пока. Девелоперы кодят на своих машинках, у QA есть два старых десктопа в углу, на них по очереди тестируются все сервисы. Все спокойно, 2 крупных релиза в год, багфиксы и мелкие фичи иногда. Девелоперы не гнушаются для проверки пары идей зайти по RDP/SSH на один из продакшен-серверов и подхачить пару файликов, чтоб собрать логи или удаленный дебаггер поставить. Обычное дело. Все знают всю структуру сервисов и их связи.
Серверов немного и почему бы не прописать в конфиге своего сервера адрес биллинг-сервера? Все равно он один и не менялся давно. Не просить же этого хмурого парня, который отвечает за базу, чтобы он добавил табличку с параметрами — опять раскричится что всякий мусор храним в его драгоценной базе и меняем схему все время. Добавим, а потом уберем после рефакторинга. В биллинг сервере добавим адрес внешнего payment gateway тоже в конфиг — он-то уж точно всегда один и тот же, но хардкодить плохо, а в базу пихать константы нам опять не дадут.
Внезапно для роста необходимо довести количество серверов до 100 на продакшене, поскольку после удачной рекламной кампании количество пользователей стало неплохо расти. Приехал CEO, показал красивую презентацию, намекнул что это только начало. Рассказал что у нас два новых партнера, крупнейшие в своей отрасли и нам надо не ударить в грязь лицом и вообще он уже сказал что мы умеем вот эту и эту фичу. Через месяц демо, но мы же сможем эти фичи сделать с нуля, правда?
Надо — значит надо, перспективы хорошие. Премии обещают хорошие. Раз-два — и фичи быстро делаются. Появляются два новых сервиса, чтоб не переписывать старые — потом объединим, если будет нужно. Эти сервисы, к сожалению, очень сильно связаны со всеми остальными — им надо и биллинг, и телефонию, и веб. Но тут уже возобладал здравый смысл и решили адреса всех серверов хранить в базе — а то уже много стало их. Теперь все сервисы при старте из базы берут список серверов и с ним работают потом. Удобно. У старых компонент, правда, еще в конфигах осталось что-то, но это потом вычистим.
Приезжали CEO и CTO с кучей других менеджеров, очень довольны. Партнеры оценили демо, дали денег. Много. Вот вам пачка, купите серверов сколько надо и что там говорили про рефакторинг? Так и быть, фигачим. Java сейчас в моде? Все принято на Java писать в успешных конторах? Так и мы теперь успешная — давайте сделаем Java! И сразу все сделаем правильно, разделим на несколько сервисов, которые будут через API общаться.
[пропускаем первые полтора года на рефакторинг и его рефакторинг].
Теперь у нас 200 серверов на продакшене и тестовых серверов около 50. Количество различных внутренних компонент — около 20. Многие похожи, но делают разные вещи. Все самописные.
Все 10 системных администраторов горят работой, очень хорошие парни. Релизы каждые 2-3 месяца, планов дофига. Деньги есть. Пользователи идут. Разработчиков и тестировщиков набирают потоком, PM не вылезает с собеседований.
Но есть и проблемы.
Продолжение следует…
Здесь самое хорошее место для того, чтобы перевести дух и в комментариях устроить обсуждение. Я думаю многие узнали что-то из своих компаний.
В следующих частях я опишу первые попытки автоматизации, появление Chef и, в заключение, мое представление архитектуры идеального сервиса, который может решить большинство проблем для компании.
Комментарии (81)
allburov
27.07.2015 11:01+11Я думаю не стоило разделять, вываливайте на наши головы все сразу!
Очень хочется услышать реализацию, сам проходил по подобному пути от «все делается руками и занимает полчаса» до «Как, на 50 серверах поменять конфиг до вчера?»
Envek
27.07.2015 11:11+7Для затравки даже слишком мало. Пишите продолжение.
Мы сейчас используем связку Puppet и Capistrano. Puppet «готовит» площадки (их несколько, у каждого заказчика своя) и ставит и настраивает вспомогательные сервисы. Capistrano деплоит основное приложение. Первое же ограничение: на puppet-мастере может быть только 1 модуль одной версии. А приложения у разных заказчиков имеют особенность расходиться в версиях (в виду организационных, финансовых и прочих причин). Пока что это доставляет только теоретическое неудобство, но я уже понимаю, что надо мигрировать с Puppet'а куда-нибудь ещё, пока смотрю в сторону Ansible. Ну а что делать с несвязанностью Capistrano и инструмента подготовки площадок (два разных конфига, которые должны быть синхронны) — я ещё и не знаю.
baldr Автор
27.07.2015 11:21+2Да, вот именно множество версий — одна из основных проблем, которую с помощью Chef решить не так просто.
По поводу продолжения — вас понял. Сейчас дописываю третью часть, но, наверное, объединю вторую и третью, а потом постараюсь урезать бьющий поток мыслей и все уместить в последнюю часть.
flashvoid
28.07.2015 04:21А в чем проблема хранить несколько версий одной кукбуки на chef сервере?
Задавать через chef_environment, который править через berkshelf.
mobilesfinks
27.07.2015 15:03А использовать enviroment не пробовали?
В каждое окружение можно запихнуть свою версию модуля. Модули которые доступны для всех окружений лежат в /etc/puppet/modulesEnvek
27.07.2015 15:12Сейчас у нас environment'ы — это переменные, задающиеся для нод в site.pp, по этим environment'ам из Hiera подтягиваются площадко-специфичные настройки, но версия модуля одна. Про то, что каждому environment'у можно иметь свою версию модуля, я не знал.
baldr Автор
27.07.2015 15:13То есть постоянно перебрасывать сервер между environment'ами? Да, выход, для небольшого количества серверов.
Но не очень красиво, особенно если environment'ы уже используются по прямому назначению.
Могут возникнуть вопросы — а что делать если на один сервер нужно поставить два сервиса разных версий (в вашем случае environment'ов)?mobilesfinks
27.07.2015 15:31Это вам тогда нужно модуль перепиливать, что бы можно было ставить два сервиса разных версий. Я вот так вижу.
baldr Автор
27.07.2015 15:40Да, скорее всего.
В итоге все меньше преимуществ «из коробки» и все больше самописных костылей.
Кстати, хотелось бы узнать, как обычно у коллег решаются такие вопросы:
* есть вы, кто пытается автоматизировать хаос в деплойменте
* есть программист, который пишет сервис A на Erlang
* есть программист, который пишет сервис B на NodeJS
* есть программист (который работает тут уже 15 лет) на языке C, пишущий сервис C. Он звезда и может сказать вам где этот ваш руби он крутил вместе с вами.
Ну, допустим, есть еще десяток разных сервисов — от MSSQL до Java…
Кто должен описывать скрипты для установки этих сервисов?
foxmuldercp
27.07.2015 23:23DevOps/Release/CI инженер, он же — «Вы» из Вашего списка.
Я эти понятия не очень разделяю, возможно я в чём-то не прав, но общая суть — инженер деплоймента — он же админ продакшена, куда никто кроме системы интеграции и деплоймента не лезет.
flashvoid
28.07.2015 04:27+1В идеале разработчик с огладкой на админа, в реальности админ с оглядкой на разработчика.
snp
27.07.2015 17:46А вы не пробовали вместо Capistrano перейти на сборку пакетов (deb/rpm и т.п.)? Как раз и с версиями, может быть, ситуация упростится. И в puppet вы просто будете ставить native пакет.
Envek
27.07.2015 22:24Не пробовали, ибо не знаем, как оное делать — хороших туториалов случайно не попадалось, специально сами не гуглили. Я, правда, не представляю, как пакет будет накатывать миграции. И как откатываться в случае чего взад.
snp
27.07.2015 23:05Миграции можно завязать с pre-install/post-install скриптами.
Откатываться… Ну, по идее это решение для продакшна, когда всё протестировано на стейдже, то и откатываться не надо :) По крайней мере, в автоматическом режиме.
Вместо ansible возможно вам стоит попробовать chef (пусть даже в бессерверном варианте). На мой взгляд, там можно всякие странные и извращённые вещи достаточно просто сделать.
essential55
27.07.2015 12:00+2Давайте по делу? Мы же все-таки тут не художественную литературу читаем.
С версиями модулей проблема есть, но это не мешает вам написать модуль, который умеет устанавливать разные версии приложений. Я сталкивался с проблемой версии модулей, когда начинаешь устанавливать кучу готовых модулей из forge и у каждого свои зависимости, но у нас стояла задача установки «попсовых» приложений. Ресурсов и времени для написания своих модулей было мало, поэтому использовали, то что было в паблике.baldr Автор
27.07.2015 12:25Да, поначалу пришлось строить лес с помощью костылей поверх Chef. Но в определенный момент понимаешь что количество своих костылей больше количества полезных фич, которые предлагает тот или иной инструмент.
Проблемы могут приходить и изнутри — версии двух пакетов внезапно могут быть одинаковыми, но разрабатываться в разных бранчах.
А сколько, как вы думаете, может продолжаться разговор о том что нам нужен внутренний репозиторий для каждого окружения?mobilesfinks
27.07.2015 15:42А сколько, как вы думаете, может продолжаться разговор о том что нам нужен внутренний репозиторий для каждого окружения?
У нас уже год вокруг этого крутится, и всё не получается решить вопрос — когда этим заниматься ))
Так что да — продолжительное решение вопросов с активно используемой инфраструктурой.
easy_john
27.07.2015 13:59Автор работает в одной компании со мной? ;)
Как я понимаю сейчас транспорт доставки билдов и подготовки серверов у нас puppet, на него навернуты несколько слоев выше, которые обеспечивают более высокоуровневую коммуникацию.baldr Автор
27.07.2015 14:06Я уверен, что будет много людей, узнающих что-то из своего процесса, поскольку, как мне кажется, проблемы в больших компаниях одни и те же :)
Собственно, статья и писалась для того, чтобы описать одни грабли и показать с какой стороны на них можно наступать и сколько раз.easy_john
27.07.2015 14:22Слишком много совпадений, думаю компания все же одна.
Наступать можно бесконечно, это проверено. Некоторые даже наступают специально, что бы была видимость процесса.
Я бы сказал, что нет смысла писать свою систему автоматизации доставки билдов и управления конфигурации с нуля.
Например можно взять два-три хороших продукта разного уровня и состыковать их небольшим количеством кода под свои задачи.baldr Автор
27.07.2015 14:35+1Подходящих продуктов может и не быть, процесс компании может не захотеть меняться, а «небольшое количество кода» всегда вырастает в «большое количество кода» и в итоге мы получаем все-таки написанное свое, но с большим количеством костылей вокруг части, которую мы поменять не можем.
Например, для Windows не было и до сих пор не так уж много инструментов для глубокой настройки системы. Несколько лет назад в стандартной поставке появился PowerShell и начали появляться какие-то сниппеты, которые могут облегчить настройку. Но 5 лет назад их не было.
В Chef еще два года назад невозможно было под Windows подмонтировать сетевой ресурс с доменным юзером, например, или без буквы диска. Можно было вызвать «net use» и ловить вывод, да. Но это несерьезно.
Powershell или bash, или Ruby, или C++ для желающих — все части нужно между собой состыковывать. Bash-скрипт, запускающий python-процесс, запускающий ruby-скрипт, который запускает ruby-скрипт, который запускает bash-скрипты, которые вызывают cmd-файл под windows — через это мы проходили. Цепочка была чуть длиннее, а для linux чуть короче, но как программист, я испытываю содрогание от таких вещей, а как системный администратор — начинаю подсчитывать количество пакетов, которые нужно иметь установленными.easy_john
28.07.2015 12:55Мы вас вычислили по фейсбуку ;) Какое-то время мы работали в одной компании.
Может и не быть, но адаптация существующего продукта выглядит более перспективной с точки зрения развития и поддержки, чем целиком самописный код.
Например поверх той тулзы в разработке которой ты участвовал мы сейчас прикручиваем vRealize от вмвари, и оно, похоже, вполне получается жизнеспособно.
phoenixweiss
27.07.2015 15:51+3В статье вообще очень поверхностно это описано, мол «вот мог бы рассказать — рассказал бы, а так просто посокрушаюсь». Ни конкретных проблем ни конкретных решений. Очень бы хотелось услышать конкретику и посмотреть реальные примеры.
Когда серверов меньше десяти, по сути Chef и его аналоги даже и не нужны. Но опять же, смотря в чем конкретно состоит задача.
Вот у мня была задача периодического поднятия площадок под Rails на паре-тройке серверов в полгода. Крутил шефа, паппета, ансиблю — слишком громоздко для моих задач (хотя шеф удобнее всего). Знакомые разработчики посоветовали скрипт «babushka» с github, но он меня не сильно вдохновил. Тем более задача была даже проще. В итоге убил пару выходных, и написал свой маленький велосипед «just for fun» под названием SSKit, исходники на github. Подтянул баш и решил проблему. Код пока корявенький, но есть много TODO которые как будет время буду доделывать.baldr Автор
27.07.2015 16:39+3Коллеги, пожалуйста, подождите торопить. Я планировал выкладывать понемногу, но меня уже попросили бахнуть все сразу.
Я сейчас дописываю все идеи и в течение дня-двух выложу остальное.
Мысли копились на протяжение нескольких лет, я не профессиональный писатель и все идет довольно сумбурно, так что, пожалуйста, подождите критиковать.
Если тема интересна, мне кажется, вы вполне пока можете обсудить уже существующие вопросы, я постараюсь учесть замечания по ходу написания.
amarao
28.07.2015 02:45+4У систем управления конфигурацией есть два дополнительных важных свойства:
1) Они заменяют собой бэкап для всего, кроме данных. То есть никаких больше «бэкапов серверов». Если сервер упал, проще накатить заново, а не разворачивать бэкап. Данные при этом в дистиллированном виде отдельно бэкапятся.
2) Они позволяют за короткое время получить тестовую среду, если вдруг приспичило (а вообще говоря, и положено).
Так что даже в контексте одного сервера оно может быть полезным. Хотя порог вхождения в эти штуки очень высокий, да.
amarao
27.07.2015 18:05+9Синдром «разумеется, наш дизайн окажется лучше и покроет все случаи, с которыми мы столкнёмся лучше, чем у готового решения». Чем лучше? Тем, что написан у нас.
Глупость чистой воды. Многие кукбуки шефа требуют тысяч человеко-часов на написание и сопровождение (тесты, да?), а делая «своё», очевидно, придётся и писать очередные рецепты/пьесы/соннеты самому.
Ин-хаус решения очень часто страдают срезанием углов (так удобнее для нашей архитектуры), что потом больно кусает в неожиданные моменты в будущем.
А главный вопрос: что будет делать компания, когда уволится Главный Архитектор Собственной Системы Деплоя?porzione
27.07.2015 20:08Вот это хорошо сказано. Приходилось даже как-то болезненно менять всю схему деплоя, чтобы упростить работу с готовыми кукбуками шефа и минимизировать использование своих костылей. По правде говоря, болезненно это было только для нескольких девелоперов, которые накатали кучу странных скриптов и понимали, как это работает, только они сами. Главный их аргумент был знаменитое «не надо чинить то, что не сломано». Но работало это все только в комплекте с авторами этих скриптов. А речи том, чтобы тестировать систему деплоя, тогда вообще не было.
baldr Автор
27.07.2015 22:18Нам в любом случае пришлось писать рецепты под нас. Готовых мы не нашли.
Универсальность нужна для продажи продукта, а для внутренних целей продукт, заточенный под себя гораздо удобнее.
А что касается «главного вопроса» — я уволился год назад. Система работает и развивается.
Проблема аналогична любой такой же из разработки ПО — качество кода и документации должно позволять другим разработчикам понять как оно работает. Не все идеально, но не все и плохо.amarao
27.07.2015 23:08+3Понимаете, «заточенный под себя» означает, что у вас заточенные под себя бизнес-процессы, которые никогда не будут меняться. Каждый раз, когда кто-то срезает угол в архитектуре, бог заставляет котёнка рефакторить код на перле в виде одной функции на 800 строк. Если же условия меняются, появляются новые проекты, меняется структура отделов или особенности бизнеса, то время, за которое «существующий код» будет адаптирован под новую конфигурацию определяется аккуратностью её деления и соблюдения абстракций (утрируя до невозможности, чтобы в главном приложении не было хардкоженного IP сервера базы данных).
Насчёт того, что ни одного рецепта готового у вас не нашлось — просто не верю. Ни пользователей заводить, ни группы, ни устанавливать пакеты, ни конфигурировать всякие веб-сервера — не, ни разу? Или оно пролетело быстро, а вот львиную долю времени ушло на свои рецепты? Если честно, а?
ЗЫ Кривите душой: у вас «своя система», и «готовых рецептов не нашли». Под свою самописную систему не нашли?baldr Автор
27.07.2015 23:36Очень много кастомного в сервисе, правда.
Про windows — не было практически ничего для Chef. Абсолютно ничего. Пользователи-группы — не было нужно, а вот поставить галочку в IIS даже руками не сразу найдешь в настройках — видимо.никому не было нужно.
Под Linux — создать пользователя-группу не так сложно даже на bash. Но вы абсолютно правы про срезанные углы — некоторые вещи иногда аукались. Веб-сервера — там больше проблем с настройками, сами пакеты через rpm ставятся довольно просто. А вот настройки в конфигах тоже очень хитровымученные. Девелоперы у нас тоже талантливые были…amarao
28.07.2015 00:05+3А, извините. Волшебный мир windows — кто ж вас тянул-то? В условиях «нам надо удобно под windows» я просто руками развожу. Был на недавнем совещании о том, как собирать image'ы с виндами — ау… страх и ужас.
aim
30.07.2015 15:06под windows ничего не было, нет и в ближайшее время пока за это MS не возьмётся — не будет. вся это кнопочно-давительная система только-только разворачивается лицом к администратору-девелоперу. лет пять ещё будет.
ildarz
28.07.2015 15:24Это с одной стороны. А с другой — afaik, тот же Chef как раз из такой системы «для внутреннего употребления» и вырос. Рассуждай его автор так же, было бы одной популярной системой управления меньше. :)
amarao
28.07.2015 17:16Есть большая разница, когда люди пишут инструмент, потому что его нет, и когда люди пишут инструмент, потому что существующие решения «слишком сложные».
В принципе, да, эволюционно новые системы появляются, когда старые перестают справляться. Но мотивация должна быть очень сильная и обоснованная, то есть претензия должна быть не вида «мы напишем лучше», а указание на архитектурные проблемы, которые каким-то образом создают затруднения.
Ingtar
27.07.2015 19:34Читал и прямо себя видел в недалеком прошлом :))
Мы используем Ansible, разработчикам он очень понравился, и для администрирования понятен.amarao
27.07.2015 23:08мимо коммент улетел. habrahabr.ru/post/263595/?reply_to=8516453#comment_8516393
Ingtar
28.07.2015 16:52я прям так вот не измерял, но субьективно дискомфорта не ощущаю.
Плейбук из 70 шагов выполнится ну минуты за 2 для хоста.
Для бОльшего кол-ва хостов выезжаем за счет форков.
А сам коннект у вас по ssh долгий? Может быть дело в этом?amarao
28.07.2015 17:25Ну вот у меня нет ощущения, что 70 шагов за 2 минуты, это нормально. Рядом сидит команда шефоводов, и у них гигантская штука, держащая на себе необъятную мозгом инсталляцию с почти 250к строк в репе с шефом (из них 180к строк — кукбуки), выполняется (в холостом режиме, когда всё уже сконфигурировано и надо только проверить, что не поменялось) секунд за 20-30.
Оно меня настолько впечатлило, что я даже подумываю, что надо-таки сесть и выучить шеф, чтобы самому сравнить с ансиблом.Ingtar
28.07.2015 18:33Я честно не знаю, как там работает Шэф.
Для меня такая скорость (теоретическая. я могу ошибиться, но не сильно :)) приемлима. Попробуйте увеличить кол-во форков
Вообще ансиб штука последовательная. Пока она не выполнит шаг на всех нодах — дальше не пойдет. Возможно этим выезжают Паппеты и Шэфыamarao
28.07.2015 19:22Я про время исполнения на конкретном сервере. Лично для меня время «запустил посмотреть как оно будет» и «отреагировал на опечатку в шаблоне» получается некомфортно большим. Условно, я успеваю заглянуть на 2-3 сайта за это время и написать вам комментарий. Что с одной стороны хорошо для безделия (
xkcd://компилируется), а с другой, если интересует результат работы, начинает мешать.
Envek
28.07.2015 19:23И этим же этот же Puppet не нравится. Когда машинам нужны знания о других машинах, то нужно несколько прогонов Puppet'а на каждой из машин, чтобы полностью «собрать» конфигурацию. Пока Puppet не поставит машину с СУБД, машина с приложением не узнает адрес машины с БД, пока не будет готова машина с приложением, то в СУБД не вставится правило, разрешающее подключаться к базе приложению, и в балансировщик машина с приложением тоже не «пропишется» и так далее. Получается какая-то «eventually configured» парадигма.
amarao
27.07.2015 21:05Как вы его производительность ощущаете? Меня оно уже бесит, потому что template для двух десятков файлов — это целое Сложное Дело, которое долго выполняется.
foxmuldercp
27.07.2015 23:29Вы про Ansible?
темплейт для 20 файлов… ээ… Что-то в консерватории не так.
Можно подробнее, про задачу то, попробую подуматьamarao
28.07.2015 00:04Обычная конфигурация, десяток приложений, у каждой в среднем 20 файлов. В сумме большую часть времени процесс тупит на обработке этих шаблонов. И это в режиме «без изменений», то есть прогон на всякий случай. Я посмотрел-посмотрел и испытываю некоторое разочарование, потому что шеф за это время успевает прошерстить кратно большее число рецептов.
Vayun
28.07.2015 00:21Какая версия?
amarao
28.07.2015 00:431.7.2
Vayun
28.07.2015 11:39Стоит проверить на текущей стабильной 1.9.х
amarao
28.07.2015 15:14И тут начинается очередная проблема с системами управления конфигурациями: они крайне медленно обновляются в репозиториях.
Vayun
28.07.2015 18:06Вообще-то для всех основных дистрибутивов есть репозитории с последней стабильной версией docs.ansible.com/ansible/intro_installation.html
А еще есть pip и git)amarao
28.07.2015 19:13+1Да, и мы мгновенно скатываемся в curl|bash деплой. Вместо стабильного и проверенного временем решения, имеем хипстоту и докеризм в продашкене.
aim
30.07.2015 15:09просто дистрибутивы в том виде в котором большинство это понимает — позапрошлый век. они удобны как построение ядра. остальное в системе надо держать в своём репозитории.
amarao
30.07.2015 16:39Вы про сервера или про десктоп? Я очень не хочу жить в условиях «сервер CI для приложений со своего десктопа». Даже если этот CI называется «пересобрать мир».
Вообще, построение своего окружения дело полезное, но дорогое. Есть масса случаев, когда удобно «взял и установил», и оно вполне себе работает.aim
30.07.2015 17:06я про всё. и не вижу проблем в сервере CI для приложений со своего десктопа. что в этом такого? ну и дистрибутив для тесктопа я выбираю поновее — последние 4 года это Fedora. А в данный момент это вообще OS X.
p.s. ну и не забываем — большинство ПО самими разработчиками неплохо собирается под нужный дистрибутив. так что не всё ТАК плохо.amarao
30.07.2015 17:14+2Это значительные затраты времени на сопровождение. Поднять CI — одно дело. Более-менее прилично сопровождать — совсем другое. Ну и сколько приложений человек может сопровождать не теряя компетенции? Ну сотню, не больше. Дальше просто «они все одинаковые» (читай, у человека никакой компетенции в том, что делает). А в чём тогда смысл CI'я? Играть в «генту для серьёзных парней, у меня всё моё компилируется на моём CI'е»?
Вопрос «сборки ПО под дистрибутивы самими разработчиками» — это свой, волшебный мир. Я вот сейчас утилиту пытаюсь донести до апстрима дебиана. У нас она давным-давно в нашей репе и юзается, и всё бело и пушисто. Но в процессе общения с ментором от моего пакетирования мокрого места не оставили — уровень ожидаемого качества сопровождения в дистрибутивах значительно выше, чем просто «собралось, и, вроде бы, ставится без ошибок».
Я при этом даже не затрагиваю вопросы стабильности и добросовестности.
Установка софта «от разработчиков» ничем не отличается от виндузятнического «скачал экзешник — запустил». В этом смысле репозитории дистрибутива — совершенно иной уровень доверия.aim
30.07.2015 17:19я вообще начал с того что дистрибутивы удобны для постоения ядра. и не призываю пересобирать их целиком.
но вот сделать сборку куда включить IDE которая используется в компании. или метапакет для установки типичных компонент десктопа принятых на предприятии — отчего нет?amarao
30.07.2015 17:35А, понял. Вы «ядром» называете всё, кроме нескольких программ. Ну, в этом контексте «да». Только я тогда не понимаю фразы насчёт «просто дистрибутивы в том виде в котором большинство это понимает — позапрошлый век». Ничего друго-то и нету. И те несколько десятых процента, которые «пересобираются» погоды не меняют.
foxmuldercp
28.07.2015 10:19Вообще странно, все говорят что питон быстрый и все такое, но у меня основной рецепт — обновление кеша репозиториев и пакетов, поэтому там время выполнения отследить сложно — запустил и занимаешься другим. А что с файликами шаблонами вообще происходит? это кейс обновления конфигов сервиса?
amarao
28.07.2015 15:15Там дело не в том, что «питон быстрый», а в том, как быстро эти данные уползают на удалённый сервер.
foxmuldercp
28.07.2015 16:21Эээ, боюсь спрашивать какой объём этих данных.
amarao
28.07.2015 17:19Десятки килобайт. Ну килобайт триста в сумме вместе с комментами. И проблема там не в «загруженности канала», а в том, как долго начинается обработка каждого файла.
Можете попробовать сами:
- name: slow down template: src=foo.j2 dest=/tmp/{{item}} with_items: - one - two - three - four ... - item19 - item20
template/foo.j2 может в себе содержать 1-2 {{item}}, этого достаточно, чтобы увидеть тормоза.Vayun
28.07.2015 18:09Как минимум надо использовать SSH c ControlMaster и «pipelining = true» в ansible.cfg
grossws
28.07.2015 18:16Оно по умолчанию перестало использовать control channel?
Также стоит учитывать, что pipelining может не работать при использовании requiretty в sudoers.Vayun
28.07.2015 18:18оно не будет его использовать там где его нет, например в RHEL
grossws
28.07.2015 18:24Это ж client-side feature, так что вопрос пакетирования в том дистрибутиве, с которого используется ansible. Мне centos6 ничуть не мешал использовать ControlMaster/ControlPath с рабочей станции для управления конфигурацией серверов под centos.
amarao
28.07.2015 19:16grep pipe /etc/ansible/ansible.cfg # Enabling pipelining reduces the number of SSH operations required to pipelining = True
ControlMaster yes и ControlPersist 600 у всех хостов.
Всё равно медленно.
Askon
27.07.2015 23:45Смысл первой части — «нет универсального бесплатного продукта под всё, напишем для себя свой»? ) Chef не подошел скудной поддержкой windows, а чем микрософтовский систем центр не подошел, ценой или отсутствием поддержки linux'a?
baldr Автор
28.07.2015 02:57И тем, и тем :) А еще Facebook использует Chef — значит и мы можем.
antarx
28.07.2015 18:07На самом деле отличный аргумент, против которого сложно спорить. Facebook'ом ещё обосновывают использование MySQL и PHP. Вот только первый они полностью переписали, а второй масштабно патчат под свои нужды. Полагаю, c Chef они действуют так же
baldr Автор
28.07.2015 22:51MySQL и PHP они используют именно потому что слишком сильно с ним связаны — перейти на что-то другое им теперь сложно, поэтому они изобретают костыли с MySQL и патчат PHP.
Спасибо вам за пример, это именно то, о чем я хотел предупредить в статье — сначала подумайте, а потом выберите инструмент, возможно проще сразу написать свое.
tangro
Хорошо бы описать задачу, с которой Chef или Puppet не справились бы и плясать от этого.
baldr Автор
Конечно, я и пытаюсь вначале обрисовать окружение, которое в дальнейшем будет подвергаться автоматизации.