Cloud Infrastructure Automation for Docker Nodes


One of the most loved features by our users is Tutum’s ability to simply provision and manage infrastructure from a growing number of cloud IaaS providers. With Tutum, users don’t have to worry about setting up servers, managing instances with numerous providers, across different data centers, installing dependencies, building AMIs, applying updates, patches, upgrades etc. Tutum works behind the scenes to take care of all of this for you. By freeing developers from all the busy work, Tutum enables developers to do more, with less.

Given the increasing interest in Tutum’s infrastructure capabilities, auto-magically provisioning and managing nodes (i.e. instances, servers, VMs) we’ve decided to write this blog post to share detailed information on the process.

There are two ways to provision a node using Tutum:

Tutum-managed Nodes from IaaS Providers

Tutum, today, natively supports the following Infrastructure as a Service (IaaS) providers:

For Tutum users, linking any provider is straight-forward, and the process only differs depending on authentication methods.

  • Digital Ocean’s (DO) newest API uses the OAuth standard. After the user logs in to DO and grants access, Tutum is able to securely communicate with Digital Ocean to provision and manage droplets. You can read more about OAuth authentication here. Documentation from DO is available here.
  • Softlayer relies on an API key to allow third party services to interact with its API on behalf of the user. Users need to retrieve their API key by logging into their Softlayer account. Tutum uses said API key to communicate with Soflayer to provision and manage VMs. Softlayer API documentation is available here.
  • Amazon Web Services makes use of an Access Key. The Access Key is composed of an Access Key ID and the Secret Access Key; Tutum requires both to provision infrastructure on AWS on behalf of the user. Access Keys can be created from AWS’s IAM (Identitiy and Access Management) console.
  • Azure is interesting to say the least. Although Microsoft claims to offer support for the OAuth standard, months of trying to get it working on Tutum tells us otherwise. Microsoft’s OAuth implementation is constrained, and tokens expire after ~5 hours, making OAuth insufficient for Tutum’s use case, where tokens must be long-lived. Thankfully Azure also offers the ability to authenticate and make use of its API through public/private certificate pairs. Tutum will soon be supporting certificates in favor of Oauth. More info from Microsoft Azure here.

Node clusters: for simpler management and infrastructure scaling, tutum-managed nodes from IaaS providers are provisioned into node clusters. Node clusters are logical groups of nodes of the same type, from the same provider and running in the same region. Node Clusters can be easily scaled up/down with a drag of the slider.

Bring Your Own Node (BYON)

If your infrastructure provider isn’t supported by Tutum yet, or if you have you own servers, VMs, or Vagrant boxes that you’d like to use with Tutum, BYON lets you do just that.

With bring your own node, you just need to execute a simple script in the host you want to register in Tutum as a node. For example:

$ curl -Ls | sudo -H sh -s 6a6bcfb8335e4119ba0bd216d3fe0ae1

The script installs our tutum-agent on it.

How Node Provisioning Works

Provisioning a node with Tutum is a 2-step process. The first of which is only applicable to Tutum-managed nodes from IaaS Providers.

  1. Tutum communicates with a provider’s API on behalf of the user to configure the host (instance, droplet, VM, etc.) as per the user’s request.

At this point, Tutum handles any errors an IaaS provider may throw (e.g. no capacity in chosen region, outdated billing information, etc.) and informs the user of the state of the request. Tutum does not continue the provisioning process until the node is up and ready to go.

The second step of this process happens for all nodes, tutum-managed nodes and BYON.

  1. In this step, tutum-agent is installed in the host. This agent is an open source project, which you can learn more here. The agent is a lightweight binary, written in Go. It installs docker, runs the docker daemon and communicates with Tutum’s API to get the certificates, which secures communication between Tutum and that node’s docker daemon. It is also responsible for upgrading Docker as new versions are made available. In the future, it will also automate the installation of node’s security patches.

Firewall/NAT Tunneling

If the agent detects that the Docker port (2375) is not accessible from the outside world, it will automatically set up a secure introspectable tunnel using Ngrok. Tutum runs its own ngrok server at This tunnel enables Tutum to communicate with a node even if it’s behind a NAT (Network Address Translation) or a firewall.

Provisioning Status

Users can follow the provisioning process in the node’s or node cluster’s timeline. Once the provisioning process is completed, the node is then ready to start running your containers!

However, from time to time things won’t work as expected. If something were to go wrong, Tutum provides users with as much detailed information as possible (depends on the IaaS provider). The team is also internally notified of any issues in order to troubleshoot and further enhance the provisioning process.

Where in the World?

Users can choose the region/data center in which to provision their nodes during the provisioning wizard. Tutum provides support for all standard regions of all IaaS providers, meaning users have in excess of 50 different locations to choose from to deploy their nodes.

Similarly, users have the ability to explicitly choose the node in which a service’s containers run. This is done using deploy tags. Users can tag nodes or node clusters and use those tags as deployment constraints when running their services.

Here’s an example: imagine production services and staging services must be deployed to different nodes. A user can tag production nodes with a “production” tag, and staging nodes with a “staging” tag. When creating services, “production” and “staging” can be specified to force a service’s containers to land in those nodes. Tags can be used for other purposes, like distinguishing between layers, such as “lb”, “web”, “data”, etc.

An interesting use case for deployment tags is to create a custom multi-provider, multi-region node clusters for increased resiliency and availability. This will be covered in detail in a future article.

AWS EC2 Regions Exception

AWS EC2 node deployment is handled a bit differently, since AWS regions are divided into multiple availability zones (AZs) learn more here.

This means users can deploy multiple nodes in the same region, yet those nodes may actually be in different zones of the same region. Tutum automatically attempts to provision nodes of the same node cluster in different AZs for increased availability. This works well with Tutum’s high availability deployment strategy, which automatically distributes containers of a service across multiple nodes. This strategy to provision nodes is applied both to AWS classic and to VPC deployments.

I hope this article helps shed some light and provides users with a better understanding of what happens behind the scenes at Tutum when we’re provisioning your infrastructure to help you focus on what’s truly important, your applications. Questions? Feedback? Comments? Do not hesitate to reach out!

Tagged with: , , ,
Posted in Features, General
One comment on “Cloud Infrastructure Automation for Docker Nodes

Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: