You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
jasonkarns
changed the title
Feature Request thought: Support docker-compose.yml directly
Feature Request: Support docker-compose.yml as alternative to Procfile
Nov 13, 2020
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
The text was updated successfully, but these errors were encountered: