Search
11 results for “docker”
Search results
Docker Fundamentals
How images, containers, volumes, and networks fit together in Docker's runtime model, and the shift from installing software to running images.
What is the difference between a Docker image and a Docker container?
An image is a read-only, layered filesystem snapshot plus metadata (entrypoint, exposed ports, environment); it never changes once built and can be shared through a registry. A container is a running (or stopped) instance of an image: Docker adds a thin writable layer on top of the image's read-only layers and starts a process inside an isolated namespace. You can start many independent containers from the same image, each with its own writable layer and state, the same way many processes can run from the same binary on a normal OS.
Why does data written inside a container disappear when the container is removed?
Anything a container writes lands in its own writable layer, which is deleted along with the container by `docker rm`. That is deliberate; it is what makes containers disposable and reproducible, a fresh container from the same image always starts from the same known state. Anything that actually needs to survive a container's lifecycle (a database's data files, uploaded assets) has to live outside that writable layer, in a named volume or a bind mount, which Docker mounts into the container at a chosen path but manages independently of the container itself.
Why is publishing a port with `-p 8080:80` different from the container just "having" port 80?
A container's ports exist only on its own private network namespace by default; nothing on the host or outside can reach them until Docker explicitly forwards a host port to it. `-p 8080:80` tells Docker's network layer to forward the host's port 8080 to port 80 inside the container's namespace, host port first, container port second. Leaving a port `EXPOSE`d in a Dockerfile only records metadata/documentation, it has no effect on connectivity at all: another container on the same Docker network can already reach any port the first container is listening on, EXPOSE or not. Publishing to the host is the one thing that always requires an explicit `-p`.
Why Every Container in Your Rolling Deploy Takes an Extra 10 Seconds to Stop
Why npm as PID 1 can prevent Node.js from receiving SIGTERM, trigger Docker's ten-second timeout, and end container shutdown with SIGKILL.
Production-Ready AKS GitOps with Terraform and ArgoCD
The DevOps Project That Finally Made Kubernetes, GitOps, and Terraform Click
Why does GitOps improve auditability compared to engineers running kubectl or terraform apply directly?
Every change to cluster state has to go through a Git commit, which means it inherits Git's existing history, authorship, and (if branch protection is configured) pull-request review, automatically. Direct `kubectl apply` access leaves no equivalent trail: two changes with the same effect are indistinguishable, there's no required review step, and reconstructing "who changed what and why" after an incident means digging through cluster event logs instead of reading a linear, reviewed commit history.
How does GitOps make rollbacks different from a traditional deployment rollback?
In a traditional deploy, rolling back means re-running a deployment process with an older artifact reference, a distinct operation from a normal deploy. In GitOps, a rollback is just a Git revert: since the desired cluster state is fully described by the repository at any commit, reverting to a previous commit and letting the reconciliation loop pick it up produces the previous cluster state through the exact same mechanism as any other change. There is no separate "rollback pipeline" to maintain or that can itself have bugs.
Why does sending SIGKILL to a stuck process work when SIGTERM doesn't, and what does that cost you?
SIGTERM asks a process to terminate but can be caught by a signal handler, letting the process run its own cleanup logic (closing files, flushing buffers, releasing locks) before actually exiting, or in a broken process, being caught and never acted on at all. SIGKILL cannot be caught, blocked, or ignored under any circumstances, the kernel terminates the process directly, which is why it works on a process SIGTERM couldn't reach. The cost is that none of that cleanup logic runs, a database connection isn't closed cleanly, a temp file isn't removed, a lock isn't released, so SIGKILL is a last resort after SIGTERM has been given a real chance to work, not a default first move.
Group Policy: Desktop Backgrounds, Power Plans, Logon Notices
Standardize domain-joined desktops with Group Policy: enforce wallpaper, power settings, and a legal logon notice, with verification steps.
Azure Policy, Tags, and Resource Locks: Governance Guide
Implement Azure governance with Policy, resource tags, and locks: enforce standards, track cost and ownership, and protect resources from deletion.