Docker 101: Run a Containerized CLI Tool and Send Data to Its STDIN
Premium Challenge
Upgrade your membership to unlock this and all other premium materials.
In the previous challenge,
you practiced connecting to a Redis server using a containerized version of the redis-cli client.
This challenge takes the problem one step further and expects you to store a user avatar (a small PNG image) in a remote Redis server -
again, by using a containerized version of the redis-cli client.
To store the avatar image in Redis, you can use the following command:
cat ~/avatar.png | redis-cli -h HOST -p PORT \
-x set avatar:user123
The -x flag tells redis-cli to read the avatar:user123 key data from the command's STDIN,
so piping a binary file to it should make it written to Redis.
The Redis server is reachable at 172.16.0.3:6379.
Your mission is to store the avatar image in Redis using the above approach but running the redis-cli client in a local Docker container:
cat ~/avatar.png | docker run ...
Hint: Connecting to a remote Redis server
If you need a refresher on running redis-cli in containers, check out the
previous challenge about overriding container commands.
Hint: Understanding the 'docker run -i' mode
The -i flag tells the docker run command to keep the container's STDIN open.
This is essential when piping data from the Docker host into a containerized command.
When executed without -i, the docker run command starts a container and immediately closes its STDIN,
so no further data can be sent to it.
Hint: Why using 'docker run -it' is not a good idea
The -i and -t flags are often used together.
For instance, this command starts an interactive client connected to a remote Redis server:
docker run -it redis redis-cli -h 172.16.0.3
However, the -t flag cannot be used in scripts.
This flag tells Docker to allocate a pseudo-TTY for the container,
which is great and often desired when the container is started from an interactive shell
(e.g., in a local terminal or via an SSH session),
but fails with the following error when the container is started from a script:
the input device is not a TTY