Tungsten Proxy in Docker Container

It’s been a while since the Continuent team started containerization of the three major Tungsten products - Tungsten Connector, Replicator and Manager. Our goal is to provide customers with a fully containerized solution and then just go to the next step, which is to connect everything using Kubernetes.

In the early access phase, Continuent would like to provide the Tungsten Proxy (originally Tungsten Connector) as a standalone service within a minimal Docker Image.

What does "minimal" mean? We followed Docker best practices and created a Tungsten Proxy Docker Image, which stores only the Tungsten Proxy service without any other unnecessary services and/or operating system. Thus, this implementation allows us, and our customers, to create Tungsten Proxy Docker containers with a total size of 518 MB (413 kB writable data of container + 517 MB for shared Tungsten Proxy Docker Image).

Use Cases

Running the Tungsten Proxy in a Docker container requires deep knowledge of both Docker and the Tungsten stack. By default, Continuent recommends running the Tungsten Proxy in a well-known Linux environment, such as bare metal or Virtual Machines. The configuration described below is meant for advanced users who use orchestration tools or prefer containers on the backend of their applications.

Deployment

Let’s say our example environment consists of 3 servers - db1, db2 and db3. Server db1 will be the node which holds a Tungsten Proxy in Docker container.

Configuration

Our Tungsten Proxy Docker Image allows us to configure multiple useful options so far:

docker run -d --name tproxy_3307 [configuration here] [repository url here]

• --env CONNECTOR_NAME=tproxy_3307
  This environment variable allows us to change the proxy internal name in the Tungsten Clustering scope. That is the way our proxy introduces itself in tools like cctrl. From best practice, this --env variable should be the same as the docker container name defined in option --name.
• --env CONNECTOR_PORT=3306
  This environmental variable sets the Tungsten Proxy service’s listening port.
• --env CONNECTOR_DATASERVICES=’nyc=db1,db2,db3’
  Same as a content of the dataservices.properties file. In case of multiline content, join lines with a \n character.
• For each server defined in CONNECTOR_DATASERVICES, provide the server's IP address using --add-host=db2:10.10.0.2. If a defined server is also a hosting server of a container, then provide default docker network interface address (can be found via ifconfig), by default it is --add-host=db1:172.17.0.1. These options are mandatory in case the container is in bridge network mode.
• Repository URL is static domain name, where Continuent team share prepared Tungsten Proxy Docker images. To get this URL please contact support.

Networking

From a networking perspective, there are 2 well-known options: bridge network mode and host network mode.

The default network driver setting for Docker is bridge mode. This networking mode offers more isolation for container service and is effective for solutions where multiple Tungsten Proxy Docker containers are deployed in one host. For example, we differentiate multiple Tungsten Proxies with a container external port and a custom Tungsten Proxy name.

docker run -d --name tproxy_3307 --network bridge -p 3307:3306 --add-host=... [more options here]

The command above will create a Docker container with a name tproxy_3307 and bind its internal 3306 port to the container’s external port 3307, which means that our Tungsten Proxy service is accessible by applications on port 3307.

To contrast with Bridge mode, the host network driver mode removes network isolation between the hosting server and the container, and is useful for deployments where only one Tungsten Proxy container is running on the host.

docker run -d --name tproxy_3307 --network host --env CONNECTOR_PORT=3307 [more options here]

This command will create again a Docker container with the name tproxy_3307, and set a proxy service listening port to 3307. Current container is not isolated from the hosting server environment, thus we don’t need to define port bindings and map of servers in the local network. However, if we create multiple Docker containers in host network mode, we get a port binding conflict (for ports used for services communication, metrics and API publishing), and this approach would need additional ports configuration.

IPv6 Support

As mentioned in the documentation of robbertkl/docker-ipv6nat: “Docker was not created with IPv6 in mind”. Thus, if we want to use, for some reason, IPv6 in the networking of our Tungsten Proxy docker containers, we need to proceed with additional configuration steps:

1. Before deploying a Tungsten Proxy docker container, start robbertkl/ipv6nat container that provides NAT for IPv6 (ability for container to communicate with remote hosts in local DNS using IPv6 addresses).

   docker run -d --name ipv6nat --privileged --network host --restart unless-stopped -v /var/run/docker.sock:/var/run/docker.sock:ro -v /lib/modules:/lib/modules:ro robbertkl/ipv6nat

2. Create a dedicated user-defined bridge network for Tungsten Proxy docker containers.

   docker network create --ipv6 --subnet fd00:dead:beef::/48 tproxy_network

3. In every next Tungsten Proxy docker container, use a dedicated IPv6 network as

   docker run ... --network tproxy_network

   and define --add-host configuration with IPv6 addresses (the container hosting server is now --add-host=db1:fd00:dead:beef::1).