Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Релиз инжиниринг Mail.ru, взгляд изнутри / Максим Глеков (Mail.Ru Group)

556 views

Published on

В нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?

Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.

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

Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Релиз инжиниринг Mail.ru, взгляд изнутри / Максим Глеков (Mail.Ru Group)

  1. 1. Релиз инжиниринг Mail.ru, взгляд изнутри Глеков Максим программист-разработчик почтовой службы • v4
  2. 2. Организация работы релиз-инженеров • Стоит ли брать что-то готовое? • Сборка релиза • Раздача релиза • Демон обновлений • Тестовые сервера • Выкладка на бой • Мониторинг • Узкие места ПОСЛЕ ЧЕГО ОТВЕЧУ НА ВСЕ ВАШИ ВОПРОСЫ И ДАМ ТЕХНИЧЕСКИЕ РЕКОМЕНДАЦИИ О чем доклад ?
  3. 3. Организация работы верстальщика
  4. 4. Организация работы релиз-инженера
  5. 5. Может быть есть что-то готовое? Что выбрать? • Git pull на продакшне :)
  6. 6. Может быть есть что-то готовое? Что выбрать? • Git pull на продакшне :) • Fabric (python)
  7. 7. Может быть есть что-то готовое? Что выбрать? • Git pull на продакшне :) • Fabric (python) • Capistrano (ruby)
  8. 8. Почему мы написали свою систему? Все сложно • Безопасность • Быстрые фиксы багов • Минимальные зависимости
  9. 9. Комманды для управления Какие нужны и зачем? • risk-deploy-create — создать релиз • risk-deploy-push — положить релиз на группу серверов • risk-deploy-switch — переключить группу серверов • risk-deploy-clean — удалить релиз с группы серверов
  10. 10. Сборка релиза Последовательность действий в раскладчике
  11. 11. Проверка конситентности сборки Md5sum — то, что нам надо • файл с контрольными суммами • Проверка консистентности сборки: md5sum -c имя_файла_с_суммами • «дешевый» способ» — измерение размера всей сборки • «дешевый способ» только для мониторинга!
  12. 12. Тарболы практика Где же все-таки удобнее использовать тарболы? • Нет root-доступа • Разные дистрибутивы Linux • Еще хуже -— Windows • Маленькие репозитории • Раскладки на тестовые сервера
  13. 13. Тарболы практика Где же все-таки удобнее использовать тарболы? • Нет root-доступа • Разные дистрибутивы Linux • Еще хуже — Windows • Маленькие репозитории • Раскладки на тестовые сервера
  14. 14. SquashFs самое оптимальное? SquashFs — отличное решение для выкатки боевых релизов • Сжимающая файловая система gzip/lzma • Применяется во встраиваемых системах
  15. 15. SquashFs самое оптимальное? SquashFs — отличное решение для выкатки боевых релизов • Сжимающая файловая система gzip/lzma • Применяется во встраиваемых системах • роутеры • квадрокоптеры • холодильники • кофеварки
  16. 16. SquashFs самое оптимальное? SquashFs — отличное решение для выкатки боевых релизов • Сжимающая файловая система gzip/lzma • Применяется во встраиваемых системах • роутеры • кофеварки • холодильники • квадрокоптеры • Просто собрать: mksquashfs data_dir sqsh_file_path.sqsh
  17. 17. SquashFs самое оптимальное? SquashFs — минусы • Одна и та же версия SquashFs • Одно и то же сжатие gzip или lzma • Для монтирования требуются root-права
  18. 18. Почему не RPM + puppet? RPM или DEB — неплохое решение • Требуется писать spec файлы • Просто собирать: rpmbuild -bb имя_спеки • Все фаилы в одном пакете • Не засоряет систему • RPM → DEB с помощью alien
  19. 19. Почему не RPM + puppet? RPM или DEB — минусы • Для установки требуются root-права • Нужно привлекать админа • Проблемы с накати/откати в выходной/ночью
  20. 20. Что выбрали мы? Вроде бы все очевидно.... • Мы катим в среднем 3 раза в день • Для выкатки пакуем все файлы • Тарболы только для тестовых серверов • В продакшне SquashFS • RPM на проектах с редкими выкатками (Ответы@Mail.ru, Календарь@Mail.ru)
  21. 21. Схема обновления обновлений дифами Плохой вариант для production • Выкатки не консистентны • Откатиться полноценно назад трудно • Непонятно чем закончится исправление ошибки • Подходит только для тестовых серверов
  22. 22. Раздача релиза Хранилище релизов
  23. 23. Раздача релиза Сущности внутри репозитория • Кикстарт — файл с текущей сборкой • deploy_files.list — файл со списком сборок
  24. 24. Раздача релиза Выкладываем на группу серверов в тест • risk-deploy-push -b alphatest -f e.mail.ru-f-alpha-505-en-m.glekov-1427105421
  25. 25. Раздача релиза Выкладываем на группу серверов в тест
  26. 26. Раздача релиза Схема раздачи
  27. 27. Раздача релиза Но есть проблема.... • Узкое место — получение обновлений с одного источника
  28. 28. Раздача релиза Простое решение - шардинг • Увеличить количество раздающих серверов
  29. 29. Устройство демона обновлений Get risk — так называется наш демон обновлений
  30. 30. Статика (js,css, images, etc) Шаблоны отдельно, статика отдельно — надо делать две отдельные сборки!
  31. 31. Выкладка релиза на тестовые серверы Тестовые серверы, плавающий DOCUMENT_ROOT • DOCUMENT_ROOT сервера — директория с шаблонами • На серверах, где нет веток, DOCUMENT_ROOT один • На серверах с ветками каждая ветка — новый DOCUMENT_ROOT • Переключение DOCUMENT_ROOT в backend регулярным выражением
  32. 32. Выкладка релиза на тестовые серверы FUSE (Filesystem on Userspace) для веток • Храним только различающиеся файлы • Недостающие файлы берем из корневой ветки
  33. 33. Выкладка релиза на тестовые серверы FUSE для веток
  34. 34. Выкладка релиза на тестовые серверы FUSE для веток
  35. 35. Выкладка релиза на тестовые серверы FUSE для веток
  36. 36. Выкладка релиза на тестовые серверы FUSE для веток
  37. 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. 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. 39. Мониторинг Get Risk Network Monitoring или просто grnmon ;)
  40. 40. Мониторинг Get Risk Network Monitoring
  41. 41. Мониторинг Get Risk Network Monitoring
  42. 42. Как устроен мониторинг Get Risk Network Monitoring • Как работает мониторинг? • Демон grnmon — принимает данные с серверов • MySQL — хранение данных для старта • Memcached — чтобы не мучить базу • Fcgi — отдача jsonp из Memcached • JavaScript — отображение данных
  43. 43. Переключаем сервера между билдами Накати — первый этап • risk-deploy-switch -b alphatest -f e.mail.ru-f-alpha-505-en-m.glekov-1427105421 • Время переключения между билдами от 2-5 секунд (!!!!)
  44. 44. Дашборд Или как мы понимаем, что все хорошо
  45. 45. Что-то пошло не так....
  46. 46. Быстрый откат в случае неудачи Сколько времени надо, чтобы откатиться? • Не более 2-5 сек (!!!) • Переключаемся обратно на прошлый стабильный билд • Снова смотрим в дашборд
  47. 47. Запуск тестов Несколько советов
  48. 48. Узкие места, проблемы и методы их решения Есть некоторые нюансы... • При работе с большими тарболами(> 100 MB) надо использовать pv для затормаживания диска (Ex: cat filename | pv -L limit_rate_speed -rt | tar -xmzf - -C folder_full_path) • Все операции должны быть атомарные • Шардинг серверов с обновлениями • Не пользоваться базой данных в демоне обновления
  49. 49. СПАСИБО ЗА ВНИМАНИЕ! Вопросы? m.glekov@corp.mail.ru

×