5 ms·

Docker swarm is supposed to be the migration target for these cases, but I’ve never actually used it.

tommica 3y ago
I run it on a personal server, so there is no multi server setup, but I enjoy the fact that it's just an extension of docker compose.
agumonkey 3y ago
I lost track about it, I thought swarm was canceled
- Cfu288 3y ago
  Docker swarm mode (still around) != docker swarm (cancelled). Poorly named so the confusion is normal
e12e 3y ago
Swarm works, but has poor support for volumes - which means it's tricky to run legacy applications on swarm (which eg uploads files to local disk, not s3 - or keeps state/cache on disk, not a database). Ingress is also more complicated/bespoke - the best I've found is traefik with labels for routing/config. My advice today would be to scale Docker compose vertically (eg: on a dedicated server) - then move to Kubernetes. The swarm middle ground isn't really worth it IMNHO.
- nwienert 3y ago
  Traefik is really simple to set up and I’d bet setting up s3 is 100x easier than kubernetes no? Unless I’m missing something. Fwiw I found swarm lovely and just so much easier to work with than anything else solving the same problems.
  - e12e 3y ago
    Porting a ten year old app from local file storage to s3 might not be trivial. For a new app, one generally should and can embrace 12-facors, and delegate state to stateful services (managed databases, key-value stores, s3 etc). Do note that for simple services, local disk can be very hard to beat for low complexity, extremely high performance - with the caveat that horizontal scaling might be tricky. Ed: also depending on privacy requirements - self- hosted s3 (eg minio) might be tricky for a production load. OTOH self-hosted Kubernetes is no walk in the park either!
- ndsipa_pomu 3y ago
  > Swarm works, but has poor support for volumes - which means it's tricky to run legacy applications on swarm (which eg uploads files to local disk, not s3 - or keeps state/cache on disk, not a database). One way round that is to use an NFS volume. However, I've hit problems with too many client NFS connections on a docker swarm and so found it better to mount the NFS volume on each host and use a bind mount instead.
  - ancieque 3y ago
    CSI support will hopefully make this easier. But: there are quite some options once you Look deeper. Also the volume plugin spec is so simple that it is possible to maintain your own plugin (even without csi).
  - e12e 3y ago
    My general feeling about adding an NFS depency to multinode swarm is that it's effectively adding a single point of failure to a system which is otherwise somewhat robust against single node failure...
belthesar 3y ago
I've done some labbing with Swarm. Swarm is _just different enough_ to be a pain, but just similar enough to fool you into thinking you know what you're doing. Because swarm was also confused terminology (at one point there were two things with the name swarm that did things differently) the tech definitely got a bad rap for a while, but it also stagnated supporting tooling. You can use things like Portainer and Swarmpit to get some visibility into your swarm cluster members, deploy workloads, etc, but it definitely feels like a second class citizen. Ultimately, I would love for something to exist out there that had the opinions and scope of deployment like Swarm in terms of simplicity, but didn't conflate other tools out there so that ergonomics and documentation were better and less confusing. Kubernetes gives you so much, but I do feel like it's a misstep that the only reasonable way we've simplified Kubernetes for production workflows is to pay a large PaaS to manage it for us.
- llama052 3y ago
  Honestly with a github action and Argo CD workflow the kubernetes patterns aren't that scary. However maybe I'm just too comfortable in the ecosystem at this point. I will say Kubernetes being as open as it is and all the overlapping tooling would seem incredibly overwhelming for someone trying to enter that space.
fivre 3y ago
neither has anyone else! the inevitable "you could have used something simpler than Kubernetes!" comments that appear every time it's mentioned neglect to note that you're more likely to find a Kubernetes example for whatever you're doing readily available in the wild.

I run it on a personal server, so there is no multi server setup, but I enjoy the fact that it's just an extension of docker compose.

agumonkey 3y ago

I lost track about it, I thought swarm was canceled

Cfu288 3y ago
Docker swarm mode (still around) != docker swarm (cancelled). Poorly named so the confusion is normal

e12e 3y ago

Swarm works, but has poor support for volumes - which means it's tricky to run legacy applications on swarm (which eg uploads files to local disk, not s3 - or keeps state/cache on disk, not a database). Ingress is also more complicated/bespoke - the best I've found is traefik with labels for routing/config. My advice today would be to scale Docker compose vertically (eg: on a dedicated server) - then move to Kubernetes. The swarm middle ground isn't really worth it IMNHO.

nwienert 3y ago
Traefik is really simple to set up and I’d bet setting up s3 is 100x easier than kubernetes no? Unless I’m missing something. Fwiw I found swarm lovely and just so much easier to work with than anything else solving the same problems.
- e12e 3y ago
  Porting a ten year old app from local file storage to s3 might not be trivial. For a new app, one generally should and can embrace 12-facors, and delegate state to stateful services (managed databases, key-value stores, s3 etc). Do note that for simple services, local disk can be very hard to beat for low complexity, extremely high performance - with the caveat that horizontal scaling might be tricky. Ed: also depending on privacy requirements - self- hosted s3 (eg minio) might be tricky for a production load. OTOH self-hosted Kubernetes is no walk in the park either!
ndsipa_pomu 3y ago
> Swarm works, but has poor support for volumes - which means it's tricky to run legacy applications on swarm (which eg uploads files to local disk, not s3 - or keeps state/cache on disk, not a database). One way round that is to use an NFS volume. However, I've hit problems with too many client NFS connections on a docker swarm and so found it better to mount the NFS volume on each host and use a bind mount instead.
- ancieque 3y ago
  CSI support will hopefully make this easier. But: there are quite some options once you Look deeper. Also the volume plugin spec is so simple that it is possible to maintain your own plugin (even without csi).
- e12e 3y ago
  My general feeling about adding an NFS depency to multinode swarm is that it's effectively adding a single point of failure to a system which is otherwise somewhat robust against single node failure...

belthesar 3y ago

I've done some labbing with Swarm. Swarm is _just different enough_ to be a pain, but just similar enough to fool you into thinking you know what you're doing. Because swarm was also confused terminology (at one point there were two things with the name swarm that did things differently) the tech definitely got a bad rap for a while, but it also stagnated supporting tooling. You can use things like Portainer and Swarmpit to get some visibility into your swarm cluster members, deploy workloads, etc, but it definitely feels like a second class citizen. Ultimately, I would love for something to exist out there that had the opinions and scope of deployment like Swarm in terms of simplicity, but didn't conflate other tools out there so that ergonomics and documentation were better and less confusing. Kubernetes gives you so much, but I do feel like it's a misstep that the only reasonable way we've simplified Kubernetes for production workflows is to pay a large PaaS to manage it for us.

llama052 3y ago
Honestly with a github action and Argo CD workflow the kubernetes patterns aren't that scary. However maybe I'm just too comfortable in the ecosystem at this point. I will say Kubernetes being as open as it is and all the overlapping tooling would seem incredibly overwhelming for someone trying to enter that space.

fivre 3y ago

neither has anyone else! the inevitable "you could have used something simpler than Kubernetes!" comments that appear every time it's mentioned neglect to note that you're more likely to find a Kubernetes example for whatever you're doing readily available in the wild.