Это вторая публикация, созданная по мотивам моих выступлений на конференциях. Первая была общей и посвящена обзору практик Continuous Delivery с Docker. Новая основана на более прикладном докладе «Собираем Docker-образы быстро и удобно», который прозвучал 8 ноября на конференции HighLoad++ 2016 в секции «DevOps и эксплуатация».
Как и в прошлый раз, если у вас есть возможность потратить ~час на видео, рекомендуем посмотреть его полностью (см. в конце статьи). В ином случае — представляем основную суть в текстовом виде.
Наши требования в контексте процессов CI/CD (Continuous Integration, Continuous Delivery и Continuous Deployment) таковы:
Для соответствия этим требованиям стандартного механизма Docker — Dockerfile — оказывается недостаточно. У авторов Docker есть официальные тому причины, которые приняты в проекте в качестве основополагающих и весьма логичных принципов, таких как нацеленность на решение общих (а не частных) проблем и высокий уровень портируемости.
Поэтому мы написали свою утилиту — dapp (на Ruby, распространяется под MIT License). На данном этапе она умеет заниматься только сборкой образов, а в планах её развития — поддержка полного цикла CI/CD. При проектировании и реализации dapp отдано предпочтение простоте использования и быстроте/эффективности.
Обновлено 13 августа 2019 г.: в настоящее время проект dapp переименован в werf, его код полностью переписан на Go, а документация значительно улучшена.
Конфигурация для образов, собираемых с dapp, описывается в Dappfile по принципу Один репозиторий → Один проект → Один Dappfile. Форматом этого файла на данный момент является Ruby DSL, но мы планируем перейти на более простой и привычный YAML.
Какие же возможности приносит dapp?
В dapp реализован паттерн с четырьмя стадиями сборки Docker-образа:
Результаты выполнения этих стадий кэшируются, что приводит к значительному росту скорости повторных сборок образа.
Для контейнеров в момент сборки доступен так называемый «внешний контекст» — это монтируемые каталоги, которые используются в момент сборки, но исключаются из конечного образа. В этих каталогах можно сохранять информацию и использовать её при следующих сборках.
Пример использования — каталог /var/lib/apt: его содержимое после выполнения apt-get update необходимо и для следующих сборок, но не нужно внутри самого образа (дополнительный объём данных).
Поддержка изменений из Git тоже сделана в соответствии с идеями оптимизации и гибкости. При первой сборке образа в него добавляются все исходники приложения (git archive), а при последующих — только дельты, т.е. Git-патчи (git patch apply). Содержимое патчей кэшируется для лучшей производительности.
Предусмотрена возможность указать файлы/директории, в случае изменения которых необходимо выполнять стадию install.
Порой для сборки проекта («компиляции» каких-то его компонентов) требуются большие сторонние инструменты, которые конечным приложением потом не используются (т.е. хранить в образе не нужно). Это относится не только к сборке исходников на языках типа Си, но и, например, генерации ассетов с помощью Node.js. Проблема реализована с помощью так называемых «артефактов». При выполнении команды dapp build создаётся дополнительный Docker-образ с артефактом (т.е. сторонним инструментом, требуемым для сборки образа). Файлы этого артефакта добавляются в реальный (конечный) образ из дополнительного с помощью внешнего контекста. Для артефактов тоже поддерживается кэш.
Модульность при сборке образов приносит значительную пользу, но её реализация в рамках shell (Bash) — неблагодарное занятие. Зато она прекрасно сделана в системах управления конфигурациями: Chef → Berkshelf, Puppet → Librarian… Мы используем Chef, поэтому добавили его поддержку в dapp. Эта поддержка означает возможность выполнять рецепты внутри создаваемого Docker-образа.
Технически всё организовано так, что в специальный каталог внутри Git-репозитория (.dapp_chef) помещается Chef cookbook. При выполнении команды dapp build всё необходимое собирается в директорию, монтируемую внутрь Docker-контейнера. Дополнительно в контейнер монтируется и полностью установленный Chef (chefdk). Далее запускается Chef, который настраивает контейнер по cookbook. Полученный в итоге образ настроен по рецептам, но не содержит ни chefdk, ни cookbook.
Принятый в Dappfile формат позволяет описывать сразу множество образов в одном файле.
Мы используем и развиваем dapp уже почти 2 года и действительно хотим сделать из него полезное Open Source-решение, которое будет помогать вам настраивать свои процессы CI/CD и решать сопутствующие задачи. Напоминаем, что исходный код доступен на GitHub, там же с радостью принимаются issues и pull requests. Документация доступна здесь.
Для dapp мы ищем уникального энтузиаста, который мечтает стать технологическим евангелистом. Если у вас есть реальный интерес в подобных инструментах, опыт в DevOps, управлении проектами и написании грамотных технических текстов — не откладывайте в долгий ящик и обязательно напишите нам на info@flant.ru.
Видео с выступления (около часа) опубликовано в YouTube (по ссылке воспроизведение начинается с 13-й минуты, где прекратились технические проблемы с микрофоном и завершена вводная часть, повторяющая общий доклад по CI).
Презентация доклада:
Другие доклады по теме в нашем блоге:
Как и в прошлый раз, если у вас есть возможность потратить ~час на видео, рекомендуем посмотреть его полностью (см. в конце статьи). В ином случае — представляем основную суть в текстовом виде.
Что мы хотим от Docker-образов?
Наши требования в контексте процессов CI/CD (Continuous Integration, Continuous Delivery и Continuous Deployment) таковы:
- Компактный объём. Причина — в рамках CD нужно собирать очень часто и много (каждый коммит), что уже в скором времени может привести к потребности в огромных хранилищах. Мы приняли у себя норму образа в <200 Мб (базовый образ с системой Ubuntu занимает 130 Мб).
- При коммите объёмом в 10 Кб мы хотим видеть аналогичное прибавление в размере образа, а не добавленную полную величину образа.
- Быстрая сборка образов — за 10 секунд.
- Возможность использования сгенерированных образов как конечного продукта для разных площадок (от тестовых до production).
dapp вместо Dockerfile
Для соответствия этим требованиям стандартного механизма Docker — Dockerfile — оказывается недостаточно. У авторов Docker есть официальные тому причины, которые приняты в проекте в качестве основополагающих и весьма логичных принципов, таких как нацеленность на решение общих (а не частных) проблем и высокий уровень портируемости.
Поэтому мы написали свою утилиту — dapp (на Ruby, распространяется под MIT License). На данном этапе она умеет заниматься только сборкой образов, а в планах её развития — поддержка полного цикла CI/CD. При проектировании и реализации dapp отдано предпочтение простоте использования и быстроте/эффективности.
Обновлено 13 августа 2019 г.: в настоящее время проект dapp переименован в werf, его код полностью переписан на Go, а документация значительно улучшена.
Конфигурация для образов, собираемых с dapp, описывается в Dappfile по принципу Один репозиторий → Один проект → Один Dappfile. Форматом этого файла на данный момент является Ruby DSL, но мы планируем перейти на более простой и привычный YAML.
Какие же возможности приносит dapp?
1. Стадии и кэш
В dapp реализован паттерн с четырьмя стадиями сборки Docker-образа:
- before_install: настройки ОС и т.п., на что (по итогам нашего анализа десятков разных проектов) приходится <1% коммитов;
- install: прикладные зависимости — около 5% коммитов;
- before_setup;
- setup: конфиги — около 2%.
Результаты выполнения этих стадий кэшируются, что приводит к значительному росту скорости повторных сборок образа.
2. Внешний контекст
Для контейнеров в момент сборки доступен так называемый «внешний контекст» — это монтируемые каталоги, которые используются в момент сборки, но исключаются из конечного образа. В этих каталогах можно сохранять информацию и использовать её при следующих сборках.
Пример использования — каталог /var/lib/apt: его содержимое после выполнения apt-get update необходимо и для следующих сборок, но не нужно внутри самого образа (дополнительный объём данных).
3. Git
Поддержка изменений из Git тоже сделана в соответствии с идеями оптимизации и гибкости. При первой сборке образа в него добавляются все исходники приложения (git archive), а при последующих — только дельты, т.е. Git-патчи (git patch apply). Содержимое патчей кэшируется для лучшей производительности.
Предусмотрена возможность указать файлы/директории, в случае изменения которых необходимо выполнять стадию install.
4. Артефакты
Порой для сборки проекта («компиляции» каких-то его компонентов) требуются большие сторонние инструменты, которые конечным приложением потом не используются (т.е. хранить в образе не нужно). Это относится не только к сборке исходников на языках типа Си, но и, например, генерации ассетов с помощью Node.js. Проблема реализована с помощью так называемых «артефактов». При выполнении команды dapp build создаётся дополнительный Docker-образ с артефактом (т.е. сторонним инструментом, требуемым для сборки образа). Файлы этого артефакта добавляются в реальный (конечный) образ из дополнительного с помощью внешнего контекста. Для артефактов тоже поддерживается кэш.
5. Поддержка Chef
Модульность при сборке образов приносит значительную пользу, но её реализация в рамках shell (Bash) — неблагодарное занятие. Зато она прекрасно сделана в системах управления конфигурациями: Chef → Berkshelf, Puppet → Librarian… Мы используем Chef, поэтому добавили его поддержку в dapp. Эта поддержка означает возможность выполнять рецепты внутри создаваемого Docker-образа.
Технически всё организовано так, что в специальный каталог внутри Git-репозитория (.dapp_chef) помещается Chef cookbook. При выполнении команды dapp build всё необходимое собирается в директорию, монтируемую внутрь Docker-контейнера. Дополнительно в контейнер монтируется и полностью установленный Chef (chefdk). Далее запускается Chef, который настраивает контейнер по cookbook. Полученный в итоге образ настроен по рецептам, но не содержит ни chefdk, ни cookbook.
6. Несколько образов
Принятый в Dappfile формат позволяет описывать сразу множество образов в одном файле.
dapp как Open Source
Мы используем и развиваем dapp уже почти 2 года и действительно хотим сделать из него полезное Open Source-решение, которое будет помогать вам настраивать свои процессы CI/CD и решать сопутствующие задачи. Напоминаем, что исходный код доступен на GitHub, там же с радостью принимаются issues и pull requests. Документация доступна здесь.
Кстати, у нас есть работа!
Для dapp мы ищем уникального энтузиаста, который мечтает стать технологическим евангелистом. Если у вас есть реальный интерес в подобных инструментах, опыт в DevOps, управлении проектами и написании грамотных технических текстов — не откладывайте в долгий ящик и обязательно напишите нам на info@flant.ru.
Видео и слайды
Видео с выступления (около часа) опубликовано в YouTube (по ссылке воспроизведение начинается с 13-й минуты, где прекратились технические проблемы с микрофоном и завершена вводная часть, повторяющая общий доклад по CI).
Презентация доклада:
P.S.
Другие доклады по теме в нашем блоге:
- «werf — наш инструмент для CI/CD в Kubernetes (обзор и видео доклада)» (Дмитрий Столяров; 27 мая 2019 на DevOpsConf);
- «Базы данных и Kubernetes» (Дмитрий Столяров; 8 ноября 2018 на HighLoad++);
- «Лучшие практики CI/CD с Kubernetes и GitLab» (Дмитрий Столяров; 7 ноября 2017 на HighLoad++);
- «Наш опыт с Kubernetes в небольших проектах» (Дмитрий Столяров; 6 июня 2017 на RootConf).
