Официально представляем dapp — DevOps-утилиту для сопровождения CI/CD

    Читатели этого блога, а также посетители последних HighLoad++ и РИТ++ с большой вероятностью уже слышали про нашу утилиту для DevOps-инженеров dapp, но теперь мы решили официально и окончательно представить её «большому миру». Формальное право на то нам даёт тот факт, что мы работаем с dapp для решения задач в production уже больше года, поэтому считаем, что технология созрела для более массового использования.



    Итак, dapp — написанный на Ruby инструмент, созданный в компании «Флант» как Open Source-проект для реализации и сопровождения процессов CI/CD. Что он позволяет?

    Сборка образов


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

    1. четыре стадии сборки образа (before_install, install, before_setup, setup), результаты выполнения которых кэшируются (даёт значительный рост в скорости повторных сборок образа);
    2. «внешний контекст» для монтирования каталогов, используемых во время сборок, но исключаемых из конечного образа;
    3. продуманная работа с Git, добавляющая в образ только дельты (git patch apply) при новых сборках и кэширующая содержимое этих патчей;
    4. «артефакты» — возможность использования сторонних инструментов на этапе сборки проекта, но не включать их в финальный образ; для артефактов тоже поддерживается кэш (с недавним выпуском Docker 17.06 эта фича перестала быть столь значимой из-за появления multi-stage builds);
    5. поддержка Chef, позволяющая настраивать системы в Docker-образах по рецептам (cookbooks).

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

    Деплой в Kubernetes


    Зато мы продвинулись в другом важном направлении — расширении возможностей dapp за рамками сборки образов, в области других составляющих процессов непрерывной интеграции и доставки приложений. Начальная поддержка деплоя в dapp ознаменовала возможность интеграции с системой Kubernetes, используемой нами для оркестровки контейнеров (подробнее мы недавно рассказывали: «Наш опыт с Kubernetes в небольших проектах (обзор и видео доклада)»). Суть этой фичи заключается в следующем:

    1. Для Kubernetes готовятся YAML-конфигурации, которые могут быть разными для каждого нужного контура (production, staging, testing…) и которые помещаются в специальный каталог в Git-репозиторий с кодом приложения и инфраструктуры (например: файлы backend.yaml, frontend.yaml, cron.yaml в специальном каталоге .kube/).
    2. Созданные конфигурации отдаются утилите kubectl, которая разворачивает описанную в них инфраструктуру в нужном кластере Kubernetes (опять же, кластеры могут быть разными для каждого контура).
    3. Созданные Docker-образы разворачиваются в инфраструктуре Kubernetes.

    Технически это реализовано с помощью команды dapp kube deploy (см. документацию), которая по своей сути является обёрткой к менеджеру пакетов Kubernetes — Helm, позволяя:

    1. дополнять и расширять возможности передачи параметров в Helm (добавляет секретные значения и файлы, имеет helper для чтения этих файлов в шаблонах);
    2. интегрировать образы, собираемые по Dappfile, в Helm (имеет helper для составления имени образа).

    Примечание: Сам деплой мы делаем через GitLab CI, о чём писали в недавней статье «GitLab CI для непрерывной интеграции и доставки в production»: «Часть 1: наш пайплайн», «Часть 2: преодолевая трудности».

    Дополнительная информация


    Прямо сейчас наш коллега пишет статью-знакомство с dapp (обновлено: читайте «Практика с dapp. Часть 1: Сборка простых приложений»). А пока предлагаю ссылки на уже имеющуюся информацию:

    • упомянутый доклад «Собираем Docker-образы для CI/CD быстро и удобно вместе с dapp (обзор и видео)»: пост и видео с выступления технического директора АО «Флант» Дмитрия Столярова, где и состоялась первая и более «камерная» презентация dapp;
    • официальная техническая документация на русском языке — flant.github.io/dapp;
    • отдельного внимания в этой документации заслуживает инструкция «Первое приложение на dapp»;
    • официальная группа поддержки в Telegramdapp_ru.

    Да, это Open Source!


    Исходный код dapp написан на языке Ruby и опубликован на GitHub под свободной лицензией Apache License 2.0 (она же используется в таких близких нам проектах, как Moby/Docker, Kubernetes, Helm, etcd и других).

    Мы приглашаем DevOps-инженеров и Open Source-энтузиастов, заинтересованных в применении dapp, к участию в проекте. Исследуйте его, задавайте вопросы (можно прямо здесь в комментариях), указывайте на проблемы, предлагайте улучшения. Спасибо за внимание!
    • +26
    • 10,2k
    • 6

    Флант

    272,00

    Специалисты по DevOps и высоким нагрузкам в вебе

    Поделиться публикацией
    Комментарии 6
      0
      Здорово!
      Поздравляю так сказать с официальной презентацией))
        +2
        Интересный инструмент! Скажите, чем обусловлен выбор ruby? Чем он выигрывает у более распространённых python, perl?
          +1

          Как я понимаю, потому что chef, который тоже написан на ruby)

            0
            Лично я без шуток люблю Perl, но всё-таки он действительно отживает своё. Ruby нам нравится (+ имеется хороший опыт с ним у всего отдела разработки), для задачи подходит, а также, как верно угадали в соседнем комментарии, сыграл свою роль Chef, используемый нами для IaC. Хотя сегодня, думаю, писали бы такое уже на Go.
              0
              Вот тоже возник вопрос — почему не Golang. Почему-то вы ориентируетесь на Ruby в Chef, а не на go в docker/helm/kubernetes :) Может быть во второй версии? ;)
                0
                Да, у нас были мысли на этот счёт… Пока только мысли, но как станет больше причин — не сомневаюсь, что материализуются :-)

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое