Bridge from docker-compose

[sordina]

I made a similar tool a while ago https://github.com/sordina/logody#logody but ended up not using it very much mainly because of this one feature that I wished would exist - interoperability with docker-compose.

Feel free to close this issue if it's beyond the scope of your project but I think it would be extremely useful and popular if you liked the idea.

In essence I wished that docker compose would be able to not only spin up dockerized processes, but also native processes and express them together in the same services section. You'd be able to have them networked by name and have their lifecycle managed by the docker-compose tool.

One way I imagine that this could be achieved is by having two programs:

• A dockerized-bridge process that acts as a docker image for reference by a compose file to describe what native processes you want to run
• A local process manager process that the bridge can communicate with to manage native processes

This second program could be process-compose!

The main thing missing that would enable this is a network API for lifecycling processes. If this was present then it would be possible to create the bridge program to allow description of processes in its configuration to be communicated to the process-compose running on the host natively.

Anyway, just thought you might think the idea is interesting. As I mentioned, no worries if it is out of scope! Happy to discuss if you like.

[F1bonacc1]

Hi @sordina,
First of all, it's great to hear that I am not the only one who felt the need for such a utility. Thanks for that :)
I think that a bridge between containers and processes could be an interesting idea.

It would be a straightforward development to support services in process-compose, but only from the execution point of view. Something along the lines:

processes:
  proc1:
    command: "/path/to/proc"
services:
  service1: 
    image: image-name:tag
    ports:
      - '4001:4000'
    environment:
      - 'ENV1=1'
    volumes:
      - '/vol1/:/vol'

All of those can be expressed as simple commands to the docker daemon.
The communication between the services, dependencies, name resolving, and network establishment is a trickier part of docker-compose.
From this perspective, it is easier to fork docker-compose and add the process-compose functionality on top of it.

Another thing that I am wondering about is the process <--> service name resolving. I might be wrong, but I think it will require some changes in the dockerd code.

At this point, I am still trying to figure out the MVP set of features and to get as much feedback as possible on the current state of the tool.
This undertaking will also (mostly) break the multiplatform support of process-compose.

Currently, there are a lot of X marks (not implemented) in the planned list of features. I'll be glad to get more feedback and figure out if this is an MVP type of feature, a future plan, or a pivot.

[sordina]

Thanks @F1bonacc1 great to hear your thoughts.