DOCKER - 13 Have a Shell in a Container
In this lesson we open a shell inside a container to manipulate it from the inside. We have two main options: docker container run -it <image> <command> to start a new container with an interactive shell, or docker container exec -it <name> <command> to attach to a container that is already running.
Let's start a new nginx container called "proxy" and override its default command with bash. An image ships with a default command (here, the nginx binary). The run CLI lets you replace it on the fly:
docker container run -it --name proxy nginx bash
The prompt now shows root@<container-id>. You are not root on the host, only inside the container. ls -al at the root shows the full filesystem of the nginx image. From here you could edit configuration files, install packages or run any administrative command. Type exit to leave the shell — the container stops, because it ran only as long as its main command (bash) was alive. The container is gone from docker container ls but still visible with docker container ls -a.
Key commands and behaviors
- Start with shell:
docker container run -it ubuntu bash— same idea on an Ubuntu image. You canapt-get update && apt-get install -y curlas on a real server. The container retains those changes until removed. - Restart and reattach:
docker container start -ai <name>reopens an existing container with its interactive shell. - Attach to a running container:
docker container exec -it mysql bashspawns an additional process inside a live container, perfect for admin tasks on MySQL or nginx. Exiting that shell does not stop the original process. - Alpine and missing bash: Alpine is a tiny distribution (about 5 MB).
docker container run -it alpine bashfails because bash is not bundled; useshinstead:docker container run -it alpine sh. Alpine's package manager isapk, which you can use to install bash if you really need it.
Take away: you can only run binaries already present in the image, unless you install them. Alpine's small footprint (around 4-5 MB) makes it an excellent base for production images. See you in the next video.
Summary
This Docker lesson teaches how to gain shell access inside a running container using two primary commands: `docker container run -it` to start a container with an interactive shell, and `docker containers exec -it` to access an already running container. The lesson covers practical examples with different Linux distributions (nginx, ubuntu) and explains the key behavioral difference: exiting a shell from `docker run` stops the container, while exiting from `docker exec` keeps the container running since it only spawned a secondary process.
Key points
- Use `docker container run -it <image> bash` to start a container and immediately access its shell prompt as the root user
- Use `docker containers exec -it <container_name> bash` to open a shell in an already running container without stopping it
- Linux distributions in containers are minimal compared to virtual machines or physical installations; you can still use package managers (like `apt`) to install additional software
- When exiting a shell from `docker run`, the container stops because the main process (the shell) has ended; with `docker exec`, the container continues running because you only spawned a secondary process
- Container filesystems are isolated—modifications made inside one container (like installing curl with `apt install curl`) persist only in that container instance, not in new containers from the same image
- The container prompt shows `root@<container_id>`, indicating you are running commands as the root user inside that specific container, not the host system
FAQ
What's the difference between `docker run -it` and `docker containers exec -it`?
`docker run -it` creates and starts a new container with an interactive shell, and the container stops when you exit the shell. `docker containers exec -it` attaches to an already running container to execute a command (like bash), and the container continues running when you exit because you only spawned a secondary process.
Why does my container stop when I exit the bash shell?
The container stops because bash was the main process launched by `docker run`. When the main process exits, the container has nothing to keep it running. To keep a container alive while accessing its shell, either use `docker exec` on an already running container, or ensure the container has another primary process running.
Can I install software inside a container like I would on a regular Ubuntu machine?
Yes, you can use the package manager (apt for Debian/Ubuntu-based images) to install software inside a container. However, these changes only persist in that container instance. If you create a new container from the same image, it will not have the newly installed software; you would need to rebuild the image with those dependencies included.