I have a cluster of 10 Swarm nodes started via docker swarm join command
If i want to scale a docker instance to 15 via
docker service create --replicas 15
how does docker swarm know where to start the container?
is it round-robin or does it take into consideration of compute resource (how much cpu/mem being used)?
When you create a service or scale it in the Swarm mode, scheduler on Elected Leader (one of the managers) will choose a node to run the service on. There are 3 strategies currently available to the leader.
spread
binpack
random
The spread and binpack strategies compute rank according to a node’s available CPU, its RAM, and the number of containers it has. The random strategy uses no computation. It selects a node at random and is primarily intended for debugging.
Under the spread strategy, Swarm optimizes for the node with the least number of containers. The binpack strategy causes Swarm to optimize for the node which is most packed.
Swarm uses spread by default.
Keep in mind you can Constraint Containers on specific nodes too.
It's not possible to set strategies in docker version 1.12.1 (Latest release to posting date)
Related
How can I make Docker Swarm distribute containers based on CPU load and not equally across all nodes (right now it seems to be doing the latter)?
I know this is a basic question. But I'm new to docker and have this query.
Do I need to install docker in all my nodes that are part of my swarm mode?.
If so what are the ways that I install docker in all my nodes in one shot?
Of course you need to install Docker and its dependencies on each node. On one of the manager nodes, you need to initiate the swarm with docker swarm init and then you join the other machines either as manager nodes or worker nodes.
The number of manager nodes depends on your requirement to compensate node losses:
1 manager node: requires 1 healthy node
3 manager nodes: require 2 healthy nodes for quorum, can compensate 1 unhealthy node
5 manager nodes: require 3 healthy nodes for quorum, can compensate 2 unhealthy nodes
7 manager nodes: require 4 healthy nodes for quorum, can compensate 3 unhealthy nodes
more than 7 is not recommended due to overhead
Using a even number does not provide more reliability, it is quite the oposite. If you have 2 manager nodes, the loss of either one of them renders the cluster headless. If the cluster is not able to build quorum (requires the majority of of manager nodes beeing healthy), the cluster is headless and can not be controlled. Running containers continue to run, but no new containers can be deployed, failed containers won't redeploy, ...).
People usualy deploy a swarm configuration with a configuration management tool like Ansible, Puppet, Chef or Salt.
Can anyone share their experience of changing the docker swarm scheduling strategy as there are three (spread, binpack and random). spread is default strategy used by docker swarm and I want it change to binpack.
The Swarm scheduling strategies you've listed are for the Classic Swarm that is implemented as a standalone container that acts as a reverse proxy to various docker engines. Most everyone is using the newer Swarm Mode instead of this, and little development effort happens for Classic Swarm.
The newer Swarm Mode includes a single option for the scheduler that can be tuned. That single option is an HA Spread algorithm. When you have multiple replicas of a single service, it will first seek to spread out those replicas across multiple nodes meeting the required criteria. And among the nodes with the fewest replicas, it will pick the nodes with the fewest other scheduled containers first.
The tuning of this algorithm includes constraints and placement preferences. Constraints allow you to require the service run on nodes with specific labels or platforms. And the placement preferences allow you to spread the workload across different values of a given label, which is useful to ensure all replicas are not running within the same AZ.
None of these configurations in Swarm Mode include a binpacking option. If you wish to reduce the number of nodes in your swarm cluster, then you can update the node state to drain workload from the node. This will gracefully stop all swarm managed containers on that node and migrate them to other nodes. Or you can simply pause new workloads from being scheduled on the node which will gradually remove replicas as services are updated and scheduled on other nodes, but not preemptively stop running replicas on that node. These two options are controlled by docker node update --availability:
$ docker node update --help
Usage: docker node update [OPTIONS] NODE
Update a node
Options:
--availability string Availability of the node ("active"|"pause"|"drain")
--label-add list Add or update a node label (key=value)
--label-rm list Remove a node label if exists
--role string Role of the node ("worker"|"manager")
For more details on constraints and placement preferences, see: https://docs.docker.com/engine/reference/commandline/service_create/#specify-service-constraints---constraint
I am currently trying to understand what would be necessary to create a docker swarm to make some service highly available. I read through a lot of the docker swarm documentation, but if my understanding is correct, docker swarm will just execute a service on any host. What would happen if a host fails? Would the swarm manager restart the service(s) running on that host/node on another one? Is there any better explanation of this than in the original documentation found here?
Nothing more complex than that really. Like it says, Swarm (and kubernetes, and most other tooling in this space) is declarative, which means that you tell it the state that you want (i.e. 'I want 4 instances of redis') and Swarm will converge the system to that state. If you have 3 nodes, then it will schedule 1 redis on Node 1, 1 on Node 2, and 2 on Node 3. If Node 2 dies, then the system is now not 'compliant' with your declared state, and Swarm will schedule another redis on Node 1 or 3 (depending on strategy, etc...).
Now this dynamism of container / task / instance scheduling brings another problem, discovery. Swarm deals with this by maintaining an internal DNS registry and by creating VIP (virtual IPs) for each service. Instead of having to address / keep track of each redis instance, I can instead point to a service alias and Swarm will automatically route traffic to where it needs to go.
Of course there are also other considerations:
Can your service support multiple backend instances? Is it stateless? Sessions? Cache? Etc...
What is 'HA'? Multi-node? Multi-AZ? Multi-region? Etc...
I would like to create docker-compose file in my development environment and use it to spin up a single machine "swarm". The goal would be to have the development environment be as consistent as possible with the CI, QA, and Prod environments.
I used docker a year+ ago but a lot has changed and I'm very interested in using 1.12 as my platform. My questions are as follows:
What is the difference between a "node" and a "physical machine"? Can a single machine (aka, a developer laptop) host multiple node's? My guess is that a node is virtual and that I should be able to have more than one but don't feel certain of it.
Assuming answer to #1 is that it is possible ... is there any reason these various nodes can't be "swarm workers" along with a singular "manager" all running on the laptop?
Note: I know it would be possible with VM's to emulate other machines -- many of the examples start off by doing this -- but I want to avoid running any VMs to lower the resource cost of running this setup
Are there any good examples of single-node swarms people can refer me to?
A node in the docker swarm is an instance of the docker engine configured in the swarm (with an init or join). An instance of a docker engine can only join up to a single swarm (so 0 or 1), so you can't create multiple nodes on the same engine. A typical developer install to test multiple nodes in a swarm is to spin up multiple VM's, each with a docker install.
You can have a swarm with a single manager which is also a worker. Tasks scheduled in a swarm may be scheduled on a manager just as they would a worker. Workers have no ability to manage the swarm, but managers have all the abilities of a worker. If you want to simply be able to run docker service commands, you can do a docker swarm init on yourself and then define your services there.