Temporary Shell Containers for Maintenance and Diagnostics

1. The Concept: Tools Only for the Duration of the Task

The core principle behind temporary shell containers is simple: every tool needed for a diagnostic or maintenance task is brought in inside a container that vanishes without a trace once the task is done. No apt-get install curl on the production server, no pip install, no back door tools that stay installed permanently because "we needed them once." At the end of the maintenance task, the server itself is in exactly the same state it was before.

This is not a theoretical ideal, it is a practical workflow: docker run --rm -it --network container:myapp nicolaka/netshoot spins up a tool image with hundreds of network diagnostic utilities in the network namespace of the running container, in a matter of seconds. Once the shell exits, the temporary shell container is completely removed. For the operator, it feels like an extended shell inside the container, without ever touching the main container itself.

For recurring maintenance tasks, temporary shell containers can be defined as shell functions or Makefile targets. Instead of memorizing a complex docker run command, you simply call make db-shell or ./bin/db-shell, which internally starts a temporary shell container with all the required parameters. That lowers the barrier and makes the workflow reproducible for the whole team.

2. Basic Pattern: Running docker run --rm Interactively

The --rm flag is the single most important flag for temporary shell containers: it makes sure the container is deleted automatically once it exits. Without --rm, stopped container instances pile up, consuming disk space and cluttering the output of docker ps -a. Adding -it provides an interactive terminal; without this flag the shell would exit immediately because no input would be possible.

Choosing the right base image for temporary shell containers determines which tools are available. For general diagnostic work, alpine:latest combined with an apk add is often enough, though the downside is that the apk add step runs every single time. A prebuilt diagnostic image that already contains everything you need is a better choice. nicolaka/netshoot is the de facto standard image for network diagnostics in container environments and ships with more than 100 network tools.

# Temporary shell container patterns: all containers auto-remove on exit

# Basic interactive shell in alpine (with package install on demand)
docker run --rm -it alpine:latest sh

# Network diagnostic shell in the same network as the app stack
docker run --rm -it \
  --network myproject_default \
  nicolaka/netshoot

# Attach to the exact network namespace of a running container
# Sees the same network interfaces, routing table, and open ports as the target container
docker run --rm -it \
  --network container:myapp \
  nicolaka/netshoot

# Quick HTTP test to an internal service (no curl on the production host needed)
docker run --rm \
  --network myproject_default \
  curlimages/curl:latest \
  curl -sv http://php-fpm:9000/status

# Temporary DNS resolution test
docker run --rm \
  --network myproject_default \
  alpine:latest \
  sh -c "nslookup mysql && nslookup redis"

# One-shot command with --rm, runs the command, removes the container, and returns the output
docker run --rm \
  --network container:myapp \
  busybox \
  sh -c "netstat -tlnp"

3. Network Diagnostics in the Container Stack

Network problems in Docker Compose stacks are often hard to diagnose because containers run in isolated networks that host tools cannot see directly. A temporary shell container in the same Docker network can access the stack's service names directly and test DNS resolution, TCP connections, and HTTP endpoints. That replaces guesswork about whether a service is reachable internally with concrete measurements.

With --network container:CONTAINER_NAME, the temporary shell container fully takes over the network namespace of the target container. It sees the same network interfaces, the same routing table, and the same open ports, and can establish connections from exactly the same perspective the target container would have. That matters for diagnoses that depend on the container's viewpoint, such as whether an outbound connection to an external API endpoint is reachable from inside the container.

For latency and bandwidth measurements between containers, iperf3 inside the temporary shell container delivers precise readings. Packet captures with tcpdump in the network namespace of the target container show exactly which packets reach the container, without needing tcpdump permanently installed in the main container image. Before temporary shell containers, this level of diagnostic depth was only achievable by installing tools on the host.

4. Namespace Sharing: Seeing Other Containers' Processes and Network

Linux namespaces are the technical foundation of container isolation. Docker lets you start temporary shell containers so that they share specific namespaces with another container. That enables deep diagnostic insight without modifying the main container. Network namespace sharing was already described above. With --pid container:CONTAINER_NAME, the temporary shell container sees every process of the target container and can run strace, lsof, or perf against them.

IPC namespace sharing with --ipc container:CONTAINER_NAME allows access to the shared memory segments of the target container. This is relevant for diagnostics when a process communicates via shared memory and that communication needs to be observed. In practice, network and PID namespace sharing is the most common combination for container diagnostics.

It is important to understand that namespace sharing does not grant privileges the target container does not already have. If the main container runs as a non-root user without privileged capabilities, the temporary shell container operating in that process's PID namespace cannot perform privileged operations either. For deeper system level diagnostics that require privileged capabilities, the temporary shell container must be started with --privileged, something that should only happen on production systems in genuine emergencies with deliberate risk management.

5. Choosing the Right Diagnostic Image for Each Purpose

Choosing the right diagnostic image is essential to getting value out of a temporary shell container. An image that is too minimal will lack the tools you need. An image that is too large takes too long to pull. The solution is a curated collection of specialized diagnostic images kept on hand for different tasks:

For network diagnostics, nicolaka/netshoot (roughly 400 MB) is the most comprehensive image, bundling curl, wget, dig, nmap, tcpdump, iperf3, ngrep, ss, ip, and many more tools. For simple tests, curlimages/curl (under 10 MB) is enough. For DNS specific diagnostics, alpine/bind-tools provides dig, nslookup, and host. For MySQL diagnostics, the official mysql client container is ideal, and for PostgreSQL, postgres with just the client binary. For general purpose UNIX diagnostics, busybox at under 5 MB is often sufficient.

# Reference card: the right diagnostic image for the right task

# Network: comprehensive toolset (curl, dig, tcpdump, nmap, iperf3...)
docker run --rm -it --network container:myapp nicolaka/netshoot

# HTTP test only, minimal image (under 10 MB)
docker run --rm --network myproject_default curlimages/curl curl -sv http://app:8080/health

# DNS diagnosis
docker run --rm --network myproject_default alpine/bind-tools dig mysql A

# MySQL client shell (no mysql client on the host required)
docker run --rm -it \
  --network myproject_default \
  mysql:8.4 \
  mysql -h mysql -u root -prootpass appdb

# Redis CLI
docker run --rm -it \
  --network myproject_default \
  redis:7-alpine \
  redis-cli -h redis

# PostgreSQL client
docker run --rm -it \
  --network myproject_default \
  postgres:16-alpine \
  psql -h postgres -U appuser appdb

# Certificate inspection, no openssl on the host needed
docker run --rm alpine/openssl s_client -connect mironsoft.de:443 -showcerts </dev/null 2>&1 \
  | openssl x509 -noout -dates

# File operations and shell utilities, minimal 5 MB image
docker run --rm -it --network myproject_default busybox sh

6. Database Access via Temporary Client Containers

The most common use case for temporary shell containers in production environments is database access for diagnostics and maintenance. Instead of installing a MySQL client on the production server, you start a temporary shell container with the matching database image and connect from there to the database container. That means no database port has to be exposed externally, all credentials stay inside the container network, and the client is gone once the session ends.

For database dumps, the pattern is especially elegant: docker run --rm --network myproject_default -v /backup:/backup mysql:8.4 mysqldump -h mysql -u root -prootpass appdb | gzip > /backup/appdb-$(date +%Y%m%d).sql.gz. The dump tool runs inside the temporary shell container, has direct access to the database over the internal network, and writes the dump to a volume mounted on the host. Once it finishes, the container is gone and the dump sits on the host.

For migration diagnostics, where you need to inspect the exact SQL state after a failed migration, direct database access via a temporary shell container is the fastest tool available. An interactive MySQL client inside the container, pointed at the production database, allows ad hoc queries without bypassing the application logic. That is more powerful than ORM based diagnostics and faster than writing a diagnostic script.

7. Filesystem Diagnostics Without Exec Into the Main Container

A common misconception: docker exec -it container_name sh is not always available or desirable. Minimal images without a shell binary, such as scratch based or distroless images, do not permit docker exec at all. And in production environments, you do not want to burden the main container with a shell session that could accidentally modify files. Temporary shell containers with shared volumes offer a safer alternative.

With --volumes-from CONTAINER_NAME, the temporary shell container takes over all the volumes of the target container and can read, and write, their contents, which should be used with care. For pure diagnostics, use :ro for read only access: -v myapp_data:/data:ro. That lets you inspect the target container's filesystem state without risking accidental changes.

For log analysis, this pattern is especially useful: a temporary shell container with grep, awk, jq, and less mounts the log volume of the production container and allows analysis without putting load on the production container. That is more efficient than copying logs to the host and enables real time analysis with tail -f.

8. Temporary Containers vs. Installing Tools on the Host

The alternative to temporary shell containers is the classic approach: install tools on the host or in the container when they are needed. That sounds simpler, but it carries significant drawbacks that accumulate over time.

The decisive argument for temporary shell containers is not convenience, it is correctness: a network diagnostic tool on the host sees the host network, not the container network. A connection that works from the host to the MySQL container through port mapping says nothing about whether containers can communicate internally via service names. Only a temporary shell container in the right network delivers the correct perspective.

9. Security: What Temporary Containers Should and Should Not Do

Temporary shell containers are not a blank check for unrestricted production access. Capability requirements should be kept minimal: no --privileged for routine diagnostic tasks, no unrestricted network access to every container. The principle of least privilege applies to diagnostic containers too. A container used for DNS diagnostics does not need write access to volumes, and a container used for log analysis does not need network access.

In automated environments, access to temporary shell containers should be logged. Who ran which command, in which container, and when? For compliance requirements, an audit daemon (auditd) on the host can capture every docker run invocation for an audit log. In Kubernetes environments, kubectl debug sessions with ephemeral containers offer the equivalent pattern for temporary diagnostic containers, with built in RBAC control.

One critical point: a temporary shell container started with --volume /:/host, mounting the entire host filesystem tree, is no longer a temporary container in any meaningful sense, it effectively has root access to the host. Equally problematic: docker run --rm -it --pid host ... grants visibility into every process on the host. These options should only be used on production systems in genuine emergencies with explicit approval, and the action should be logged.

10. Summary

Temporary shell containers using docker run --rm are the modern tool for container diagnostics and maintenance. They bring diagnostic tools in with the right network perspective, leave no residue behind, and are more precise than host tools thanks to their container environment. Namespace sharing gives insight into running containers without modifying their code or image. Specialized diagnostic images like nicolaka/netshoot provide all the tools needed for network, process, and filesystem diagnostics.

Investing in wrapper scripts and Makefile targets for common shell container tasks makes this pattern accessible to the whole team. The security principle of least privilege applies to diagnostic containers as well: --privileged only in a genuine emergency, read only volume mounts for log analysis, and logging of all diagnostic sessions in regulated environments. With these guidelines, temporary shell containers are a safer and more powerful alternative to the classic approach of installing tools directly on the server.

11. FAQ: Temporary Shell Containers