Most enterprises have a structured release management process that allows phased deployment between multiple environments including development, test, model (stage or acceptance), and production.  https://en.wikipedia.org/wiki/Deployment_environment.

With Docker Enterprise Swarm you can generally setup these environments in one of the following ways: Single Cluster, Multi-Env Cluster, Geo-Single Clusters, and Geo-Multi-Env Cluster.  I will explain these different approaches and help you determine when each approach might be useful in your enterprise.  Of course, there is a myriad of variations on each of these that you could employ to suit your own needs.

In the examples below I will focus on three environments in various configurations that a CI/CD process can deploy docker services/stacks to dev, test, and prod.  Each example will show a management plane that has 3, 5, or 7 UCP managers.  It is also assumed there are a handful of DTR workers (not shown in diagrams).

Single Cluster

The Single Cluster Docker Swarm has a single management plane along with three collections of worker nodes.  The three collections of workers support dev, test, and prod application environments.  With this approach, the managers are responsible for all three collections of workers.

In the Single Cluster, you have only one environment that is general purpose and is intended to handle the majority of your application team’s needs. This assumes you have a single location and that location can handle all of your enterprise business divisions’ needs.

Upon deployment through your CI/CD pipeline, an appropriate label must be specified in your stack file to indicate which collection/environment to deploy to. Also, in this configuration, there is only one set of security, logging, monitoring, etc. that you need to configure and manage.

Multi-Env Cluster

The Multi-Env Cluster is still a set of general-purpose environments for application teams.  The difference is that CI/CD pipelines deploy to three distinct clusters and developers must browse through three different UCP management planes to find their applications.  It is obvious that with the Multi-Env Cluster approach you have more to manage. Three environments with three sets of managers.  Whatever authentication, authorization, RBAC, logging, monitoring, etc. that you put into place for one environment is now done twice more.

Compared with the Single Cluster, the Multi-Env Cluster approach means you are paying-for more management nodes and installing and managing more machines and licenses.

On the positive side, if the operations or development teams mess up the dev environment, then that does not impact test or production environments because you have complete isolation.

Geo-Single Clusters

Another approach expands on the Single Cluster by generating several geographic or business unit clusters; one cluster per geography, business unit, or application team while still keeping the multiple environments within each individual cluster.

This Geo-Single Cluster supports multiple clusters on separate continents (geographic locations) wherein each cluster is a Single Cluster with dev, test, and prod collections.

Because of the increased complexity with this approach, it is extremely important to have automation in place for the operations teams that are responsible for creating and managing these clusters to an SLA.  Or you can create a self-service portal and allow your application/business teams to create their own clusters using your own Infrastructure as Code (IaC) templates.  This self-service IaC approach would include all of your enterprise standards for security, governance, and architecture.

Geo-Multi-Env Clusters

Going one step further and creating multiple clusters per environment and per geography introduces my final configuration option.  This approach addresses requirements for supporting multiple geographies and multiple environments per geography (or business unit).  Consider this clustering approach to be a multiplication of Geography X Multi-Env.

The Geo-Multi-Env Cluster supports disparate geographic locations on three continents wherein each continent has a Multi-Env Cluster with unique dev, test, and prod clusters.  You can easily see how complexity is growing.  As in the Multi-Env Cluster approach, this will require full automation in an IaC fashion to be successful.

Approaches

So which Docker clustering approach you take depends on your requirements.

If your enterprise has a single data center and is considering deploying Docker then the Single Cluster approach is probably right for you. This is true whether you are deploying on-premise or to the cloud.

If the above is true but you are more risk-averse, then the Multi-Env Cluster approach is your choice.  This comes with an additional cost of UCP manager nodes to license and additional effort to configure and manage.

If your enterprise needs to be responsive to geographic locations or your business units need their own separate clusters, then the Geo-Single Cluster approach is your choice.  This approach has the same cost regarding effort as the Multi-Cluster approach. However, your license cost is increasing because of the extra worker nodes count.

Finally, if you are geographically dispersed and highly risk-averse and do not mind the additional license and effort costs, then the Geo-Multi-Env Cluster approach is for you.

This table summarizes how to choose the right cluster approach based on Risk Aversion and Geography/Business Unit driven decisions.

Summary

These four clustering approaches handle a large majority of my customer’s needs. I have one customer using the Multi-Env Cluster approach in their on-premise data center. A second customer is using the Single Cluster approach but deploying to the Azure public cloud. A third customer has a very large Single Cluster within their own on-premise data center. They are currently looking at expanding this cluster with additional worker nodes in both AWS and Azure clouds.

At DockerCon 2018 in San Francisco and also in DockerCon EU18 I heard an architect from Bosch talk about how they rolled out their clusters across 4 continents using the Geo-Multi-Env Cluster approach. It was his presentation in Barcelona DockerCon that prompted me to consider these variations and formally document them in this blog.

There are obviously many variations on these approaches that can also be considered. However, these four clustering approaches form the foundation of where you would start. If you want any help in strategizing your companies’ approach, then contact us at https://capstonec.com/contact-us.

Mark Miller