Pull to refresh

Когда Chef и Puppet — не решение. Часть 1

Reading time 5 min
Views 26K
image

За последние лет пять я вижу очень много статей по «удачным» рецептам построения систем деплоймента и управления конфигурацией на базе Chef/Puppet/Vagrant/Ansible. Я потратил около 7 лет на решение задач автоматического деплоймента в компании, в которой я в то время работал, и теперь считаю, что имею достаточно опыта, чтобы покритиковать многие распространенные инструменты.

Я не могу раскрыть очень много подробностей в силу NDA и еще не прошедшего срока о неразглашении, хотя мне и очень бы хотелось детально описать мой подход. В этой статье мне бы хотелось обрисовать общий принцип и идеи и получить конструктивную критику в комментариях. Описанные ниже примеры конечно же не относятся ни к какой конкретной компании и имеют своей целью просто привести примеры.

Статья задумывалась довольно конкретной, но внезапно получилась довольно большой, поэтому я решил разбить ее на несколько частей для удобства восприятия, а заодно для того, чтобы получить комментарии к конкретным частям.

Я бы хотел сейчас обратиться к читателям, у которых в продакшене 5-10 серверов и все они ограничиваются моделью «вебсервер — база — пара application серверов». Поскольку тема в этой статье может быть очень холиварной — пожалуйста, учтите мои особенности. Я согласен с тем, что для небольших компаний решение с Chef/Puppet/Vagrant/Ansible/еще-что-то может хорошо работать. Оно может. Я не пытаюсь рассказать насколько плохи эти инструменты вообще. Я пытаюсь предостеречь от чрезмерного увлечения модными решениями и перед внедрением подумать насколько хорошо реально это может помочь и нет ли других вариантов.

Основная моя мысль, которую я собираюсь объяснить далее: для крупной компании наступает тот момент, когда разработка собственного решения для деплоймента получается более выгодной и удобной, чем использование готовых инструментов или даже адаптирование их под свои процессы.

Если ваша компания достаточно крупная, но, тем не менее, не может себе позволить выделить одного-двух, а лучше 5-6 разработчиков на разработку собственного решения этой задачи — лучше возьмите готовое. Либо можете попробовать убедить начальство во вреде (именно вреде!) сторонних решений. Я в свое время был недостаточно убедителен и, на мой взгляд, из-за этого мы потеряли года три.

Я замечаю, что большинство презентаций и видео-лекций по введению в автодеплоймент начинаются с чего-то вроде «давайте посмотрим как просто задеплоить php-файл на локалхост». Внезапно, заканчиваются они именно этим успешно задеплоенным файлом, а в лучшем случае — еще показывается как просто установить apache и mysql на два сервера с назначенными им ролями. На этом впечатленный зритель решает что это действительно просто и давайте все будем использовать этот крутой шмаппет на нашем продакшене прямо сейчас.

Но стоило бы задуматься…

image

К сожалению, что-то похожее произошло и у нас и я не смог воспрепятствовать попытке использовать 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 и, в заключение, мое представление архитектуры идеального сервиса, который может решить большинство проблем для компании.
Tags:
Hubs:
+14
Comments 88
Comments Comments 88

Articles