Релиз инжиниринг Mail.ru, взгляд изнутри / Максим Глеков (Mail.Ru Group)
0 likes•913 views
Документ описывает процесс релиз-инжиниринга в компании Mail.ru, включая организацию работы релиз-инженеров, сборку и раздачу релизов. Рассматриваются различные технологии и подходы, такие как использование squashfs, tarballs и систем управления версиями, а также вопросы мониторинга и отката релизов. В конце приводятся советы и рекомендации по улучшению процесса, упомянуты узкие места и их возможные решения.
Релиз инжиниринг Mail.ru, взгляд изнутри / Максим Глеков (Mail.Ru Group)
- 1. Релиз инжиниринг Mail.ru, взгляд изнутри Глеков Максим программист-разработчик почтовой службы • v4
- 2. Организация работы релиз-инженеров • Стоит ли брать что-то готовое? • Сборка релиза • Раздача релиза • Демон обновлений • Тестовые сервера • Выкладка на бой • Мониторинг • Узкие места ПОСЛЕ ЧЕГО ОТВЕЧУ НА ВСЕ ВАШИ ВОПРОСЫ И ДАМ ТЕХНИЧЕСКИЕ РЕКОМЕНДАЦИИ О чем доклад ?
- 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 • Выкатки не консистентны • Откатиться полноценно назад трудно • Непонятно чем закончится исправление ошибки • Подходит только для тестовых серверов
- 23. Раздача релиза Сущности внутри репозитория • Кикстарт — файл с текущей сборкой • deploy_files.list — файл со списком сборок
- 24. Раздача релиза Выкладываем на группу серверов в тест • risk-deploy-push -b alphatest -f e.mail.ru-f-alpha-505-en-m.glekov-1427105421
- 25. Раздача релиза Выкладываем на группу серверов в тест
- 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 сек (!!!) • Переключаемся обратно на прошлый стабильный билд • Снова смотрим в дашборд
- 48. Узкие места, проблемы и методы их решения Есть некоторые нюансы... • При работе с большими тарболами(> 100 MB) надо использовать pv для затормаживания диска (Ex: cat filename | pv -L limit_rate_speed -rt | tar -xmzf - -C folder_full_path) • Все операции должны быть атомарные • Шардинг серверов с обновлениями • Не пользоваться базой данных в демоне обновления