Доклад о том, почему практика в области поставки продукта не совпадает с теорией и как я с этим бодался на примере iFunny.

2. План
1. Теория и реальность
2. Выбор системы
3. Наш путь

3. Немного о нас
● Продукт iFunny как флагман компании
● Целевая аудитория - США и Бразилия
● 4 миллиона DAU в сутки
● Инфраструктура на AWS
● API-монолит, требующий частых
деплоев…
● ...и множество вспомогательных сервисов

4. Buzzwords
1. Jenkins
2. no-Jenkins
3. Docker Compose
4. Terraform
5. Amazon ECS

6. О чем говорится в Библии
● Быстрые и небольшие изменения
● Версионирование процесса
● Понятный визуализированный pipeline
● Релиз в production по кнопке
● Триггер сборок по зависимостям

7. На деле
● Огромный git merge и плачевный исход
● Описание сборки только в GUI
● Процесс сборки/тестирования - черный ящик
● Нет кнопки “deploy” (вообще!)
…
● Но с зависимостями все хорошо
○ Хотя и не везде

8. И это еще не все
● 80% решений - платные
● Лимиты по concurrency-билдам
● Перебои в нужный момент

9. Чего не хватает?
● Культуры разработки
● Тестов
● Автоматизации
● Идемпотентности и стабильности
● Времени

10. Понятие CI Theatre
● Наличие CI-сервера = Continuous Integration
● Долгоживущие ветки → Страх во время merge
● Комментировать тесты, чтобы билд прошел
● Неразборчивость в терминах в принципе
● Ответственность на “релиз-инженерах”

12. Что было раньше
● Лицензия Bamboo на 5 агентов
● Как следствие, очередь из билдов
● Небольшой configuration drift
● Проблемы с автоматизацией процессов
● Продукт потерял актуальность

13. Выбор новой системы

14. Минус ограничения и стоимость SAAS

15. Минус платные агенты

16. Минус зависимость от стека технологий

17. Минус трамвай из буханки хлеба

18. Как следствие

20. Артефакт поставки: было
● Деплой API в ZIP-архиве
● 40% деплоя в rpm
● 50% деплоя в контейнерах

21. Артефакт поставки: проблемы
● А как деплоить новый сервис X?
● Недо-автоматизация процессов
● Segmentation faults из-за обновления opcache в PHP

22. Артефакт поставки: стало
Все в сад контейнеры
● Стандартизация сборки и поставки
● Гибкость разработки
● Простота и понятность
● Масштабируемость сервиса

23. Тесты API: было
Dev-сервера с базами данных
● Зависимость от тестовых данных
● Быстрое захламление данными
● Долгое время выполнения тестов

24. Тесты API: стало
Docker-compose с контейнерами БД
● Быстрый старт тестирования
● Независимость от платформы
● Сокращение времени pipeline с 30
до 10 минут
...однако есть проблема с concurrency

25. Docker-Compose + Jenkins: реализация
● Поднимаем новые ноды перед тестами
● Тэггируем их именем билда
● Инициализируем compose-окружение
● Накатываем тестовые данные
● Параллельно прогоняем пакеты тестов
● Убиваем compose-окружение
● Снимаем тег для использования в последующих билдах

26. Инструментарий деплоя: было
● Часть сервисов на Ansible + IPtables + conntrack
● Часть сервисов на Amazon Elastic Beanstalk
● Что-то вообще деплоили руками
○ со временем завернули в Ansible

27. Инструментарий деплоя: проблемы
Ansible + IPtables + Conntrack
● Некорректная обработка unreachable-хостов
● Пятисотки от Docker API
● Нельзя остановить деплой
● Отсутствие параллелизации внутри одного хоста
Beanstalk
● Медленный деплой
● Множество ограничений и подводных камней
● Неуместные CloudFormation-стеки

28. Главная проблема остается
А как деплоить новый сервис X?

29. Инструментарий деплоя: стало
Amazon Elastic Container Service

30. ECS: базовые концепции
● Cluster → Service → Task
● Task Definition в JSON
● ECS-агент для контроля хостов
● Application Load Balancer для контроля трафика
● Task placement strategy для распределения контейнеров
● Min/max healthy percentage для конфигурации деплоя
● Autoscaling задач по Cloudwatch alarms

31. ECS: текущее состояние
● 5 кластеров
● 18 сервисов
● 100-150 контейнеров

32. Проблемы текущего подхода
● Подводные камни в
масштабировании
● Отсутствие Service Discovery
● Отсутствие инструмента деплоя от
Amazon
○ Альтернатива - ecs-deploy

33. Чем помогает Jenkins
● Автоматизация инициализации агентов
(EC2 plugin)
● Описание pipeline в коде (Groovy)
● Большая база плагинов
● Отсутствие ограничений по concurrency-
билдам
● Open-source software как экономия
● Потрясная интеграция с Github

34. Чем не помогает Jenkins
● Нельзя строить интеграцию с ECS и
Beanstalk в pipeline
● Концепции билда и деплоя не разделены

35. Чем вредит Jenkins
● Бесконечные апдейты бесконечного числа
плагинов
● Подводные камни в Groovy
● Отсутствие обработки ошибок плагинов
● Периодические аномалии, за которые
стыдно
○ решается рестартом

36. Выводы
● Релиз-инжиниринг - задача из разряда “сделай сам”
● Легко наступить в “культ карго” - сложно выбраться
● Сложность delivery-pipeline и вашего приложения коррелируются
● Однако все это очень интересно

37. https://myopsblog.wordpress.com/
https://www.facebook.com/mchinkov
michael.chinkov@gmail.com
https://www.slideshare.net/MikhailChinkov