Add hooks for rollbacks, restarts, and updates, possibly other events

[Radiergummi]

Tell us about your request For runtime events in a swarm mode cluster, or even just a standalone daemon, Docker should have the capability to invoke handlers to notify external systems. Specifically, I'd like to be able to register handlers for service rollbacks, container restarts, or updates.
I can envision two different ways to implement this:

1. A configuration option that simply takes a command line that will receive the event, service, and metadata as a JSON object, say:

   deploy:
     rollback_config:
       on_complete: ["curl", "-s", "https://example.com/webhooks/rollback", "-d"]
     update_config:
       on_complete: "notify-me --payload"

   (This could also accept a placeholder like {{data}} or %s to make it more obvious)

2. A configuration option that takes a Docker image, either a shorthand (image and tag), or a full, context-like object:

   deploy:
     rollback_config:
       on_complete: "matchory/swarm-hooks:latest"
     update_config:
       on_complete:
         image: "matchory/swarm-hooks:latest"
         command: ["--event", "update"]
         secrets:
          - deployment_hooks_api_token

I'm very excited about option 2, because it opens up a lot of possibilities.

Which service(s) is this request for?
Swarm Mode, Compose

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Our application stack consists of several applications, a backend API and multiple clients. When introducing new features, we update and deploy the backend to support the new features while maintaining backwards compatibility, then roll out the clients.
The build pipeline involved will build the containers, then connect to a Swarm leader, and issue a docker stack deploy. That will submit the deployment job to the cluster and return with exit code 0. At this point, the pipeline is complete and reports a successful deployment.
If the deployment fails after this however, maybe due to a failed application startup or a bad credential, the service will be rolled back by the cluster. Nobody will notice, however. Only when a client is deployed and causes errors because it uses the new features unavailable in the older backend version will we go hunting for the root cause and notice the service has an unexpected version.

Are you currently working around the issue? There is currently no way that I'm aware of to notice state changes of deployments, nor a --wait switch or similar for the stack deploy command, so we're left with sleeping in the deployment pipeline for a few minutes, poll the cluster for the currently active image, and make the pipeline fail if that doesn't match the new one.
And even that won't help if the container crashes for arbitrary reasons later on -- while I wouldn't want to link this to the deployment pipeline, I'd still want to know if a service has been rolled back without regularly checking the cluster.

Additional context Add any other context or screenshots about the feature request here.

[enmabybella]

{{data}}