Docker

ARG is a build-time variable: it exists only while docker build runs, is set with --build-arg, and is gone at runtime. ENV is baked into the image, so it exists during the build and is present as an environment variable in every container started from the image.

FROM sets the filesystem your image starts from. Full distro images have every tool but are large; -slim strips docs and extras; Alpine is tiny but uses musl libc; distroless ships only the runtime with no shell or package manager; scratch is empty and only fits static binaries. Pick the smallest image that still runs and that you can still debug.

The classic builder ran instructions strictly top to bottom, one container per step. BuildKit builds a dependency graph, so independent stages run in parallel, unused stages are skipped, and only the build-context files actually needed are transferred. It also adds features the old builder lacks: secret, cache and ssh mounts, and multi-platform builds.

ENTRYPOINT is the executable that always runs; CMD gives default arguments, or the whole command when there is no ENTRYPOINT. Arguments after the image name in docker run replace CMD but are appended to ENTRYPOINT.

The . is the build context: the directory tree the CLI packages up and hands to the builder before building. Only files inside it can be used by COPY, and everything not excluded by .dockerignore is transferred.

Each build instruction becomes a cached layer, and once one instruction misses the cache every later one is rebuilt. Copying source first means any code edit invalidates the dependency install. Copy the manifest, install, then copy source, so installs stay cached until dependencies change.

A tag is a mutable label the registry can repoint at new content at any time. A digest is the sha256 hash of the image manifest, so one digest always resolves to byte-identical content. Tags name an image; digests identify it.

It lands in the container's own thin writable layer on the host, on top of the read-only image layers. Removing the container deletes that layer and the data. Image layers are never written to, which is why many containers can share one image.

Every Dockerfile instruction commits its own read-only layer. A later layer can only mark files as deleted; the bytes still sit in the earlier layer and still ship. Delete in the same RUN that created the files.

For RUN the key is the literal command string plus the parent layer and environment — the builder never inspects what the command would produce. For COPY and ADD from the build context the key is a checksum of the copied files' content and metadata. Any mismatch rebuilds that step and everything below it.

docker cp streams a tar archive through the Docker Engine API, so the daemon does the extraction and the image needs no shell or tar binary. It works on stopped containers, expands no wildcards, and does not preserve ownership unless you pass -a.

Use docker run --device /dev/ttyACM0:/dev/ttyACM0. Docker creates that one device node inside the container and permits it in the container's device allow-list. --privileged works only by unlocking every host device at once, which is far too broad.

docker exec starts a new process inside a running container; exiting it leaves the container alone. docker attach connects your terminal to the container's existing main process (PID 1), so Ctrl+C sends SIGINT to that process and usually stops the container.

docker ps -a shows Exited (N) in the STATUS column, and docker inspect --format '{{.State.ExitCode}}' <container> gives the number. 0 means the main process finished successfully; any non-zero value means it failed — 1 is the generic "the application errored" code.

It tells Docker a command to run periodically inside the running container to test whether the app actually works. Exit 0 means healthy, 1 means unhealthy. The result shows in docker ps as (healthy), (unhealthy) or (starting) next to the container's uptime, with details in docker inspect.

Every container started without --network lands on the shared default bridge, docker0, where peers can only be reached by IP address. A bridge you create with docker network create adds name-based discovery, membership-scoped isolation and per-network options.

On a user-defined network Docker runs an embedded DNS server at 127.0.0.11 that resolves container names and network aliases to container IPs. The built-in default bridge network has no such DNS: there you only have raw IPs or the deprecated --link flag.

bridge gives the container its own network namespace on a virtual switch with NAT for outbound traffic and published ports for inbound - the default. host puts the container directly in the host's network namespace: no isolation, no NAT, no port publishing. none gives a namespace with only loopback: no external networking at all.

Run docker network create appnet, then start containers with --network appnet. A running container is attached later with docker network connect appnet NAME and removed with docker network disconnect. Membership gives an interface and IP on that bridge, so members reach each other on any port. Docker's isolation iptables rules block traffic between different bridges.

The form is host:container, so -p 8080:80 sends traffic arriving at host port 8080 to port 80 in the container. Capital -P publishes every EXPOSEd port to a random free host port; docker port shows the result. The container process must listen on 0.0.0.0, not 127.0.0.1, or nothing reaches it.

Create with docker volume create name, list with docker volume ls, see its host path and driver with docker volume inspect name, attach with -v name:/path. Named volumes outlive containers: deleting the container leaves the volume until you run docker volume rm.

A bind mount maps a host path into the container — good for local source code and config. A named volume is Docker-managed storage that outlives containers — good for databases and app data. A tmpfs mount lives only in RAM — good for scratch files and secrets.

A bind mount is a passthrough to the same host inodes; Docker translates nothing. The kernel records the numeric UID of the writing process, and containers run as UID 0 by default, so the host sees root-owned files.

Every container started from that image gets a fresh anonymous volume (a random 64-hex-character name) mounted at /var/lib/data unless the run command supplies its own mount. Each docker run creates another one, and they are only cleaned up by --rm, docker rm -v or a prune — hence the pile-up.

Options: pass --user with the host's numeric UID/GID at run time; bake the UID in at build time with a build argument; or start as root, chown the mount in an entrypoint, then drop privileges with gosu. Each trades reproducibility against portability.

The registry answered with an auth error, and the client cannot tell "no such repository" from "you are not allowed". Check the image reference includes the registry hostname, run docker login <registry> with valid credentials, and confirm your account has pull rights on that repository.

Already exists means that layer, identified by its sha256 digest, is already in the host's local image store, so nothing is transferred. Downloading is the compressed layer blob arriving from the registry. Extracting is that blob being decompressed and unpacked onto disk.

Docker Hub counts image manifest requests, not layers or bytes. Anonymous pulls are counted per source IP address and get the smallest quota; authenticated pulls count against your Docker account and get more; paid plans get more still. First fix: docker login on the machine that pulls.

The git-SHA tag is a permanent name for one exact build, so it can be redeployed later and traced back to a commit. The stable tag only points at whichever build is current, so it answers what is live now, not what shipped when.

:latest is an ordinary mutable tag with no special meaning — it is not "the newest image". Different hosts can run different content under the same name, rollback has nothing to roll back to, and caching makes it unpredictable. Deploy explicit version tags resolved to digests.

The platform chooses the port, passes it in as an environment variable, and then connects to the container's IP on that port. An app that hardcodes a different port, or listens only on 127.0.0.1, is unreachable from outside its own network namespace.

Pull the new image while the old container still serves, then stop it, remove it and run a new container on the new tag. Pin an immutable tag, and keep the previous image for rollback.

A scheduler takes over the host-shaped docker run flags — --restart, -p, -v, --cpus, --memory and health checking — restating them as fields in its own spec. The image keeps what it runs and as whom: ENTRYPOINT/CMD, USER, its filesystem, and logging to stdout.

Two supervisors watch one container and systemd watches the wrong process. docker run -d exits at once, so the unit looks dead while the container runs, and the engine's restart policy revives a container systemd stopped.

Mostly no. The engine runs HEALTHCHECK and records healthy/unhealthy, but takes no action on it; a scheduler declares its own probes in its spec and acts on those. Kubernetes ignores the image's HEALTHCHECK entirely. Keep the check command in the image — the probe definition moves out.

--privileged grants all Linux capabilities, disables the default seccomp and AppArmor/SELinux confinement, lifts the cgroup device restrictions so all host devices are usable, and mounts /sys writable. With that, a process can mount the host disk or load kernel modules — effectively host root.

The scanner inventories everything installed in the image (OS packages per layer plus app dependencies), determines each component's name and version, then matches those against vulnerability databases (like the NVD and distro advisories). Matches are reported as CVEs with severities. It is metadata matching, not runtime analysis.

The Docker daemon runs as root and docker group members can talk to its socket. One container that bind-mounts the host filesystem gives them full root. Offer rootless Docker, Podman, or a narrow sudo rule instead.

Build arguments are recorded in the image's build history, and any ENV keeps the value in image config. Anyone who pulls the image can read them with docker history or docker inspect, or by unpacking the saved image — and deleting a file later does not remove earlier layers.

By default the container process runs as UID 0, the same UID 0 the host kernel calls root. A USER instruction runs it as an unprivileged UID, so escapes, bind mounts and host files get no root rights. It is defence in depth, not isolation.

The Docker Engine API is the JSON-over-HTTP API that dockerd serves, by default on the unix socket /var/run/docker.sock. The docker CLI holds no container logic: each command becomes an HTTP request such as POST /containers/create.

Docker Desktop boots a small Linux virtual machine and runs dockerd inside it. The docker command you type on macOS or Windows is only a client talking to that daemon, so every Linux container is a process inside the VM.

docker image prune deletes only dangling images: untagged layers orphaned when a tag moved to a newer build. Adding -a deletes every image that no container references, including tagged images you still want.

docker inspect prints a JSON array holding the engine's full low-level record for each named object — State, Config, HostConfig, NetworkSettings, Mounts. --format (or -f) applies a Go template to each object, so docker inspect -f '{{.State.Status}}' web prints just that field.

The docker CLI reaches dockerd through the unix socket /var/run/docker.sock, which is owned by root and group docker. Add your user with sudo usermod -aG docker $USER, then open a new login session so the group takes effect.

--push is shorthand for --output type=registry: buildx streams the finished layers from the builder straight to the registry. On a docker-container builder the image never enters the local image store, so a separate docker push would find nothing to push.

A bind mount maps a host directory onto a path inside the running container, so an edit on the host is visible to the process instantly. Source baked in with COPY changes only when you rebuild the image.

A non-zero exit from any RUN command aborts docker build immediately: no layer is committed for that step and no image is tagged. Running the test suite in a RUN step is what turns a failing test into a failing build.

It creates a builder instance backed by a BuildKit container rather than the BuildKit embedded in the daemon. That driver is what unlocks exporting cache to an external backend, building for other platforms, and a custom BuildKit config.

Because the debug agent is listening on the container's own loopback address, so the published port forwards to nothing. Bind the agent to all interfaces instead - JDWP address=*:5005, debugpy --listen 0.0.0.0:5678 - and the attach succeeds.

Re-run the build with --progress=plain. The default progress display collapses each step to its last few lines, while plain mode streams every line of every step, prefixed with the step number and elapsed seconds, and leaves it all on screen.

Run docker ps -a: the container is still listed, with a STATUS such as Exited (1) 20 seconds ago that says whether it ran and died or never started. Then docker logs on that container shows what it printed.

docker exec starts a process from the container's own filesystem, and a scratch or distroless image ships no /bin/sh to start. Bring tools from outside instead: nsenter from the engine host, a toolbox container sharing its namespaces, or a copied static binary.

Because /proc is not namespaced. free and top read /proc/meminfo, which is host-wide, so a --memory limit is invisible to them. Read the container's cgroup files (/sys/fs/cgroup/memory.max and memory.current) or docker stats instead.

docker stats streams a live per-container line: CPU %, MEM USAGE / LIMIT, MEM %, NET I/O, BLOCK I/O and PIDS. The daemon computes them from the containers' cgroup counters on the host, not from tools running inside the containers.

Yes. Dockershim was the Kubernetes node agent's built-in adapter for talking to Docker Engine, and only that adapter was removed. An image is a standard OCI artefact, so containerd and CRI-O pull and run exactly the same images.

Namespaces are a kernel feature that gives a process its own view of a global resource. Separate namespaces exist for process IDs, network stacks, mounts, hostname, IPC, users and cgroups. A container is just a process placed in a fresh set of them.

image-spec defines the image format on disk and on the wire: layers, an image config, a manifest, and an index, all addressed by digest. distribution-spec defines the registry HTTP API used to push and pull those blobs. runtime-spec defines the unpacked bundle — a rootfs directory plus config.json — that a runtime such as runc executes.

The docker CLI is a thin HTTP client. It sends a request over the Unix socket /var/run/docker.sock to the long-running daemon dockerd, which does all the real work — pulling images, creating containers, managing networks — and streams results back. Containers are children of the daemon's stack, not of your shell.

A virtual machine virtualizes hardware: the hypervisor gives each guest its own kernel and virtual devices. A container virtualizes the operating system: processes share the host kernel and are isolated by kernel features. A container is a process, not a machine.