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
instance!=<INST>new instance must not be on the same server as
instance==~<INST>attempt to place on the same server as
instance!=~<INST>attempt to place on a server other than
At this time,
<INST> can only be an exact name match for the affinity or anti-affinity rule.
# 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 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
To learn more about this topic as it relates to Docker containers, read about controlling container placement with Docker Swarm.