My Magento 2 service container images include REDIS services for the Magento session and system cache and a Varnish service for the full page cache. Varnish is an HTTP accelerator designed for content-heavy dynamic web sites and is the recommended full page cache system for Magento 2.

Varnish is configured via the Varnish Configuration Language (VCL) config file. By configuring multiple backend servers in VCL and grouping them into a director we can create a Varnish load balancer.

[text]
backend magento2_php_apache_1 {
.host = "x.x.x.2";
.port = "80";
.probe = {.request =
"GET /healthcheck.php HTTP/1.1" "Host: magento2.gaiterjones.com" "Connection: close" "Accept: text/html";.timeout = 1s;.interval = 30s;.window = 10;.threshold = 8;}
}
backend magento2_php_apache_2 {
.host = "x.x.x.8";
.port = "80";
.probe = {.request =
"GET /healthcheck.php HTTP/1.1" "Host: magento2.gaiterjones.com" "Connection: close" "Accept: text/html";.timeout = 1s;.interval = 30s;.window = 10;.threshold = 8;}
}
backend magento2_php_apache_3 {
.host = "x.x.x.10";
.port = "80";
.probe = {.request =
"GET /healthcheck.php HTTP/1.1" "Host: magento2.gaiterjones.com" "Connection: close" "Accept: text/html";.timeout = 1s;.interval = 30s;.window = 10;.threshold = 8;}
}
backend magento2_php_apache_4 {
.host = "x.x.x.11";
.port = "80";
.probe = {.request =
"GET /healthcheck.php HTTP/1.1" "Host: magento2.gaiterjones.com" "Connection: close" "Accept: text/html";.timeout = 1s;.interval = 30s;.window = 10;.threshold = 8;}
}
backend magento2_php_apache_5 {
.host = "x.x.x.9";
.port = "80";
.probe = {.request =
"GET /healthcheck.php HTTP/1.1" "Host: magento2.gaiterjones.com" "Connection: close" "Accept: text/html";.timeout = 1s;.interval = 30s;.window = 10;.threshold = 8;}
}
sub vcl_init {
new cluster1 = directors.round_robin();
cluster1.add_backend(magento2_php_apache_1);
cluster1.add_backend(magento2_php_apache_2);
cluster1.add_backend(magento2_php_apache_3);
cluster1.add_backend(magento2_php_apache_4);
cluster1.add_backend(magento2_php_apache_5);
}
[/text]

Scale Manager

I use a service container called php-apache to run the Magento core code. Docker compose allows you to scale containers on a single host, so for example with the command

docker-compose scale php-apache=5

I can quickly scale the Magento2 php-apache service up to 5 containers, that is 5 instances of the php-apache service running the Magento2 core php code and apache web server.

The scale manager service monitors docker processes and detects when the php-apache service is scaled up or down. When a change is detected it dynamically creates the VCL configuration required to tell Varnish about the changes and applies these to the Varnish server.

Magento 2 Scale Demo

In the video below I start with one running instance of the Magento 2 service, I then scale the service up to 5 and using the scale demo page (which is not cached by Varnish) on my Magento 2 dev site to analyse the scale manager output data and display the running Magento 2 service containers.

As I refresh the page the Magento 2 container rendering the page is highlighted in yellow. you can see how Varnish round robins between the 5 available containers. Finally I scale the service back down and manually update the Varnish server config via the command line php script on the manager.

Another way to see the round robin connection distribution from varnish is to load up a phpinfo() page, you will see the SERVER_ADDR variable changing with each container that processes the request.

Would you actually run 5 Magento 2 php-apache services? Good question! For true resilience and load balancing you would need multiple hosts and a Docker swarm. Multiple service containers on a single host do at least provide a simple level of redundancy and host server load balancing, I would definitely consider using it in production especially with a multi core server.

Many thanks to Fabrizio Balliano for the inspiration and assistance.

See this post for instructions on how to deploy this Magento 2 development environment.

For example if I have a web application service called php-apache

docker-compose scale php-apache=10

Will start another 9 containers running the php-apache service giving me 10 containers running the same php-apache web application service.

Of course if you want to have real resilience and load sharing Docker swarm is the solution so the question is, are there any benefits from scaling a service in mulitple containers on a single host?

Well, yes, because you can still load balance the traffic to your application and achieve a basic level of container resilience.

Scaled services will only work for applications that use private ports as multiple Docker containers cannot share the same public port. I use an NGINX service container as a reverse proxy to my web application services with NGINX listening on the host public http port, proxying traffic to the service containers on their private internal container http ports.

This scenario can scale easily and there are some documented examples that describe how to load balance Docker scaled web application services, however all the examples I found require manual configuration and a restart of the load balancer to update it when service containers are scaled up or down.

I wanted to create a dynamic scaled service where the load balancer or proxy is dynamically updated when services are scaled up or down.

NGINX as a reverse proxy will also load balance when multiple upstream hosts are configured for a website but the default configuration file must be manually edited, saved and NGINX restarted before the changes take affect.

A bit of googling around uncovered a module that allows you to dynamically update the NGINX upstream host configuration. I compiled the module into my existing NGINX service container and tested it and was able to dynamically add and remove upstream hosts, perfect for dynamically scaling Docker services!

Scaledemo Application

To demonstrate how Docker Mono Host Service Scaling and Dynamic Load Balancing with NGINX works I put together a group of containers to simulate a scaled web application :

• manager
  • A php service container that acts as the manager for the scaled services project.
• nginx
  • An NGINX container compiled with the ngx_http_dyups dynamic upstream module.
• php-apache
  • A php7, Apache2 service container that will run my demo ‘Bean Counter’ web application.
• memcached
  • Cache server used by the manager to store Docker data, and by the web application to store the ‘Bean Counter’ data.

Manager

Dynamic updates to NGINX are carried out by the manager service container. It pulls Docker system information from the Docker host via a cron job every 60 seconds, parses the data for running service containers that match the configured project web application service container (php-apache) and generates an NGINX upstream host configuration.

The manager compares the upstream host configuration running on NGINX with the generated configuration from Docker. If they differ it updates NGINX via php-curl with the new configuration. The parsed manager Docker data is stored on the memcache server so that it is available to other services.

When I scale the php-apache service up or down NGINX is dynamically configured with the changes at the next manager update, or heartbeat. I can also manually force the update via a cli command on the manager.

Demo

Watch the video below to see the scale demo in action.

In the video I start the containers with docker compose, scale php-apache up to 10 instances and check the dynamic update and round robin load balancing via the demo web application that parses the manager data from memcache and also increments a counter.

I then scale it up again to 20 instances and manually update the nginx configuration via the manager. You can see NGINX load balancing the web application with round robin requests to each of the 20 service containers as I click the refresh button to increment the bean counter and reload the page. The container that served the page is highlighted in yellow.

Finally I scale the service back down to 2 instances and stop the containers.

You can build the Docker containers and try out the demo yourself using the docker-compose files from GitHub.

• Clone the project files
  • git clone https://github.com/gaiterjones/docker-scaledemo
• Build the containers
  • cd scaledemo
  • docker-compose build
• Make sure there are no other service using port 80 on your host and start the containers
  • docker-compose up -d
• Point your browser at http://scaledemo.dev.com (which should resolve to your Docker host) to see the demo page
• Scale the php-apache container
  • docker-compose scale php-apache=5

To manually update NGINX from the scale manager

• Connect to the manager container
  •  docker exec -t -i scaledemo_manager_1 /bin/bash
    • or docker exec magento2_manager_1 php cron.php scalemanager
• run the scalemanager php script
  • php cron.php update scalemanager