Хабрахабр

Возможности dapp, которые делают жизнь проще

В статье представлен (и продемонстрирован в коротких видеороликах) инструментарий, облегчающий разработку и отладку конфигураций с dapp — Open Source-утилитой, которую мы ежедневно используем при построении и сопровождении процессов CI/CD.

По умолчанию все описанные далее инструменты будут справедливы как для него, так и для конфигурации в Ruby DSL (используется в предыдущих версиях dapp), а если это не так — указано отдельно. Примечание: Недавно была анонсирована поддержка синтаксиса YAML в dapp, об особенностях которого можно прочитать в этой публикации.

Написание конфигурации на первых шагах усложняется отсутствием понимания того, что содержится в сборочном контейнере при выполнении инструкций.

Каждая стадия собирается в сборочном контейнере, за основу которого берётся образ предыдущей стадии (базовый образ в случае стадии from), а затем сохраняется в Docker-образ, кэш приложения. Сборка приложения и артефакта состоит из набора связанных стадий. Подробнее узнать про природу стадий, их функции, особенности и возможные состояния можно в документации dapp. Все стадии выполняют определённую функцию и связаны с соответствующими директивами в конфигурации.

При интроспекции сборочный контейнер, среда, содержит служебный инструментарий и переменные окружения. В процессе сборки есть возможность получить доступ к определённой стадии, воспользовавшись опциями интроспекции. Его добавление осуществляется монтированием директорий из служебных контейнеров наших дистрибутивов dappdeps (в сборочном контейнере они доступны по пути /.dapp/deps). Инструментарий представляется в виде набора утилит, который необходим на время сборки. Подробнее про идею этих дистрибутивов, процесс их сборки и состав можно почитать в статье про dappdeps.

Такой подход может быть полезен, когда поставленная задача ясна, но шаги для её решения не очевидны и требуют экспериментов. При разработке интроспекция позволяет прийти к необходимому результату в сборочном контейнере, а затем перенести все шаги, инструкции, в конфигурацию соответствующей стадии.

Процесс написания конфигурации в режиме интроспекции (на примере приложения symfony-demo) продемонстрирован в этом видео:

При отладке интроспекция позволяет посмотреть, почему сборка завершилась с ошибкой или результат не соответствует ожиданиям, проверить наличие зависимых файлов, состояние системы:

в этой статье) появляется возможность отладки Ansible playbooks в сборочном контейнере с последующим переносом Ansible-задач в соответствующие стадии конфигурации: Наконец, при использовании интроспекции с Ansible-сборщиком (подробнее о поддержке Ansible в dapp см.

При сборке поддерживаются следующие опции интроспекции:

# интроспекция до и после выполнения проблемного набора инструкций
dapp dimg build --introspect-error dapp dimg build --introspect-before-error # интроспекция собранной стадии STAGE
dapp dimg build --introspect-stage STAGE
dapp dimg build --introspect-artifact-stage STAGE # интроспекция до выполнения инструкций стадии STAGE
dapp dimg build --introspect-before STAGE
dapp dimg build --introspect-artifact-before STAGE

По аналогии с монтированием рабочей директории при сборке Dockerfile хочется работать с текущим состоянием локального репозитория. При разработке конфигурации в стандартном режиме сборки требуются формальные коммиты для того, чтобы dapp учитывал изменения в файлах при сборке.

Если быть точным, учитываются пути из следующих поддиректив git: add, includePaths, excludePaths, stageDependencies. Эта концепция реализована в dev-режиме сборки: при сборке учитываются некоммитнутые изменения локального Git-репозитория, соответствующие конфигурации.

При добавлении git-submodules и вложенных Git-репозиториев учитываются файлы .gitignore на всех уровнях.

dapp dimg build --dev # удаление dev-кэша стадий всех проектов
dapp dimg mrproper --improper-dev-mode-cache

Любое изменение инструкций приводит к пересборке соответствующей стадии со всеми инструкциями. Стадии before_install, install, before_setup, setup зависят от соответствующих инструкций в конфигурации. Таким образом, при тяжеловесных, требовательных ко времени, инструкциях разработка может затянуться.

Помимо того, что сборку необходимо выполнять заново, нет возможности получить состояние среды до упавшей инструкции, проверить корректность выполнения предыдущих. Добавим ко всему этому ситуацию, когда при выполнении команд сборка падает на одной из последних инструкций стадии.

При сборке инструкции кэшируются по отдельности, а пересборка осуществляется только при изменении их порядка. Для удобства разработки и отладки была введена директива asLayers, которая указывается для конкретного приложения или его артефакта в конфигурации (dappfile.yaml).

один Docker-образ на все инструкции стадии, а если указать asLayers: true, то включится новый режим кэширования — один Docker-образ на одну команду для shell или один task для Ansible. При отсутствии директивы asLayers (или в случае asLayers: false) используется кэширование по умолчанию, т.е.

После того, как сборочные инструкции отлажены, asLayers необходимо выключить. Переключение между режимами сборки регулируется только директивой asLayers — остальные инструкции конфигурации остаются неизменными. Видеодемонстрация использования asLayers в dapp:

При использовании опций интроспекции --introspect-error и --introspect-before-error пользователь может получить среду до или после выполнения проблемной инструкции. Директива asLayers позволяет кэшировать инструкции по отдельности.

Важные примечания:

  • Новые возможности dapp реализуются только в YAML-конфигурации, поэтому asLayers уже не поддерживается в вариантах с Ruby DSL.
  • Важно не пользоваться этой инструкцией при штатной сборке образов: данный режим порождает избыточное количество Docker-образов и не рассчитан на инкрементальную сборку (т.к. увеличивается время ожидания и размер сборочного кэша).

В то же время это Open Source-проект, и мы рады также видеть issues и от сторонних пользователей, сценарии работы которых могут отличаться от нашего опыта. Поскольку dapp остаётся одним из главных инструментов в ежедневной работе наших DevOps-инженеров, мы имеем высокую мотивацию делать его по-настоящему удобным, удовлетворяя все их потребности. Также готовы ответить на любые ваши вопросы по использованию dapp в комментариях к этой статье — welcome!

Читайте также в нашем блоге:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть