Деплоить что это значит
Что такое деплой в программировании
Deploy (деплой) — что это такое? Дословный перевод слова деплой на русский язык означает «развертывать». Давайте разберемся что именно мы развертываем и каким образом.
После того как программный код сайта написан, возникает вопрос: что-же необходимо сделать, чтобы он появился в интернете? Как правило, классический путь состоит из 3-х шагов:
Простыми словами, деплой — это процедура переноса вашего сайта на сервер. Данная операция может быть очень затруднительной и напрямую зависит от применяемых инструментов. Когда программисты начинают реализовывать deploy, они выполняют следующие действия:
Мы привели в пример один из возможных и очевидных вариантов для понимания, на самом деле их бесчисленное множество.
Хочется отметить, что многие web-студии до сих пор реализовывают данный процесс вручную. То есть программист заходит на сервер и включает git pull. После чего реализовывает вышеуказанные пункты. Данный подход к деплоингу — неправильный. Web-deploy подразумевает под собой полную автоматизацию всех задач, которые необходимо выполнить.
По большому счету, на сегодняшний день все работы, связанные с настройкой и обслуживанием серверов должны быть максимально автоматизированы и отточены.
Однако невзирая на множество различных вариантов деплоя проектов, существует одно неотъемлемое правило для каждого — запрещено делать откаты. Другими словами, если в процессе выполнения deploy вы допустили ошибку и все пошло не по плану, то следует «деплоить» по новой версию, которая была ранее.
Помимо этого, deploy можно подразделять на категории откатов и обновлений:
Так же следует отметить такой способ, как канареечный релиз (canary release). Применяя такую методологию переход на обновленную версию происходит поэтапно — первоначально для малого количества пользователей, а потом для всех остальных.
Выбираемый вариант деплоинга напрямую зависит от применяемого хоста, а также метода настройки сервера. Вот перечень основных хостингов:
По большому счету все варианты web-деплоя разделены на 2 составляющих: на PaaS и все прочее.
Теперь вы знаете, что такое деплой для сайта или приложения. Также следует отметить, что существует такое понятие, как Deployer для PHP. Данная опция позволяет загрузить на сервер определенную ветку системы контроля версий. Более того, ему можно написать задачи наподобие выполнения миграции после выкачивания ветки на рабочий сервер.
Надеемся данный материал был для вас полезен. В случае, если вы не смогли найти ответа на ваш вопрос или в чем-то не до конца разобрались — пишите нам в комментарии, и мы обязательно ответим.
Что такое деплой?
Деплой — процесс «разворачивания» веб-сервиса, например, сайта, в рабочем окружении. Рабочее окружение — место, где сайт запускается и доступен для запросов. Это может быть как готовый хостинг, так и своя собственная серверная инфраструктура.
Деплоятся не только веб-сервисы, но любые сервисы, доступные по сети. Даже если эта сеть внутренняя и не доступна для запросов через интернет.
Как это происходит. Разработчики добавляют код в репозиторий. В какой-то момент они решают, что пора доставить его до продакшена. Это может происходить как по регулярному расписанию, например раз в две недели, так и просто по необходимости, вплоть до выкатки после каждого изменения. Во многом количество деплоев зависит от уровня его автоматизации — того, насколько процесс легкий в проведении и откате в случае проблем. На Хекслете деплои выполняются практически после каждого изменения, около 3 деплоев в день.
Каждый раз, когда разработчики решили что все, пора, они создают релиз. Под релизом обычно понимают тег в Git, который фиксирует, что уйдет в деплой. То есть изменения, добавленные в мастер после создания тега, не повлияют на сам тег, а значит мы точно уверены в том, что деплоим.
Для статических сайтов или отдельного фронтенда (только HTML, CSS и статические файлы) деплой сводится к обновлению кода на сервере. В ситуации деплоя бэкенда, как минимум, подключается база данных. В общем случае деплой может быть сложной процедурой, занимающей приличное время. В распределенных системах, состоящих из множества независимых веб-сервисов, вообще не бывает общего деплоя — каждая часть приложения деплоится (выкатывается) независимо.
Стоит сказать, что PaaS-платформы, такие как Heroku, берут деплой полностью на себя. Там достаточно выполнить коммит, и дальше все произойдет само. Цена за это — стоимость самой платформы
Шаги деплоя
Доставка кода на сервер
Возможны разные варианты доставки кода на сервер в зависимости от способа его упаковки. Иногда код просто копируют на сервер как набор файлов, но такое встречается редко, чаще он обновляется через Git. Раньше был популярен способ деплоя через стандартные пакетные менеджеры Linux-дистрибутивов. Сейчас он тоже встречается, и для определенных ситуаций подходит лучше всего.
Обновление базы данных
Новая версия приложения, как правило, требует изменений в базе данных. Для этого во время (или до) деплоя запускают миграции — специальные скрипты, содержащие правила обновления базы данных. Например sql-скрипты:
Запуск и остановка
Где-то в этом процессе происходит остановка старой версии и запуск новой. Если сначала остановить старую версию, а потом выполнить миграции и запустить новую, то мы получим простой (downtime) в работе сервиса. Так действительно работают многие, но это может быть болезненно для бизнеса и частых деплоев. Поэтому самые продвинутые проекты не останавливаются во время деплоя. О том, как это делать — ниже.
Автоматизация
Деплой нужно максимально автоматизировать, от этого зависит Time To Market, ключевая характеристика бизнес-ориентированных приложений. Чем быстрее и чаще мы доставляем изменения пользователю, тем лучше. Быстрее проверяем гипотезы, быстрее вносим исправления, быстрее оправдываем деньги, вложенные в разработку. Без автоматизации разработчики боятся выполнять деплой, он становится обузой, что приводит к снижению числа деплоев и регулярному стрессу для всей команды, с засиживанием на работе до позднего вечера.
Основных способа автоматизации три:
Но даже если автоматизация выполнена, все равно остается задача «запустить деплой». Запуск тоже автоматизируется. Существует целый подход, который называется Непрерывная доставка(continuous delivery). Его сложно внедрить и он не везде подходит, но если получилось, то про деплой забывают. Он выполняется полностью сам без участия людей. Главное в таком варианте — хороший мониторинг и система оповещения (алертинг) для реакции на ошибки.
Zero Downtime Deployment
Если не предпринимать специальных шагов, то каждый деплой будет приводить к остановке (возможно частичной) сервиса. В это время пользователи либо увидят ошибку, либо сообщение о происходящем обновлении. Но такого не происходит на большинстве крупных сервисов в интернете. Почему? Из-за реализации подхода «деплой без даунтайма» (downtime — простои в работе сервиса).
Zero Downtime Deployment выглядит так, как будто сервис никогда не останавливается, но при этом обновляется. Достигается это за счет одновременного запуска старой версии и новой кода. То есть когда деплоится приложение, то сначала поднимается новая версия рядом со старой. И только когда автоматика убеждается, что новая версия запустилась и работает, происходит остановка старой версии. Для выполнения этой процедуры понадобится следующее:
«Не баг, а фича» — учимся понимать язык программистов
Понять смысл IT-терминов можно, только узнав, как они употребляются
Программисты говорят на особом языке, в котором полно терминов и сленга. Эта речь не всегда понятна не только обычным людям, далёким от компьютеров, но и начинающим айтишникам — новичкам в разработке.
Есть куча статей, объясняющих смысл терминов, но неподготовленному человеку от них мало пользы. И если вы общаетесь с программистами или собираетесь стать одним из них, то, скорее всего, во всём придётся разбираться самостоятельно. Иначе можете оказаться в ситуации, похожей на ту, что в клипе:
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Гораздо проще понять, что значит «пичупидо», если знать контекст, в котором употребляются все эти слова. Поэтому попробую объяснить некоторые термины и сленг на примере истории одного программиста (вымышленного).
Дисклеймер. Все совпадения случайны, а персонажи и ситуации вымышлены. В художественных целях они наделены негативными качествами, поэтому не берите с них пример: это касается как профессиональных качеств, так и отношения к алкоголю, курению и энергетическим напиткам. Также некоторые слова используются и в других сферах.
Новая задача
Ваня — обычный джун в веб-студии. Его работа — поддержка бэкенда сайтов старых клиентов студии.
Джуниор ( англ. junior — младший) в данном случае — младший разработчик в веб-студии. Также бывают мидл- ( англ. middle — средний) и сеньор-разработчики ( англ. senior — старший).
Бэкенд или бэк ( англ. back end — задний край) — серверная часть сайта или приложения, которая нужна для обработки и хранения данных. Его противоположность — фронтенд или фронт ( англ. front end — передний край) — видимая часть приложения или сайта. Если же разработчик занимается сразу фронтендом и бэкендом, его называют фуллстек-разработчиком ( англ. full stack — полная куча / полный набор).
Рабочая неделя Вани начинается с митингов, потому что спринт в его компании длится всего неделю.
Митинг — собрание, на котором обсуждается, что успели или не успели сделать сотрудники, а также чем они будут заниматься в новом спринте.
Спринт — период от одной до четырёх недель, за который сотрудники должны успеть выполнить задачу или задачи. Спринты являются частью Скрам.
Скрам ( англ. scrum) — метод управления проектами. Относится к гибкой методологии разработки эджайл ( англ. agile — гибкий).
На этот раз он получил задачу по добавлению валидации в один из интернет-магазинов. До этого вся валидация была на стороне пользователя.
Валидация — проверка данных, которые вводит пользователь.
До пятницы ещё целая неделя, поэтому с митинга Ваня пошёл сразу в курилку. Достав сигарету, он стал слушать разговор мидла и сеньора:
— Недавно залез в репозиторий, а там одни foobar’ы. Целый час голову ломал, а потом махнул рукой и заново переписал.
— Как наберут новых джунов, так всегда говнокод появляется. Как он вообще код ревью проходит?
— Надо проверить в гитхабе историю коммитов.
Тут Ваня поперхнулся, затушил сигарету и заторопился на рабочее место — от греха подальше.
Репозиторий — хранилище исходных файлов проекта.
Foo и Bar — имена функций или переменных, по которым невозможно понять, зачем они нужны. Использование таких имён допускают в учебниках и документации, но не в реальных проектах, потому что они замедляют чтение и понимание кода другими программистами.
Говнокод — очень плохой код.
Код ревью — проверка кода.
Гитхаб — сервис для хранения репозиториев IT-проектов и совместной работы над ними.
Коммит — запись изменений в репозиторий. Коммит содержит в себе данные об изменениях, комментарий и имя автора коммита.
У стола его уже ждал тимлид:
— Ваня, после того как ты добавил функцию загрузки фотографии в личном кабинете, появился баг. Теперь всё ломается, если ввести промокод.
— Вы уверены, что это из-за меня? Мой код вообще промокодов не касался.
— Уверен. Откати сайт и исправь всё до конца недели — нельзя ждать, пока клиент заметит, что одна из фич пропала.
— Но у меня уже есть задача на эту неделю, я не успею всё исправить.
— Это далеко не первый твой факап, поэтому, если не успеешь, мы поставим новый рекорд — так быстро мы джунов ещё не увольняли.
Тимлид ( англ. team leader — лидер команды) в данном случае — программист, который выполняет роль менеджера. Тимлид редко пишет код, вместо этого он следит, чтобы его команда хорошо справлялась с задачами.
Баг ( англ. bug — жук) — неожиданный результат или неожиданное поведение программы, ошибка.
Откатить ( англ. rollback) — отменить изменения, вернуться к прошлой версии.
Фича ( англ. feature — особенность) — полезная (а иногда забавная) функция / особенность программы.
Исправление багов
Дебажить было сложно, но Ваня не мог облажаться и в этот раз. За год его уже успели уволить из трёх компаний, после четвёртого увольнения его резюме будет испорчено окончательно.
Дебаг (англ. debug — устранение багов) — исправление ошибок в коде программы.
Три дня и три ночи Ваня корпел над кодом, но ничего не выходило. В отчаянии он обратился к коллеге, который проводил код ревью для его коммита в прошлый раз.
— Прости, но если бы я знал, что не так в твоём коде, я бы твой пул реквест не заапрувил.
— Но ты же написал lgtm в комментарии!
— И теперь мне за это прилетело. Слушай, я уже сто раз пожалел, что помог тебе сюда устроиться. Тимлид просёк, что я сквозь пальцы смотрю на твой код, поэтому сейчас проблемы у нас обоих. В случае чего я найду новую работу, а ты — вряд ли. Так что сейчас у тебя отличный повод подтянуть знания.
— Ладно, разберусь как-нибудь.
Апрув ( англ. approve) — подтвердить что-нибудь.
Пул реквест ( англ. pull request) — запрос на подтверждение коммита.
LGTM ( англ. looks good to me — На мой взгляд, хорошо) — сокращение, которое часто встречается на гитхаб в комментариях к подтверждению коммитов. Обычно его используют, когда не получается сказать ничего конструктивного по поводу кода.
Осталось всего два дня, чтобы исправить баг и добавить новую фичу, а у Вани не было почти никаких продвижений. После работы он, как обычно, зашёл в магазин, но вместо энергетиков решил взять пиво, потому что вспомнил о Пике Балмера.
Пик Балмера — шуточная теория, что при содержании алкоголя в крови между 0,129 и 0,138% (примерно 2 бутылки пива) программист получает сверхспособности к написанию кода. Теорию выдвинул Стив Балмер, CEO Microsoft с 2000 по 2014 год.
Бессонные ночи и пиво сделали своё дело, поэтому Ваня заснул прямо за компьютером.
Наутро он не сразу понял, что проснулся, и, лёжа лицом на клавиатуре, продолжал слушать разрывающийся будильник. Прошло всего несколько минут, но Ване они показались вечностью.
Ненавидя себя, он поплёлся на работу. Сев за рабочий стол и посмотрев в код, внезапно понял, в чём была ошибка (известно, что многие проблемы в разработке приложений решаются, когда программист спит). Исправив всё за пару минут, он пошёл к тимлиду.
— Я разобрался с багом.
— Отлично, но странно, что у тебя ушло так много времени. Давай протестируем твой код и выгрузим на прод.
Прод или продакшн ( англ. production environment — рабочее окружение) — компьютер (чаще всего сервер), на котором запускается готовое к работе приложение.
Тестирование прошло успешно. И хотя Ване стало спокойнее, он не спешил радоваться — за полтора дня нужно было успеть выполнить задачу, на которую требовалась как минимум неделя.
К счастью, недавно он начал изучать JavaScript, поэтому мог просто скопировать код валидации с фронта и переделать его для бэкенда.
JavaScript — язык фронтенд-разработки.
Помучившись день, он всё-таки закончил. Тимлид оценил усилия:
— Ну вот, можешь же, когда захочешь. Тебе повезло, что мы не деплоим на прод по пятницам, поэтому у тебя ещё есть время до середины понедельника, чтобы ещё раз всё проверить и поправить.
Деплой ( англ. to deploy) — процесс перевода кода в рабочее приложение, чтобы запустить его на каком-нибудь компьютере.
Воодушевлённый успехом, Ваня ещё раз всё протестировал, поэтому к следующему митингу он был спокоен — больше исправлять старые баги ему не придётся.
По крайней мере на этот спринт.
Заключение
Научила ли чему-нибудь Ваню эта история? Возможно. Но вы наверняка стали на один шаг ближе к пониманию программистов. Или даже к тому, чтобы стать одним из них.
Deployer — удобный и гибкий деплой приложений
Несомненно, тема, думаю, многими заезжена до дыр — всё-таки, деплой надо делать для каждого проекта — но я всё же подниму её и расскажу об одном замечательном инструменте, о котором, по какой-то странной причине, до сих пор ничего не написали на Хабре, да и вообще в русскоязычном сегменте как-то о нём мало что написано. Исправим это недоразумение.
Deployer хорош во многих отношениях. Код скрипта для деплоя получается коротким. Написан на старом добром Пыхчанском — то бишь, скорее всего, ставить отдельно какие-то другие инструменты на сервер вам не придётся. Если же и придётся — то PHP обычно устанавливается одной командой на любом сервере. Почему-бы и не заюзать его в своих проектах?
Первый коммит был сделан аж в 2013-м году, и до сих пор инструмент потихоньку развивается. У него также есть приятный сайт, на котором можно найти о нём всю документацию.
Что лично мне нравится больше всего из того, что даёт данный инструмент — это возможность быстро откатиться на прошлый «рабочий» релиз, если новый релиз оказался неудачным. Также довольно удобно то, что если при попытке «выкатить» новый релиз что-то пойдёт не так (миграции не применились, фронтенд файлы не скомпилировались, тесты не прогнались..) — то ваше текущее работающее приложение это никак не затронет — оно будет работать как ни в чём ни бывало. Дело в том, что Deployer не изменит ссылку у директории, обозначающей текущий активный релиз, до того момента, пока ваш новый «релиз» не будет полностью установлен и готов к работе.
Единственное, чего Deployer не решает — это возможные проблемы с применением миграций к вашей базе данных. Но это вообще тема сложная, не знаю, существуют ли вообще элегантные решения в данном случае. Если существует — буду рад узнать, какое.
Структура папок релизов
Пример скрипта деплоя Laravel приложения
Я люблю лично зайти на свой сервер, запустить скрипт деплоя и наблюдать за процессом его работы. Просто, мне так намного спокойнее жить, так как я всегда могу предпринять какие-то срочные меры, если при деплое что-то пойдёт не так. А так, как я знаю, люди обычно запускают подобный скрипт со своей локальной машины, которая подключается по SSH к серверу и производит деплой. Если это надо сделать сразу на нескольких машинах — то такой подход конечно будет удобнее. К слову, Deployer позволяет выполнять деплой сразу на нескольких машинах в том числе.
Естественно, перед тем как получить возможность выполнить данный скрипт, вам необходимо сначала установить Deployer на свою систему.
В одном из моих проектов на Laravel 5 скрипт деплоя deploy.php выглядит следующим образом:
Следовательно, чтобы запустить процесс деплоя, нам остаётся набрать лишь одну команду в Bash’е:
Таким образом, как мы видим, введя всего одну команду, мы заставим сервер выполнить все необходимые шаги для разворачивания нашего проекта. И только если всё прошло хорошо, папка current сменит ссылку на новый релиз и перезапустит PHP после всего этого.
В общем-то, это всё, что я хотел рассказать и показать. Надеюсь, это будет кому-то полезным. Ну и конечно интересно будет узнать мнение других людей о том, как они занимаются деплоем своих приложений.
5 способов деплоя PHP-кода в условиях хайлоада
Если бы хайлоад преподавали в школе, в учебнике по этому предмету была бы такая задача. «У соцсети N есть 2 000 серверов, на которых 150 000 файлов объемом по 900 Мб PHP-кода и стейджинг-кластер на 50 машин. На серверы код деплоится 2 раза в день, на стейджинг-кластере код обновляется раз в несколько минут, а еще дополнительно есть „хотфиксы“ — небольшие наборы файлов, которые выкладываются вне очереди на все или на выделенную часть серверов, не дожидаясь полной выкладки. Вопрос: считаются ли такие условия хайлоадом и как в них деплоить? Напишите не менее 5 вариантов деплоя». Про задачник по хайлоаду можем только мечтать, но уже сейчас мы знаем, что Юрий Насретдинов (youROCK) точно бы решил эту задачу и получил «пятерку».
Понятие «деплой кода»
Процесс деплоя обычно состоит из нескольких этапов.
Старая система деплоя в Badoo
Если у вас есть файл с образом файловой системы, то как его смонтировать? В Linux нужно создать промежуточное Loop-устройство, привязать к нему файл, и после этого уже это блочное устройство можно смонтировать.
Loop-устройство — это костыль, который нужен в Linux, чтобы смонтировать образ файловой системы. Есть ОС, в которых этот костыль не требуется.
Как происходит процесс деплоя с помощью файлов, которые мы тоже называем для простоты «лупами»? Есть директория, в которой находится исходный код и автоматически сгенерированное содержимое. Берем пустой образ файловой системы — сейчас это EXT2, а раньше мы использовали ReiserFS. Монтируем пустой образ файловой системы во временную директорию, копируем туда все содержимое. Если нам не нужно, чтобы на продакшн что-то попадало, то копируем не все. После этого размонтируем устройство, и получаем образ файловой системы, в котором находятся нужные файлы. Дальше архивируем образ и заливаем на все серверы, там разархивируем и монтируем.
Другие существующие решения
Для начала давайте поблагодарим Ричарда Столмана — без его лицензии не существовало бы большинства утилит, которые мы используем.
Способы деплоя PHP-кода я условно разделил на 4 категории.
Деплой на основе системы контроля версий svn up
Я выбрал SVN не случайно — по моим наблюдениям, в таком виде деплой существует именно в случае SVN. Система достаточно легковесная, позволяет легко и быстро провести деплой — просто запускаете svn up и всё готово.
Но у этого способа есть один большой минус: если вы делаете svn up, и в процессе обновления исходного кода, когда из репозитория приходят новые запросы, они будут видеть состояние файловой системы, которой не существовало в репозитории. У вас будет часть файлов новых, а часть старых — это неатомарный способ деплоя, который не подходит для высокой нагрузки, а только для небольших проектов. Несмотря на это, я знаю проекты, которые все равно так деплоятся, и у них пока все работает.
Деплой на основе утилиты rsync
Есть два варианта, как это сделать: заливать файлы с помощью утилиты напрямую на сервер и заливать «поверх» — обновлять.
rsync в новую директорию
Поскольку вы сначала целиком заливаете весь код в директорию, которой еще не существует на сервере, и только потом переключаете трафик, этот способ атомарный — никто не видит промежуточного состояния. В нашем случае создание 150 000 файлов и удаление старой директории, в которой тоже 150 000 файлов, создает большую нагрузку на дисковую подсистему. У нас весьма активно используются жесткие диски, и сервер где-то в течение минуты не очень хорошо себя чувствует после такой операции. Поскольку у нас 2000 серверов, то требуется 2000 раз залить 900 Мб.
Эту схему можно улучшить, если сначала залить на какое-то количество промежуточных серверов, например, 50, и потом уже с них доливать на остальные. Так решаются возможные проблемы с сетью, но проблема создания и удаления огромного количества файлов никуда не исчезает.
rsync «поверх»
Отправка изменений работает так. Rsync составляет списки файлов на стороне сервера, с которого осуществляется деплой, и на принимающей стороне. После этого считает stat от всех файлов и отправляет весь список на принимающую сторону. На сервере, с которого идет деплой, считается разница между этими значениями, и определяется, какие файлы нужно послать.
В наших условиях на этот процесс уходит примерно 3 Мб трафика и 1 секунда процессорного времени. Кажется, что это немного, но у нас 2000 серверов, и на все получается не меньше одной минуты процессорного времени. Не такой уж это и быстрый способ, но однозначно лучше, чем отправка целиком через rsync. Осталось как-то решить проблему с атомарностью и будет почти идеально.
Деплой одним файлом
Какой бы одиночный файл вы бы не заливали, это относительно просто сделать с помощью BitTorrent или утилиты UFTP. Один файл проще распаковать, можно атомарно заменить в Unix, и легко проверить целостность файла, сгенерированого на билд-сервере и доставленного на конечные машины, посчитав MD5 или SHA-1 суммы от файла (в случае rsync вы не знаете, что находится на конечных серверах).
Для жестких дисков последовательная запись это большой плюс — на незанятый винчестер файл на 900 Мб запишется за время порядка 10 секунд. Но все равно нужно записывать эти самые 900 Мб и передавать их по сети.
Лирическое отступление про UFTP
Эта Open Source утилита изначально создавалась для передачи файлов по сети с большими задержками, например, через сеть на основе спутниковой связи. Но UFTP оказалась пригодной и для заливки файлов на большое количество машин, потому что работает по протоколу UDP на основе Multicast. Создается один Multicast-адрес, на него подписываются все машины, которые хотят получить файл, и свичами обеспечивается доставка копий пакетов на каждую машину. Так мы перекладываем нагрузку по передаче данных на сеть. Если ваша сеть это выдержит, то этот способ работает намного лучше, чем BitTorrent.
Вы можете попробовать эту Open Source утилиту у себя на кластере. Несмотря на то, что она работает по протоколу UDP, у нее есть механизм NACK — negative acknowledgement, который заставляет переотправлять потерянные при доставке пакеты. Это надежный способ деплоя.
Варианты деплоя одним файлом
tar.gz
Вариант, который сочетает в себе недостатки обоих подходов. Мало того, что вы должны записать 900 Мб на диск последовательно, после этого вам нужно случайным чтением-записью еще раз записать те же 900 Мб и создать 150 000 файлов. По производительности этот способ еще хуже, чем rsync.
phar
PHP поддерживает архивы в формате phar (PHP Archive), умеет отдавать их содержимое и инклюдить файлы. Но не все проекты легко поместить в один phar — нужна адаптация кода. Просто так код из этого архива не заработает. Кроме того, в архиве нельзя поменять один файл (Юрий из будущего: в теории все-таки можно), требуется перезалить архив целиком. Также несмотря на то, что phar-архивы работают с OPCache, при деплое кеш нужно сбрасывать, потому что иначе будет оставаться мусор в OPCache от старого phar-файла.
hhbc
Этот способ нативен для HHVM — HipHop Virtual Machine и его использует Facebook. Это что-то вроде phar-архива, но в нем лежат не исходные коды, а скомпилированный байт-код виртуальной машины HHVM — интерпретатора PHP от Facebook. В этом файле запрещено что-либо менять: нельзя создавать новые классы, функции и некоторые другие динамические возможности в этом режиме отключены. За счет этих ограничений виртуальная машина может использовать дополнительные оптимизации. Как утверждает Facebook, это может принести до 30% к скорости исполнения кода. Наверное, для них это хороший вариант. Здесь также нельзя поменять один файл (Юрий из будущего: на самом деле можно, потому что это sqlite-база). Если вы хотите поменять одну строчку, нужно передеплоить весь архив заново.
Для этого способа запрещено использовать eval и динамические include. Это так, но не совсем. Eval использовать можно, но если он не создает новые классы или функции, а include нельзя делать из директорий, которые находятся вне этого архива.
loop
Это наш старый вариант, и у него есть два больших преимущества. Первое — он выглядит, как обычная директория. Вы монтируете loop, и для кода все равно — он работает с файлами, как на develop-окружении, так и на production-окружении. Второе — loop можно смонтировать в режиме чтения и записи, и поменять один файл, если нужно все-таки что-то срочно поменять на продакшн.
Но у loop есть минусы. Первый — он странно работает с docker. Об этом расскажу чуть позже.
Второй — если вы используете symlink на последний loop в качестве document_root, то у вас возникнут проблемы с OPCache. Он не очень хорошо относится к наличию symlink в пути, и начинает путать, какие версии файлов нужно использовать. Поэтому OPCache приходится сбрасывать при деплое.
Еще проблема — требуются привилегии суперпользователя, чтобы монтировать файловые системы. И нужно не забывать их монтировать при старте/рестарте машины, потому что иначе будет пустая директория вместо кода.
Проблемы с docker
Если вы создаете docker-контейнер и пробрасываете внутрь него папку, в которой смонтированы «лупы» или другие блочные устройства, то возникает сразу две проблемы: новые точки монтирования внутрь docker-контейнера не попадают, и те «лупы», которые находились на момент создания docker-контейнера, нельзя отмонтировать, потому что они заняты docker-контейнером.
Естественно, это вообще несовместимо с деплоем, потому что количество loop-устройств ограничено, и непонятно, как новый код должен попадать в контейнер.
Мы пробовали делать странные вещи, например, поднимать локальный NFS-сервер или монтировать директорию по SSHFS, но у нас это по разным причинам не прижилось. В результате в cron мы прописали rsync от последнего «лупа» в настоящую директорию, и она раз в минуту выполняла команду:
Здесь /var/www/ — это директория, которая продвинута в контейнер. Но на машинах, где есть docker-контейнеры, нам не нужно часто запускать PHP-скрипты, поэтому то, что rsync неатомарный, нас устраивало. Но все равно этот способ очень плохой, конечно. Хотелось бы сделать систему деплоя, которая хорошо работает с docker.
rsync, 2 директории и realpath_root
Этот способ предложил Расмус Лердорф, автор PHP, а он-то знает, как деплоить.
Как сделать атомарный деплой, причем в любом из способов, о которых я рассказал? Берете symlink и прописываете его в качестве document_root. В каждый момент времени symlink указывает на одну из двух директорий, и вы делаете rsync в соседнюю директорию, то есть в ту, в которую код не указывает.
Используйте эту константу при обращении ко всем файлам внутри кода, который вы используете на продакшне. Так вы получите свойство атомарности: запросы, которые приходят до того, как вы переключили symlink, продолжают инклюдить файлы из старой директории, в которой вы ничего не меняли, а новые запросы, которые пришли уже после переключения symlink, начинают работать из новой директории и обслуживаться новым кодом.
Но это нужно прописывать в коде. Не все проекты к этому готовы.
Rasmus-style
Расмус предлагает вместо ручной модификации кода и создания констант немножко модифицировать Apache или же использовать nginx.
У этого способа интересные плюсы — в OPCache PHP приходят уже настоящие пути, они не содержат symlink. Даже самый первый файл, на который пришел запрос, уже будет полноценным, и не будет никаких проблем с OPCache. Поскольку используется document_root, то это работает с любым PHP-проектом. Вам не нужно ничего адаптировать.
Не требуется fpm reload, не нужно сбрасывать OPCache при деплое, из-за чего сильно нагружается сервер процессора, потому что должен распарсить все файлы заново. В моем эксперименте сброс OPCache примерно на полминуты повышал потребление процессора в 2-3 раза. Хорошо бы его переиспользовать и этот способ позволяет это делать.
Теперь минусы. Поскольку вы не переиспользуете OPCache, и у вас 2 директории, то нужно хранить по копии файла в памяти под каждую директорию — под OPCache требуется в 2 раза больше памяти.
Есть еще ограничение, которое может показаться странным — нельзя деплоиться чаще, чем раз в max_execution_time. Иначе будет та же проблема, потому что пока идет rsync в одну из директорий, еще могут обрабатываться запросы из нее.
Если вы используете Apache по какой-то причине, то нужен сторонний модуль, который также написал Расмус.
Расмус говорит, что система хороша и я тоже её вам рекомендую. Для 99% проектов она подойдет, причём как для новых проектов, так и для существующих. Но, конечно же, мы не такие и решили написать своё решение.
Новая система — MDK
В основном наши требования ничем не отличаются от требований для большинства веб-проектов. Мы всего лишь хотим быстрый деплой на стэйджинге и продакшн, малое потребление ресурсов, переиспользование OPCache и быстрый откат.
Но есть еще два требования, которые, возможно, отличаются от остальных. Прежде всего это возможность применять патчи атомарно. Патчами мы называем изменения в одном или нескольких файлах, которые что-то правят на продакшене. Мы хотим это делать быстро. В принципе, с задачей патчей система, которую предлагает Расмус, справляется.
Также у нас есть CLI-скрипты, которые могут работать по несколько часов, и они все равно должны работать с консистентной версией кода. В таком случае приведенные решения, к сожалению, нам либо не подходят, либо мы должны иметь очень много директорий.
Поэтому мы придумали новую систему и назвали ее MDK. Расшифровывается как Multiversion Deployment Kit — многоверсионный инструмент для деплоя. Мы его сделали, исходя из следующих предпосылок.
Взяли архитектуру хранения деревьев из Git. Нам же нужно иметь консистентную версию кода, в которой работает скрипт, то есть нужны снапшоты. Снапшоты поддерживаются LVM, но там они реализованы неэффективно, экспериментальными файловыми системами, наподобие Btrfs и Git. Мы взяли реализацию снапшотов из Git.
Я люблю Go, поэтому для скорости написали систему на Go.
Как работает Multiversion Deployment Kit
Мы взяли идею снапшотов у Git. Я ее немножко упростил и расскажу, как она реализована в MDK.
Допустим, у нас есть некоторая иерархия файлов, в которой корневая карта ссылается на определенные версии файлов из других карт, а они, в свою очередь, ссылаются на другие файлы и карты, и фиксируют определенные версии. Мы хотим поменять какой-то файл.
Возможно, вы уже видели подобную картинку: меняем файл на втором уровне вложенности, и в соответствующей карте — map*, обновляется версия файла three*, модифицируется ее содержимое, меняется версия — и в корневой карте тоже меняется версия. Если мы что-то меняем, то получаем всегда новую корневую карту, но все файлы, которые мы не меняли переиспользуются.
Ссылки остаются на те же файлы, что и были. Это основная идея создания снапшотов любым способом, например, в ZFS это реализовано примерно так же.
Как MDK лежит на диске
На диске у нас есть: symlink на самую свежую корневую карту — код, который будет обслуживаться из веба, несколько версий корневых карт, несколько файлов, возможно, с разными версиями, и во вложенных директориях лежат карты для соответствующих директорий.
Предвижу вопрос: «И как же этим обрабатывать веб-запрос? На какие файлы будет приходить пользовательский код?«
Да, я вас обманул — есть и файлы без версий, потому что если вам приходит запрос на index.php, а у вас его нет в директории, то сайт работать не будет.
У всех PHP-файлов есть файлы, которые мы называем заглушками, потому что они содержат две строчки: require от файла, в котором объявлена функция, которая умеет с этими картами работать, и require от нужной версии файла.
Сделано это так, а не симлинками на последнюю версию, потому что, если из файла a.php вы заинклюдите b.php без версии, то, поскольку написано require_once, система запомнит, с какой корневой карты она начала, будет использовать именно ее, и получать согласованную версию файлов.
Для остальных файлов у нас есть просто symlink на последнюю версию.
Как деплоить с помощью MDK
Модель очень похожа на git push.
Пример
Допустим, есть файл с именем «one» на сервере. Присылаем к нему корневую карту.
В корневой карте прерывистыми стрелками отмечены ссылки на файлы, которых у нас нет. Мы знаем их имена и версии, потому что они находятся в карте. Запрашиваем их у сервера. Сервер присылает, и оказывается, что один из файлов — это тоже карта.
Смотрим — у нас вообще ни одного файла нет. Опять запрашиваем файлы, которых не хватает. Сервер их присылает. Больше карт не осталось — процесс деплоя завершен.
Можно легко догадаться, что будет, если файлов 150 000, а изменился один. Увидим в корневой карте что не хватает одной карты, пойдем по уровню вложенности и получим файл. По вычислительной сложности процесс почти не отличается от копирования файлов напрямую, но при этом сохраняется консистентность и снапшоты кода.
У MDK минусов нет:) Он позволяет быстро и атомарно деплоить небольшие изменения, а скриптам работать сутками, потому что мы можем оставлять все файлы, которые деплоили в течение недели. Они будут занимать вполне адекватное количество места. Также можно переиспользовать OPCache, а CPU почти ничего не ест.
Мониторить достаточно сложно, но можно. Все файлы версионируются по содержимому, и можно написать cron, который будет проходить по всем файлам и сверять имя и содержимое. Также можно проверять, что корневая карта ссылается на все файлы, что в ней нет битых ссылок. Более того, при деплое проверяется целостность.
Можно легко откатить изменения, потому что все старые карты на месте. Мы можем просто перекинуть карту, там сразу будет все что нужно.
Для меня плюс то, что MDK написана на Go — значит, быстро работает.
Я опять вас обманул, минусы все же есть. Чтобы проект работал с системой, требуется существенная модификация кода, но она проще, чем может показаться на первый взгляд. Система очень сложная, я бы не рекомендовал ее реализовывать, если у вас нет таких требований, как у Badoo. Также все равно рано или поздно кончается место, поэтому требуется Garbage Collector.
Мы написали специальные утилиты, чтобы редактировать файлы — настоящие, а не заглушки, например, mdk-vim. Вы указываете файл, она находит нужную версию и ее редактирует.
MDK в цифрах
У нас на стэйджинге 50 серверов, на которых мы деплоимся за 3-5 с. По сравнению со всем, кроме rsync, — это очень быстро. На продакшн мы деплоимся порядка 2 минут, небольшие патчи — 5-10 с.
Если вы по какой-то причине потеряли вообще всю папку с кодом на всех серверах (чего никогда не должно случиться :)) то процесс полной заливки идет около 40 минут. У нас это случилось один раз, правда ночью в минимум трафика. Поэтому никто не пострадал. Второй фейл был на паре серверов в течение 5 минут, так что это не достойно упоминания.
Система не в Open Source, но если вам интересно, то пишите в комментариях — может быть выложим (Юрий из будущего: система всё ещё не в Open Source на момент написания этой статьи).
Заключение
Слушайте Расмуса, он не врет. По моему мнению, его способ rsync совместно с realpath_root — лучший, хотя «лупы» тоже работают вполне неплохо.
Думайте головой: посмотрите то, что нужно именно вашему проекту, и не пытайтесь создать космический корабль там, где достаточно «кукурузника». Но если все-таки у вас требования похожи, то и система, похожая на MDK, вам подойдет.
Мы решили вернуться к этой теме, которая обсуждалась на HighLoad++ и, возможно, тогда не получила должного внимания, потому что была лишь одним из многих кирпичиков достижения высокой производительности. Но теперь у нас есть отдельная профессиональная конференция PHP Russia, полностью посвященная PHP. И вот тут уж оторвемся по полной. Обстоятельно поговорим и про производительность, и про стандарты, и про инструменты — много про что, включая рефакторинг.
Подпишитесь на Telegram-канал с обновлениями программы конференции, и увидимся 17 мая.