Scaling in Docker Compose with hands-on Examples

In my previous blog, I explained about basics of components of compose file that includes continers, images, networks, volumes and environment variables.

In this blog we are going to deep dive into compose core concepts like scaling, reverse proxy and 3 tier application deployment etc..

Introduction:

Docker Compose allows you to define and run multi-container Docker applications. One of the key features of Docker Compose is container scaling. It allows you to easily scale the number of container instances for a particular service, making it a great tool for DevOps engineers when working on applications that need to handle increased traffic or load.

In this blog, we will walk through a real-time example of how to scale containers using Docker Compose, with the help of a simple web application. We will also cover some common interview questions for experienced DevOps engineers.

Realtime Example:

Scaling Containers for an E-Commerce Application

Imagine you’re managing an E-Commerce application that allows users to buy books, clothes, gadgets, and more. Initially, you have your application running on 10 containers. However, as the application gains popularity, you experience a significant increase in traffic and customers. This sudden surge in demand can overwhelm your containers, leading to potential crashes due to the heavy load.

To prevent such issues, you can implement auto-scaling for your containers. The goal is to dynamically adjust the number of containers based on demand:

• Scale-in: When the number of customers increases, you can scale-in your containers by adding more instances. This ensures that your application can handle the higher load and provides a better experience for users.

• Scale-down: Conversely, when the number of customers decreases, you can scale down by reducing the number of containers. This helps optimize resource usage and reduce costs when traffic is lower.

Important Consideration for Scaling with Docker Compose

When writing your docker-compose.yml file, it’s crucial not to specify container_name or host_port. Here’s why:

• Container Name Conflict: If you specify a static container_name, Docker will try to assign that name to all containers in the scaled service. This causes a conflict when you scale up or down, as multiple containers cannot share the same name.

• Port Conflict: Similarly, specifying a fixed host_port for each container can lead to port collisions when scaling the service, as multiple containers cannot bind to the same host port.

By omitting these properties, Docker Compose will automatically handle the naming and port assignment, allowing you to scale containers seamlessly without running into conflicts.

Compose file for our web application:

Here i am writing a compose file with single service

---
version: "3"
services:
  movie:
    build: ./train
    deploy:
      replicas: 2
    ports:
      - "80"

In the above compose file, we can see the replicas: 2 so it will create 2 containers by default. if we want we can scale-up in future. in the ports section we need to define container_port only.

We can see that we didn’t mention the container_name or host_port but docker-compose automatically assign the container names and random port numbers to access the application.

lets check using docker-compose up -d

Now see the containers using docker-compose ps

As we can clearly see the containers are having names and random port numbers.

output-1:

output-2:

Container scale-in using compose

syntax: docker-compose up -d --scale service-name=count

docker-compose up --scale movie=4 -d

Now if you perform this command, already we have 2 existing containers, if we scale-in then 2 more containers will gets created then the total number of containers will be 4.

lets check using docker-compose ps

Container scale-out using compose

syntax: docker-compose up -d --scale service-name=count

docker-compose up --scale movie=1 -d

Now out of 4, 3 containers will get removed then only 1 container will be there

Now lets check the number of containers using docker ps

Scaling Benefits in Action

• Load Balancing: With multiple instances of the web service, Docker Compose automatically distributes the incoming traffic among the containers.

• High Availability: If one of the containers fails, the other containers continue to handle requests, ensuring the app remains available.

• Efficiency: Scaling the web service allows you to handle more traffic by simply increasing the number of replicas without needing to modify the application itself.

Drawbacks:

docker compose only supports manual scaling, there is no feature called auto-scaling. If you want to experience autoscaling we need to learn kubernetes.

Conclusion

Using Docker Compose to scale containers is a quick and effective way to handle increased load in a real-time application. By modifying the docker-compose.yml file and running a simple command, we can scale up the application to meet demand. Whether you're running a microservice-based app or a monolithic web app, Docker Compose’s scalability is an essential feature for modern DevOps workflows.

Give me your heart 💖

If you found this blog helpful for your interviews or in learning Docker troubleshooting, please hit a heart for 10 times and drop a comment! Your support motivates me to create more content on DevOps and related topics. ❤️

If you'd like to connect or discuss more on this topic, feel free to reach out on LinkedIn.
Linkedin: linkedin.com/in/musta-shaik