Patch me if you can: как мы отлаживаемся на production. Часть 2

Спасибо!

Есть такое понятие как common sense. Я полагаю что тестирования на возникновение колллизий не производилось, но выбранной (с запасом) точности хватает для решения поставленной задачи. Риск (вероятность возникновения ошибки, помноженная на стоимость её устранения) присутствует при разработке любого ПО. Как мне кажется, в данном случае риск не стоит того чтобы применять алгоритмы хеширования, отличные от повсеместно распространённых.

Для криптографических хешей любая его часть тоже является криптографической хэш функцией. Тот же crc32, к примеру, не криптографический хэш, и его качество в качестве алгоритма хеширования будет хуже куска md5. Ну а 8 символов было выбрано, чтобы имена файлов были не слишком длинные :). Лучше было сделать побольше, по всей видимости :).

Красиво расписали. А теперь представьте что серверов не 3 и не 5, а несколько тысяч. И что выкладка делается без остановки всего и вся, «наживую». И подумайте еще раз.

По сути, MDK очень похож на git в смысле «git pull и всё». Так что с этой точки зрения — мы ровно так и деплоимся. К сожалению git — инструмент не для деплоя. Он прост и удобен и хорошо работает на малых масштабах, но pull — достаточно прожорливая операция. 100-200 параллельных git pull и сервер задыхается. Да, можно заткнуть эту проблему железом — поставить сервер «пожирнее», потом, когда его не станет хватать — сделать несколько «реплик» git-репозиториев на разных серверах и выкладывать кластерами, каждый из которых будет смотреть в свою реплику. Но этим тоже нужно управлять: следить за тем, что свежая версия выехала на все реплики, что кластер ходит в свою реплику и может сходить в соседнюю при недоступности своей и т.п.

Касаемо поддержки множества версий готовых к быстрому включению в работу: да, можно хранить 28 дополнительных директорий, но если считать, что одна версия весит 1ГБ и код этот лежит на 1000 серверов, получается 28ТБ места. Да, тут тоже можно оптимизировать: можно разворачивать директорию с нужной версией только непосредственно перед использованием, но тогда время переключения версии «везде» будет занимать не 2-3 секунды, а несколько минут. Можно использовать хардлинки или специфические свойства ФС (снепшоты и т.п.), но в этом случае сложность системы всё растет и добавляются всё новые проблемы.

В зависимости от ваших собственных потребностей, как компании, в зависимости от вашего флоу разработки и графика выкладок вы будете отдавать разные приоритеты разным проблемам. Если у вас выкладка всегда на весь продакшн и она происходит раз в неделю — хранение всего 4 версий-директорий закрывает целый месяц жизни компании.

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

MDK в данном случае — это ещё один инструмент со своим набором плюсов и минусов.
Он прост и один решает из коробки комплекс задач: атомарность переключения (symlink current.map), быстрое и почти синхронное переключение версии на большом количестве машин, экономия трафика при выкладке (за счет доставки только недостающих изменений), высокая стойкость к нагрузкам (у нас каждый ДЦ сейчас обслуживается всего одним сервером и он не умирает, когда тысяча машин с производства внезапно хотят сразу все получить свежие данные), отсутствие необходимости держать несколько PHP-FPM во время переключения (и тратить на них драгоценную память), возможность автоматически обнаруживать неконсистентность кода (если кто-то пришёл и руками поправил на машине файлик).

Благодаря его использованию у нас получилась _простая_ система: в ней нет большого количества узлов и механизмов, она даёт нам много свободы, за ней просто следить и её просто эксплуатировать, она хорошо вписалась в нашу инфраструктуру.

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

В целом я немного удивлен, что именно эта часть статьи такая комментируемая, думал что люди чаще будут писать о своем опыте "багфиксинга", это было бы интересно (по крайней мере мне) почитать.

Кажется, разобрался. Не сразу сообразил, что под томами вы имеете ввиду volume, не был знаком с этим термином в русскоязычном варианте.

Не могу сказать, что это выглядит просто, если честно. Иногда кажется, что докер все-таки не так удобен для скриптовых языков программирования — теряется часть их (языков) преимуществ в виде простой замены части файлов с кодом (именно простой, придумать вариант всегда можно). С другой стороны, не человеку из компании, придумавшей целую систему для замены файликов, говорить о простоте :)