Открыть список
Как стать автором
Обновить
Флант
DevOps-as-a-Service, Kubernetes, обслуживание 24×7

Собираем Docker-образы для CI/CD быстро и удобно вместе с dapp (обзор и видео)

Блог компании ФлантСистемное администрированиеDevOps
Это вторая публикация, созданная по мотивам моих выступлений на конференциях. Первая была общей и посвящена обзору практик Continuous Delivery с Docker. Новая основана на более прикладном докладе «Собираем Docker-образы быстро и удобно», который прозвучал 8 ноября на конференции HighLoad++ 2016 в секции «DevOps и эксплуатация».



Как и в прошлый раз, если у вас есть возможность потратить ~час на видео, рекомендуем посмотреть его полностью (см. в конце статьи). В ином случае — представляем основную суть в текстовом виде.

Что мы хотим от Docker-образов?


Наши требования в контексте процессов CI/CD (Continuous Integration, Continuous Delivery и Continuous Deployment) таковы:

  1. Компактный объём. Причина — в рамках CD нужно собирать очень часто и много (каждый коммит), что уже в скором времени может привести к потребности в огромных хранилищах. Мы приняли у себя норму образа в <200 Мб (базовый образ с системой Ubuntu занимает 130 Мб).
  2. При коммите объёмом в 10 Кб мы хотим видеть аналогичное прибавление в размере образа, а не добавленную полную величину образа.
  3. Быстрая сборка образов — за 10 секунд.
  4. Возможность использования сгенерированных образов как конечного продукта для разных площадок (от тестовых до 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-образа:

  1. before_install: настройки ОС и т.п., на что (по итогам нашего анализа десятков разных проектов) приходится <1% коммитов;
  2. install: прикладные зависимости — около 5% коммитов;
  3. before_setup;
  4. 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.


Другие доклады по теме в нашем блоге:

Теги:devopsdockerфлантdappcontinuous deliveryдеплойwerf
Хабы: Блог компании Флант Системное администрирование DevOps
Всего голосов 16: ↑15 и ↓1 +14
Просмотры23.7K

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
flant.ru
Численность
101–200 человек
Дата регистрации
Представитель
Дмитрий Шурупов

Блог на Хабре