Providing High Availability to Docker-based Clustered Applications

When we launched the beta for DCHQ (http://dchq.io) back in March, one of the most important enhancement requests we heard from customers was around providing multi-host container-based application deployments. Our early adopters were thrilled about our advanced application modeling that allowed them to do much more with Docker Compose (e.g. invoking BASH script plug-ins or using cross-image environment variable bindings). However they still had important fundamental questions that were unanswered until we released DCHQ On-Premise v2.0 and DCHQ.io Hosted PaaS.

· Do all the containers in my application template have to run on the same host?

· What happens if the host goes down?

· Can I create a clustered application across multiple hosts or regions?

· How do I ensure High Availability?

· Can I comply with our company’s affinity rules so that our databases run on dedicated hosts?

We’re happy to announce that we now integrate with Weave and support multi-host container-based application deployments — addressing all of the aforementioned questions. DCHQ automates the deployment of clustered applications across multiple hosts in order to ensure high-availability and to comply with affinity rules.

When creating a Data Center or Cluster, a user is now able to select Weave as a networking option.

A user is then able to create a multi-tier (multi-image) application template using Docker Compose — but with a few core enhancements to facilitate container deployments across multiple hosts, and other enhancements that will be covered in upcoming blogs. In the example below, a clustered Java application is deployed on two Tomcat Application Servers and MySQL as the underlying database. You will notice that the cluster_size parameter allows you to specify the number of containers to launch (with the same application dependencies). The host parameter allows you to specify the host you would like to use for container deployments. Here are the values supported for the host parameter:

· host1, host2, host3, etc. — selects a host randomly within a data-center (or cluster) for container deployments

· <IP Address 1, IP Address 2, etc.> — allows a user to specify the actual IP addresses to use for container deployments

· <Hostname 1, Hostname 2, etc.> — allows a user to specify the actual hostnames to use for container deployments

· Wildcards (e.g. “db-*”, or “app-srv-*”) — to specify the wildcards to use within a hostname

A user can then deploy this application from the Self-Service Library by selecting the Environment Tag and Data-Center.

Once the application is running, you will notice that all containers are running on different hosts. A user is then able to access all the application life-cycle management capabilities — including backup, updating running containers using BASH script plug-ins, continuous delivery using Jenkins, auto-scaling and monitoring.

With this integration, DCHQ is now providing:

· AFFINITY GROUPS // Deploy applications across multiple hosts to comply with affinity rules leveraging an integration with Weave. For example, web server and database containers can be deployed on different hosts to comply with best practices.

· HYBRID SUPPORT // Accelerate application development by allowing users to deploy their application server on a local machine while the rest of the app components may be deployed on a shared data-center.

· HIGH AVAILABILITY // Ensure that clustered application servers are distributed across multiple hosts or regions for high availability

Sign Up Now for DCHQ.io Hosted PaaS

Download DCHQ On-Premise v2.0

Show your support

Clapping shows how much you appreciated Amjad Afanah’s story.