Как лучше всего предоставить настраиваемые инструменты командной строки для вашего контейнерного приложения?
мы - поставщик программного обеспечения, который в настоящее время исследует Docker в целом и Kubernetes в частности, чтобы позволить клиентам установить наш программный стек в своей среде. Наше программное обеспечение поставляется с целым набором инструментов командной строки, которые в основном используются для целей администрирования. Хотя большинство задач администратора можно выполнить через пользовательский интерфейс, другие можно выполнить только с помощью этих инструментов. Мы думали, как предоставить эти инструменты клиентам, использующим наше программное обеспечение на Docker. Первой мыслью было предоставить им доступ к большому архиву, который они могли бы загрузить и запустить на своей административной машине. Но нам быстро пришла в голову идея вместо этого предоставить контейнер «инструменты администратора», содержащий все эти инструменты. В отличие от других наших контейнеров, этот не предназначен для запуска в качестве сервера, а для запуска либо из сценариев, либо в интерактивном режиме. Даже если учесть, что соответствующие командные строки docker или kubectl становятся немного длиннее, в основном это работает, и я думаю, что этот подход имеет определенные достоинства, поскольку это «внутриполосный» способ публикации наших инструментов командной строки. Однако некоторые административные задачи требуют, чтобы вы передавали файлы соответствующему инструменту командной строки или инструменты генерировали файлы (например, резервные копии). Итак, вам нужен способ получить эти файлы в вашем контейнере или из него. В среде Docker довольно просто использовать команду «docker run» и смонтировать том или каталог хоста в контейнер, содержащий файлы. В Kubernetes это, похоже, не так просто (см. Создайте модуль kubernetes с объемом, используя kubectl run, чтобы узнать, как это сделать с помощью "kubectl run" ... Ура!). Запуск контейнера инструментов администратора в обычном модуле (созданном с помощью файла YAML) с монтированием тома и присоединение к нему на самом деле проще.
В заключение я хотел бы высказать ваши мысли по вопросу заголовка: каков «лучший» способ сделать инструменты командной строки для администрирования контейнерных приложений доступными для их пользователей?
- Отправить их как специальный архив и позволить пользователям использовать их, как они делали это в мире до контейнеров?
- Отправлять их в контейнерах, предназначенных для интерактивного использования (как описано выше)?
- любые другие идеи?
С Уважением Пижамный
Ответы 3
Пользователям должны быть доступны следующие параметры:
- Инструменты должны быть доступны в виде образов докеров с тегами.
- Пользователи должны иметь право использовать образы докеров либо с запуском докеров, либо с кубернетами, в зависимости от того, что им подходит (оставьте это пользователям).
- Инструменты также должны быть доступны в виде tar-архивов, как и в мире до докеров, потому что не все пользователи хотели бы использовать докер.
- Инструменты также могут быть предоставлены / размещены в облаке, и пользователи могут запускать их оттуда. см.
https://cmd.io/
Вы хотите Операторы Kubernetes.
Люди не хотят использовать ваш CLI, они используют ваш CLI только для «работы». Если вы можете поместить свои действия CLI в оператор Kubernetes, вы получите стандартный API, который может использовать любой другой инструмент.
Например, предположим, что наше программное обеспечение похоже на базу данных. У вашего оператора может быть запись, представляющая каждую базу данных, в которой будут поля для «как часто выполнять резервное копирование» и «сколько реплик». Любой инструмент (или даже kubctl CLI) может установить эти поля, и ваш оператор сделает всю грязную работу, чтобы это произошло. Ваши клиенты устанавливают единого оператора, и им не нужно управлять временными контейнерами, которые «выполняют работу», и им не нужно понимать ваш интерфейс командной строки.
Мне нравятся инструменты командной строки не меньше, чем следующему инженеру-программисту; и мое мнение таково, что Докер не должен быть частью вашего решения.
Как потребитель инструмента, я хорошо осведомлен о двух важных деталях: мне нужны привилегии, эквивалентные root, для запуска чего-либо в Docker вообще, и что контейнеры Docker имеют отдельные пространства файловой системы от моего основного приложения. На примере самого Docker приятно знать, что я могу
docker images | grep dmaze | awk '{ print $1 ":" $2 }' | xargs docker rmi
но это станет намного сложнее, если я заменю docker расширенным вызовом docker run -e ... -v ... -v ... vendor/imagename command.
Точно так же стоит просмотреть Stack Overflow, чтобы найти такие вопросы:
I've packaged my tool in Docker. I'm trying to run it. What
docker run -voption do I need to give it access to my files? It doesn't run as root; what permission settings do I need? If I have one file that references another, how do I make the filenames consistent across environments? I forgot todocker run -v, is my output file totally gone now?
Если ваши инструменты упакованы как образ Docker, вы перекладываете все эти сложности на пользователя; просто сбросить что-то в $PATH мне намного проще в использовании.
Преимущества для вас как поставщика инструментов кажутся минимальными. Образ Docker - это единственный артефакт, как и файл tar. Вы, вероятно, можете рассчитывать на то, что общий набор базовых библиотек C и языковых сред будет легко доступен; вы можете многое сделать, например, со стандартной библиотекой Python, и она будет доступна почти в каждой установке Linux.
Kubernetes здесь точно не применим. Это наиболее полезно для запуска распределенных приложений в кластерных средах. У некоторых очень преданных разработчиков может быть minikube, но это не повседневная вещь, и получение интерактивной оболочки в модуле Kubernetes является даже большим исключением, чем получение оболочки в контейнере Docker (или должно быть).