Can't immediately tell if this works for deploying with Docker Compose. It's my main sticking point with Dokku[0], which I've been finding quite pleasant to work with otherwise.
There are a few technical and philosophical reasons we don't support compose out of the box:
- The build process does not lend itself well to a cleanup step. Since images are overwritten, users end up having old images lying around.
- There is no zero-downtime scheduling for compose containers. You either replace them all at once - via `up` - and suffer the downtime, or namespace them by specifying a `--project-name` command arg and then doing some tricks when updating routing.
- Many folks want docker-compose to specify the entire environment, including datastores. If you change the project name, compose links don't work anymore since you're essentially creating a new stack. If you use the same project name, we don't have any guarantees on where data lives, since many folks use volumes for that stuff (and volumes may not be backed by filesystems).
- The compose yml format exposes lots of stuff that may not be desirable to expose on a shared instance in the name of security. For users that share a host with others in a semi-untrusted setup, I'd hate for their first step to be "disable the compose builder and scheduler plugins".
Note that you can deploy compose to ACI and ECS, both of which have a bunch of caveats around usage[1][2]. The only Kubernetes support I'm aware of for compose is Kompose[3], which transforms the file to something kubernetes is aware of for application.
I think overall the limitation around zero-downtime deploys in compose makes support in Dokku less interesting. We have support for basically everything you'd want otherwise. Our current alternative is to use dokkupose[4] to transform a compose file to the corresponding Dokku commands.
If folks are comfortable with the downtime and any other limitations, it might be nice to have a simple docker-compose plugin for building/scheduling, but I feel as though it wouldn't be worth it (maybe its just me).
Docker-compose was a limiting factor for me as well. I am seeing more and more projects that I deploy --- maybe 25 of the 50 I deploy a month -- using docker-compose.
I would love a simple docker-compose plugin, or a way to deploy with compose (I'd be okay if it gave a warning that 'may cause potential issues etc etc').
Do you have any resources on how to write plugins for dokku?
Again, I am extremely impressed by dokku and a big fan. I think a significant amount of your users would benefit from some way to use docker-compose. Would love to contribute.
I thought about this a bit last night and did some research. I think with the evolved compose file format, this is more doable (though still with routing downtime until I do some extra work). I've filed a ticket for this here: https://github.com/dokku/dokku/issues/5102
This makes a lot of sense, and I presupposed some of this reasoning, so it's great to hear that my understanding was correct.
Most of the frustration just comes from a lot of existing projects I'd like to simply deploy rely on docker-compose, so instead of just cloning and deploying, I need to adapt things. So really it's not exactly a frustration with Dokku :P
I thought about this a bit last night and did some research. I think with the evolved compose file format, this is more doable (though still with routing downtime until I do some extra work). I've filed a ticket for this here: https://github.com/dokku/dokku/issues/5102
[0] https://dokku.com/