如何使用 docker-py 将伪 tty 附加到 Docker 容器以复制 `docker exec -ti 的行为<container><command> `?</container>

Question

I am using the most recent version of Docker Py and I have not been able to attach a pseudo-tty to an already running container so as to make sure that the behaviour of docker exec -ti <container> <command> is replicated. Any help would be appreciated.

Answer 1

Try using attach method or attach-stream from the docker-py.

As described in docker-py attach , the method is attaching tty(s) to the running container. This is similar to the native docker attach command which is attaching the stdin, stdout and stderr to the container.

The container needs to be created with stdin_open = True and tty = true when calling create_container for the attach to work.

Example using attach-socket :

pull the debian:latest container

docker pull debian:latest

Create the python script test.py as follows

#! python3
import docker
import os
import time

# Create container and start it
client = docker.from_env()
container = client.create_container('debian:latest', name='test', stdin_open = True, tty = True, command = 'sh')
client.start(container)

# Create communication socket
s = client.attach_socket(container, {'stdin': 1, 'stdout': 1, 'stream':1})

# Set the socket as non-blocking
s._sock.setblocking(False)

# Start communication by sending cat
os.write(s.fileno(),b'cat /etc/hosts\n')

# Since we are non-blocking, wait for a while to get the output
time.sleep(1)

# Read up-to 10000 bytes. If there are more, we can issue another read
print(os.read(s.fileno(),10000))

client.stop(container)
client.wait(container)
client.remove_container(container)

Now test the script. You will see the output from the command we had executed at the shell.

~# python3 test.py
b'cat /etc/hosts\r\n127.0.0.1\tlocalhost\r\n::1\tlocalhost ip6-localhost ip6-loopback\r\nfe00::0\tip6-localnet\r\nff00::0\tip6-mcastprefix\r\nff02::1\tip6-allnodes\r\nff02::2\tip6-allrouters\r\n172.17.0.2\t48f4a5f32f48\r\n# '

Note: The socket is set to non-blockin in order to avoid being blocked while waiting for the response from the container. This approach is specific to the use case.