- PVSM.RU - https://www.pvsm.ru -
Это вторая публикация, созданная по мотивам моих выступлений на конференциях. Первая была общей и посвящена обзору практик Continuous Delivery с Docker [1]. Новая основана на более прикладном докладе «Собираем Docker-образы быстро и удобно», который прозвучал 8 ноября на конференции HighLoad++ 2016 [2] в секции «DevOps и эксплуатация».
Как и в прошлый раз, если у вас есть возможность потратить ~час на видео, рекомендуем посмотреть его полностью (см. в конце статьи). В ином случае — представляем основную суть в текстовом виде.
Наши требования в контексте процессов CI/CD (Continuous Integration, Continuous Delivery и Continuous Deployment) таковы:
Для соответствия этим требованиям стандартного механизма Docker — Dockerfile — оказывается недостаточно. У авторов Docker есть официальные тому причины, которые приняты в проекте в качестве основополагающих и весьма логичных принципов, таких как нацеленность на решение общих (а не частных) проблем и высокий уровень портируемости.
Поэтому мы написали свою утилиту — dapp [3] (на Ruby, распространяется под MIT License). На данном этапе она умеет заниматься только сборкой образов, а в планах её развития — поддержка полного цикла CI/CD. При проектировании и реализации dapp отдано предпочтение простоте использования и быстроте/эффективности.
Конфигурация для образов, собираемых с 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 [3], там же с радостью принимаются issues [4] и pull requests [5]. Документация по dapp на русском языке доступна здесь [6].
Для dapp мы ищем уникального энтузиаста, который мечтает стать технологическим евангелистом. Если у вас есть реальный интерес в подобных инструментах, опыт в DevOps, управлении проектами и написании грамотных технических текстов — не откладывайте в долгий ящик и обязательно напишите нам на info@flant.ru.
Видео с выступления (около часа) опубликовано в YouTube [7] (по ссылке воспроизведение начинается с 13-й минуты, где прекратились технические проблемы с микрофоном и завершена вводная часть, повторяющая общий доклад по CI [1]).
Презентация доклада:
Автор: Флант
Источник [8]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/251059
Ссылки в тексте:
[1] практик Continuous Delivery с Docker: https://habrahabr.ru/company/flant/blog/322686/
[2] HighLoad++ 2016: http://www.highload.ru/2016/
[3] dapp: https://github.com/flant/dapp
[4] issues: https://github.com/flant/dapp/issues
[5] pull requests: https://github.com/flant/dapp/pulls
[6] здесь: http://flant.github.io/dapp/
[7] опубликовано в YouTube: https://youtu.be/8R5UDg29Vic?t=12m45s
[8] Источник: https://habrahabr.ru/post/324274/
Нажмите здесь для печати.