Документ описывает процесс релиз-инжиниринга в компании Mail.ru, включая организацию работы релиз-инженеров, сборку и раздачу релизов. Рассматриваются различные технологии и подходы, такие как использование squashfs, tarballs и систем управления версиями, а также вопросы мониторинга и отката релизов. В конце приводятся советы и рекомендации по улучшению процесса, упомянуты узкие места и их возможные решения.

1. Релиз инжиниринг Mail.ru, взгляд изнутри
Глеков Максим
программист-разработчик почтовой службы
• v4

2. Организация работы релиз-инженеров
• Стоит ли брать что-то готовое?
• Сборка релиза
• Раздача релиза
• Демон обновлений
• Тестовые сервера
• Выкладка на бой
• Мониторинг
• Узкие места
ПОСЛЕ ЧЕГО ОТВЕЧУ НА ВСЕ ВАШИ ВОПРОСЫ И ДАМ ТЕХНИЧЕСКИЕ РЕКОМЕНДАЦИИ
О чем доклад ?

3. Организация работы верстальщика

4. Организация работы релиз-инженера

5. Может быть есть что-то готовое?
Что выбрать?
• Git pull на продакшне :)

6. Может быть есть что-то готовое?
Что выбрать?
• Git pull на продакшне :)
• Fabric (python)

7. Может быть есть что-то готовое?
Что выбрать?
• Git pull на продакшне :)
• Fabric (python)
• Capistrano (ruby)

8. Почему мы написали свою систему?
Все сложно
• Безопасность
• Быстрые фиксы багов
• Минимальные зависимости

9. Комманды для управления
Какие нужны и зачем?
• risk-deploy-create — создать релиз
• risk-deploy-push — положить релиз на группу серверов
• risk-deploy-switch — переключить группу серверов
• risk-deploy-clean — удалить релиз с группы серверов

10. Сборка релиза
Последовательность действий в раскладчике

11. Проверка конситентности сборки
Md5sum — то, что нам надо
• файл с контрольными суммами
• Проверка консистентности сборки: md5sum -c имя_файла_с_суммами
• «дешевый» способ» — измерение размера всей сборки
• «дешевый способ» только для мониторинга!

12. Тарболы практика
Где же все-таки удобнее использовать тарболы?
• Нет root-доступа
• Разные дистрибутивы Linux
• Еще хуже -— Windows
• Маленькие репозитории
• Раскладки на тестовые сервера

13. Тарболы практика
Где же все-таки удобнее использовать тарболы?
• Нет root-доступа
• Разные дистрибутивы Linux
• Еще хуже — Windows
• Маленькие репозитории
• Раскладки на тестовые сервера

14. SquashFs самое оптимальное?
SquashFs — отличное решение для выкатки боевых релизов
• Сжимающая файловая система gzip/lzma
• Применяется во встраиваемых системах

15. SquashFs самое оптимальное?
SquashFs — отличное решение для выкатки боевых релизов
• Сжимающая файловая система gzip/lzma
• Применяется во встраиваемых системах
• роутеры
• квадрокоптеры
• холодильники
• кофеварки

16. SquashFs самое оптимальное?
SquashFs — отличное решение для выкатки боевых релизов
• Сжимающая файловая система gzip/lzma
• Применяется во встраиваемых системах
• роутеры
• кофеварки
• холодильники
• квадрокоптеры
• Просто собрать: mksquashfs data_dir sqsh_file_path.sqsh

17. SquashFs самое оптимальное?
SquashFs — минусы
• Одна и та же версия SquashFs
• Одно и то же сжатие gzip или lzma
• Для монтирования требуются root-права

18. Почему не RPM + puppet?
RPM или DEB — неплохое решение
• Требуется писать spec файлы
• Просто собирать: rpmbuild -bb имя_спеки
• Все фаилы в одном пакете
• Не засоряет систему
• RPM → DEB с помощью alien

19. Почему не RPM + puppet?
RPM или DEB — минусы
• Для установки требуются root-права
• Нужно привлекать админа
• Проблемы с накати/откати в выходной/ночью

20. Что выбрали мы?
Вроде бы все очевидно....
• Мы катим в среднем 3 раза в день
• Для выкатки пакуем все файлы
• Тарболы только для тестовых серверов
• В продакшне SquashFS
• RPM на проектах с редкими выкатками (Ответы@Mail.ru,
Календарь@Mail.ru)

21. Схема обновления обновлений дифами
Плохой вариант для production
• Выкатки не консистентны
• Откатиться полноценно назад трудно
• Непонятно чем закончится исправление ошибки
• Подходит только для тестовых серверов

22. Раздача релиза
Хранилище релизов

23. Раздача релиза
Сущности внутри репозитория
• Кикстарт — файл с текущей сборкой
• deploy_files.list — файл со списком сборок

24. Раздача релиза
Выкладываем на группу серверов в тест
• risk-deploy-push -b alphatest -f e.mail.ru-f-alpha-505-en-m.glekov-1427105421

25. Раздача релиза
Выкладываем на группу серверов в тест

26. Раздача релиза
Схема раздачи

27. Раздача релиза
Но есть проблема....
• Узкое место — получение обновлений с одного источника

28. Раздача релиза
Простое решение - шардинг
• Увеличить количество раздающих серверов

29. Устройство демона обновлений
Get risk — так называется наш демон обновлений

30. Статика (js,css, images, etc)
Шаблоны отдельно, статика отдельно — надо делать две отдельные
сборки!

31. Выкладка релиза на тестовые серверы
Тестовые серверы, плавающий DOCUMENT_ROOT
• DOCUMENT_ROOT сервера — директория с шаблонами
• На серверах, где нет веток, DOCUMENT_ROOT один
• На серверах с ветками каждая ветка — новый DOCUMENT_ROOT
• Переключение DOCUMENT_ROOT в backend регулярным выражением

32. Выкладка релиза на тестовые серверы
FUSE (Filesystem on Userspace) для веток
• Храним только различающиеся файлы
• Недостающие файлы берем из корневой ветки

33. Выкладка релиза на тестовые серверы
FUSE для веток

34. Выкладка релиза на тестовые серверы
FUSE для веток

35. Выкладка релиза на тестовые серверы
FUSE для веток

36. Выкладка релиза на тестовые серверы
FUSE для веток

37. Хочу себе FUSE!
Что можно найти в открытом доступе?
• MergeFS (http://bersace03.free.fr/mergefs/mergefs)
• UnionFS (http://unionfs.filesystems.org/)
• Aufs (http://aufs.sourceforge.net/)
• Mhddfs (http://mhddfs.uvw.ru/)

38. Выкладываем в продакшн
Выкладываем билд, который прошел через тестовые сервера
1. Раскладываем сборку по серверам:
risk-deploy-push -b production -f e.mail.ru-f-alpha-505-en-m.glekov-1427105421
2. Переключаемся на разложенную сборку:
risk-deploy-switch -b production -f e.mail.ru-f-alpha-505-en-m.glekov-1427105421

39. Мониторинг
Get Risk Network Monitoring или просто grnmon ;)

40. Мониторинг
Get Risk Network Monitoring

41. Мониторинг
Get Risk Network Monitoring

42. Как устроен мониторинг
Get Risk Network Monitoring
• Как работает мониторинг?
• Демон grnmon — принимает данные с серверов
• MySQL — хранение данных для старта
• Memcached — чтобы не мучить базу
• Fcgi — отдача jsonp из Memcached
• JavaScript — отображение данных

43. Переключаем сервера между билдами
Накати — первый этап
• risk-deploy-switch -b alphatest -f e.mail.ru-f-alpha-505-en-m.glekov-1427105421
• Время переключения между билдами от 2-5 секунд (!!!!)

44. Дашборд
Или как мы понимаем, что все хорошо

45. Что-то пошло не так....

46. Быстрый откат в случае неудачи
Сколько времени надо, чтобы откатиться?
• Не более 2-5 сек (!!!)
• Переключаемся обратно на прошлый стабильный билд
• Снова смотрим в дашборд

47. Запуск тестов
Несколько советов

48. Узкие места, проблемы и методы их решения
Есть некоторые нюансы...
• При работе с большими тарболами(> 100 MB) надо использовать pv для
затормаживания диска (Ex: cat filename | pv -L limit_rate_speed -rt | tar -xmzf -
-C folder_full_path)
• Все операции должны быть атомарные
• Шардинг серверов с обновлениями
• Не пользоваться базой данных в демоне обновления

49. СПАСИБО ЗА ВНИМАНИЕ!
Вопросы?
m.glekov@corp.mail.ru