Execute a command after run/entrypoint

[taythebot]

What is the problem you're trying to solve
It would be great if we could execute a command when the container is up or after the entrypoint. Currently the only workaround is to do so in entrypoint or manually execute the command after the container is up. The former prevents users from using the official Docker images.

My specific use case is simulating a local multi-datacenter Consul cluster.To do so I need to execute a join command that connects nodes together. Creating a custom Docker image, that is a copy of an already available official Docker image, just to add one command seems a bit silly.

There is an issue about this at docker/compose#1809 which have a lot of good points!

Describe the solution you'd like
Something like this would work:

service:
    image: database
    onrun: echo "Executing command after run!"

This already exists in Kubernetes through its lifecycle hooks. As someone pointed out, in the issue linked above, since Docker compose and Kubernetes have many of the same use cases it would be reasonable to support this.

Kubernetes Implementation: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#hook-handler-implementations

[EricHripko]

I am quite new to this discussion, so apologies if this was brought up before (couldn't pinpoint this aspect of discussion after reading through the linked thread). The use cases that were listed seem to broadly fall into these 2 categories:

• Operational - for example, backup or restore the database.
• Configuration - for example, tweak settings of the just-started infrastructure.

These use cases rely on the infrastructure running and being ready in the first place before onrun command can be executed (e.g., rabbitmqctl is gonna fail if the daemon is starting still). Since Compose spec currently doesn't have a definition for conditions under which the service is deemed "ready", this becomes quite tricky. Of course, Compose implementations could theoretically just exec the command immediately after creating the container. This places the responsibility for readiness checks on the user, which might not be a great experience.

Another thing to point out is that, based on the use cases mentioned, it doesn't seem like there is a strict requirement for onrun command to be executed in the same container. This means that, theoretically, 'Operational' use cases could be satisfied by defining another service. Possibly related issue to this is #11 (talking about preparing environments and life-cycle of containers).

For the 'Configuration', it seems like it's a case of image owners shifting their responsibilities to consumers. It's not great that configuration has to be imperative (via exec) instead of declarative (via volume mounts or environment variables in the spirit of 12FA). It'd be good to draw the line here for where the responsibilities lay.

[SuperSandro2000]

Just do:

command: (echo hi &) && echo ho

But I am sure this would not work because you most likely want some wait condition and from here we would go down the rabbit hole. Just do a custom entrypoint which is already possible from the compose file and you are good to go.

[dantebarba]

+1 for lifecycle hooks.

[MarcoMedrano]

Solution to it cant be to create a whole new image.. we just need a way to do it clean and easy in docker-compose

[reduardo7]

I created a repository with examples about how to implement this required feature:

https://github.com/reduardo7/docker-on-ready

[michaelkrieger]

See also #84 and docker/compose#6736 for similar discussions.

[JS-E]

A PR for this issue is almost ready here -> #289 - Just needs a tweak and an approve. This feature will be super useful