Тезисы

Одним из важных элементов процесса Continuous Delivery, построенного с использованием Docker, является сборка Docker-образов. На первый взгляд задача кажется тривиальной, а синтаксис Dockerfile — простым и понятным.

Но что, если вы используете микросервисную архитектуру и вам необходимо собирать сотни или даже тысячи образов каждый день? А если вам нужно исправить срочный баг на production, готовы ли вы ждать лишние минуты, пока будет произведена сборка?

Даже небольшие команды, не ведущие параллельную разработку десятков проектов, на практике сталкиваются с проблемами, не имеющими очевидных решений.
- Как собирать несколько образов для одного проекта (например, разные образы для frontend и backend)?
- Как уменьшить среднее время сборки до нескольких секунд?
- Как правильно исключить из образа лишнюю информацию, сделав его легким? Например, как исключить из образа nodejs, который требуется для компиляции ассетов? Dev-библиотеки, требующиеся для компиляции приложения на Си++?
- Как вести распределенную сборку, используя при этом общий кэш? Или собирать Docker-образы для разных бранчей одного проекта, корректно используя общий кэш?
- Как переиспользовать код сборки между несколькими проектами?
- Как вести совместную разработку?

В этом докладе я расскажу о том, как мы решили обозначенные проблемы и почему считаем, что существующие возможности Dockerfile (и docker build) плохо подходят для сборки образов для CI/CD.

Чем быстрее и чем эффективнее происходит процесс сборки, тем чаще можно собирать и чаще тестировать, тем быстрее можно выкатывать и тем дольше можно хранить историю.