**Docker Fundamentals — Part 2** In [Part 1: What Is Docker? Why It Exists and How Containers Solved “It Works on My Machine”](https://www.kodane.dev/posts/what-is-docker-why-it-exists-and-how-containers-solved-it-works-on-my-machine), we looked at the problem Docker was created to solve: inconsistent environments. We explored how applications can behave differently across development, testing, staging, and production environments, and how containers help create more consistent environments. But understanding **why Docker exists** is only the beginning. Now it's time to look under the hood. If Docker helps us package and run applications consistently: * What exactly are we packaging? * What is a Docker image? * What is a container? * What does a Dockerfile actually do? * What happens when we run `docker build`? * And how does an image eventually become a running application? Let's break it down. > **New to the series?** Start with [Part 1: What Is Docker? Why It Exists and How Containers Solved “It Works on My Machine”](https://www.kodane.dev/posts/what-is-docker-why-it-exists-and-how-containers-solved-it-works-on-my-machine). --- ## 1. The Docker Mental Model Before looking at individual concepts, remember this simple relationship: ```text Dockerfile │ │ docker build ▼ Docker Image │ │ docker run ▼ Docker Container ``` A **Dockerfile** contains the instructions for creating an image. A **Docker image** is the packaged application and everything it needs to run. A **container** is a running instance of that image. Think of it this way: > **Dockerfile = recipe** > **Image = prepared meal** > **Container = the meal being served** You can use the same image to create multiple containers. ```text Docker Image / | \ / | \ ▼ ▼ ▼ Container Container Container ``` This distinction is extremely important. --- # 2. What Is a Docker Image? A **Docker image** is a read-only template used to create containers. It contains the files, application code, dependencies, libraries, and configuration needed to run an application. For example, imagine you have a Django application. Your application might require: ```text Python Django Django REST Framework PostgreSQL client libraries Redis client Application code System dependencies ``` A Docker image can package the required runtime environment and application into a reproducible artifact. Instead of telling another developer: > Install Python, create a virtual environment, install these packages, install these system dependencies... you can give them an image that contains what the application needs. This is one of the ideas that makes Docker powerful: > **The environment becomes something you can package, reproduce, and distribute.** --- # 3. Images Are Built in Layers Docker images are made up of **layers**. A simplified image might look like this: ```text ┌─────────────────────────────┐ │ Application Code │ ├─────────────────────────────┤ │ Python Packages │ ├─────────────────────────────┤ │ Python Runtime │ ├─────────────────────────────┤ │ Base Linux Files │ └─────────────────────────────┘ ``` Each instruction in a Dockerfile can contribute a layer. For example: ```dockerfile FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . ``` Docker can reuse layers that haven't changed. For example, if your application code changes but `requirements.txt` hasn't changed, Docker can often reuse the dependency-installation layer instead of installing everything again. This is one reason Docker builds can become significantly faster after the initial build. It also explains why the order of instructions in a Dockerfile matters. --- # 4. What Is a Docker Container? A **container is a running instance of a Docker image**. If an image is the blueprint, the container is the running application created from that blueprint. For example: ```bash docker run python:3.12 ``` Docker takes the `python:3.12` image and creates a container from it. You can have: ```text python:3.12 image │ ├── Container A ├── Container B └── Container C ``` Each container is isolated from the others while sharing the underlying host's kernel. This gives you a lightweight way to run applications and services independently. --- # 5. Image vs Container This is one of the most common things beginners confuse. ### Image An image is the packaged template. ### Container A container is an instance created from that image. A useful analogy: ```text Class → Object Image → Container ``` Or: ```text Recipe → Meal Dockerfile → Image Image → Container ``` The important thing to remember is: > **You don't run a Dockerfile. You build an image from it and run a container from that image.** --- # 6. What Is a Dockerfile? A **Dockerfile** is a text file containing instructions that Docker uses to build an image. A simple Dockerfile might look like this: ```dockerfile FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD ["python", "main.py"] ``` Let's break this down. --- # 7. Understanding `FROM` ```dockerfile FROM python:3.12-slim ``` `FROM` specifies the base image. In this example, we're starting with an image that already contains Python 3.12 on a slim Linux distribution. Instead of building Python ourselves, we use an existing image. You will commonly see: ```dockerfile FROM python:3.12-slim ``` or: ```dockerfile FROM node:22-alpine ``` or: ```dockerfile FROM nginx:alpine ``` The appropriate base image depends on what your application needs. --- # 8. Understanding `WORKDIR` ```dockerfile WORKDIR /app ``` This sets the working directory inside the image and container. After this instruction: ```text /app ``` becomes the working directory for subsequent instructions. For example: ```dockerfile WORKDIR /app COPY . . ``` means: > Copy the application files into `/app`. Using `WORKDIR` is cleaner than repeatedly specifying paths manually. --- # 9. Understanding `COPY` ```dockerfile COPY requirements.txt . ``` This copies a file from your local build context into the image. For example: ```text docker-demo/ ├── Dockerfile ├── requirements.txt └── main.py ``` After: ```dockerfile COPY requirements.txt . ``` the image contains: ```text /app/ └── requirements.txt ``` Later: ```dockerfile COPY . . ``` copies the rest of the application into the image. --- # 10. Understanding `RUN` ```dockerfile RUN pip install -r requirements.txt ``` `RUN` executes a command while the image is being built. For example: ```dockerfile RUN apt-get update ``` or: ```dockerfile RUN pip install -r requirements.txt ``` or: ```dockerfile RUN npm install ``` The result becomes part of the image. This distinction is important: ```text RUN ↓ Executed during image build ``` while: ```text CMD ↓ Executed when the container starts ``` --- # 11. Understanding `CMD` Consider: ```dockerfile CMD ["python", "main.py"] ``` `CMD` defines the default command that should run when a container starts from the image. So when you run: ```bash docker run myapp ``` Docker starts the container and executes: ```bash python main.py ``` A Django production image might eventually use: ```dockerfile CMD ["gunicorn", "core.wsgi:application"] ``` The exact command depends on your application. --- # 12. Understanding `EXPOSE` You may also see: ```dockerfile EXPOSE 8000 ``` This documents that the application inside the container listens on port `8000`. For example, Django commonly runs on: ```text 8000 ``` However, `EXPOSE` does **not** publish the port to your host machine. To make the container's port accessible from your computer, you need port mapping: ```bash docker run -p 8000:8000 myapp ``` The relationship is: ```text Your computer Container 8000 → 8000 ``` Now you can access the application through: ```text http://localhost:8000 ``` --- # 13. Building Your First Docker Image Let's create a very small Python application. Our project: ```text docker-demo/ ├── Dockerfile └── main.py ``` `main.py`: ```python print("Hello from Docker!") ``` Now create the Dockerfile: ```dockerfile FROM python:3.12-slim WORKDIR /app COPY . . CMD ["python", "main.py"] ``` From the project directory, run: ```bash docker build -t docker-demo . ``` Let's understand the command: ```text docker build ``` Tells Docker to build an image. ```text -t docker-demo ``` Assigns the image a name. ```text . ``` Tells Docker to use the current directory as the build context. After the build completes, check your images: ```bash docker images ``` You should see something similar to: ```text REPOSITORY TAG IMAGE ID CREATED docker-demo latest abc123... ... ``` --- # 14. Running Your Image Now that we have an image, we can create a container from it. Run: ```bash docker run docker-demo ``` You should get: ```text Hello from Docker! ``` What just happened? ```text Dockerfile ↓ docker build ↓ docker-demo image ↓ docker run ↓ container ↓ python main.py ↓ Hello from Docker! ``` This is the fundamental Docker workflow. --- # 15. Listing Containers To see currently running containers: ```bash docker ps ``` However, our Python application exits immediately after printing the message. So you may not see it with: ```bash docker ps ``` Instead, use: ```bash docker ps -a ``` The `-a` means: > Show all containers, including stopped containers. You might see: ```text CONTAINER ID IMAGE STATUS abc123 docker-demo Exited (0) ``` The container stopped because the command inside it finished. This is an important concept: > **A container stays alive as long as its main process is running.** --- # 16. Container Lifecycle A container can move through different states. A simplified lifecycle looks like: ```text Created ↓ Running ↓ Stopped ↓ Removed ``` Common commands include: ### Start a stopped container ```bash docker start ``` ### Stop a running container ```bash docker stop ``` ### Restart a container ```bash docker restart ``` ### Remove a container ```bash docker rm ``` --- # 17. Naming Containers Docker automatically generates container names, but you can specify your own. For example: ```bash docker run --name my-python-app docker-demo ``` Now you can reference it using: ```bash docker stop my-python-app ``` or: ```bash docker start my-python-app ``` This becomes particularly useful when you're working with multiple services. --- # 18. Viewing Container Logs Suppose your application is running inside a container and something goes wrong. You can inspect its output with: ```bash docker logs my-python-app ``` You can also follow logs as they are produced: ```bash docker logs -f my-python-app ``` The `-f` means follow. For backend applications, logs are useful when debugging: * startup errors * database connection problems * missing environment variables * application exceptions * dependency issues --- # 19. Executing Commands Inside a Container Sometimes you need to inspect a running container. You can use: ```bash docker exec -it my-python-app bash ``` If `bash` isn't available, you may need: ```bash docker exec -it my-python-app sh ``` This gives you an interactive shell inside the container. You might then run: ```bash ls ``` or: ```bash pwd ``` or: ```bash python --version ``` This is particularly useful when debugging containerized applications. --- # 20. Port Mapping Let's say your Django application runs inside a container on port: ```text 8000 ``` Running: ```bash docker run myapp ``` doesn't automatically make that port accessible from your host. You can map the port: ```bash docker run -p 8000:8000 myapp ``` The syntax is: ```text -p HOST_PORT:CONTAINER_PORT ``` For example: ```bash docker run -p 9000:8000 myapp ``` means: ```text Your computer localhost:9000 │ ▼ Container port 8000 ``` You can then access the application through: ```text http://localhost:9000 ``` --- # 21. Environment Variables Applications often require configuration such as: ```text DATABASE_URL SECRET_KEY REDIS_URL DEBUG API_KEY ``` You can pass environment variables when starting a container: ```bash docker run \ -e DEBUG=False \ -e DATABASE_URL="..." \ myapp ``` Inside the container, your application can read them from the environment. For Django: ```python import os DEBUG = os.getenv("DEBUG", "False") == "True" ``` However, avoid putting sensitive credentials directly inside your Dockerfile. Don't do this: ```dockerfile ENV DATABASE_PASSWORD="my-secret-password" ``` Secrets should be managed through appropriate environment and secret-management mechanisms. --- # 22. What About Data Persistence? Containers are designed to be disposable. That creates an important question. Suppose PostgreSQL is running inside a container and you create a database. What happens if the container is removed? Without persistent storage, the data associated with the container can be lost. This is where **Docker volumes** become important. A volume allows data to live independently of the container. Conceptually: ```text Container │ ▼ Volume │ ▼ Persistent Data ``` Volumes become especially important when working with: * PostgreSQL * MySQL * Redis * uploaded files * application-generated data We'll go deeper into volumes and networking when we introduce Docker Compose in Part 3. --- # 23. Docker Networking Containers can communicate with each other through Docker networks. Imagine an application consisting of: ```text Django │ ├── PostgreSQL │ ├── Redis │ └── Celery ``` Instead of exposing every service publicly, Docker can place them on the same internal network. Conceptually: ```text Docker Network ┌─────────────────────┐ │ │ │ Django ── PostgreSQL │ │ │ │ ├──── Redis │ │ │ │ │ └──── Celery │ │ │ └─────────────────────┘ ``` This becomes much easier to manage with Docker Compose. --- # 24. A More Realistic Django Dockerfile Now let's connect these concepts to something closer to a real Django application. A simplified Django Dockerfile might look like: ```dockerfile FROM python:3.12-slim WORKDIR /app ENV PYTHONDONTWRITEBYTECODE=1 ENV PYTHONUNBUFFERED=1 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD ["gunicorn", "core.wsgi:application", "--bind", "0.0.0.0:8000"] ``` The process is: ```text Dockerfile ↓ Build ↓ Django Image ↓ Run ↓ Django Container ↓ Gunicorn ↓ Port 8000 ``` Notice something important. The Dockerfile doesn't contain PostgreSQL or Redis as running services. Those are separate services. This is where our architecture starts becoming more interesting. --- # 25. Why Not Put Everything Into One Container? A beginner might think: > “Why don't I put Django, PostgreSQL, Redis, Celery and Nginx into one container?” A better approach for a multi-service application is usually to separate those services into their own containers. For example: ```text ┌──────────────┐ │ Django │ │ Container │ └──────┬───────┘ │ ├──────────────┐ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ PostgreSQL │ │ Redis │ │ Container │ │ Container │ └──────────────┘ └──────┬───────┘ │ ▼ ┌──────────────┐ │ Celery │ │ Container │ └──────────────┘ ``` Each service has a clear responsibility. But now we have another problem: > **How do we start and manage all these containers together?** That's exactly the problem **Docker Compose** helps solve. We'll tackle that in Part 3. --- # 26. The Most Important Docker Commands At this point, these are the commands worth remembering: ### Check Docker ```bash docker --version ``` ### List images ```bash docker images ``` ### Build an image ```bash docker build -t myapp . ``` ### Run a container ```bash docker run myapp ``` ### Run in the background ```bash docker run -d myapp ``` ### List running containers ```bash docker ps ``` ### List all containers ```bash docker ps -a ``` ### Stop a container ```bash docker stop ``` ### Start a container ```bash docker start ``` ### Restart a container ```bash docker restart ``` ### Remove a container ```bash docker rm ``` ### Remove an image ```bash docker rmi ``` ### View logs ```bash docker logs ``` ### Enter a running container ```bash docker exec -it bash ``` These commands cover a large portion of the basic Docker workflow. --- # 27. The Complete Picture Let's put everything together. You start with your application: ```text Application Code │ ▼ Dockerfile │ │ docker build ▼ Docker Image │ │ docker run ▼ Docker Container │ ├── Port ├── Environment Variables ├── Network └── Volumes ``` This is the foundation of containerized application development. Remember: ```text Dockerfile → Instructions Image → Packaged application Container → Running instance Volume → Persistent data Network → Container communication ``` Once these concepts make sense, Docker becomes much less mysterious. --- # 28. Docker Is More Than `docker run` At the beginning, Docker can look like a collection of commands: ```bash docker build docker run docker stop docker start docker logs ``` But the real value comes from understanding the architecture behind those commands. When you understand: * how images are built * how containers are created * how containers communicate * how ports are mapped * how data persists * how configuration is passed you can start designing real containerized systems instead of simply running commands you found online. --- # 29. What We Have Learned In Part 1, we focused on **why Docker exists**. In Part 2, we've moved into **how Docker works**. We learned that: * A **Dockerfile** contains instructions for building an image. * A **Docker image** is a packaged, reusable artifact. * A **container** is a running instance of an image. * Images are built from layers. * `docker build` creates images. * `docker run` creates and starts containers. * Containers have their own lifecycle. * Ports can be mapped between the host and container. * Environment variables provide runtime configuration. * Volumes provide persistent storage. * Docker networks allow containers to communicate. * Real-world applications often use multiple containers for different services. But we haven't yet solved the problem of managing all those containers together. Imagine having: ```text Django PostgreSQL Redis Celery Worker Celery Beat Nginx ``` and needing to start all of them. You could manually run multiple `docker run` commands. But that quickly becomes inconvenient. There is a better approach. --- # Part 3: Docker Compose In the next part of this series, we'll introduce **Docker Compose** and build a more realistic multi-container application. We'll look at how to define services such as: ```text Django PostgreSQL Redis Celery ``` inside a: ```text docker-compose.yml ``` and manage the entire application with commands such as: ```bash docker compose up ``` and: ```bash docker compose down ``` That's where Docker becomes much more practical for everyday backend development. --- ## Docker Fundamentals Series ### ← Part 1 **[What Is Docker? Why It Exists and How Containers Solved “It Works on My Machine”](https://www.kodane.dev/posts/what-is-docker-why-it-exists-and-how-containers-solved-it-works-on-my-machine)** Learn why Docker exists, the problems it was designed to solve, and how containers changed modern software development. ### → Part 2 — You Are Here **Docker Images, Containers and Dockerfiles: Understanding How Docker Works** Understand the core building blocks of Docker and how an application moves from a Dockerfile to a running container. ### → Part 3 — Coming Next **Docker Compose: Running a Real-World Application with Multiple Containers** Learn how to manage Django, PostgreSQL, Redis, Celery, and other services together using Docker Compose. --- ## References * Docker Documentation — Docker Overview * Docker Documentation — Dockerfile Reference * Docker Documentation — `docker build` * Docker Documentation — `docker run` * Docker Documentation — Storage and Volumes * Docker Documentation — Networking

Why Your Django Admin Is an Hour Behind and Why Your Database Isn't Wrong