Accessing Containers with Exec

Introduction

In this lab, you will learn how to enter a running Docker container. This is a crucial debugging skill because even though containers are designed to be disposable, you often still need to inspect a live environment to understand what is happening.

To inspect files, check running processes, or troubleshoot issues inside a container, you often need a command shell inside that container's environment. The docker exec command lets you start an additional command inside an already running container without rebuilding or restarting it.

That word "additional" is important. docker exec does not replace the main container process. It starts another process inside the same container namespaces while the original service keeps running.

You will walk through the following steps:

• Start a background Nginx container.
• Use docker exec to start an interactive Bash shell inside the container.
• Run commands inside the container to identify its operating system.
• Exit the container and return to your host terminal.

Start a Background Container

In this step, you will start a new Docker container using the Nginx image. You will run it in "detached" mode so it runs in the background, and you will assign it a specific name to make it easier to reference later.

Run the following command in your terminal:

docker run -d --name web1 nginx

Breaking down the command:

• docker run: The command to create and start a container.
• -d: Runs the container in detached mode (background).
• --name web1: Assigns the name web1 to the container.
• nginx: The image to use.

Verify that the container is running:

docker ps

You should see web1 in the list of active containers.

You need the container to be running because docker exec works by entering an existing live container context. It cannot start a shell inside a container that has already stopped.

Enter the Container

Now that the container is running, you will use the docker exec command to start a shell session inside it. This effectively "logs you in" to the container, similar to SSH-ing into a remote server.

Execute the following command:

docker exec -it web1 bash

Breaking down the command:

• docker exec: Executes a command inside an existing container.
• -it: This combination is essential for interactive sessions.
  • -i (interactive): Keeps the input stream open.
  • -t (tty): Allocates a pseudo-terminal, making it behave like a real command prompt.
• web1: The name of the target container.
• bash: The command to run inside the container. Here, we launch the Bash shell.

So docker exec is really "run this command inside the container." A shell is only one common use case; the command could just as easily be ls, cat, or a debugging utility.

Observe the change:

After running this command, your command prompt will change. It will look something like root@<container-id>:/#.

This indicates that you are now executing commands inside the container, isolated from your host machine.

That isolation usually includes filesystem view, process namespace, and network context. You are still on the same kernel, but you are now looking through the container's scoped environment rather than the host's full environment.

Inspect the Container Environment

You are now inside the container. The file system you see belongs to the container, not your LabEx environment. You can verify this by checking the operating system information.

Run the following command inside the container shell:

cat /etc/os-release

You will see output describing the Linux distribution used by the Nginx image (usually Debian).

Example Output:

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
...

This confirms that the container has its own isolated operating system environment, separate from the host.

More precisely, it has its own userspace filesystem and process environment. It is not a separate kernel, but it can still feel like a separate small Linux system from the inside.

Exit and Return to Host

When you are finished debugging or inspecting the container, you need to exit the shell session to return to your host machine.

Type the following command inside the container:

exit

After pressing Enter, your command prompt should return to the standard LabEx user prompt.

What happened?

You have closed the Bash process inside the container. However, the container itself (web1) is still running in the background because the main process (Nginx) is still active.

This is the key lifecycle lesson of docker exec: ending your interactive shell does not stop the container unless that shell was the main process that defined the container's life.

You can confirm this by running:

docker ps

web1 is still listed.

To clean up, you can stop and remove the container:

docker rm -f web1

Summary

In this lab, you learned how to access a running container using docker exec -it. You practiced:

• Starting a container in the background.
• Entering the container using an interactive Bash shell.
• Verifying the environment inside the container.
• Exiting safely while keeping the service running.

This is a fundamental skill for working with Docker, allowing you to troubleshoot applications and inspect container environments directly.