Может ли процесс в одном контейнере Docker записывать в стандартный поток процесса в другом контейнере

Question

У меня есть приложение, работающее в контейнере A, и я хотел бы написать в stdin процесса, выполняющегося в контейнере B. Я вижу, что если я хочу записать в stdin B с хост-машины, я могу использовать docker attach , По сути, я хочу позвонить docker attach B из A.

В идеале я бы хотел настроить это через docker-compose.yml. Может быть, я мог бы сказать docker-compose создать сокет домена Unix A, который направляет к stdin B, или подключить некоторый магический номер порта к stdin B.

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

Для всех, кто интересуется подробностями, у меня есть приложение на python, запущенное из контейнера A, и я хочу, чтобы оно говорило с stockfish (шахматным движком) в контейнере B.

Answer 1

, если это поможет, вы можете попытаться создать и прочитать / записать в сокет. и смонтировать этот сокет в обоих контейнерах как:

docker run -d -v /var/run/app.sock:/var/run/app.sock:ro someapp1

docker run -d -v /var/run/app.sock:/var/run/app.sock someapp2

отказ от ответственности: это просто идея, я никогда не делал ничего подобного

Answer 2

Процесс в одном контейнере Docker не может напрямую использовать stdin / stdout / stderr другого контейнера.Это один из способов, которыми контейнеры «похожи на виртуальные машины».Обратите внимание, что это также практически невозможно в обычном Linux / Unix без отношения родительского / дочернего процесса.

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

(Может быть способ сделать это, если вы предоставляете вызывающему процессу доступ к Docker хостасокет, но вы бы предоставили ему неограниченный доступ через хост и связали бы реализацию с Docker: пути HTTP или подпроцесса просты в разработке и тестировании без Docker, а затем перемещаются в контейнерную область отдельно и не требуют возможностизахвата хозяина.)