2k nodes, 100k containers https://blog.online.net/2016/07/29/docker-swarm-an-analysis-...
(Disclaimer: I'm on the Nomad team but wasn't at the time of the post)
11–20 of 37 posts
2k nodes, 100k containers https://blog.online.net/2016/07/29/docker-swarm-an-analysis-...
(Disclaimer: I'm on the Nomad team but wasn't at the time of the post)
2k nodes, 100k containers https://blog.online.net/2016/07/29/docker-swarm-an-analysis-...
1.55k nodes, 250k containersed applications[0].
Mind you, it's hard to compare these as there's no real "cloud bench". For pure benchmark porn Nomad are the undisputed champs on their 1 million case.
The Cloud Foundry scaling test was intended to show a system with fully service-configured, fully-routed apps, with varying app characteristics (memory and RPS). To further stress the system, thousands of apps crashing and are relaunched on a continuous basis.
Cloud Foundry installations with >10k containers have been ordinary for a while now; the 250k thing was to ensure we had lots of headroom and shake out chokepoints in Diego.
[0] https://content.pivotal.io/blog/250k-containers-in-productio...
Disclosure: I work for Pivotal, the majority donor of engineering on Cloud Foundry.
[1] https://docs.docker.com/engine/swarm/
[2] https://github.com/docker/swarm
[3] Difference between Docker Swarm and Swarm mode: http://stackoverflow.com/questions/40039031/what-is-the-diff...
Does anyone know how easy it is to set up autoscaling with Docker Swarm running on Google Cloud or AWS? We're looking to get starting with Docker Swarm or Kubernetes soon, and are considering using Docker Swarm because of its simplicity and developer familiarity with Docker Compose (we use it for our dev environment). We just want to add nodes to a cluster as traffic spikes and subsides.
For instance/node level autoscaling (which is closer to what you need), I would recommend using the autoscaling features provided by AWS/Google Cloud.
I always wonder, why not isolate on a process level, or even withing a single, multi-threaded app. Sure you can run some sort of web service on hundreds of docker containers or you can run a single, fast web server that scales?
When that single web server goes down, it's not so "fast" anymore.
Why is worrying about a single web server going down more worrisome than some part of the Docker stack going down and causing the same issue?
I always wonder, why not isolate on a process level, or even withing a single, multi-threaded app. Sure you can run some sort of web service on hundreds of docker containers or you can run a single, fast web server that scales?
When that single web server goes down, it's not so "fast" anymore.
Does anyone know how easy it is to set up autoscaling with Docker Swarm running on Google Cloud or AWS? We're looking to get starting with Docker Swarm or Kubernetes soon, and are considering using Docker Swarm because of its simplicity and developer familiarity with Docker Compose (we use it for our dev environment). We just want to add nodes to a cluster as traffic spikes and subsides.
I always wonder, why not isolate on a process level, or even withing a single, multi-threaded app. Sure you can run some sort of web service on hundreds of docker containers or you can run a single, fast web server that scales?
Earlier quoted context omitted.
When that single web server goes down, it's not so "fast" anymore.
Agreed, though I keep wanting to take the time to get VRRP working with a web server to have redundancy. OpenBSD uses this to coordinate stateful firewalls with 2 or more systems, if 1 goes down all state info is present on the second node which takes over.