At Tutum, our objective is to provide you with the best tools to develop, test and deploy applications in a faster, simpler, yet flexible way. To achieve that, we make use of containers, which provide great benefits in terms of portability and minimal footprint.
We are pleased to announce that we have taken another step towards this objective with the implementation of dynamic links and private overlay networks for containers (using weave).
Background on Docker links and service discovery
Docker introduced at a very early stage in its development the notion of container links with the purpose of providing a simple service discovery mechanism between containers. By using container links, Docker injects connection information (IP and port) of the services available from one container to another. It provides this information in two ways: via environment variables (i.e.
$DB_3306_TCP_ADDR), and via hostnames (i.e.
The benefits of service discovery are very well known: it’s a great way to remove the need to manually specify topology network information (IP and port) of an environment (dev, prod, etc.) when launching containers.
Docker links force you to use environment variables or “placeholder” hostnames in the application image configuration files. This is a great way to allow the image to be reusable across different environments. Both environment variables and DNS hostnames are supported in virtually any programming language, needing very little change to the application codebase.
It also allows you to store this service discovery information in the form of “links” in a “stack definition” (see fig/docker-compose) which can still be reused between environments. It becomes especially powerful if every service in the stack uses containers (you will see the benefit as the number of services increase).
At Tutum, we like this simple yet powerful approach to service discovery, and we have made it even better when you deploy your containers in Tutum with what we call dynamic links.
In Tutum, containers use an internal DNS service to resolve hostnames. For the application, it works exactly the same as if it were running locally, but instead of resolving it using a static
/etc/hosts file, it will issue a query against Tutum’s DNS service which will return the appropriate IP of the linked container at that time (hence the dynamic). This of course works between nodes thanks to the new overlay network for containers, discussed next.
If your linked service consists of more than one container, you will have a per-link hostname which resolves to all linked containers IPs with DNS round robin (i.e.
web A 10.7.0.2 10.7.0.3), and per-container hostnames which resolve to each linked container IPs (i.e.
web-1 A 10.7.0.2,
web-2 A 10.7.0.3). More information about how it all works is available on our support site.
With dynamic links, if you redeploy a service, scale it, or deploy a new linked service, hostnames will automatically be added/updated on all running containers, removing the need to redeploy any of them.
And best of all, this is 100% compatible with Docker links, so if your stack runs in your laptop, it will seamlessly run at scale in Tutum without any modifications.
Private overlay network for containers
All nodes deployed using Tutum are now connected to one another which enables a secure overlay network for the containers running on them. This is true regardless of the geographical location, IaaS provider, or type of node (bring-your-own-node works too!). Every new node launched or added to Tutum via BYON will automatically join the private network. This private network is encrypted and requires authentication; only nodes belonging to a specific account can connect and communicate with each other.
What this mean is that every new container launched has its own universal IP. This IP is reachable from any other container on any other node (belonging to the same account, of course). Even better, when you redeploy a service, all of its containers reuse the same IP address, even if new containers are scheduled to a different node. Thanks to this behavior, there is now no need to redeploy an entire stack when redeploying a single service.
In order for existing services to take advantage of this new functionality, they must be redeployed. Existing services will automatically be connected to the overlay network during the redeployment process. If you use Tutum’s BYON (bring-your-own-node) functionality, make sure your nodes have ports
6783/udp open in any firewalls.
These new features, coupled with the new stacks functionality, will make the deployment of multi-service architectures a far more rewarding experience.
How can we make service discovery work better for you? Looking forward to your feedback!