3 ms·

>this has the same great K8S API, that Swarm lacks. (Deployment is a first class citizen in kube land, but you only have to make do with the service YMLs in the

>this has the same great K8S API, that Swarm lacks. (Deployment is a first class citizen in kube land, but you only have to make do with the service YMLs in the Swarm sphere.) With all due respect, some (like me) consider that a feature of Swarm. If k3s comes with the same API (and implicit yaml complexity) of k8s, but just reduces RAM usage...well that's not very interesting for me. Docker Swarm is very lean - there are zillions of videos of how people are building interesting raspberry Pi stacks using it (https://youtu.be/mMpZpa7uUSk https://youtu.be/mMpZpa7uUSk). But for most people using Swarm - they are using it for one reason only : simplicity.

GordonS 8y ago
I use Docker Compose on a small, cloud-hosted VM to run all my development dependencies and stuff I need for testing (I've got RabbitMQ, Postgres and Splunk running at present). It was really simple to setup, and "just works" - and the nodes don't have to compete with a greedy K8s orchestrator for resources!
- seabrookmx 8y ago
  Ditto. For a single machine you don't need "orchestration" - you just need something cleaner than a bash script to start/stop and potentially restart your containers. I set up my home server with minikube more as a learning exercise, but went back to docker-compose for running all the things I actually rely on (Plex for instance) just because it's so much simpler.
  - pas 8y ago
    Agreed. k8s makes no sense on 1 node. But in my experience Swarm is just not enough when you have more than one node. You have to work around a few missing key features. (Like the management of deployments. With Swarm you have stacks, and you can update them, but you can't easily roll back the update, you can't easily manage/configure the update. And if the update gets stuck, it just gets stuck, it's not managed.)
    - sandGorgon 8y ago
      The stuck issue is not a limitation of Swarm, but was a bug that has gotten fixed in 18.06 - https://github.com/moby/moby/issues/37493 https://github.com/moby/moby/issues/37493 Rollback has existed for a while now - https://docs.docker.com/engine/reference/commandline/service_rollback/ https://docs.docker.com/engine/reference/commandline/service... . you can actually tune the parallelism and the delay

GordonS 8y ago

I use Docker Compose on a small, cloud-hosted VM to run all my development dependencies and stuff I need for testing (I've got RabbitMQ, Postgres and Splunk running at present). It was really simple to setup, and "just works" - and the nodes don't have to compete with a greedy K8s orchestrator for resources!

seabrookmx 8y ago
Ditto. For a single machine you don't need "orchestration" - you just need something cleaner than a bash script to start/stop and potentially restart your containers. I set up my home server with minikube more as a learning exercise, but went back to docker-compose for running all the things I actually rely on (Plex for instance) just because it's so much simpler.
- pas 8y ago
  Agreed. k8s makes no sense on 1 node. But in my experience Swarm is just not enough when you have more than one node. You have to work around a few missing key features. (Like the management of deployments. With Swarm you have stacks, and you can update them, but you can't easily roll back the update, you can't easily manage/configure the update. And if the update gets stuck, it just gets stuck, it's not managed.)
  - sandGorgon 8y ago
    The stuck issue is not a limitation of Swarm, but was a bug that has gotten fixed in 18.06 - https://github.com/moby/moby/issues/37493 https://github.com/moby/moby/issues/37493 Rollback has existed for a while now - https://docs.docker.com/engine/reference/commandline/service_rollback/ https://docs.docker.com/engine/reference/commandline/service... . you can actually tune the parallelism and the delay