Introduction

Up until now, I had been building simple Flask applications using a single Dockerfile. While this approach works, it often results in larger Docker images that contain unnecessary files, build tools, and dependencies.

In real-world environments, organisations aim to:

• Reduce image size

• Improve security

• Speed up deployments

• Optimise container performance

Docker Multi-Stage Builds help achieve these goals.

In this article, I'll show how I built a simple Flask application using a Multi-Stage Dockerfile and explain why this approach is considered a Docker best practice.

What is a Multi-Stage Build?

A Multi-Stage Build allows us to use multiple FROM statements within a single Dockerfile.

Typically:

Instead of deploying everything from the build process, only the files required for runtime are copied into the final image.

Why Use Multi-Stage Builds?

Benefits include:

• Smaller Image Size

• Improved Security

• Faster Container Downloads

• Faster Deployments

• Better Resource Utilisation

• Production-Ready Images

Project Structure

Step 1: Create the Flask Application

Create a file called app.py.

from flask import Flask

app = Flask(__name__)

@app.route('/')
def home():
    return """
    <h1>CloudOps Chronicle</h1>
    <h2>Docker Multi-Stage Build Demo</h2>
    """

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

The application simply displays a welcome page.

Step 2: Define Dependencies

Create requirements.txt.

flask

This file contains the Python package required by the application.

Step 3: Create a Multi-Stage Dockerfile

# Stage 1 - Builder

FROM python:3.12 AS builder

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .


# Stage 2 - Runtime

FROM python:3.12-slim

WORKDIR /app

COPY --from=builder /app /app

RUN pip install --no-cache-dir flask

EXPOSE 5000

CMD ["python", "app.py"]

Understanding the Dockerfile

Builder Stage:

FROM python:3.12 AS builder

The first stage prepares the application environment and installs dependencies.

Runtime Stage:

FROM python:3.12-slim

A smaller base image is used for running the application. This helps reduce image size.

Copy from Previous Stage:

COPY --from=builder /app /app

This is the key part of a Multi-Stage Build.

Docker copies only what is needed from the builder stage into the runtime stage.

Step 4: Build the Image

Build the Docker image:

docker build -t multi-stage-flask:v1 .

Verify:

docker images

Example:

Step 5: Run the Container

docker run -d \
--name multi-stage-demo \
-p 5000:5000 \
multi-stage-flask:v1

Verify:

docker ps

Step 6: Test the Application

curl http://localhost:5000

Conclusion

Docker Multi-Stage Builds are a simple but powerful technique for creating efficient container images.

By separating the build process from the runtime environment, we can build smaller, cleaner, and more secure images that are better suited for production deployments.

For anyone learning Docker and preparing for Kubernetes, understanding Multi-Stage Builds is an important step towards mastering containerisation.

Happy Learning!

Introduction

Containers are designed to be temporary and disposable. This raised an important question:

What happens to application data when a container is removed?

To understand this concept, I built a simple Flask application that stores a visitor counter in a file. I then tested what happens with and without Docker Volumes.

In this article, I'll explain how Docker Volumes help preserve data even when containers are deleted and recreated.

The Problem

Example:

If the container is removed:

docker rm -f mycontainer

the data disappears as well.

For applications such as:

• Databases

• Log storage

• User uploads

• Application configuration

This behaviour is not desirable.

What is a Docker Volume?

A Docker Volume is a storage mechanism managed by Docker.

Rather than storing data inside the container, data is stored separately on the host.

Because the volume exists independently of the container, the data remains available even after the container is removed.

Project Architecture

The application stores a simple visit counter inside a file located in a Docker Volume.

Project Structure

Step 1: Create the Flask Application

Create app.py.

from flask import Flask
import os

app = Flask(__name__)

COUNTER_FILE = "/data/counter.txt"

@app.route('/')
def home():

    if not os.path.exists(COUNTER_FILE):
        with open(COUNTER_FILE, "w") as f:
            f.write("0")

    with open(COUNTER_FILE, "r") as f:
        count = int(f.read())

    count += 1

    with open(COUNTER_FILE, "w") as f:
        f.write(str(count))

    return f"""
    <h1>CloudOps Chronicle</h1>
    <h2>Docker Volume Demo</h2>
    <h3>Visits: {count}</h3>
    """

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Each time the page is accessed, the counter value increases and is written to a file.

Step 2: Create requirements.txt

flask

Step 3: Create the Dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

RUN mkdir /data

EXPOSE 5000

CMD ["python", "app.py"]

Build the image:

docker build -t flask-volume:v1 .

Testing Without a Volume

docker run -d \
--name flask-volume-test \
-p 5000:5000 \
flask-volume:v1

Access the application:

curl http://localhost:5000

Example:

Visits: 1
Visits: 2
Visits: 3

Now remove the container:

docker rm -f flask-volume-test

Start it again:

docker run -d \
--name flask-volume-test \
-p 5000:5000 \
flask-volume:v1

The counter starts again from:

Visits: 1

The data was lost.

Creating a Docker Volume

Create a volume:

docker volume create visit-data

Verify:

docker volume ls

Running With a Volume

Start the container again, this time mounting the volume.

docker run -d \
--name flask-volume-test \
-p 5000:5000 \
-v visit-data:/data \
flask-volume:v1

The -v option maps the Docker Volume to the /data directory inside the container.

Verify Data Persistence

Access the application several times:

Now remove the container:

docker rm -f flask-volume-test

Create it again:

docker run -d \
--name flask-volume-test \
-p 5000:5000 \
-v visit-data:/data \
flask-volume:v1

Access the application:

The counter continues from the previous value.

Success!

The data survived because it was stored inside the Docker Volume rather than inside the container.

Inspecting the Volume

List volumes:

docker volume ls

Inspect the volume:

docker volume inspect visit-data

This shows where Docker stores the volume data on the host system.

Conclusion

Docker containers are designed to be temporary, but application data should not be.

Docker Volumes provide a simple and effective way to persist data beyond the lifecycle of a container.

Happy Learning!

Introduction

Most production applications do not expose the application server directly to users. Instead, a reverse proxy such as NGINX sits in front of the application and handles incoming requests.

In this project, I built a simple architecture where:

• NGINX receives client requests

• NGINX forwards requests to a Flask application

• Both services run as separate containers

• Docker Compose manages the entire deployment

Project Architecture

            User
              |
              v
        NGINX Proxy
          Port 80
              |
              v
       Flask Application
          Port 5000

The user only interacts with NGINX.

NGINX forwards traffic internally to the Flask container.

Project Structure

nginx-flask/
├── app.py
├── requirements.txt
├── Dockerfile
├── nginx.conf
├── docker-compose.yml
└── README.md

Step 1: Create the Flask Application

Create app.py:

from flask import Flask

app = Flask(__name__)

@app.route('/')
def home():
    return """
    <h1>CloudOps Chronicle</h1>
    <h2>NGINX Reverse Proxy Demo</h2>
    """

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

The application listens on port 5000.

Step 2: Create requirements.txt

flask

This file contains the Python dependencies required by the application.

Step 3: Create the Dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 5000

CMD ["python", "app.py"]

Build the image:

docker build -t nginx-flask-web .

Verify:

docker images

Step 4: Configure NGINX

Create nginx.conf:

events {}

http {

    server {

        listen 80;

        location / {

            proxy_pass http://web:5000;

        }

    }

}

The important part is:

proxy_pass http://web:5000;

Here:

• web is the Docker Compose service name

• 5000 is the Flask application port

Docker Compose automatically provides DNS-based service discovery.

Step 5: Create Docker Compose File

Create docker-compose.yml:

services:

  web:
    image: nginx-flask-web:latest
    container_name: flask-app-1

  nginx:
    image: nginx:latest
    container_name: nginx-proxy

    ports:
      - "80:80"

    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf

    depends_on:
      - web

Step 6: Start the Application

docker compose up -d

Verify:

docker ps

Example output:

CONTAINER ID   IMAGE                 NAMES
xxxxxxxx       nginx:latest          nginx-proxy
xxxxxxxx       nginx-flask-web       flask-app

Step 7: Test the Application

http://localhost
  or
http://<server-public-ip>

Although users access port 80, the application is actually running on port 5000.

NGINX handles the forwarding.

Challenges Faced

During the implementation, you might encountered a few issues:

• Docker Compose Buildx dependency requirements

• Understanding the difference between ports and expose

• Service discovery between containers

• NGINX proxy configuration

Conclusion

Running Flask behind NGINX using Docker Compose was an excellent exercise in understanding modern application architecture.

If you're learning Docker, I highly recommend trying this project before moving to Kubernetes.

Happy Learning!

for reference : https://github.com/h-manojbabu/docker-image-build/tree/main/nginx-flask

In real-world applications, a single container is rarely enough. Applications often need databases, caches, message queues, and supporting services.

In this project, I built a simple Flask application that communicates with a Redis container using Docker Compose.

By the end of this exercise, we can learned:

-->Docker Compose
-->Multi-container applications
-->Container networking
-->Service discovery
-->Flask and Redis integration

Why Docker Compose?

Docker Compose allows us to define and run multiple containers as a single application.

Without Docker Compose:

Container 1 → Start manually

Container 2 → Start manually

Network → Create manually

Dependencies → Configure manually

With Docker Compose:

docker compose up -d

Everything starts automatically.

Project Architecture

+-----------------+
| Flask Web App   |
| Port 5000       |
+--------+--------+
         |
         |
         v
+-----------------+
| Redis Database  |
| Port 6379       |
+-----------------+

The Flask application stores and retrieves a visitor counter from Redis.

Project Structure

flask-redis/
├── app.py
├── requirements.txt
├── Dockerfile
├── docker-compose.yml
└── README.md

Creating the Flask Application

Create a file named app.py.

from flask import Flask
import redis

app = Flask(__name__)

redis_client = redis.Redis(host='redis', port=6379)

@app.route('/')
def index():
    try:
        visits = redis_client.incr('counter')
        return f"""
        <h1>CloudOps Chronicle</h1>
        <h2>Docker Compose Demo</h2>
        <h3>Visits: {visits}</h3>
        """
    except Exception as e:
        return f"Error: {e}"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

The application increments a counter every time the page is refreshed.

Defining Dependencies

Create requirements.txt.

flask
redis

These packages are installed when the Docker image is built.

Creating the Dockerfile

Create Dockerfile.

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 5000

CMD ["python", "app.py"]

Creating Docker Compose Configuration

Create docker-compose.yml.

services:

  web:
    image: flask-redis-web:latest
    container_name: flask-web

    ports:
      - "5000:5000"

    depends_on:
      - redis

  redis:
    image: redis:latest
    container_name: redis-server

This file defines: Flask container, Redis container, Container Dependencies, Port mapping.

Building the Application Image

Build the Flask container image.

docker build -t flask-redis-web .

Verify:

docker images

Example:

REPOSITORY         TAG
flask-redis-web    latest
redis              latest

Starting the Application

Launch both containers together.

docker compose up -d

Verify:

docker ps

Output:

CONTAINER ID   IMAGE                    NAMES
265e8b0b5xxx   flask-redis-web:latest   flask-web
fdbf76392xxx   redis:latest             redis-server

Both services are now running successfully.

Testing the Application

Access:

http://<server-ip>:5000

Checking Container Logs

docker logs flask-web
docker logs redis-server
docker compose logs

These commands are useful when troubleshooting containerised applications.

Challenges Faced

During the implementation, I encountered a few issues:

• Docker Compose plugin compatibility

• Buildx requirements

• Git push conflicts caused by remote repository changes

• Container dependency configuration

Happy Learning!

Today, I started my Docker learning journey by creating, running, and publishing my first Docker image.

As someone with a background in infrastructure and cloud operations, I wanted to understand the basics of containerisation before diving deeper into Kubernetes and cloud-native technologies.

In this article, I'll walk through the steps I followed to:

• Create a simple Docker image

• Run a container

• Push the image to Docker Hub

• Store the project in GitHub

What is Docker?

Docker is a containerisation platform that helps package an application and its dependencies into a lightweight, portable container.

This allows applications to run consistently across different environments.

Project Structure

My first project was a simple static web page.

staticwebpage/

├── Dockerfile

├── index.html

└── README.md

Step 1: Create the Web Page

I created a simple HTML file:

Hello Docker!

My first container is running successfully.

Step 2: Create the Dockerfile

I used the NGINX image as the base image.

FROM nginx:latest

COPY index.html /usr/share/nginx/html/index.html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

Step 3: Build the Docker Image

Build the image using:

docker build -t staticwebpage:v1 .

Verify the image:
docker images

Output:
REPOSITORY TAG

staticwebpage v1

Step 4: Run the Container

Start the container:

docker run -d -p 8080:80 --name staticwebpage staticwebpage:v1

Access the application:

http://:8080

Conclusion

Building and publishing my first Docker image was a great learning experience. Docker has become a fundamental skill for modern Infrastructure, Cloud, and DevOps engineers, and I'm excited to continue exploring the ecosystem.

If you're just getting started with Docker, I encourage you to build something simple and learn by doing.

Happy Learning! 🚀

Author: Manoj Naik
Publication: CloudOps Chronicle
Topics: Docker, DevOps, Cloud Computing, Linux, Infrastructure Engineering