is there any way to disable/leave the swarm mode of docker when starting the daemon manually, e.g. dockerd --leave-swarm, instead of starting the daemon and leave the swarm mode afterwards, e.g. using docker swarm leave?
Many thanks in advance,
Aljoscha
I don't think this is anticipated by docker developers. When node leaves swarm, it needs to notify swarm managers, that it will not be available anymore.
Leaving swarm is a one time action and passing this as an configuration option to the daemon is weird. You may try to suggest that on docker's github, but I don't think it will have much supporters.
Perhaps more intuitive option would be to have ability to start dockerd in a way that communication to docker swarm manager would be suspended - so your dockerd is running only locally, but if you start without that flag (--local?) it would reconnect to swarm that it was attached before.
Related
Is it possible to have a docker swarm node leave the swarm, but keep running services started while being a member of the swarm?
Short answer: don't try to do that.
This would be against the design of swarm mode. For the same reason that docker disables the live-restore functionality when you have swarm mode, you shouldn't be able to keep services running when a node leaves the swarm cluster. The logic behind both decisions is when swarm mode detects that the target state of the service doesn't match the current state, it will do what it can to achieve that target state.
With the live-restore, docker would normally leave containers running when the daemon is stopped, and restore those containers to the docker daemon when the daemon restarts. And similarly, if the containers continued to run when the node leaves the swarm, from the view of the swarm manager, the result would be the same, containers running that the manager has no way to track the current state.
Since the current state cannot be tracked in those scenarios, docker errors on the side of stopping the container when it gracefully stops or leaves the swarm. The scenario where containers will continue to run is during an ungraceful disconnection from the swarm manager(s). In that scenario, the worker doesn't know if only it is down and the workload has been rescheduled elsewhere, or if only the manager is down, and stopping the containers would turn a small outage into a big one, so docker errors on the side of leaving the containers running when the disconnect is uncontrolled.
When docker swarm was released in both, standalone and swarm mode, one of the main features was the possibility to change scheduler between binpack and spread. If I run docker swarm in docker-machine, I can choose the strategy by passing the --swarm-strategy parameter, but if I try it running in swarm mode there is in CLI command to pass that parameter.
I found some issues in the docker repository on github that people ask about new strategies different of binpack and spread, but, again, I didnt find how to change it. Seeing the docker source code in master branch, again, there is no CLI command to interact with these parameters.
I know how to interact with docker though docker-machine and standalone to send these parameters, but I don't know that using docker swarm mode. My question is: How to change the strategies when using docker swarm mode? Or: When it will be possible?
After looking through docker official swarm explanations, github issues and stackoverflow answers im still at a loss on why i am having the problem that i have.
Issue at hand: docker-compose up starts services not in the swarm even though swarm is active and has 2 nodes.
Im using 1.12.1 docker version.
Looking at swarm tutorial i was able to start and scale my swarm using docker service create without any issues.
running docker-compose up with version 2 docker-compose.yml results in services starting outside of swarm, i can see them through docker ps but not docker service ls
I can see that docker-machine as the tool that solves this problems, but then again it needs virtual box to be installed.
so my questions would be
Can i use docker-compose with docker-swarm (NOT docker-engine) without docker-machine and without experimental build bundle functionality?
If docker service create can start a service on any nodes is it an indication that network configuration of the swarm is correct ?
What is the advantages/disadvantages of docker-machine versus experimental build functionality
1) No. Docker Compose isn't integrated with the new Swarm Mode yet. Issue 3656 in GitHub is tracking that. If you start containers on a swarm with Docker Compose at the moment, it uses docker run to start containers, which is why you see them all on one node.
2) Yes. Actually you can use docker node ls on the manager to confirm all the nodes are up and active, and docker node inspect to check a particular node, you don't need to create a service to validate the swarm.
3) Docker Machine is also behind the 1.12 release, so if you start a swarm with Docker Machine it will be the 'old' type of swarm. The old Docker Swarm product needed a whole lot of extra setup for a key-value store, TLS etc. which Swarm Mode does for free.
1) You can't start services using docker-compose on the new Docker "Swarm Mode". There's a feature to convert a docker-compose file to the new dab format which is understood by the new swarm mode but that's incomplete and experimental at this point. You basically need to use bash scripts to start services at the moment.
2) The nodes in a swarm (swarm mode) interact using their own overlay network. It's the one named ingress when you do docker network ls. You need to setup your own overlay network to run services in. eg:
docker network create -d overlay mynet
docker service create --name serv1 --network mynet nginx
3) I'm not sure what feature you mean by "experimental build'. docker-machine is just a way to create hosts (the nodes). It facilitates the setting up of the docker daemon on each host, the certificates and allows some basic maintenance (renewing the certs, stopping/starting a host if you're the one who created it). It doesn't create services, volumes, networks or manages them. That's the job of the docker api.
I currently have three hosts (docker1, docker2 and docker3) which I have not set up using Docker Machine, each one running the v1.12-rc4 Docker daemon.
I run docker swarm init on docker1, which in turn prints a docker swarm join command which I run on both docker2 and docker3. At that point, running docker info on each host contains the Swarm: active line.
It is at this point that the behavior seems to differ from what I used to get with the standalone Swarm container. Especially, running docker network ls will only show me the networks on the local host, and when trying to create an overlay network, it does not seem like worker nodes are aware of it (i.e. it does not show up on their docker network ls.)
I feel like I have missed out on some important information relating to the workings of the Swarm Mode as opposed to the Swarm container.
What is the correct way of setting up such a cluster without Docker Machine on Docker 1.12 while getting the overlay network feature?
I too thought this was an issue when I first started using it.
This works a little differently in 1.12rc4 - when you deploy a container to your swarm with that network attached to it, it should then create the network on the other nodes as well.
Hope this helps!
Issue
You are using the docker command (used to communicate with your localhost Docker daemon) and not the "swarm" command (used to communicate with the Swarm master).
Solution
It depends on the command you used to start Swarm.
A full step-by-step tutorial (including details on how to deploy an overlay network) is detailled on this answer. I'm sure that reading this will help you ;)
With a network scope of swarm, the network is only propagated to worker nodes on an as-needed basis. If you create a service using that network, and it gets scheduled on that worker node, the network will show up in the docker network ls.
With the now-upcoming 1.13 release, you can get a network that has similar behavior to the non-swarm networks by doing docker network create --attachable .... That network will be valid for both services and normal containers, and will be available to all members of the cluster. As of 1.13.0-rc2, those don't seem to show up in the output of docker network ls.
I have a silly question regarding docker swarm.
I am thinking I can start a web application image in two containers, either in same server or two vm servers, then I start a load balance container, pointing to two web app containers through IP and port.
In this case, why do I need docker swarm for clustering management? What benefits can docker swarm bring?
I have read from docker documentation, they only introduce what is swarm and how to use swarm. But I can not find out answer for why I have to use swarm.
Thanks
What is swarming managing? turns a pool of Docker hosts into a single, virtual Docker host.
Can swarm auto-start the container if the container died? Yes it can, so can the Docker daemon on each host.
Can swarm auto-create more nodes if the resource is not enough? No it cannot. It does not aims on providing this service. Nevertheless you can program a node that start and run containers when needed.
Which mean, if traffic grows fast, do we still manually create more node and deploy more containers? Yes, unfortunately.
update
If needed, here is an answer that details how to deploy a Swarm cluster.