Container Orchestration Without Kubernetes: Docker Compose in Production

Introduction

As a developer, I've worked on several small to medium-sized applications where the need for container orchestration arose. While Kubernetes is the de facto standard for large-scale container orchestration, it can be overkill for smaller applications. In this article, I'll explore using Docker Compose in production for such applications, covering key aspects such as health checks, restart policies, resource limits, and logging.

Health Checks

Docker Compose allows you to define health checks for your services using the healthcheck directive. This ensures that your services are running correctly and restarts them if they fail. For example:

version: '3'
services:
  web:
    build: .
    healthcheck:
      test: curl --fail http://localhost:8080 || exit 1
      interval: 10s
      timeout: 5s
      retries: 3

In this example, the web service will be considered unhealthy if the curl command fails to retrieve the homepage within 5 seconds, and will be restarted after 3 retries.

Restart Policies

Docker Compose also allows you to define restart policies for your services using the restart directive. This ensures that your services are restarted automatically in case of failure. For example:

version: '3'
services:
  web:
    build: .
    restart: always

In this example, the web service will be restarted automatically in case of failure.

Resource Limits

Docker Compose allows you to define resource limits for your services using the deploy directive. This ensures that your services do not consume excessive resources and brings them down if they do. For example:

version: '3'
services:
  web:
    build: .
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

In this example, the web service will be limited to 0.5 CPU cores and 512MB of memory.

Logging

Docker Compose allows you to define logging drivers for your services using the logging directive. This ensures that your services log output is properly handled and stored. For example:

version: '3'
services:
  web:
    build: .
    logging:
      driver: json-file
      options:
        labels: 'com.example'
        env: 'os,customer'

In this example, the web service will log output in JSON format with labels and environment variables.

When to Switch to Kubernetes

While Docker Compose is suitable for small to medium-sized applications, there are certain scenarios where switching to Kubernetes makes sense. These include:

• Large-scale applications with multiple services and complex dependencies
• Applications requiring advanced networking and security features
• Applications requiring automated rolling updates and self-healing
• Applications requiring integration with other cloud-native tools and services

In general, if your application requires more advanced features and scalability than what Docker Compose can provide, it's time to consider switching to Kubernetes.

Practical Takeaways

When using Docker Compose in production, keep the following best practices in mind:

• Use health checks to ensure your services are running correctly
• Use restart policies to ensure your services are restarted automatically in case of failure
• Use resource limits to prevent excessive resource consumption
• Use logging drivers to properly handle and store log output
• Consider switching to Kubernetes if your application requires advanced features and scalability