One of the application types that Docker allows to containerize is CLI tools. For instance, httpie, a user-friendly command-line HTTP client, has a popular containerized version alpine/httpie.
Running the alpine/httpie image with no arguments prints httpie's help message:
docker run alpine/httpie
Running the alpine/httpie image with a single URL argument makes an HTTP GET request to it and prints the response:
docker run alpine/httpie https://github.com
But what if you wanted to launch a shell in the alpine/httpie image instead of running the httpie binary? It's a totally valid requirement when you want to explore the contents of the container.
Can you do it?
Hint 1: CMD vs. ENTRYPOINT 💡
The only mandatory argument of the docker run command is the image name. When invoked in its shortest form (e.g., docker run alpine/httpie), Docker launches the container's default command, which is in turn a combination of two image's attributes: Cmd and Entrypoint.
Run the following command and locate them:
docker image inspect alpine/httpie
Hint 2: Overriding container's entrypoint 💡
The alpine/httpie image has the entrypoint set to the http binary (i.e., the HTTP build of the httpie client). It means that executing docker run alpine/httpie with additional arguments will pass them as extra arguments to the containerized http command. This is why running the following two commands produces the same results:
# no prior httpie installation required
docker run alpine/httpie https://labs.iximiuz.com
# requires prior httpie installation
http https://labs.iximiuz.com
But there should be a way to override the entrypoint of a container. Look for the relevant part in the docker run --help output.
Hint 3: Running an interactive shell container 💡
If you're not sure how to launch an interactive shell in a container, try solving these challenges first:
Level up your Server Side game — Join 11,000 engineers who receive insightful learning materials straight to their inbox