Control container placement with affinity rules

Building "cloud-scale" applications means designing to accommodate failure, and that requires distributing application components so that localized failures don't take down the entire application. Some people also want to control placement to keep components close together for theoretically faster network performance between them.

You can set affinity and anti-affinity rules to control the relative placement of your application components in the cloud to meet your needs.

By default, Triton makes a reasonable attempt to spread all containers and VMs owned by a single account across separate physical servers.

We recommend setting a loose anti-affinity for each of your application components. Add -a <RULE> or --affinity=<RULE> to set the parameters to your instance creation. Rules have one of the following forms:

• instance==<INST> the new instance must be on the same server as <INST>
• instance!=<INST> new instance must not be on the same server as <INST>
• instance==~<INST> attempt to place on the same server as <INST>
• instance!=~<INST> attempt to place on a server other than <INST>'s.

At this time, <INST> can only be an exact name match for the affinity or anti-affinity rule.

For example:

# List available instances
$ triton insts | grep "mongo"
SHORTID   NAME                 IMG                              STATE    FLAGS  AGE
b5e88fcf  mongo-1              mongodb-3@20170405               running  -      12m
7r988f3s  mongo-2              mongodb-3@20170405               running  -      45m

# Create "mongo-3" with an attempt to put it on a different server from "mongo-2"
$ triton instance create -w --name=mongo-3 -a 'instance!=~mongo-2' mongodb-3 g4-highcpu-128M
Creating instance mongo-4 (214a3cb1-3cca-6650-9db0-d4f7d29c08af, mongodb-3@20170405)
Created instance mongo-4 (214a3cb1-3cca-6650-9db0-d4f7d29c08af) in 1m9s

To add multiple rules, use the -a option more than once when creating an instance.

To see where your MongoDB containers are, use triton:

$ triton instances -o name,compute_node | sort | grep "mongo"
NAME           COMPUTE_NODE
mongo-1        f57ce6d4-18d3-11e4-bb70-002590ea597c
mongo-2        8a818a00-e289-11e2-8944-002590c3ebfc

This CLI example will reveal any piling of instances:

$ triton insts -H -o compute_node | sort | uniq -c | sort
   1   8f836eda-1cf6-11e4-a382-002590e4f380
   1   aaa7da0a-2f7d-11e3-9d09-002590c3ed18
   1   c78dd9de-e064-11e2-b0c9-002590c3edd4
   2   d088b3f6-2f7e-11e3-b276-002590c3ed68
   3   69590e24-2f7e-11e3-a59d-002590c3f140
   4   f57ce6d4-18d3-11e4-bb70-002590ea597c

More about affinity

To learn more about this topic as it relates to Docker containers, read about controlling container placement with Docker Swarm.