This is a feature request idea, not so much an actual request.
Background and Rationale
As a consultant, when I encounter a new project, I almost immediately reach for overmind to manage the application processes. However, more and more clients have existing application stacks defined using docker-compose.
Personally, I find the ergonomics of docker-compose rather painful. Instead of being able to just run bin/rails * or any of the other ruby binstubs, I have to tunnel commands through a long docker-compose run command.
To sidestep this, I frequently set up an overmind procfile locally that approximates what is already defined in the docker-compose.yml. (Indeed, docker-compose is more descriptive as it includes information regarding the dependencies between containers.) The end result is an overmind procfile that essentially has a 1:1 mapping between processes and docker containers; with each procfile process defined as docker-compose run *.
Proposal
It would be amazing if overmind had "first class" support for docker-compose.yml, given its prevalence. My thinking is that overmind itself could read the docker-compose.yml, and would create a process for each container, as if a user had manually mapped each container to a process in a Procfile as I described above.
I totally understand that overmind is focused on Procfiles and tmux management; so I'm not actually suggesting that overmind itself handle this additional "process manifest" source. But rather, I wanted to open this issue to spawn a discussion:
Discussion
For other users who may have shared experience with overmind and docker(-compose), is this even a desirable scenario? Are there better alternatives?
Is overmind architected in such a way that there might be an extension point whereby plugins/extensions to overmind could construct the process list instead of reading the Procfile? (Thus keeping the docker-focused feature completely separate from overmind itself.)
Is this a horrible idea that has Very Bad implications?
It seems like filling the Procfile with docker-compose run * doesn't save you from docker-compose run bin/rails * as your application anyway runs in a container bond with dependency containers and stuff.
This is a feature request idea, not so much an actual request.
Background and Rationale
As a consultant, when I encounter a new project, I almost immediately reach for overmind to manage the application processes. However, more and more clients have existing application stacks defined using docker-compose.
Personally, I find the ergonomics of docker-compose rather painful. Instead of being able to just run
bin/rails *
or any of the other ruby binstubs, I have to tunnel commands through a longdocker-compose run
command.To sidestep this, I frequently set up an overmind procfile locally that approximates what is already defined in the
docker-compose.yml
. (Indeed, docker-compose is more descriptive as it includes information regarding the dependencies between containers.) The end result is an overmind procfile that essentially has a 1:1 mapping between processes and docker containers; with each procfile process defined asdocker-compose run *
.Proposal
It would be amazing if overmind had "first class" support for docker-compose.yml, given its prevalence. My thinking is that overmind itself could read the docker-compose.yml, and would create a process for each container, as if a user had manually mapped each container to a process in a Procfile as I described above.
I totally understand that overmind is focused on Procfiles and tmux management; so I'm not actually suggesting that overmind itself handle this additional "process manifest" source. But rather, I wanted to open this issue to spawn a discussion:
Discussion