Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support docker-compose.yml as alternative to Procfile #102

Open
jasonkarns opened this issue Nov 13, 2020 · 1 comment
Open

Comments

@jasonkarns
Copy link

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

  1. For other users who may have shared experience with overmind and docker(-compose), is this even a desirable scenario? Are there better alternatives?
  2. 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.)
  3. Is this a horrible idea that has Very Bad implications?
@jasonkarns 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
@DarthSim
Copy link
Owner

DarthSim commented Dec 2, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants