This post has been republished via RSS; it originally appeared at: Containers articles.
Continuing with our series of blog posts to help ITPros in using containers, today's topic will be on the "Tips and Tricks" area. On our last blog post, I talked on how it's important to spin up a container to ensure the commands you run inside it run correctly before you use them in your dockerfile.
Usually, when running containers - especially if you are running multiple containers - you won't be opening an interactive session into it. Rather, you'll run them detached - which means the container runs on the background (yes, this is just like a virtual machine running on Hyper-V or VMWare). However, because of this assumption that containers will run detached, the interaction with containers is way different than VMs. In addition, since containers don't have a GUI, you actually have to be very specific on how you want to interactively access a container. Let's look into it:
Opening an interactive session from Docker Run
The simplest way to open an interactive session is when you run a container for the first time with docker run. Here's an example:
In this case we're creating, starting, and entering a PowerShell session all with the command above. However, if you have a stopped container, you have to run another command:
Yet another option is when you have a container already running and you want to execute a command inside that container. For that, you can use docker exec:
The command above is obviously an example and will simply show the output of "dir" from the container. Another variant of docker exec is:
This will open an interactive PowerShell session into a running container, so you don't need to specify what PowerShell command you want to run.
Note: I'm assuming you'll want to open a PowerShell session when operating a container interactively, but you could replace "powershell" by "CMD" in all commands above.
Don't fall into the --entrypoint trap!
The commands above are all fine for the container image I'm using - the Server Core base container image. However, you'll see there's a variant of the commands above out there, which omits the "--entrypoint" parameter. This is because you don't actually need to specify that in some cases. When browsing the web for examples, you'll see something like this:
See that in this example we're still opening an interactive session (as specified by the -it parameter), but we completely removed the --entrypoint parameter and moved the powershell instruction to the end. As I mentioned, this will work fine and the reason is because the Server Core base container image was created with no predefined entry point.
However, some container images do have a predefined entry point already, such as the IIS container image. In fact, you can see for yourself how the IIS container image was created by looking at its dockerfile.
If you try to open an interactive session on the IIS container image without the --entrypoint parameter, it will fail. Instead, make sure you use that just like the examples above.
By putting the --entrypoint right after the run command, you successfully specify where the container should start.
Hopefully this information is helpful to you. If you've been working with containers and have other questions and topics you'd like me to cover, feel free to use the comments section! :)