Docker Concepts: Images and Containers

To solve the 'it works on my machine' problem, Docker uses two fundamental concepts: Images and Containers. Understanding the distinction between these two is the first step in effectively using Docker to package and run your applications. Think of them as the blueprint and the building constructed from that blueprint.

What is a Docker Image?

A Docker image is a lightweight, standalone, executable package that includes everything needed to run a piece of software: the code, a runtime (like Python), system tools, system libraries, and settings. It's essentially a template or a blueprint.

Characteristics of Docker images include:

1. Read-Only Template: Once an image is built, it doesn't change. This immutability ensures consistency every time you use the image to start a container.
2. Layered Filesystem: Images are built in layers. Each instruction in a Dockerfile (which we'll cover in the next section) typically creates a new layer. This layering makes builds and distribution efficient because Docker only needs to rebuild or download layers that have changed. For example, your base operating system layer might be reused across many images.
3. Contains Everything Needed: An image bundles the application code (like your Flask app), dependencies (requirements.txt), the Python interpreter itself, and any required operating system libraries or tools needed for the application to run correctly.

Think of a Docker image like a detailed recipe for baking a cake. The recipe lists all the ingredients (libraries, code), the specific oven settings (runtime configuration), and the step-by-step instructions (build process). The recipe itself doesn't change.

What is a Docker Container?

A Docker container is a running instance of a Docker image. If the image is the blueprint (or recipe), the container is the actual house built from the blueprint (or the cake baked from the recipe).

When you "run" an image, you create a container. Here's what defines a container:

1. Execution Environment: It's an isolated environment where your application runs. The container has its own process space, network interface, and filesystem, largely isolated from the host machine and other containers.
2. Based on an Image: Every container is created from an image. The container essentially runs the application packaged within that image.
3. Writable Layer: While the image itself is read-only, a container adds a thin writable layer on top of the image layers. Any changes made while the container is running (like writing log files or temporary data) happen in this layer. These changes are typically lost when the container is removed, unless specific storage mechanisms are used.
4. Multiple Instances: You can create and run many containers from the same image, just like you can bake multiple identical cakes using the same recipe. Each container runs independently.

Using our analogy, a container is like actually baking the cake using the recipe (image). You follow the instructions, mix the ingredients, and put it in the oven. The resulting cake is the container, a tangible instance created from the recipe. You can bake many identical cakes (containers) using that one recipe (image).

Images vs. Containers: The Blueprint and the Instance

The core relationship is simple: Images are the build-time construct, and containers are the run-time construct. You build an image once, and then you can run it multiple times, on different machines, creating identical containers each time.

This relationship provides the consistency needed for deployment. Because the image packages the application and its environment, running a container from that image ensures the application behaves the same way regardless of the underlying host system's configuration.

The process starts with a Dockerfile containing instructions. Running docker build creates a read-only Docker Image. Running docker run using this image launches one or more independent, runnable Containers.

Understanding this difference is fundamental. We build an image containing our Flask application, its dependencies, and the Python runtime. Then, we run this image as a container, which executes our Flask application in an isolated, consistent environment, ready to serve predictions. In the following sections, we'll learn how to write the Dockerfile (the recipe) to build the image for our prediction service.