Hackforge Academy

Explanation

Dockerizing means packaging a Python microservice and all its dependencies into a Docker image that can run consistently in different environments. Each microservice can run inside its own container with its own dependencies, configuration, and network settings. Docker is useful in microservices because services can be built, deployed, scaled, and restarted independently. A typical Python FastAPI service is packaged with a Dockerfile and runs using Uvicorn inside the container.

Code:

# Example project
# product-service/
# ├── app/
# │   └── main.py
# ├── requirements.txt
# └── Dockerfile

# app/main.py
from fastapi import FastAPI

app = FastAPI()


@app.get('/products')
def get_products():
    return {
        'service': 'Product Service',
        'products': []
    }

Explanation

A Dockerfile contains the instructions required to build a Docker image. For a Python FastAPI microservice, the Dockerfile normally starts from a Python base image, sets the working directory, copies the dependency file, installs dependencies, copies the application code, exposes the service port, and starts Uvicorn. Keeping dependency installation before copying the application source can improve Docker build caching.

Code:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

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

COPY app ./app

EXPOSE 8000

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Explanation

After creating a Dockerfile, the docker build command creates an image containing the Python application and its dependencies. The docker run command starts a container from that image. The -p option maps a host port to the container port so that the FastAPI service can be accessed from outside the container. Docker containers provide an isolated and reproducible environment for running microservices.

Code:

# Build the Docker image
docker build -t product-service .

# Run the container
docker run -d \
  --name product-service \
  -p 8000:8000 \
  product-service

# Check running containers
docker ps

# View logs
docker logs product-service

# API
# http://localhost:8000/products

Explanation

In a microservices architecture, each service can have its own Docker image and container. For example, User Service, Product Service, Order Service, and Payment Service can each be packaged independently. Containers can communicate over a Docker network using service names instead of localhost. This allows services to be developed and deployed independently while still communicating with each other through REST APIs.

Code:

# Create a Docker network
docker network create microservices-network

# Run Product Service
docker run -d \
  --name product-service \
  --network microservices-network \
  product-service

# Run Order Service
docker run -d \
  --name order-service \
  --network microservices-network \
  order-service

# Inside Order Service, use:
# http://product-service:8000/products
#
# Do not use localhost to access another container.

Explanation

Docker Compose makes it easier to run multiple containers as one application. A compose.yaml file can define multiple Python microservices, databases, networks, environment variables, and port mappings. Services can communicate using their Compose service names. This is particularly useful for local development and testing of microservices architectures. In production, the same container images can later be deployed using container orchestration platforms such as Kubernetes or cloud container services.

Code:

services:
  product-service:
    build: ./product-service
    ports:
      - '8001:8000'

  order-service:
    build: ./order-service
    ports:
      - '8002:8000'
    environment:
      PRODUCT_SERVICE_URL: http://product-service:8000
    depends_on:
      - product-service

# Start all services:
# docker compose up --build

# Stop all services:
# docker compose down