Containers, Docker & Docker Compose

Section 1

Notebook Summary#

Dense, hand-copyable revision sheet. Every line here is expanded in the Detailed Notes below.

Section 2

Detailed Study Notes#

You finish a feature on Friday, it works perfectly on your laptop, and you push it. Monday morning a teammate pulls the branch and nothing runs — a different Java version here, a missing library there, an environment variable no one wrote down. The code never changed. The surroundings did. Everything below exists to kill that failure mode: package the surroundings with the code, once, and ship them together.

2.1The deployment problem#

Software is built in phases, and the last one — getting it onto users' machines — is where "works on my machine" bites.

A software project moves through a life cycle of about seven phases. For this lesson only the last three matter: the development phase (splitting the project into modules and turning requirements into code), the testing phase (validation and quality assurance — catching functional, UX, and security issues), and the deployment phase (delivering the finished product to its intended users and making it actually usable). Deployment is the step where the environment mismatch above shows up.

2.2What is a container#

A container is a lightweight, self-contained box that holds everything a piece of software needs to run — the code, a runtime, libraries, environment variables, and config files — all sealed together and isolated from other containers.

Because each container bundles its own dependencies and is isolated from the others, the same container behaves the same way on any machine that can run containers. That reproducibility is the whole point.

The natural next question is: isn't that just a virtual machine? Not quite. A virtual machine (VM) carries a full copy of an operating system, so it's large and slow to spin up but strongly isolated — it has its own kernel. A container carries only the app and its dependencies and shares the host machine's kernel, so it's small, fast to create and destroy, but less fully isolated from the host.

2.3The Open Container Initiative (OCI)#

The OCI is a group of companies that agreed on shared container standards so a container built by one tool runs anywhere.

Those standards give containers two properties. Portability means everything needed to run the software lives inside the container. Interoperability means any vendor that supports the standard can run the container without changes. The OCI defines three specifications:

2.4Docker: image vs container#

Docker is an open platform to create, deploy, and run applications in containers. It shrinks the gap between writing code and running it in production, so you ship faster and stop worrying about setting up environments by hand.

Two Docker terms get confused constantly, and the distinction is the most important thing in this lesson. A Docker image is a reusable, shareable, read-only file — a template built from your code, its dependencies, and a Dockerfile. A Docker container is a running instance created from an image: it takes the image's read-only layers and adds a writable layer on top, and it's the thing that actually runs your application.

Where do images come from? A registry is a cloud repository of ready-made images. The default is DockerHub (docker.io); others include AWS ECR, Azure ACR, Google GCR, and Red Hat Quay. Pulling an image mirrors cloning from Git:

docker pull hello-world        # fetch a prebuilt image from a registry
docker run hello-world         # create + start a container from it
docker ps                      # list running containers
docker rm <container-id>        # remove a container (by id or name)
docker image rm hello-world    # remove the image itself

2.5The Dockerfile#

A Dockerfile is a plain text recipe listing the commands Docker runs to build an image automatically.

Instructions are not case-sensitive, but the convention is UPPERCASE so they stand out from their arguments. Comments start with #. Four instructions carry this lesson:

# Sample Dockerfile
FROM ubuntu:latest

WORKDIR /app

RUN ["apt-get", "update"]

CMD echo Hello World from Docker

Build an image from the recipe with docker build:

# "." is the build context (current dir); -t sets the image name:tag
docker build . -t hello-world-2

# point at a custom filename with -f
docker build . -t hello-world-3 -f Dockerfile-server

2.6Port mapping#

Port mapping opens a door on the host and forwards everything arriving there into a port inside the container.

By default a container's ports are sealed inside it. Port mapping exposes a service running in the container to the host machine or the outside network: it links a host port to a container port so that a request hitting the host port is automatically forwarded into the container. The flag is -p, and the order is host first, container second.

# run detached (-d), map host 8000 -> container 8080
docker run -d -p 8000:8080 hello-world-3

# now the host can reach the containerized server
curl -X POST -H "Content-Type: application/json" \
  -d '{"username": "barveabhishek-ab"}' http://localhost:8000

2.7Docker networking#

Docker networking lets containers talk to each other and the outside world, while keeping each one's network isolated.

It's built on the Linux kernel's network namespace — a feature that gives a group of processes their own private network stack. Every container gets its own namespace, so its own network stack. When you start a container it's automatically attached to a default network called the bridge, which lets it reach other containers and the outside.

Docker supports three network modes: bridge (the default, attaches to the default bridge network), none (disconnects the container from all networks), and host (gives the container full access to the host's network stack). The commands:

docker network create mynetwork               # make a custom network
docker network connect mynetwork <container>   # attach a running container
docker run --network mynetwork name:tag        # start already attached
docker network ls                              # list all networks

2.8Docker Compose#

Docker Compose manages many containers at once from a single YAML file, instead of running and wiring them by hand.

Real apps are rarely one container — a server, a client, a database. Starting each with its own docker run and manually creating networks is tedious and error-prone. Compose declares the whole system in one docker-compose.yml: its services (containers), networks, and volumes (persistent storage). A few terms: services are the containers, networks connect them, volumes persist data.

version: '3'                    # compose file format; v3 is standard
services:
  server:
    build:
      context: .                # build context = current dir
      dockerfile: Dockerfile-server
    ports:
      - "8000:8080"             # host:container (needed only if host must reach it)
    networks:
      - mynetwork
  client:
    build:
      context: .
      dockerfile: Dockerfile-client
    depends_on:
      - server                  # start server before client
    networks:
      - mynetwork
networks:
  mynetwork:                     # the shared network both services join

Three commands drive it:

docker-compose build      # build all images from the yml
docker-compose up         # start every service (add -d to run detached)
docker-compose down       # stop containers, remove their networks, clean up

# custom filename:
docker-compose -f my-compose.yml up

Compose looks for docker-compose.yml by default; -f points it at another file. The depends_on key sets start order, and because both services join mynetwork they can talk to each other by service name — no manual networking.

2.9Interview & practice Q&A#

2.10Key takeaways#

• A container seals an app with its dependencies so it runs identically everywhere; it shares the host kernel, unlike a VM.
• An image is the read-only blueprint; a container is a running instance of it (class → object).
• A Dockerfile is the recipe: FROM · WORKDIR · RUN (build time) · CMD (run time). Build with docker build . -t name:tag.
• Port mapping is -p host:container — host first.
• Containers talk only on the same network; modes are bridge · none · host.
• Compose declares many services + networks + volumes in one docker-compose.yml, driven by build / up / down.

Section 3

Microexercises#

Reading proves you recognise the idea; these prove you can use it. Attempt each before opening the walkthrough.

3.1Build it — a Dockerfile and its commands#

# Sample Dockerfile
FROM ubuntu:latest
WORKDIR /app
RUN ["apt-get", "update"]
CMD echo Hello World from Docker

docker build . -t hello-world-2
docker run hello-world-2
# -> Hello World from Docker

3.2Diagnose it — why can't the client reach the server?#

docker network create mynetwork

# server: attached to the custom network, port mapped
docker run -d -p 8000:8080 --network mynetwork server:latest

# client: started with no --network flag
docker run -d client:latest
# client tries to call the server by name and times out

docker run -d --network mynetwork client:latest

docker network connect mynetwork <client-container>