Релиз-инжениринг Mail.ru. Взгляд изнутри. Максим Глеков, Mail.Ru Group, Москва
0 likes•313 views
Документ представляет собой внутренний обзор практик релиз-инженеринга в компании Mail.ru, включая обсуждение использования инструментов и методов для сборки, раздачи и мониторинга релизов. Основное внимание уделяется переходу от GUI к консоли, использованию squashfs для продакшена и параметрам управления версиями на тестовых серверах. Также рассматриваются узкие места и рекомендации по оптимизации рабочего процесса релиз-инженеров.
Релиз-инжениринг Mail.ru. Взгляд изнутри. Максим Глеков, Mail.Ru Group, Москва
- 1. Релиз инженеринг Mail.ru, взгляд изнутри Глеков Максим программист-разработчик почтовой службы
- 2. Организация работы релиз-инженеров • Консоль или GUI ? • Сборка релиза • Раздача релиза • Демон обновлений • Тестовые сервера • Выкладка в продакшен • Мониторинг • Узкие места ПОСЛЕ ЧЕГО ОТВЕЧУ НА ВСЕ ВАШИ ВОПРОСЫ И ДАМ ТЕХНИЧЕСКИЕ РЕКОМЕНДАЦИИ О чем доклад ?
- 5. Консоль или GUI Что выбрать?
- 7. Консоль или GUI ? True way — только консоль • Инструментарий • putty если вы работает под Windows • ssh-agent для прокидывания ключей • В Linux и Mac OS все есть «из коробки»
- 9. Консоль или GUI Как мы управляем сетью раскладки c консоли? • risk-deploy-create — создать релиз • risk-deploy-push — положить релиз на группу серверов • risk-deploy-switch — переключить группу серверов • risk-deploy-clean — удилить релиз с группы серверов
- 10. Сборка релиза Как это делаем мы • Берем все задачи для итерации • Примерживаем все задачи к итерации • Исправляем конфликты между разными задачами • Запускаем билд релиза risk-deploy-create
- 11. Сборка релиза Последовательность действий в раскладчике
- 12. Проверка конситентности сборки Md5sum — то, что нам надо • фаил с контрольными суммами • Проверка консистентности сборки: md5sum -c имя_фаила_с_суммами • «дешевый» способ» — измерение размера всей сборки • «дешевый способ» только для мониторинга!
- 13. Тарболы практика Где же все-таки удобнее использовать тарболы? • Нет root-доступа • Разные дистрибутивы Linux • Еще хуже - Windows • Маленькие репозитрии • Раскладки на тестовые сервера
- 14. Тарболы практика Где же все-таки удобнее использовать тарболы? • Нет root-доступа • Разные дистрибутивы Linux • Еще хуже - Windows • Маленькие репозитрии • Раскладки на тестовые сервера
- 15. SquashFs самое оптимальное? SquashFs — отличное решение для выкатки боевых релизов • Сжимающая файловая система gzip/lzma • Применяется во встраиваемых системах, где необходимы низкие затраты на производство (роутеры, кофеварки, холодильники, квадрокоптеры) • Просто собрать: mksquashfs data_dir sqsh_file_path.sqsh
- 16. SquashFs самое оптимальное? SquashFs — минусы • Одна и та же версия SquashFs • Одно и тоже сжатие gzip или lzma • Для монтирования требуются root-права
- 17. Почему не RPM + puppet? RPM или DEB — неплохое решение • Требуется писать spec фаилы • Просто собирать: rpmbuild -bb имя_спеки • Все фаилы в одном пакете • Не засоряет систему • RPM → DEB с помощью alien
- 18. Почему не RPM + puppet? RPM или DEB — минусы • Для установки требуются root-права • Нужно привлекать админа • Проблемы с накати/откати в выходной/ночью
- 19. Что выбрали мы? Вроде бы все очевидно.... • Мы катим в среднем 3 раза в день • Для выкатки пакуем все фаилы • Тарболы только для тестовых серверов • В продакшене SquashFS • RPM на проектах с редкими выкатками (Ответы@Mail.ru, Календарь@Mail.ru)
- 20. Схема обновления обновлений дифами Плохой вариант для production • Выкатки не консистентны • Откатиться полноценно назад трудно • Непонятно чем закончится исправление ошибки • Подходит только для тестовых серверов
- 22. Раздача релиза Сущности внутри репозитария • Кикстарт — фаил с текущей сборкой • deploy_files.list — фаил со списком сборок
- 23. Раздача релиза Выкладываем на группу серверов в тест • risk-deploy-push -b alphatest -f e.mail.ru-f-alpha-505- en-m.glekov-1427105421
- 24. Раздача релиза Выкладываем на группу серверов в тест
- 26. Раздача релиза Но есть проблема.... • Узкое место — получение обновлений с одного источника
- 27. Раздача релиза Простое решение - шардинг • Увеличить количество раздающих серверов
- 28. Устройство демона обновлений Get risk — так называется наш демон обновлений
- 29. Статика(js,css, images, etc) Шаблоны отдельно, статика отдельно — надо делать две отдельные сборки!
- 30. Выкладка релиза на тестовые серверы Тестовые серверы, плавающий DOCUMENT_ROOT • DOCUMENT_ROOT сервера — директория с шаблонами • На серверах где нет веток DOCUMENT_ROOT один • На серверах с ветками каждая ветка — новый DOCUMENT_ROOT • Перключение DOCUMENT_ROOT в backend регулярным выражением
- 31. Выкладка релиза на тестовые серверы FUSE (Filesystem on Userspace) для веток • Храним только различающиеся фаилы • Недостающие фаилы берем из корневой ветки
- 32. Выкладка релиза на тестовые серверы FUSE для веток
- 33. Выкладка релиза на тестовые серверы FUSE для веток
- 34. Выкладка релиза на тестовые серверы FUSE для веток
- 35. Хочу себе FUSE! Что можно найти в открытом доступе? • MergeFS (http://bersace03.free.fr/mergefs/mergefs) • UnionFS (http://unionfs.filesystems.org/) • Aufs (http://aufs.sourceforge.net/) • Mhddfs (http://mhddfs.uvw.ru/)
- 36. Выкладываем в продакшен Выкладываем билд, который прошел через тестовые сервера 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
- 37. Мониторинг Get Risk Network Monitoring или просто grnmon ;)
- 38. Мониторинг Get Risk Network Monitoring
- 39. Мониторинг Get Risk Network Monitoring
- 40. Как устроен мониторинг Get Risk Network Monitoring • Как работает мониторинг? • Демон grnmon — принимает данные с серверов • MySQL — хранение данных для старта • Memcached — чтобы не мучать базу • Fcgi — отдача jsonp из Memcached • JavaScript — отображение данных
- 41. Переключаем сервера между билдами Накати — первый этап • risk-deploy-switch -b alphatest -f e.mail.ru-f-alpha- 505-en-m.glekov-1427105421 • Время переключения между билдами от 2-5 секунд (!!!!)
- 42. Дашборд Или как мы понимаем, что все хорошо
- 43. Быстрый откат в случае неудачи Сколько времени надо чтобы откатиться? • Не более 2-5 сек (!!!) • Переключаемся обратно на прошлый стабильный билд • Снова смотрим в дашборд
- 45. Узкие места, проблемы и методы их решения Есть некоторые нюансы... • При работе с большими тарболами(> 100 MB) надо использовать pv для затормаживания диска (Ex: cat filename | pv -L limit_rate_speed -rt | tar -xmzf - -C folder_full_path) • Все операции должны быть атомарные • Шардинг серверов с обновлениями • Не пользоваться базой данных в демоне обновления