CODEWITHSUNDEEP
dockerdocker-compose
Evan Thomas
Evan Thomas

Reputation: 93

Can a process in one docker container write to stdin of a process in another container

I have an application running in container A, and i'd like to write to stdin of a process running in container B. I see that if I want to write to B's stdin from the host machine I can use docker attach. Effectively, I want to call docker attach B from within A.

Ideally i'd like to be able to configure this through docker-compose.yml. Maybe I could tell docker-compose to create a unix domain socket A that pipes to B's stdin, or connect some magic port number to B's stdin.

I realize that if I have to I can always put a small webserver in B's container that redirects all input from an open port in B to the process, but i'd rather use an out of the box solution if it exists.

For anyone interested in the details, I have a python application running from container A and I want it to talk to stockfish (chess engine) in container B.

Upvotes: 4

Views: 870

Answers (2)

vvchik
vvchik

Reputation: 1455

if it will help, you may try to create and read/write to socket. and mount this socket in both containers like:

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

disclaimer: it is just idea, never did something like it by myself

Upvotes: 1

David Maze
David Maze

Reputation: 158848

A process in one Docker container can't directly use the stdin/stdout/stderr of another container. This is one of the ways containers are "like VMs". Note that this is also pretty much impossible in ordinary Linux/Unix without a parent/child process relationship.

As you say, the best approach is to put an HTTP or other service in front of the process in the other container, or else to use only a single container and launch the thing that only communicates via stdin as a subprocess.

(There might be a way to make this work if you give the calling process access to the host's Docker socket, but you'd be giving it unrestricted access over the host and tying the implementation to Docker; either the HTTP or subprocess paths are straightforward to develop and test without Docker, then move into container land separately, and don't involve the possibility of taking over the host.)

Upvotes: 2

Related Questions