За последние лет пять я вижу очень много статей по «удачным» рецептам построения систем деплоймента и управления конфигурацией на базе 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 и, в заключение, мое представление архитектуры идеального сервиса, который может решить большинство проблем для компании.
