Docker Tutorial 0/48 lessons ~6 min read Lesson 12

    Exec & Attach

    Sometimes you need to peek inside a running container — debug, inspect files, run a one-off command.

    Course progress0%
    Focus
    15 guided sections
    Practice signal
    Examples included
    Career prep
    Interview Q&A included

    Introduction

    Sometimes you need to peek inside a running container — debug, inspect files, run a one-off command. docker exec runs a new process inside an existing container; docker attach hooks into the main process's stdin/stdout.

    Purpose of this lesson

    This lesson teaches Exec & Attach as an engineering decision: what problem it solves, when to use it, how to implement it safely, and what signals tell you it is failing.

    Understanding the topic

    Use this in day-to-day container operations: pulling images, running processes, inspecting failures, publishing artifacts, and keeping the Docker host clean and predictable.

    Core concepts to understand:

    • docker exec -it <name> sh opens a shell.
    • docker exec <name> ls /app runs a one-shot command.
    • docker attach connects to PID 1's I/O — Ctrl-C may stop the container!
    • Exec runs as the container's user (often non-root); use -u root to override.

    Visual explanation

    Architecture or command flow to keep in mind:

    bash
    docker exec -it api sh
    /app # ls
    package.json node_modules dist
    /app # cat /etc/os-release | head -2
    NAME="Alpine Linux"

    Step-by-step explanation

    1. Run the command or manifest exactly once on a clean Docker host and read the output carefully.
    2. Inspect the object Docker created: image, container, network, volume, port mapping, process, or registry tag.
    3. Break one realistic assumption such as a missing port, bad tag, stopped daemon, wrong network, or deleted volume.
    4. Use docker ps, logs, inspect, stats, and system df to locate the failure.
    5. Write the final command or configuration into a repeatable script, Compose file, or CI job.

    Informative example

    Use the example below as a working baseline, then verify the runtime behavior instead of assuming the command or file is correct.

    bash
    docker exec -it api sh
    /app # ls
    package.json node_modules dist
    /app # cat /etc/os-release | head -2
    NAME="Alpine Linux"

    A production-minded check usually includes docker ps, docker logs, docker inspect, and one validation from outside the container such as curl, a database connection, or a registry pull.

    bash
    # Verification loop for Exec & Attach
    docker ps -a
    docker logs --tail=100 <container-name>
    docker inspect <container-or-image-name>
    docker system df

    Real-world use

    On-call engineers exec into a misbehaving container to check disk usage, env vars, or logs before deciding whether to restart it.

    Enterprise use cases

    In a mature engineering organization, Exec & Attach is documented as a repeatable pattern with approved base images, ownership labels, CI checks, security expectations, rollback notes, and troubleshooting commands. The difference between a tutorial and production practice is that every container decision must be observable, reviewable, and reversible.

    Best practices

    • Prefer exec over attach — safer.
    • Use docker exec -it … sh for alpine, bash for debian-based images.

    Common mistakes

    • Attaching and pressing Ctrl-C kills the main process and stops the container.

    Debugging tips

    • Read logs before restarting; a restart often removes the timing context you need for root cause analysis.
    • Use docker inspect to compare configured state with actual runtime state.
    • Check daemon health, disk usage, image tags, exit code, and port mappings before blaming application code.

    Optimization strategies

    • Prefer explicit names, labels, tags, and networks so cleanup and debugging stay predictable.
    • Pin versions for repeatability, then update intentionally through a scheduled base-image refresh.
    • Use docker system df and targeted prune commands to control local and CI disk growth.

    Advanced interview questions

    Interview Prep

    Practice concise answers, then expand each card for the explanation.

    3 questions
    1QuestionDifference between exec and attach?+

    Answer

    A strong answer for Exec & Attach should define the concept, explain the Docker component involved, give one real use case, and name at least one failure mode plus the command you would use to investigate it.
    2QuestionWhy might <code>bash</code> not exist in a container?+

    Answer

    A strong answer for Exec & Attach should define the concept, explain the Docker component involved, give one real use case, and name at least one failure mode plus the command you would use to investigate it.
    3QuestionHow do you run a command as root inside a non-root container?+

    Answer

    A strong answer for Exec & Attach should define the concept, explain the Docker component involved, give one real use case, and name at least one failure mode plus the command you would use to investigate it.

    Hands-on exercise

    Create a small lab for Exec & Attach: run the example, inspect the created Docker object, intentionally introduce one mistake, and record the command that reveals the failure. The goal is not just to make the happy path work; it is to build operational reflexes.

    bash
    # Hands-on lab scaffold
    mkdir -p docker-exec-attach-lab
    cd docker-exec-attach-lab
    # Add the Dockerfile, compose.yml, or command from this lesson.
    # Then run one happy-path test and one broken-path test.
    docker version
    docker info
    docker system df

    Summary

    Exec & Attach matters because Docker is not only a packaging tool; it is a runtime, build, networking, storage, and delivery workflow. Treat each lesson as a production habit: make it repeatable, inspectable, secure, and easy to debug.

    Ready to mark this lesson complete?Track your journey across the entire course.