Docker Introduction

• If you are like me and a late-comer to the Docker party, the following pages should help you find your way around in the Docker world.

• Docker is an open-source platform that simplifies building, shipping, and running applications by using containerization.
• It packages an application with everything it needs to run—code, runtime, libraries, and system tools—into a single, portable unit called a container.

There are two primary items that can trip you up.

1. An Image.
2. A Container.

• The image comes first and are used to produce one or more containers.
• Image = recipe / blueprint.
• Container = actual meal / house built from that blueprint.

• Read-only template.
• Contains the OS, code, libraries, env variables — everything needed to run.
• You build it or pull it: (e.g. docker pull nginx)
• It sits there, does nothing until you run it.
• You can make 100 copies from one image.
• Like a class in programming.

• Running instance of an image.
• When you do docker run nginx — Docker creates a container from the nginx image.
• It's alive, has its own process, file system, IP, can be started, stopped, deleted.
• You can change stuff inside a container, but those changes don't affect the image unless you commit them.
• Like an object created from a class.

docker run <image>  -> creates a -> container

• Image is like an ISO file for Ubuntu.
• Container is Ubuntu actually installed and running on your server.
• You can install Ubuntu 10 times from the same ISO.

• Each Docker image consist of various layers.
• This makes images small and fast.
• A Docker image is NOT one big file.
• It's a stack of layers, like a lasagna.
• Each instruction in a Dockerfile = 1 new layer.
• Lets look at a simple sample Dockerfile:

FROM ubuntu         # Layer 1 - base OS
RUN apt install python  # Layer 2 - adds python
COPY app.py .       # Layer 3 - adds your code
CMD python app.py   # Layer 4 - what to run

1. Cache: If you only change app.py, Docker reuses Layer 1 and 2. It only rebuilds Layer 3. Super fast.
2. Sharing: If you have 10 images all FROM ubuntu, you only store that ubuntu layer once on disk.
3. Read-only: Image layers are read-only.

• When you run a container, Docker adds one thin writable layer on top.
• All your changes inside the container go there.
• When you delete the container, that writable layer is gone.
• The image layers stay clean.

[ Writable Container Layer ] <- you write here, deleted when container dies
[ Layer 3 - app.py ]         <- read-only
[ Layer 2 - python ]         <- read-only
[ Layer 1 - ubuntu ]         <- read-only

• That’s why docker run is instant. It doesn't copy anything, it just adds a writable layer.

• Problem: If container layer dies when container dies, where do you keep databases, uploaded files, etc?
• A volume is a folder on your host machine that is mounted into the container. It lives outside the container lifecycle.

# Without volume - data dies with container
docker run postgres
 
# With volume - data survives
docker run -v mydata:/var/lib/postgresql/data postgres

• mydata lives on your host in /var/lib/docker/volumes/
• Container writes to /var/lib/postgresql/data → actually writes to mydata on host.
• Delete container → mydata still there.
• Start new container with same volume → your DB is still there.

1. Named volume mydata:/app/data - managed by Docker, best for databases.
2. Bind mount ./mycode:/app - you link your local folder to container. Great for development, edit code locally, container sees it instantly.
3. Anonymous volume - Docker creates random name, don't use it.

1. Image layers = how the app is built (efficient, shared, read-only)
2. Container writable layer = temporary scratch space (dies)
3. Volume = permanent memory outside the container (survives)

• Image = blueprint
• Layers = pages of the blueprint
• Container = house built from blueprint + a whiteboard inside (writable layer)
• Volume = external garage where you store stuff so it doesn't get lost when you demolish the house.