Lessons learned from using Docker Swarm mode in production
blog.bugsnag.com
Lessons learned from using Docker Swarm mode in production
1–10 of 55 posts
Re: Lessons learned from using Docker Swarm mode in production
#2I am a broken record lately on here... Nomad is really awesome for avoiding configuration hell and having to manage multiple services for container orchestration. It's a single binary and very very easy to setup and run. I actually prefer it to Swarm but YMMV.
It uses Consul under the hood and has so far been bulletproof. (They all have their drawbacks / idiosyncrasies).
Re: Lessons learned from using Docker Swarm mode in production
#3As long as your willing to re-architect your app so that workers pull web requests from a queue rather than expecting to just... serve traffic normally.
Or did I misunderstand that section?
Re: Lessons learned from using Docker Swarm mode in production
#4I am a broken record lately on here... Nomad is really awesome for avoiding configuration hell and having to manage multiple services for container orchestration. It's a single binary and very very easy to setup and run. I actually prefer it to Swarm but YMMV. It uses Consul under the hood and has so far been bulletproof. (They all have their drawbacks / idiosyncrasies). https://www.nomadproject.io/
just curious - does it provide rolling updates to the jobs that you're running currently?
Re: Lessons learned from using Docker Swarm mode in production
#5As long as your willing to re-architect your app so that workers pull web requests from a queue rather than expecting to just... serve traffic normally. Or did I misunderstand that section?
Incorrect - that's what we're running currently but as soon as the routing mesh issues are resolved you can start running apps that listen on ports too
Re: Lessons learned from using Docker Swarm mode in production
#6I am a broken record lately on here... Nomad is really awesome for avoiding configuration hell and having to manage multiple services for container orchestration. It's a single binary and very very easy to setup and run. I actually prefer it to Swarm but YMMV. It uses Consul under the hood and has so far been bulletproof. (They all have their drawbacks / idiosyncrasies). https://www.nomadproject.io/
The one feature that to me seems to be essential but appears to be missing from all these container orchestrators is the ability to tie a remote volume (Ceph/Gluster/Lustre/etc) to a container so that if a container is scheduled to run on a certain node, the volume will automatically be mounted on the same node.
It seems from the mailing list that at least Nomad will have that at some point, but I have not seen much talk about it from Kubernetes or Docker Swarm.
Re: Lessons learned from using Docker Swarm mode in production
#7Nothing whose version ends in "-rc4" is used in "production". You're using it in a very hot beta test.
Re: Lessons learned from using Docker Swarm mode in production
#8I am a broken record lately on here... Nomad is really awesome for avoiding configuration hell and having to manage multiple services for container orchestration. It's a single binary and very very easy to setup and run. I actually prefer it to Swarm but YMMV. It uses Consul under the hood and has so far been bulletproof. (They all have their drawbacks / idiosyncrasies). https://www.nomadproject.io/
The one feature that to me seems to be essential but appears to be missing from all these container orchestrators is the ability to tie a remote volume (Ceph/Gluster/Lustre/etc) to a container so that if a container is scheduled to run on a certain node, the volume will automatically be mounted on the same node. It seems from the mailing list that at least Nomad will have that at some point, but I have not seen much…
we tried using EFS for shared storage but quickly depleted our I/O bursting credits and our throughput dropped to a grinding halt, because our app's worklaod is both disk write and read intensive. No solutions yet
Re: Lessons learned from using Docker Swarm mode in production
#9I am a broken record lately on here... Nomad is really awesome for avoiding configuration hell and having to manage multiple services for container orchestration. It's a single binary and very very easy to setup and run. I actually prefer it to Swarm but YMMV. It uses Consul under the hood and has so far been bulletproof. (They all have their drawbacks / idiosyncrasies). https://www.nomadproject.io/
The one feature that to me seems to be essential but appears to be missing from all these container orchestrators is the ability to tie a remote volume (Ceph/Gluster/Lustre/etc) to a container so that if a container is scheduled to run on a certain node, the volume will automatically be mounted on the same node. It seems from the mailing list that at least Nomad will have that at some point, but I have not seen much…
Kubernetes supports this via PersistentVolumes. Supported types include:
GCEPersistentDisk AWSElasticBlockStore AzureFile FC (Fibre Channel) NFS iSCSI RBD (Ceph Block Device) CephFS Cinder (OpenStack block storage) Glusterfs VsphereVolume HostPath (single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
Re: Lessons learned from using Docker Swarm mode in production
#10I am a broken record lately on here... Nomad is really awesome for avoiding configuration hell and having to manage multiple services for container orchestration. It's a single binary and very very easy to setup and run. I actually prefer it to Swarm but YMMV. It uses Consul under the hood and has so far been bulletproof. (They all have their drawbacks / idiosyncrasies). https://www.nomadproject.io/
The one feature that to me seems to be essential but appears to be missing from all these container orchestrators is the ability to tie a remote volume (Ceph/Gluster/Lustre/etc) to a container so that if a container is scheduled to run on a certain node, the volume will automatically be mounted on the same node. It seems from the mailing list that at least Nomad will have that at some point, but I have not seen much…
True. I didn't know that was even being discussed. I'd never really thought about the container host dynamically pulling in a volume as a dependency for a container.
The best I've been able to do is use AWS EFS on my container hosts so that my ECS tasks with volume mounts find the same stuff everywhere.