How made ban more than one container on a node with use: Docker, Swarm, Compose? For example I have 5 nodes and I want deploy 3 replicas some service and I want that this replicas will be on different nodes.
Asked
Active
Viewed 352 times
0
-
I doubt it is there yet https://github.com/docker/swarm/issues/1734 – Tarun Lalwani Aug 20 '17 at 17:29
-
Yep... issue is open. It is bad. May be I should use other orchestration system, may be Nomad or Kubernetes or other? – Ivan Bukharin Aug 20 '17 at 18:05
-
You should use memory constraints and cpu constraints and not worry about # of containers – Tarun Lalwani Aug 20 '17 at 18:26
-
I using Apache Storm where exist Supervisor thing and his must be instance single on a machine node – Ivan Bukharin Aug 20 '17 at 19:24
-
You put constraint while running containers, See this https://docs.docker.com/compose/compose-file/#placement – Tarun Lalwani Aug 20 '17 at 19:49
-
This does not limit the number of instances on one machine. Constraint point to the machines where the containers are deployed, but they do not say anything about the number of container instances. – Ivan Bukharin Aug 20 '17 at 20:16
1 Answers
0
Docker's swarm mode currently defaults to an HA scheduling strategy, so there's nothing needed to get your service spread across multiple nodes as long as there are multiple available nodes to schedule the task on. Constraints, memory restrictions, and outages may impact the available nodes that is has to schedule a task on. The HA scheduler first searches for candidate nodes that have the fewest instances of a task (typically 0 unless you have more replicas than nodes), and then it tie breaks the resulting list by favoring nodes with fewer tasks.
For further control to spread out a task on multiple nodes, I'd recommend looking into the placement preferences added in recent versions. I don't believe this has made it into stacks and the compose file yet, but I expect that's only a matter of time until it does (new swarm mode features are first introduced to the docker service command line and later added to higher level abstractions). The placement preferences allow you to label your nodes to indicate a higher level topology, e.g. common racks, switches, or datacenters. And the placement preferences enable topology aware scheduling that can spread the tasks out among nodes with unique values of the desired label. So if you have two separate racks with 5 nodes each, without the topology aware scheduling everything could be scheduled on a single rack, and with the topology aware scheduling, it could put half of your tasks on each rack.
BMitch
- 231,797
- 42
- 475
- 450