How to Access a Running Container with Docker Exec

You've created your application, placed it into a container, and deployed it. However, your application seems to behave strangely. It is unable to connect to the database, your configuration file doesn't load properly, or you've got an error message that doesn't really say anything.

So far, you've checked your container's logs and couldn't get enough information out of them. Wouldn't it be great to enter the container and check everything manually?

And here comes the docker exec command.

In this article, I will cover how to access a running container with Docker exec, execute commands inside containers, and troubleshoot some typical problems without stopping your application.

What Is Docker Exec

Using the docker exec command, you can execute any command inside an already running container.

The most useful feature of this command is the possibility to open an interactive shell allowing you to examine the container's filesystem, processes, and the environment.

It will help you to:

• Check your configuration files and environment variables
• Verify that your application files are in the right directory
• Troubleshoot networking and connectivity problems
• Check running processes
• Execute diagnostic commands without stopping your container

But remember that containers are lightweight, so they might lack some of the tools that are usually installed on a regular host machine.

Step 1: Find Your Running Container

Before you access your container, you should find out which container you want to investigate.

Open a terminal and type:

docker ps

This command will display the list of running containers together with their container IDs, names, images, and statuses.

For example:

`CONTAINER ID   IMAGE          STATUS         NAMES

a1b2c3d4e5f6   nginx:latest   Up 10 minutes  my-web-app`

Here we have an Nginx container called my-web-app.

You can use either container ID or name when executing Docker commands. I prefer using names because it's easier to remember them.

Open an Interactive Shell Inside Your Container

Now that you've found the container you want to work with, you can access it and open the interactive shell:

docker exec -it my-web-app /bin/bash

Here is what each part of the command means:

• docker exec: executes a command inside a running container
• -i: keeps standard input open for interaction with the shell
• -t: allocates a pseudo-TTY for interactive use
• my-web-app: specifies a container that you want to use
• /bin/bash: starts a bash shell in this container

The -it flag is actually two separate options combined for convenience.

And now you've entered the shell of your container.

But keep in mind that not all Docker images have a Bash shell installed.

Step 3: Troubleshooting

Now that you're inside your container, let's have a look at several practical examples of troubleshooting.

Example 1: Checking Your Application Files

Suppose that your application is unable to load a configuration file.

You can use the following command to check the filesystem:

ls -la /app

This command will show you the list of files in /app directory, assuming that your application files are located in this directory.

You can check a particular file by using the cat command, for example:

cat /app/config.json

This allows you to verify that your file exists and has the correct settings in it.

Example 2: Checking Environment Variables

As a common practice, your containerized application uses environment variables for configuration.

To check them, you can use the following command:

printenv

You can check a particular variable:

printenv NODE_ENV

If your application requires NODE_ENV to be set to production, this command will check that it is so.

Remember that it is a good practice not to share environment variables because they might include sensitive information.

Example 3: Network Connectivity Problems

Let's say your application cannot connect to another service.

You can try to use the following command to check it:

curl -I http://api-service:8080

This command sends an HTTP HEAD request to the service specified and outputs its headers.

In case of failure, you might have a networking or DNS problem, or the service is unavailable.

Keep in mind that some diagnostic tools might not be included in your container image.

Step 4: Executing Commands Without Opening a Shell

Sometimes you don't need to open an interactive shell to check your container.

For example, you can list files from your terminal directly:

docker exec my-web-app ls -la /usr/share/nginx/html

You can check a particular environment variable too:

docker exec my-web-app printenv NODE_ENV

It is a great feature when you want to run a single command and don't want to open a shell session.

Step 5: Leaving the Shell

When you've finished troubleshooting, just type:

exit

This will exit your interactive shell session.

Leaving the shell doesn't stop your container! Your application continues working as before.

Best Practices When Using Docker Exec

Although docker exec is a powerful diagnostic tool, there are a couple of things to consider.

First, don't make any permanent changes in a running container. All changes in the writable filesystem of your container will disappear when your container is destroyed and built again.

Instead, update your Dockerfile or your application source code when needed and build your container again.

Also, don't install unnecessary debugging tools in your production containers. Keeping container images small decreases their attack surface and increases the efficiency of deployment.

And finally, don't forget that you can use docker exec only in a running container. If your container stops immediately after starting, you need to investigate its logs or the configuration first.

Do you want to learn more about working with Docker containers?

Then you may have a look at my Docker: Your First Project course on LinkedIn Learning. It is a part of the Docker Foundations Professional Certificate learning path, where you will get hands-on experience building and running containers.