This is very interesting. I've been looking for middle ground between Dokku and Kubernetes, I'll give swarm a try. Does it handle ingress at all? vhosts, TLS certificates, etc?

If you're paying for EE, then UCP can do a lot for you. We're using the HRM heavily, and it's very handy.

I don't know what any of those mean :(

EE = Enterprise Edition

UCP = Universal Control Plane (web app to manage clusters and containers)

HRM = Host routing mesh (I think). If I recall correctly, it’s used to control ingress to the cluster via virtual host routing, etc.

They are paid Docker Inc. products. I worked for Docker once upon a time so I’m happy to hear there are happy customers :)

Ah I see, thank you for clarifying! I'm not familiar with the products, but I'll research them.

Docker has added ingress routing in 17.06 that works at a lower level than HTTP Routing Mesh. You should try that now.

Other than that, how have you found EE ? We have considered paying for it, but after seeing Docker Cloud at 15$ per node per month, we are considering switching to it.

ingress is the most beautiful part of Swarm - it is built in.

however, it does not do termination. You should trivially include a haproxy/nginx pod/service/vm to do the termination for you.

One of the cool new infrastructure features is Docker Cloud - which allows you to "bring your own nodes" for 15$/node/month and setup Swarm. https://docs.docker.com/docker-cloud/cloud-swarm/using-swarm...

I'm using https://github.com/containous/traefik with Swarm for termination, Let's Encrypt and routing with success. Configuration is handled with service labels.

+1. Traefik is leaps and bounds more ergonomic than haproxy etc.

I believe it benched a bit worse than the comp but for most cases you're not going to run into issues.

Thanks for the shoutout. Would you happen to have a writeup on how to do that, or a few lines on whether it's Swarm-aware somehow? I guess it can't be too hard to figure out, but if there's something that will speed that up, that's better.

No - you don't need it to be swarm aware at all.

All you need to do is create a docker service out if traefik/nginx/haproxy/whatever and bind the ports of the service to type "ingress". From then on, all traffic is internal - and you deal with it normally from one docker service to another.

Ah, okay, so pretty agnostic. Sounds like this is geared towards single project deployments, though (ie it wouldn't be suited in a multitenant scenario), but that's good to know.

I've been looking for a Dokku replacement for running my side-projects on with easy scalability (by provisioning another server), but I haven't found anything that's suitable for running multiple apps together in a heroku-like way but still able to scale beyond a single server. Do you know of anything like that?

but that is what swarm is - swarm is fully production ready to scale to tons of servers and works brilliantly on a single server as well. Not sure why you think swarm wouldnt fit the bill ?

From what I saw, it's not very easy to have a deployment with multiple applications on the swarm, is that wrong?

For example, I have ten applications, and each requires a database, a redis instance, a celery instance and two web workers. Dokku lets me deploy these independently of each other, but uses the same nginx instance and proxies them transparently.

As I understand it, Swarm has no notion of multiple projects. Each swarm is running a single deployment, where all containers are equal, is that correct?

Basically, Dokku is a self-hosted Heroku, which is what I need (I want to be able to easily create a project that I can run semi-independently of the others on the same server). My understanding is that, to do that with Swarm, I'd have to have a single termination container that would connect to every app, but apps wouldn't be any more segregated than that. Maybe I'm complicating things, though. Have you used Swarm for such a use case?

I tried the official tutorial, but couldn't get it to work, as the instructions appeared outdated and didn't work for single-host deployments, and were geared more towards Windows and Mac than Linux. Would you happen to have a good "getting started" document? All my apps are already using docker-compose.

EDIT: Also, a machine that's a manager doesn't want to join the swarm as a worker as well, that's why I'm saying that it doesn't appear good for single-server deployments:

> Error response from daemon: This node is already part of a swarm. Use "docker swarm leave" to leave this swarm and join another one.

the docker stack deploy command does automatic diffing of which services have changed. So your deploys are automatically optimized. This is generally the philosophy of Swarm vs kubernetes - everything is built in. You can argue this is less powerful, but in general it works brilliantly. In so far as separating out the different "applications", you simply put them on a separate overlay network (encrypted if you want).

Also, if you are dead-set on making them entirely separate, every separate "application" is a separate "Stack". So you can stack deploy them separately.

If I had to do what you just told me - single nginx proxying to two different "applications" - i would do this. 1. stack 1 - application 1 + network 1 2. stack 2 - application 2 + network 1 3. stack 3 - nginx + network 1

now you can deploy any of them independently. You can make this even more sophisticated by having each stack on a different overlay network (encrypted as well). And nginx bridging between them.

Not sure why you are facing problem with the official tutorial - btw, a manager is a worker ;) I have a fairly large dev swarms on a single node.

Swarm is nice as-is but is, but really shines with support like docker-swarm-proxy. Please check out http://proxy.dockerflow.com/. It allows for automatic service discovery as well as routing/termination etc. It also runs as a stack on swarm itself. Supports custom TLS termination as well as SNI routing.