1.3.8-2.4,1.3-2.4,1-2.4,1.3.8,1.3,1,latest(1.3/2.4/Dockerfile)1.3.8-2.4-alpine,1.3-2.4-alpine,1-2.4-alpine,1.3.8-alpine,1.3-alpine,1-alpine,alpine(1.3/2.4-alpine/Dockerfile)1.3.8-2.4-centos,1.3-2.4-centos,1-2.4-centos,1.3.8-centos,1.3-centos,1-centos,centos(1.3/2.4-centos/Dockerfile)
mod_cluster is an httpd-based load balancer. Like mod_jk and mod_proxy, mod_cluster uses a communication channel to forward requests from httpd to one of a set of application server nodes. Unlike mod_jk and mod_proxy, mod_cluster leverages an additional connection between the application server nodes and httpd. The application server nodes use this connection to transmit server-side load balance factors and lifecycle events back to httpd via a custom set of HTTP methods, affectionately called the Mod-Cluster Management Protocol (MCMP). This additional feedback channel allows mod_cluster to offer a level of intelligence and granularity not found in other load balancing solutions.
An extension of the upstream httpd image with JBoss mod_cluster modules, built using apxs (APache eXtenSion tool):
mod_proxy_clustermod_advertisemod_managermod_cluster_slotmem
This image inherits from the configuration options from the parent httpd image.
Besides a sample configuration file is available in conf/extra/proxy-cluster.conf to help you get started with mod_cluster. This configuration includes the following aspects:
- Listen on port
6666(all interfaces) - Default VirtualHost on port
6666- enable receiving Mod Cluster Protocol Messages (MCPM)
- allow communication from the
172.0.0.0/8subnet only (default for Docker bridges) - advertise the server to the default multicast group (
224.0.1.105:23364) - enable the mod_cluster status page on
/mod_cluster-managerfrom the local host
This configuration is disabled by default. To enable it, simply uncomment the relevant directives from the main httpd configuration file (conf/httpd.conf):
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so
LoadModule manager_module modules/mod_manager.so
LoadModule cluster_slotmem_module modules/mod_cluster_slotmem.so
Include conf/extra/proxy-cluster.confThe httpd-mod_cluster images come in different flavors, each designed for a specific use case.
This is the defacto image, based on the Debian operating system, available in the debian official image.
This image is based on the Alpine Linux operating system, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.
This image is based on the CentOS operating system, available in the centos official image.
A tagging convention determines the version of the components distributed with the httpd-mod_cluster image.
- mod_cluster release: α
- httpd release: as distributed with the
httpd:latestupstream image
- mod_cluster release: α
- httpd release: β (latest patch version)
After performing changes to the Dockerfile templates or sample httpd configuration, regenerate the repository tree with:
./generate-dockerfiles.sh
After committing changes to the repository, regenerate the library definition file with:
./generate-bashbrew-library.sh >| httpd-mod_cluster
All images in this repository can be rebuilt and tagged manually using Bashbrew, the tool used for cloning, building, tagging, and pushing the Docker official images. To do so, simply call the bashbrew utility, pointing it to the included httpd-mod_cluster definition file as in the example below:
bashbrew --library . build httpd-mod_cluster
Any push to the upstream httpd repository or to the source repository triggers an automatic rebuild of all the images in this repository. From a high perspective the automated build pipeline looks like the below diagram:
