Hooks/ Plugins support to run arbitrary scripts

[mattes]

It would be nice if docker-compose up|down|.. would look for custom scripts in the current directory, like:

docker-compose.before.up
docker-compose.after.up

I guess this is mostly helpful when docker-compose is used to run the development environment. These scripts should not be meant to configure containers.

My current use-cases include:

• set up hostnames in /etc/hosts after container startup
• run docker-rsync after container started

Eventually docker-compose should allow these scripts to run in the background and stream stdout/stderr to docker-compose logs.

Related #74 #57

[mattes]

Instead of using files scripts could be baked into the docker-compose.yml file as well.

[TheFeshy]

This would also be useful for using pipework to give containers rout-able IP addresses.

It should be possible to specify whether or not Compose should wait for the script to finish before proceeding with the other containers.

[lorenz]

+1

[akoenig]

That would be a nice feature. Especially for the case when you need to execute arbitrary scripts after the application cluster is up (initializing database etc.).

So a huge +1 :)

[aanand]

In general, I'm -1 on adding functionality to Compose which runs scripts on the host machine. It breaks the abstraction - this should be the job of a Makefile, or some other script/tool which wraps Compose.

[digitalkaoz]

+1 from here, would be useful for provision the vms with non persitent data

[dnephin]

I suspect you can already use docker events (https://docs.docker.com/reference/api/docker_remote_api_v1.18/#monitor-dockers-events) to do this, without having to make any changes to compose.

[missedone]

agreed, it will be really helpful with this sort of hooks support.
we can define some hook actions as below in docker-compose.yml:

web:
  build: .
  ports:
   - "5000:5000"
  volumes:
   - .:/code
  links:
   - redis
  hooks:
   - pre_start:  xx
   - post_start: xx
redis:
  image: redis

[emersonf]

+1 ... executing database scripts against a postgres container would be brilliant, e.g.

[arioch]

+1

[hodonsky]

@aanand I believe that it is entirely up to what ever the developer runs in that script.

Plus the reason I would +1 this, is as a container spins up, it gets a self-assigned IP, and the only way to fetch that externally and apply it to another container say, for linking of some kind, is through a script or to communicate with the host machine from another container before it spins up, which isn't possible as far as I know.

This MAY allow for a more dynamic docker-compose without breaking abstraction as a practice, but leaving it up to the developer to make the mistakes.

At this point I feel like I'd have to have nested docker-compose setups... run docker compose that spins up gulp, and watches process ID's, then have gulp manage my processes instead of the host machine, I'm already feeling dirty...

[dnephin]

What about #1510, which would let you react to things without compose having to run anything directly.

[hodonsky]

@dnephin That would totally work for me, -1 here, and +1 for #1510