Application scaling is the magic trick everyone is talking about. All the cool kids are scaling their environments up and down sing containers. Scaling Docker is not an exact science: you can do it by hand (but please don’t) or use orchestration software like Kubernetes or Swarm. Today we are going to see how to scale Docker Compose using a single host
Even if it works pretty well in development, I think it lacks maturity for production. For that, be sure to check out the solutions above.
docker-compose scale web=x
One command is all you need. Docker Compose scale its services using the scale command parameter, creating as many containers as you need. Using the code from our last post, let’s try it out:
Oops! What happened? We’ve tried to create five web containers and all of them bound to the 8000 port, which isn’t supported on the host. Scaling has its issues
Reverse proxy to the rescue!
We need one more piece to make it works, a reverse proxy. What it does is listen to one port - generally 80 - and forward all HTTP requests to a running web server, such as Django’s built in. The most used out there is HAProxy, AWS ELB and NGINX. Techniques and features may vary between proxies, make sure to read the documentation carefully. Today the chosen one is NGINX.
Docker Compose scalability brings a big challenge: The reverse proxy needs to update its configuration dynamically for each container created or destroyed, adding or removing the container’s IP address at any change. It can be achieved using docker-gen, which listens to Docker’s API events and generate files based on templates.
I’m not the first person to think about it: this guy created a nginx-proxy image to handle that. Neat.
Scaling for real
To continue, make sure you have the latest code! Fortunately, we have named volumes, so our data will be safe and sound.
Access http://localhost (don’t use port 8000) on your machine and you should see our simple counter.
See the differences in the new docker-compose.yml:
Using docker-compose ps, we can see the three containers running:
OK, get ready, let’s scale:
Again, access http://localhost, but this time, open a new terminal and run the command docker-compose logs -f. You should see that every request will be processed by a different web, based on the web_x part of the log. Awesome
You can also scaled down, decreasing the number of containers.
Here, a snippet of the NGINX configuration responsible for this black magic:
The web is built on blocks, like these. Every simple application today may use a reverse proxy and a bunch of little web servers behind it, for scalability and resilience. Docker simplifies this process, letting you focus on your application!
As always, any feedback is appreciated! Share with your friends