werf / werf

A solution for implementing efficient and consistent software delivery to Kubernetes facilitating best practices.

werf is a CNCF Sandbox CLI tool to implement full-cycle CI/CD to Kubernetes easily. werf integrates into your CI system and leverages familiar and reliable technologies, such as Git, Dockerfile, Helm, and Buildah.

What makes werf special:

• Complete application lifecycle management: build and publish container images, test, deploy an application to Kubernetes, distribute release artifacts and clean up the container registry.
• Ease of use: use Dockerfiles and Helm chart for configuration and let werf handle all the rest.
• Advanced features: automatic build caching and content-based tagging, enhanced resource tracking and extra capabilities in Helm, a unique container registry cleanup approach, and more.
• Gluing common technologies: Git, Buildah, Helm, Kubernetes, and your CI system of choice.
• Production-ready: werf has been used in production since 2017; thousands of projects rely on it to build & deploy various apps.

Quickstart

The quickstart guide shows how to set up the deployment of an example application (a cool voting app in our case) using werf.

Installation

The installation guide helps set up and use werf both locally and in your CI system.

Documentation

Detailed usage and reference for werf are available in documentation in multiple languages.

Developers can get all the necessary knowledge about application delivery in Kubernetes (including basic understanding of K8s primitives) in the werf guides. They provide ready-to-use examples for popular frameworks, including Node.js (JavaScript), Spring Boot (Java), Django (Python), Rails (Ruby), and Laravel (PHP).

Community & support

Please feel free to reach developers/maintainers and users via GitHub Discussions for any questions regarding werf.

Your issues are processed carefully if posted to issues at GitHub.

You're also welcome to:

• follow @werf_io to stay informed about all important news, new articles, etc;
• join our Telegram chat for announcements and ongoing talks: werf_io. (There is a Russian-speaking Telegram chat werf_ru as well.)

Contributing

This contributing guide outlines the process to help get your contribution accepted.

License

Apache License 2.0, see LICENSE.

Featured in

werf's Issues

Отдельный файл для описания сборки образов Dimgfile

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

• Избежать использования лишних директив, таких как dimg и dimg_group.
• Упростить конфигурацию.

при условии, что:

• Целью данного проекта является базовый образ, нужный для других проектов.
• В проекте собирается только 1 образ.

Детали реализации
Потенциальная проблема по реализации: все ли глобальные директивы доступны для использования внутри dimg и dimg_group.

Добавить параметр --ssh-key в dapp run

Как пользователь dapp, я хочу иметь возможность запускать команду dapp run с параметром --ssh-key по аналогии с командой dapp build, чтобы получить предсказуемое поведение сборщика вне зависимости от наличия build-кэша.

Переименовать project в dapp в коде dapp

Как разработчик dapp, я хочу чтобы вместо двух сущностей в коде, project и dapp, была только одна сущность dapp, которая бы по сути и являлась проектом, чтобы упростить понимание исходного кода.

Ambiguity in usage parameters for DIMG PATTERN and DIMGS PATTERNS

Также есть ошибки с несоответствием указанных параметров в общем help сообщении и help сообщении для каждой конкретной команды.

См. #16.

How to get git info in the build container

As a developer of an application, which built by the werf, I want to have ability to get application version — git commit, tag or other info — to embed this info into final application image.

Maybe all CI-variables should be forwarded into build container.

Наследование depends_on из dimod'ов

Как релиз-инженер (chef-приложения) я НЕ хочу повторять в каждом Dappfile, который использует некоторый mdapp, конструкцию depends_on. Например, для mdapp’а, который вызывает composer, я НЕ хочу в каждом Dappfile указывать явно зависимость от composer.json.

Заменять директорию в базовом образе пустой директорией

Как релиз-инженер приложения я хочу иметь возможность примонтировать временную директорию или директорию, сохраняющуюся между сборками в сборочный контейнер, при этом в итоговый образ должна попасть пустая директория в указанном mount-point. Например, это уберет из конечного образа “старые” списки пакетов. Пока неизвестны случаи, когда содержимое “поднаготной” директории необходимо сохранить.

Introspect STAGE для артефактов

Как пользователь, я хочу иметь возможность introspect-ить не только стадии приложения, но и артефакта, с целью ускорения процессов написания Dappfile-ов и отладки.

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

При наличии двух dimg средствами introspect нельзя попасть в стейдж второго, но эта проблема может быть решена передачей в dapp build названия dimg. Если у dimg несколько артефактов, то даже если мы сделаем поддержку перехода в stage’и артефактов, не будет возможности попасть сразу в стейдж второго артефакта, пользователь сначала окажется в стейдже первого артефакта, из которого он должен будет вручную “выйти”. Возможным решением обеих проблем мог бы быть переход на некоторые “селекторы”, однако сейчас это выглядит оверкилом.

Отказ от Berksfile и metadata.rb

Как релиз-инженер (chef-приложения), я хочу указывать cookbook'и в Dappfile, чтобы:

• избежать ошибок, связанных с забытыми файлами chef-проекта Berksfile, Berksfile.lock и metadata.rb;
• упростить и повысить понятность описания сборки chef-приложения.

Детали реализации

• metadata.rb — генерируем
• Berksfile — генерируем
• ­от проверки Berksfile.lock — отказываемся
  • Зачем была проверка?
    • Чтобы был закоммичен актуальный Berksfile.lock
    • В Berksfile.lock фиксируются версии cookbook'ов
• Для стадии chef_cookbooks используем .chefinit вместо .dapp_chef.
  • Дополнительно рассматриваем возможность отказаться от стадии chef_cookbooks, сделав ее явной (готовый кусок кода для Dappfile).
• Для зависимостей в Dappfile указывать:
  • Название cookbook
    • есть dimod
      • для вкл. dimod автоматом добавляется соотв. cookbook
    • есть просто сторонний cookbook-зависимость (например apt)
  • Откуда брать (git, github, без указания)
  • Version constraint

build_dir stored paths should reside under subdirectory inside build directory

Because now with this setting in Dappfile:

build_dir.store '/cookbooks/inside_container'

you will collide with service directory .dapps_build/<image>/cookbooks.

cookbooks/inside_container should reside at .dapps_build/<image>/store/cookbooks/inside_container instead of .dapps_build/<image>/cookbooks/inside_container.

Наследование mount из dimod'ов

Как релиз-инженер (chef-приложения) я НЕ хочу повторять в каждом Dappfile, который использует некоторый mdapp, конструкцию mount. Например, для mdapp’а, который вызывает composer, я НЕ хочу в каждом Dappfile указывать явно монтирование кеша в build_dir.

help command please

It is great to have help command in addition to -h --help flags.
dapp help bp must provide help for command bp as dapp bp -h

$ dapp help
Error: subcommand not passed

$ dapp help bp
Error: subcommand not passed

sub-command description is missing

There are no info about what every sub-command do. User gets only usage and options.

Just one or two lines between usage and options about command actions will save time for someone.

При удалении верхнего стейдж-кэша удаляется и image приложения из docker-registry

Как пользователь dapp я хочу иметь возможность удалить устаревший стейдж-кэш из docker-registry, не удаляя при этом те тегированные образа, которые зависят от этого кэша.

Не ставить теги для стадий артефакта до полного билда приложения

Как пользователь dapp, я хочу чтобы стадии артефакта не тегировались до полной и успешной сборки приложения, чтобы политика тегирования собранных стадий образов для артефакта и приложения была единой (собранные стадии приложения не тегируются до его полной сборки).

Ошибка при падении сборки стадии с отключенным логированием

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

Парсер генератора документации кушает тэги

https://github.com/flant/dapp/blame/master/docs/pages/definition/stage.md#L136

Формат "<image:tag>" пропадает из генерируемой документации: http://flant.github.io/dapp/stages.html#from

Зависимость сигнатуры latest-patch от содержимого patch

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

• Ускорить сборку в случае, когда в одном коммите был добавлен, а в следующем удален файл (т.е. патч одинаков) — будет использован уже собранный образ из кеша.
• Уменьшить тем самым размер кеша.

Детали реализации
Нужно посмотреть в git log, когда это убрали и может быть удастся понять почему.

Smartly trap interruption signals

Как пользователь dapp я хочу, чтобы убитый процесс dapp не оставлял после работы команды систему в некорректном состоянии.

Подробности реализации

Вдумчиво добавить trap в некоторых местах

• При пуше — стопать пуш, снимать тег.
  • dapp push
  • dapp stages push
  • dapp spush
• При пуле — стопать пул, удалять пульнуто-недопульнутое.
  • dapp stages pull
    • pull долгий (30 s)
    • tag быстрый (10 ms)
    • rmi быстрый (10 ms)
• Возможны проблемы с локами, кстати, из-за того что dapp убили, а pull/push нет. Подумать об этом.
• Учесть в cleanup, что может быть запущен параллельный pull/push.

Директивы семейства depends_on должны использовать файлы из git

Как релиз-инженер приложения, я хочу настраивать файлы зависимости для пересборки образа с определенной стадии при описании git-артефактов, в которых содержатся эти файлы, чтобы:

• Повысить степень модульности при описании git-артефакта
  • После удаления блока описания git-артефакта Dappfile останется корректным (не будет depends_on привязанных к файлам, которых уже нет)
• Повысить понятность описания конфигурации
  • Сразу понятно из какого git артефакта берется файл, указанный в depends_on
    • Не нужно заглядывать в файловую структуру, чтобы узнать из какого артефакта этот файл
• Ограничить выбор файлов-зависимостей только теми файлами, которые добавляются через git-артефакты (еще файлы могут быть добавлены, например, рецептами)
  • Убавятся возможности для создания некорректных конфигураций случайным образом (когда для depends-on используются файлы не из git-артефактов)
• Чтобы можно было пересобирать образы при изменениях в external git artifact’ах.

Детали реализации

• Переехать в dsl в группу git
• => Триггер сборки по external-git
• Пример:

dimg 'front-backend-aggregation' do
  docker.from 'docker-registry.local/mosru-centos7:7'

  artifact do
    chef.dimod 'mdapp-front'

    git do
      add '/' do
        owner 'root'
        group 'root'
        to '/app/'

        stage_dependencies do 
          install 'bower.json', 'package.json'
          artifact_build '.yo-rc.json', 'Gruntfile.js', 'gulpfile.js', 'src', 'version.txt'
        end
      end
    end

    export '/app/' do
      after 'setup'
      owner 'root'
      group 'root'
      to '/app/'
    end
  end

  chef.dimod 'mdapp-mail', 'mdapp-nginx'
  chef.recipe 'main'
end

Кэширование стадий артефакта и приложения

Как пользователь dapp, я хочу чтобы одинаковые стадии (с одинаковыми контрольными суммами) артефакта и приложения переиспользовались при последовательной сборке стадий приложения и артефакта, чтобы ускорить процесс сборки.

Детали реализации
При первой сборке артефакт не использует одиниковые с dimg стейджи, так-как проверка наличия стейджей проверяет только через docker images и не учитывает те стейджи, которые вот-прямо-сейчас-собрались.

Наследование mount-ов

Как релиз-инженер приложения, я хочу, чтобы описанные в Dappfile mount-ы сохранялись в конечном образе и переиспользовались в проектах, где этот образ фигурирует в качестве базового, чтобы не дублировать mount-ы во всех связанных проектах.

Решение
Добавлять mount-ы из Dappfile в лейблы кеша и конечного образа.

Убрать зависимость dappdeps от конкретной версии libc

Как релиз-инженер приложения, я хочу чтобы сборщик не зависел от библиотеки libc внутри собираемого контейнера, чтобы иметь возможность собирать образ приложения из произвольного docker-образа.

Детали реализации

• Dappdeps зависит от libc в docker.from образе — проблема.
• Пока известно только про libc, возможно что-то еще.
  • В целом dappdeps должен быть автономен, но надо выяснить подробнее какие еще библиотеки считаются базовыми в chef/omnibus (возможно больше никакие).

Экспорт образов для virtualbox

Как пользователь dapp я хочу иметь возможность экспорта создаваемых образов для docker в формат virtualbox (qemu, vmware, ...), чтобы:

• сборка любых образов происходила с помощью dapp;
• держать в одном месте все общие и частные правила сборки образов для разных окружений (production, development).

Мотивация
На каком-то из митингов слышал о проблемах с созданием virtualbox окружений для разработчиков проектов, использующих dapp, появилась идея.

Отделение кода сборки образов в dapp

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

Детали реализации

• Переименовать project в dapp в коде dapp
• Например, сейчас есть следущие понятия, определенные на глобальном уровне в пространстве имен Dapp:
  • Builder
  • Build
  • Dimg
  • GitArtifact
• Все эти понятия связаны с Dimg.
• Надо подумать, возможно просто перенести все внутрь Dimg.
• На примере пространства имен Config: все что связано с конфигом там и только там и не мешает фокусироваться, когда разбираешься в коде dapp.
• Продумать названия консольных команд в контексте того, что dapp это НЕ только лишь сборщик, что-то в таком духе:
  • dapp cleanup -> dapp dimg cleanup
  • dapp list -> dapp dimg list
  • dapp stages -> dapp dimg stages …
  • Другие команды, которые принимают параметр DIMG:
    • dapp tag [options] [DIMG] TAG
    • dapp build вероятно остается как есть

Режим “разверни мне вот эти модули локально для разработки”

Как релиз-инженер приложения я хочу быстро разворачивать локальное окружение для dapp проекта для внесения изменений не только в проект, но и в dimod-модули, указаные в Dappfile.

Детали реализации

• Команда dapp dev clone <git-url>
  • Клонирует репо в текущую директорию.
  • Берет все dimod'ы, указанные в Berksfile и клонирует в текущую директорию.
  • Заменяет пути до исходников dimod'ов в Berksfile на локальные.
• Вопросы:
  • Что делать, когда Berksfile будет генериться автоматом?
  • Нужна ли противоположная команда, которая заменит пути в Berksfile обратно?

Error 'chroot: failed to run command '/.dapp/deps/base/0.1.14/bin/bash': No such file or directory'

Hi all. Thank you for your contribution.

When I tried to run basic build command like 'dapp build' with
the next sample Dappfile content

dimg 'web' do
    docker.from 'php:7.0-fpm'
    git '[email protected]:flant/dapp.git' do
        add '/' do
            to '/resources/frontend'
        end
  end
end

I get error

Andrews-MacBook-Pro-2:web andrew$ dapp build
web
System shellout container failure, try to remove if error persists: docker rm -f dapp_system_shellout_cf6fa6bbac8add9e9296005b33e2445ba1f6fd2e2a6613d59d51eeddf860f9e1
Stacktrace dumped to /tmp/dapp-stacktrace-a8f08481-9bab-4d27-9261-5d957b2a22ea.out
>>> START STREAM
chroot: failed to run command '/.dapp/deps/base/0.1.14/bin/bash': No such file or directory
>>> END STREAM

My OS is OSX El Captain

Any ideas? thank you.

Have you seen Roker before?

It seems that Rocker solves similar task https://github.com/grammarly/rocker

Указание mount, depends_on не только в Dappfile, но и прямо в chef-рецептах

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

Как релиз-инженер (chef-приложения) я хочу, когда пишу в рецепте код, результат выполнения которого зависит от наличия определенных mount'ов, иметь возможность сразу указать эти mount'ы, а не указывать их отдельно в Dappfile.

Детали реализации
Предусмотреть какой-то специальный синтаксис в комментариях, например “#STAGE_DEPENDENCIES: /app/compose.json”, который автоматически парсить и учитывать. В контексте того, что мы хотим перенести depends_on в git, тут пути можно указывать “внутри образа” и предусмотреть механизм обратного разрешения (из пути-в-образе в git artifact и путь в нем).

Однако, есть ощущение что комментарии в чистом виде не подойдут, так-как со захочется разрабатывать универсальные mdapp’ы, пути в которых зависят от атрибутов.

Стадия patch (final)

Релиз-инженеру приложения нужна возможность добавлять инструкции сборки для shell и chef сборщиков, которые отрабатывали бы после стадии setup, т.е. в последнюю очередь, чтобы была возможность изменять уже собранный образ в кеше, когда пересборка невозможна. Например, подменить библиотеку OpenSSL для срочного хотфикса бага в приложении, которое несколько лет не собиралось и пересобирать просто страшно.

Не верные ссылки на страницу "шеф сборщик" в документации

На странице chef_directives не верные ссылки. Должны быть на шеф сборщик, а ссылаются на базовые директивы. Вот например в конце определения chef-recipe

Прогресс-индикатор pull и push

Как пользователь dapp я хочу видеть progress bar при pull и push.

Install, usage, examples in docs

No INSTALL and other usefull sections in docs. Look pam_docker README

Доступ из ruby кода dapp к ФС сборочного контейнера

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

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

Фактически, нужно придумать как ОС-безопасно ходить в ФС контейнера и переписать работу с git apply, tar, find, install и пр. на соответствующие ruby библиотеки.

Команда dapp create

Как релиз-инженер приложения, я хочу иметь команду для генерации структуры dapp-проекта, с целью ускорения процесса создания и исключения ошибок при создании dapp-проектов.

Детали реализации
dapp create --chef

• Как-то указывать тип проекта chef/shell (по умолчанию лучше chef, т.к. чаще используется).
• Генерирует иерархию директорий и необх. файлов, можно с README.
• Приложение уже есть, генерация происходит в уже готовом git-образе.
  • Приложение первично, dapp как правило добавляют в уже готовое приложение.
    • Поэтому можно не указывать, а определять автоматом.
    • Заходим в директорию с проектом и делаем dapp create --shell|chef.
      • Ругаемся, если там уже есть следы dapp приложения.

Поддержка team city в --tag-ci

Пользователю dapp нужна возможность теггирования образов по информации, взятой из переменных окружения CI системы team-city по аналогии с поддержкой переменных для gitlab — CI_BUILD_ID, и для travis — TRAVIS_BUILD_NUMBER.

Некоммитнутые изменения в локальном git артефакте

Как разработчик приложения, собираемого через dapp, я хочу иметь возможность сделать сборку или пересборку образа с некоммитнутыми изменениями (в том числе с не добавленными в индекс) в локальном (не external) git артефакте, чтобы быстрее увидеть результат изменений исходного кода в локально запущенном образе приложения для цикла разработки-дебага.

Детали реализации
Сейчас работы с git происходит как с bare repo, в качестве которого используется просто директория .git проекта. В bare repo по-определению не может быть НЕ коммитнутых изменений (как совсем не добавленных в индекс, так и добавленных в индекс, но не коммитнутых), так-как там нет source tree.

А зачем мы работаем с локальными git-артефактами через bare repo? Это было нужно для external, чтобы один раз склонированный external git repo, можно было использовать одновременно разные бранчи при параллельной сборке (ведь external git repo лежит в build dir, который должен быть параллельно-безопасный). Однако, локальный git artifact всегда используется в один и только в один поток, поэтому история с бранчами нас не парит (тем более, что у нас и нет возможности указывать бранч для локального артефакта).

Итого — делаем два режима. По-умолчанию остается как сейчас, а с флагом --dev добавляются ВСЕ изменения (в том числе и в индексе и не добавленные в индекс).

Добавить label с версией dapp в собираемые образы

Как разработчик dapp я хочу иметь способ узнать какой версией был собран образ из stage кэша, чтобы избежать лишних вопросов к пользователям dapp об используемой версии dapp при возникновении проблем, связанных с кэшем.

Diff size of changes in git should not affect build time

The user of the werf should have an ability to make changes in the files of arbitrary size in the git mappings. And the patch size of the changes should not affect build time.

The current mechanics is not effective in handling of huge removes in the git repo.

Нельзя удалить / untag'нуть образ при наличии связанного контейнера

Как пользователь dapp я хочу, чтобы система оставалась в корректном состоянии после попытки удалить через dapp образ, для которого существует связанный [запущенный] контейнер, чтобы, например, при вызове команды dapp cleanup, этот cleanup не проходил, если хотя бы 1 образ используется.

Иерархия dapp и общая часть dappstage

Как релиз-инженер я хочу, чтобы при указании вложенных dimg они максимально использовали кэш родителей. Даже если сигнатура стадии артефакта отличается от сигнатуры стадии основного dimg, но в артефакте, например, добавлен 1 дополнительный рецепт — можно взять за базу собранный образ стадии основного dimg и запустить только 1 рецепт, чтобы получить образ стадии артефакта.

Встроенная документация в утилиту dapp

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

• Зайти посмотреть документацию на сайт, если забыл — долго
• Встроенная справка по командам в текущей версии неполна и НЕ может служить первичным руководством, понятна только после чтения полной документации с примерами
  • Например, по командам push, spush — по встроенной справке вообще ничего не понятно

Как пользователь dapp я хочу иметь возможность просматривать полную документацию на сайте проекта в том случае, если на момент просмотра нет возможности запустить команду dapp в терминале.

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

Детали реализации

• Gem для форматированного вывода markdown в консоль
  • https://github.com/ttscoff/mdless
  • Использовать гем как есть не получится
    • Не доделан и рассчитан только на cli
  • Можно вынуть оттуда движок и создать свой гем, пригодный для использования в dapp
    • Интерфейс должен быть что-то типа: format_markdown(<markdown-string>) => <string>
• Документация по командам должна быть разбита на отдельные файлы по каждой команде с иерархией директорий, соответствующей подкомандам
• Доступ к документации из cli
  • dapp help build
  • dapp help stages cleanup local
  • dapp help <полное название команды с подкомандами>
• Если текста влезает в терминал — выводить просто текст
• Если текст не влезает в терминал — выводить в PAGER
  • Как в git
• Выключать цвета, если терминал не интерактивный

Оригинальный issue-запрос: #9.

Упростить доступ к ssh-ключам при сборке

Как релиз-инженер приложения, я хочу чтобы ssh-ключи были доступны под любым пользователем в сборочном контейнере, а не только под пользователем root, чтобы упростить и сделать более универсальными правила сборки образов.

Полный переход на rugged

Как пользователь dapp я хочу, чтобы dapp работал быстро и под всеми системами, не создавал всякие левые “служебные” контейнеры и не монтировал git внутрь сборочного контейнера.

Детали реализации

Переделать git archive и git diff на rugged. Останется только вызов git apply внутри сборочного контейнера (ну и tar, find, install — вот это все).

Stages diagram

Diagram of stages (build life cycle) will help a lot to understand dapp.
Example: https://docs.chef.io/chef_client.html#the-chef-client-title-run

Требование к версии dapp в Dappfile

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

No description or website provided

Зайдя по ссылке https://github.com/flant/dapp взгляд останавливается на фразе:

No description or website provided.

Предлагаю ее заменить на что-то более информативное.

A way to prevent 'patch does not apply' problems

If build instructions make a change to the files added from git mapping, then on next rebuild of the image werf will not be able to apply patch to these files, because files has been changed by build instructions and does not match state recorded in the git commit.

There should be some mechanics in the werf to prevent and detect such changes.

Subcommand is a command

We have "sub-command". Why "sub" and why hyphen?
Usage: dapp [options] sub-command [sub-command options]

Others:

• Usage: docker [OPTIONS] COMMAND [arg...]
• Usage: vagrant [options] <command> []
• Use 'lvm help <command>' for more information
• $ man dmsetup ... COMMANDS ...
• $ berks help
  Commands:
  berks apply ENVIRONMENT
• Usage: ufw COMMAND
• systemctl [OPTIONS...] COMMAND [NAME...]

but !

Usage: knife SUBCOMMAND (options)

Инструмент умного информирования

Как релиз-инженер я хочу иметь инструмент "умного" информирования о проблемах с наложением патча, который показывает в каких инструкциях изменяется файл, который мешает наложению патча, чтобы ускорить поиск таких проблем.