Containers, images and registries

The problem containers solve

An app needs more than its code. It needs the right language version, libraries, system packages and settings. When any of these differ between a laptop and a server, the app breaks, and you hear the famous line "but it works on my machine". A container packages the app together with all of that, so the same package runs the same way everywhere.

Containers versus virtual machines

A virtual machine (VM) pretends to be a whole computer. It runs its own full operating system, including its own kernel (the core of the operating system that talks to the hardware). A container does not. It is a normal process on the host that shares the host's kernel, and Linux features called namespaces and cgroups give it its own view of files, network and processes, and limits on CPU and memory.

Because containers share a kernel, their isolation is weaker than a VM's. That is why cloud services often run containers inside lightweight VMs. AWS Fargate, for example, gives each task its own isolation boundary that does not share a kernel with other customers' tasks.

Images and layers

An image is a read-only template for a container: a small file system, your app and the command to start it. A container is a running instance of an image, with a thin writable layer on top. You can start many containers from one image.

An image is made of layers. Each instruction in a Dockerfile that changes files (such as COPY or RUN) adds a layer. Layers are cached and shared: if ten images use the same python:3.12-slim base, a server downloads that base only once, and a rebuild reuses every layer that did not change.

A small Dockerfile

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
RUN useradd --create-home appuser
USER appuser
EXPOSE 8080
CMD ["gunicorn", "--bind", "0.0.0.0:8080", "app:app"]

Registries

A registry stores and serves images. You push an image to it once, and every server or cloud service pulls from it. The image reference says where the image lives.

Google Artifact Registry replaced the older Container Registry, so new Google Cloud projects use Artifact Registry.

Build and push to Amazon ECR

aws ecr create-repository --repository-name orders-api --region ap-south-1
aws ecr get-login-password --region ap-south-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-south-1.amazonaws.com
docker build -t orders-api:1.0.0 .
docker tag orders-api:1.0.0 123456789012.dkr.ecr.ap-south-1.amazonaws.com/orders-api:1.0.0
docker push 123456789012.dkr.ecr.ap-south-1.amazonaws.com/orders-api:1.0.0

Tags versus digests

A tag such as 1.0.0 or latest is a label that points to an image. Tags can be moved: someone can push a different image with the same tag. A digest such as sha256:3f9c... is a hash of the image content. It always points to exactly one image and can never change. You can write both: orders-api:1.0.0@sha256:3f9c...

Why containers suit microservices

A microservice is a small service that does one job, such as payments or notifications, and talks to others over the network. Containers fit them well: each service has its own image with its own language and libraries, can be released on its own schedule, and can be scaled on its own. The same image moves unchanged from a developer laptop to testing to production.