Listening on the host on a named pipe for a command from a docker container

Question

I'm trying to be able to restart a docker container from within the container, by sending a command through a named pipe and listening for it on the host machine.

However it appears that the host machine is not listening for it - I call

echo "incoming" > host_directory/cdm_container_pipe3
echo "restart" > host_directory/cdm_container_pipe3

And the first call just blocks, as if nothing is reading from the pipe.

Here is the script:

#!/bin/bash -p

#

if [ -z "$container_id" ]; then
    container_id=0
fi

let "container_id=container_id+1"

#

container_name="cdm_container$container_id"

pipe="cdm_container_pipe$container_id"
if [ ! -p $pipe ]; then
  echo 'Creating pipe'
  mkfifo $pipe
fi


#

start_container() {
    docker rm $container_name
    docker run -v ~/dev/obd:/host_directory -it --name $container_name --privileged cdm_image:latest
}

#

start_container

#

while true
do
    if read line <$pipe; then
        COMMAND=$(cat $pipe)
        echo "received from pipe: $COMMAND"

        if [ $COMMAND == "restart" ]; then
            echo " updating repo and restarting container "
            docker stop $container_name
            git pull origin master
            start_container
        fi
    fi
done

For reference, I tried a cut down version which does not start the docker container:

#!/bin/bash -p

pipe="test_pipe"
if [ ! -p $pipe ]; then
  echo 'Creating pipe'
  mkfifo $pipe
fi

#

while true
do
    if read line <$pipe; then
        COMMAND=$(cat $pipe)
        echo "received from pipe: $COMMAND"
    fi
done

I was able to get this to work successfully, both piping in from another terminal and piping in from a running container using host_directory/pipe_name

Is there an issue with the while loop not running after the docker container is started? Should I try to run the container in a different thread?

Thanks, Ian

Answer 1

docker run块，因此要使其正常运行，我需要使用-d（和正在进行的命令）运行它

Answer 2

The easiest way to do this is to just have your process exit, and set a restart policy that restarts the container when this happens. If an operator wants to restart the container from the outside, they can sudo docker restart it given its name or container ID.

(If you're looking at clustered deployment solutions like Kubernetes, relying on the orchestrator is even better. The usual way to handle problems like “the database isn't ready yet” is “just crash and let the orchestrator restart you later”, for example, and the universal big-hammer way to fix misbehaving Kubernetes pods is to just delete them let and the orchestrator recreate them. It'll also be hard to wire something like a named pipe out from a process running on an arbitrary node.)