В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
12. Существующие решения
✦ Система контроля версий (svn up / git pull / hg up)
✦ rsync (в новую директорию или «поверх»)
✦ Один файл (phar, hhbc, loop)
✦ rsync + 2 директории + realpath_root
13. Существующие решения
✦ Система контроля версий (svn up / git pull / hg up)
✦ rsync (в новую директорию или «поверх»)
✦ Один файл (phar, hhbc, loop)
✦ rsync + 2 директории + realpath_root
14. svn up
+ «Ленивый»
+ Быстрый
+ Легковесный (в случае SVN)
- Неатомарный
+/- Подходит для небольших проектов
15. Существующие решения
✦ Система контроля версий (svn up / git pull / hg up)
✦ rsync (в новую директорию или «поверх»)
✦ Один файл (phar, hhbc, loop)
✦ rsync + 2 директории + realpath_root
16. Rsync в новую директорию
+ Атомарный
-- Нагрузка по I/O (заливка нового + удаление старого)
-- Много трафика
18. Существующие решения
✦ Система контроля версий (svn up / git pull / hg up)
✦ rsync (в новую директорию или «поверх»)
✦ Один файл (phar, hhbc, loop)
✦ rsync + 2 директории + realpath_root
19. Rsync поверх
++ Отправка только изменений
- Неатомарный
- Высокий CPU% на отправляющей стороне
- Отправка и прием списка всех файлов с их stat()
- 3 мб и 1 сек CPU на 150к файлов
- 40-60 сек на 1000 серверов (24 ядра и 1 Гбит/с)
20. Существующие решения
✦ Система контроля версий (svn up / git pull / hg up)
✦ rsync (в новую директорию или «поверх»)
✦ Один файл (phar, hhbc, loop)
✦ rsync + 2 директории + realpath_root
21. Один файл
++ Возможность использования uftp / bittorent
+ Простота
+ Атомарность
+ Легкость проверки целостности (md5 от одного файла)
+ Последовательная запись
- Большой объем записи
- Большая нагрузка на сеть
22. UFTP
✦ Загрузка по протоколу UDP (Multicast) + NACK
✦ Подходит для загрузки на сотни машин
✦ В наших условиях работает лучше bittorrent
✦ Open-source
24. Один файл (phar)
+ Нативный для PHP
- Необходимость адаптировать код для работы из архива
- Нельзя поменять один файл
- OPCache сбрасывается полностью
25. Один файл (hhbc)
+/- Нативный для HHVM
+ Дополнительные оптимизации (+30% к скорости)
- Необходимость адаптировать код для работы из архива
- Запрещено использовать eval и динамические include
- Нельзя поменять один файл
26. Один файл (loop)
+ Выглядит, как обычная директория
+ Можно поменять один файл (rw mount)
-- Не совместим с docker (no dynamic mounts)
- OPCache сбрасывается полностью
- Требуется sudo для mount
- Не забывать монтировать при (ре)старте
27. Один файл (loop), docker
✦ Docker не поддерживает dynamic mounts
✦ loop монтируется динамически
✦ Пробовали понимать локальные NFS, SSHFS
✦ rsync /var/loop/<N>/ /var/www/
✦ /var/www/ — директория, прокинутая в контейнер
✦ Решение плохое, rsync не атомарный
28. Существующие решения
✦ Система контроля версий (svn up / git pull / hg up)
✦ rsync (в новую директорию или «поверх»)
✦ Один файл (phar, hhbc, loop)
✦ rsync + 2 директории + realpath_root
33. Rasmus-style
+ Не требуется адаптация кода
+ Не требуется reload — переиспользуется OPCache
- Требуется в 2 раза больше памяти под OPCache
- Нельзя деплоиться чаще, чем раз в max_execution_time сек
- Для Apache нужен сторонний модуль
34. План
✦ Понятие деплоя кода
✦ Старая система деплоя в Badoo
✦ Другие существующие решения
✦ Новая система — MDK
✦ Заключение
35. Требования
✦ Быстрый деплой на staging и production
✦ Атомарные патчи
✦ Скрипты могут работать несколько часов (CLI)
✦ Малое потребление ресурсов
✦ Сохранность OPCache
✦ Быстрый откат
36. Требования
✦ Быстрый деплой на staging и production
✦ Атомарные патчи
✦ Скрипты могут работать несколько часов (CLI)
✦ Малое потребление ресурсов
✦ Сохранность OPCache
✦ Быстрый откат
39. Multiversion Deployment Kit
✦ Возьмем архитектуру хранения деревьев (tree) из Git
✦ Переименуем все файлы из file.php в file.php.<version>
✦ Для скорости напишем её на Go
✦ Готово!
40. Multiversion Deployment Kit
map:
array(
one => f/a3f4da63,
two => f/c193497a,
map => d/9c134b68,
)
root
deadbeef
one
a3f4da63
two
c193497a
map
9c134b68
three
febe6995
four
75ffdb82
48. Multiversion Deployment Kit
+ Быстрый атомарный деплой небольших изменений
+ Низкое потребление CPU
+ OPCache переиспользуется
+ Позволяет скриптам работать сутками
+ Легкий мониторинг
+ Быстрый откат изменений
+ Написана на Go
49. Multiversion Deployment Kit
- Требуется модификация кода
- Сложная
- Требуется Garbage Collector
- Для редактирования файлов нужны спец. утилиты (mdk-vim)
51. План
✦ Понятие деплоя кода
✦ Старая система деплоя в Badoo
✦ Другие существующие решения
✦ Новая система — MDK
✦ Заключение
52. Заключение
✦ Rasmus не врет, rsync + realpath_root хорош
✦ «Лупы» тоже работают вполне неплохо
✦ Используйте то, что подходит лично вам
✦ Частый деплой + долгая работа => MDK
✦ Расскажите о своем опыте
✦ Заходите на https://tech.badoo.com/ !