Why we need Orchestration
One of the biggest headaches in the current cloud computing state of the art is the attempt to automate, control and manage complex sets of manual tasks, thereby boosting their performance to save time and money. Manual methods are perceived to be safe, but they are uncoordinated, slow to configure for every use case and cannot be self-healed in case of an unexpected wrong behavior.
A particular example where this is evident is in managing cloud infrastructure and application deployments. Launching a node in a cloud infrastructure provider or deploying an application to the node we just created are easy to perform, but is this scalable?
What about launching 1000 nodes and deploying 400 applications over the infrastructure based on their free resources or making it highly available? If we need to upgrade our application to a new version without downtime, will we start from the beginning again and then migrate? How can we follow the progress and the state of our requests?
When we try to answer some of these questions, we realize that automation by itself will not be able to fulfill all these needs. What we really need are deployment strategies, task monitoring, participation and decision making on the part of the infrastructure or applications being managed.
Automating what we want to accomplish is only part of the solution – how, when and where deployments are performed: this is orchestration.
Orchestration at Tutum
When defining a service in Tutum we can specify these policies to decide how, when and where containers will be deployed.
Assigning tags to our service will determine where the service’s containers will be deployed. Tutum will select the specific nodes from the pool of candidate nodes that match all of the tags defined in the service as long as they can also accommodate the published host ports and volumes restrictions. If the service does not have tags, all the candidate nodes are selected.
Once we have the candidate nodes where containers can be deployed, Tutum uses the specified deployment strategy of the service to decide per container, which node is the most suitable. The deployment strategies that can be specified are:
Emptiest node: For each container, Tutum selects the node with the lowest total number of containers, regardless of the service the containers belong to. This strategy typically balances the total load of all services across all nodes.
High availability: For each container, Tutum selects the node with the lowest number of containers of the service we are deploying or scaling.
Every node: Target number of containers of the service is ignored and the container is deployed in every candidate node. This is typically used to increase the service availability. This strategy can also be used for node monitoring services or administrative tasks such as backups, logging, etc.
Note that in all deployment strategies Tutum system containers are not taken into account when deciding the best node.
Autorestart and Autodestroy
After having selected the candidate nodes based on the published ports, volumes restrictions and deploy tags and determine the most suitable node per each container regarding the deployment strategy, the containers are deployed.
Now that we have our containers running, we can decide what to do when the containers finish successfully or when they go down. To establish this behavior the Autorestart and Autodestroy policies can be defined. If Autorestart is activated, Tutum will evaluate whether to try restarting the container before evaluating Autodestroy.
Autorestart will automatically start your containers whenever they stop. Available options are:
OFF: if the container stops, regardless of the exit code, it won’t be autorestarted and will stay in the
ON_FAILURE: if the container stops with an exit code different from 0, it will be autorestarted.
ALWAYS: if the container stops, regardless of the exit code, it will be autorestarted.
On the other hand, Autodestroy will automatically terminate containers when they stop (destroying all data within the container). Available options are:
OFF: if the container stops, regardless of the exit code, Tutum will not terminate it and will leave it in Stopped state.
ON_SUCCESS: if the container stops with an exit code equal to 0, Tutum will automatically terminate it. Otherwise, it will leave it in Stopped state.
ALWAYS: if the container stops, regardless of the exit code, Tutum will automatically terminate it.
The Autodestroy policy is useful for one-off actions which store results in an external system such as jobs or periodic tasks.
Some restrictions are set when defining autorestart and autodestroy policies. If Autorestart is ALWAYS, Autodestroy cannot be defined because it will never be executed.
Tutum is always pursuing the easiest and simplest way to accomplish our user’s goals, with orchestration being a key piece. To give you even more control, we have Deployment constraints coming soon.
In addition to orchestration, Tutum offers much more from our private repository to our networking, logging, and monitoring solutions. We’ll continue working to improve all aspects of our container platform, to give you a seamless experience going from code to production. Let me know what you’d like to see next!