Skip to main content
Common Reference

Docker Support Policy

Version availability

This page is only applicable for all version up to v7.x

Continuent has traditionally had a relaxed policy about Linux platform support for customers using our products.

While it is possible to install and run Continuent Tungsten products (i.e. Clustering/Replicator/etc.) inside Docker containers, there are many reasons why this is not a good idea.

Version 8.0.0 of Tungsten introduced the Tungsten Operator, with full Kubernetes support for Tungsten Clustering. See the /operator documentation for more details.

Background​

As background, every database node in a Tungsten Cluster runs at least three (3) layers or services:

  • MySQL Server (i.e. MySQL Community or Enterprise, MariaDB or Percona Server)
  • Tungsten Manager, which handles health-checking, signaling and failover decisions (Java-based)
  • Tungsten Replicator, which handles the movement of events from the MySQL Primary server binary logs to the Replica databases nodes (Java-based)

Optionally, a fourth service, the Tungsten Connector (Java-based), may be installed as well, and often is.

Current State​

As such, this means that the Docker container would also need to support these 3 or 4 layers and all the resources needed to run them.

This is not what containers were designed to do. In a proper containerized architecture, each container would contain one single layer of the operation, so there would be 3-4 containers per “node”. This sort of architecture is best managed by some underlying technology like Swarm, Kubernetes, or Mesos.

More reasons to avoid using Docker containers with Continuent Tungsten solutions:

  • Our product is designed to run on a full Linux OS. By design Docker does not have a full init system like SystemD, SysV init, Upstart, etc. This means that if we have a process (Replicator, Manager, Connector, etc.) that process will run as PID 1. If this process dies the container will die. There are some solutions that let a Docker container to have a "full init" system so the container can start more processes like ssh, replicator, manager, all at once. However this is almost a heavyweight VM kind of behavior, and Docker wasn’t designed this way.
  • Requires a mutable container – to use Tungsten Clustering inside a Docker container, the Docker container must be launched as a mutable Linux instance, which is not the classic, nor proper way to use containers.
  • Our services are not designed as “serverless”. Serverless containers are totally stateless. Tungsten Cluster and Tungsten Replicator do not support this type of operation.
  • Until we make the necessary changes to our software, using Docker as a cluster node results in a minimum 1.2GB docker image.
  • Once Tungsten Cluster and Tungsten Replicator have been refactored using a microservices-based architecture, it will be much easier to scale our solution using containers.
  • A Docker container would need to allow for updates in order for the Tungsten Cluster and Tungsten Replicator software to be re-configured as needed. Otherwise, a new Docker container would need to be launched every time a config change was required.
  • There are known i/o and resource constraints for Docker containers, and therefore must be carefully deployed to avoid those pitfalls.
  • We test on CentOS-derived Linux platforms.

Summary​

In closing, Continuent’s position on container support is as follows:

  • Unsupported for all products (i.e. Clustering/Replicator/etc.) for version 6.x and 7.x
  • Use at your own risk
  • For a fully supported solution, consider Tungsten Operator v8.0.0+. See the /operator documentation for more details.