Как запустить контейнер из другого контейнера при создании инструмента / утилиты

Есть ли общий способ запустить контейнер из контейнера [...] без добавления пугающих дополнительных параметров, таких как [...] -v /var/run/docker.sock:/var/run/docker.sock ?

No.

(Вам необходимо смонтировать Docker-сокет хоста; вызывающий контейнер не должен быть --privileged; вы не можете ограничить то, что вызывающий контейнер может делать, когда у него есть доступ к сокету, поэтому он может сам запускать привилегированные контейнеры или запускать контейнер bind-монтирование /etc каталога хоста или иным образом делать непослушные вещи. Я не совсем уверен, как это взаимодействует с Podman.)

Особенно, если контейнеру необходимо выполнить обратную запись в хост-систему, трудно сделать команду docker run удобной компактной. Вам понадобится параметр -u, чтобы указать идентификатор пользователя хоста, параметры -v для сокета Docker и текущего каталога, --rm, а также имя репозитория, все как накладные расходы, каждый раз, когда вы запускаете команду. Я мог бы предпочесть использовать собственную команду, возможно, на широко доступном языке сценариев, таком как Python или оболочка Bourne.

Если вы все еще хотите запустить это из контейнера, вы можете COPY или иным образом установить инструмент B в тот же контейнер, чтобы вы могли выполнить обычный вызов подпроцесса для его запуска; или разбейте инструмент B на библиотеку и приложение и включите библиотеку в инструмент A (вроде того, что вы делаете сейчас, но более формализовано).

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

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

Таким образом, вы получите полный контроль над средами build-time и run-time. Кроме того, если у вас несколько проектов или сложных сборок, вы можете использовать многоступенчатую сборку в сочетании с buildx для параллельного запуска сборки.

Передача -v /var/run/docker.sock:/var/run/docker.sock внешнему контейнеру проблематична с точки зрения безопасности, поскольку это дает внешнему контейнеру разрешение запускать контейнеры на хосте. Вредоносный внешний контейнер может запускать такие контейнеры с привязкой, чтобы можно было записывать каталоги хоста.

Запуск внешнего контейнера с Podman от имени обычного пользователя (без root) с --privileged защищает вас от этого сценария. Внешний контейнер сможет записывать только в каталоги, которые вы передаете как привязку-монтирование (например, с параметром командной строки -v).

Значение флага --privileged объясняется в этой статье Red Hat.

Обновление от июня 2021 г.. Больше нет необходимости передавать флаг --privileged при запуске Podman в Podman. См. Мой пример в https://stackoverflow.com/a/64537135/757777 и в сообщении блога Red Hat Как использовать Podman внутри контейнера