How Docker Works, and What I’m Learning Next.

One image, repeatable environments

An application depends on more than its source code: it may need a particular runtime, system libraries, and configuration. Docker packages the application and its required environment into an image. That image can then be run on different machines with a more predictable setup, which helps reduce “it works on my laptop” surprises.

A Dockerfile is the recipe for building an image. It starts from a base image, adds application files, installs dependencies, and describes the command to run. The built image is a versioned, read-only template that can be stored in a registry and shared with other machines.

A simplified build might start with a Node.js base image, copy in the app's package files, install dependencies, copy in the source, and set the command that starts the server. The exact steps depend on the project, but the goal is to turn setup instructions into something repeatable. Images are built in layers, which means Docker can reuse unchanged layers on later builds and avoid repeating all the work.

A few useful pieces

A container is a running process created from an image. It has its own isolated view of files and processes, while sharing the host machine's operating system kernel. That shared kernel is one reason containers usually start faster and need fewer resources than a full virtual machine, which runs a whole guest operating system.

A helpful mental model is: an image is a recipe or snapshot, and a container is the running app made from it. You can start multiple containers from one image, stop one, and create it again without changing the image. Containers are isolated from each other, but they are not full virtual machines because the host kernel is shared.

Containers are intended to be replaceable, so important data should live outside the container. Docker volumes keep data between container restarts. Container networks let services find and communicate with each other. Together, images, containers, volumes, and networks provide the basic building blocks for running an application and its dependencies.

What I want to learn next

Docker helps build and run containers, but a real application may need many containers running across multiple machines. Kubernetes is a system for coordinating that work. You describe the state you want, such as keeping three copies of a service running, and Kubernetes works to make the actual state match.

I’m starting to learn its core ideas: a pod is the smallest unit Kubernetes schedules and usually contains an application container; a deployment describes how many pod copies to keep and how to update them; and a service gives a stable way to reach a changing set of pods. Next, I want to try these concepts hands-on and understand how Kubernetes handles health checks, scaling, and recovery when a container stops.

Docker and Kubernetes solve different parts

Docker helps package and run an application container. Kubernetes manages containerized workloads across a cluster of machines: it can place pods on machines, restart failed ones, and route traffic to healthy copies. Kubernetes does not replace the image; it uses a container image as the artifact to run.

My next step is to containerize a small app, run it locally, and then deploy it to a local Kubernetes cluster. I want to observe what changes when I scale a deployment, stop a pod, or update the image. Trying those actions should make the difference between packaging an app and orchestrating it much more concrete.