I need to setup a cluster of nodes using Docker Swarm. When I say a node, it should have a db, few apps/services and they need to commuicate with each other. I can create a single instance of this using Docker Compose.
But, I need multiple instances of this setup. So, would Docker Swarm help?
When I say a node, it should have a db, few apps/services and they need to commuicate with each other
Docker Swarm is a tool for managing cluster of nodes, when node is a machine (VM/physical) with docker installed. it's not clear what you expect "node" to be, but with swarm you can run any number of containers which will be deployed across the different machines in the cluster.
But, I need multiple instances of this setup. So, would docker swarm help?
You can define anything on the cluster, but basically swarm is meant to enable communication between the nodes. if you want all your services (which you call "node") to be on the same machine anyway, so swarm will not give you any benefits. just copy-paste the docker compose file between all your nodes. But this isn't something common/recommended in general so maybe if you'll explain better your needs, it would be easier to help you.
Related
Sorry for this question, but I just started with Docker and Docker Compose and I really didn't need any of this until I read that I need to use Docker Swarn or Kuebernetes to have more stability in production. I started reading about Docker Swarn and they mentioned nodes and clusters.
I was really happy not knowing about this as I understood docker-compose:
Is that I could manage my services/containers from a single file
and only have to run several commands to launch, build, delete, etc.
all my services based on the docker-compose configuration.
But now the nodes and cluster have come out and I've really gone a bit crazy, and that's why if you can help me understand this next step in the life of containers. I've been googling and it's not very clear to me.
I hope you can help me and explain it to me in a way that I can understand.
Thank you!
A node is just a physical or virtual machine.
In Kubernetes/Docker Swarm context each node must have the relevant binaries installed (Docker Engine, kubelet etc..)
A cluster is a grouping of one or more nodes.
If you have just been testing on your local machine you have a single node.
If you were to add a second machine and link both machines together using docker swarm/kubernetes then you would have created a 2 node cluster
You can then use docker swarm/kubernetes to run your services/containers on any or all nodes in your cluster. This allows your services to be more resilient and fault tolerant.
By default Docker Compose runs a set of containers on a single system. If you need to run more containers than fit on one system, or you're just afraid of that system crashing, you need more than one system to do it. The cluster is the group of all of the systems (physical computers, virtual machines, cloud instances) that are working together to run the containers. Each of those individual systems is a node.
The other important part of the cluster container setups is that you can generally run multiple replicas of a give container, and you don't care where in the cluster they run. Say you have five nodes, and a Web server container, and you'd like to run three copies of it for redundancy. Instead of having to pick a node, ssh to it, and manually docker run there, you just tell the cluster manager "run me three of these", and it chooses a node and launches the container for you. You can also scale the containers up and down at runtime, or potentially set the cluster to do the scaling on its own based on load.
If your workload is okay running a single copy of containers on a single server, you don't need a cluster setup. (You might have some downtime during updates or if the single server dies.) Swarm has the advantages of being bundled with Docker and being able to use Docker-native tools (docker-compose can deploy to a Swarm cluster). Kubernetes is much more complex, but at this point most public cloud providers will sell you a preconfigured Kubernetes cluster, and it has better stories around security, storage management, and autoscaling. There are also a couple other less-prominent alternatives like Nomad and Mesos out there.
I've been trying to devise a strategy for using Docker Swarm for managing a bunch of headless containers - don't need load balancer, exposing any ports, or auto scaling.
The only thing I want is the ability to update all of the containers (on all nodes), if any of the images are updated. Each container running will need to have a specific --hostname.
Is running docker service even viable for this? Or should I just do a normal docker run targeting specific nodes to specify the --hostname i want? The reason I'm even asking about docker service is because it allows you to do an update (forcing an update for all containers if there are updated images).
Was also thinking that Docker Swarm would make it a bit easier to keep an eye on all the containers (i.e. manage them from a central location).
The other option I was looking at was watchtower, to run on each server that is running one of the containers, as an alternative to swarm. My only issue with this is that it doesn't provide any orchestration, for centralized management.
Anyone have any ideas of what would be a better option given the scenario?
Docker swarm does not give you any advantage regarding rolling updates apart from the docker service command, swarm only provides the user horizontal scaling and places a load balancer in front of those replicas called "service", as well as some other goodies such as replicating the docker events across the swarm nodes.
docker service --force would work as expected.
However, you should probably use both, docker swarm for orchestration and watchtower for rolling updates.
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.
Is it possible to create a docker swarm cluster using nodes on different cloud providers?
Let's say some of them on AWS, some on GCE and some on Azure?
In my understanding, as long as your nodes could access each other, then you will be able to create a swarm cluster. It doesn't matter who are your cloud providers or where your node located.
If you read the swarm deployment document carefully, you will find the critical thing of deploying a cluster is "let the compute nodes to communicate with controller node". Assume you already have a controller node with swarm and a discovery service (such as consul or etcd) both installed, the you can add a compute node like this:
$ docker run -d swarm join --advertise=<node_ip>:2375 consul://<consul_ip>:8500
Where node_ip and consul_ip should be your controller node's IP.
So the tricky part is, can you make your nodes communicate to each other? Actually this question is not easy to answer. You need to care about IP allocation, network design, routers etc.
Yes. Look at Docker Machine for a quick way of setting up the basic infrastructure.
Docker Machine
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.