Add more custom script hooks

[justenwalker]

From @misterbisson:

22 opens up the door to more than just deregistering services. Consider running Couchbase in Docker. The blueprint and demo makes deploying Couchbase and scaling it up easy (repo), but scaling down requires more steps that haven't been automated.

A SIGTERM handler could be exactly what's needed to add that automation. If it could also execute a user-defined executable (and wait for it), it would allow us to mark the Couchbase node for removal from the cluster and automatically rebalance the data to the remaining nodes before stopping it.

I haven't tested it, but I think the right command to call would be:

couchbase-cli rebalance -c 127.0.0.1:8091 -u $COUCHBASE_USER -p $COUCHBASE_PASS --server-remove=${IP_PRIVATE}:8091

And when that is done, it should be safe to stop (and remove/delete) the container.

[misterbisson]

From @justenwalker in #22 (comment):

In my mind, OnStop makes more sense to happen after the application exits rather than before - so that we know the service isn't interacting with anything before we send cleanup commands (like Finally block)

That raises questions about the inconsistency with of the language compared to onStart. onStart is actually executed before the application starts. The following is a crappy solution, in my mind, but it avoids changing any existing code:

• onStart before application start
• onStarted after application start
• onStop before application stop
• onStopped after application stop

The following is more clear, in my mind, but does require changing existing code:

• preStart before application start, the current behavior of onStart
• postStart after application start
• preStop before application stop
• postStop after application stop

...though I hasten to add that I don't really see a need for postStart, I'm just enumerating it for clarity.

[misterbisson]

@justenwalker the title of the ticket may be too specific given our similar, but slightly different interests. Would you be okay with retitling it in a way that fits the conversation about pre and post stopped execution?

[tgross]

onStarted after application start

This is going to be difficult to actually implement because we block execution flow on the application. Even if we could figure out a way around that, the application can "start" (as in fork) but not actually be "running" for any useful purpose. e.g. slow Java startup times.

onStop before application stop

Services deregister and then stop. Does this happen before or after the service is deregistered?

[justenwalker]

So do we need something like:

• onStart - Unchanged
• preStop - Runs before Containerbuddy terminates the application - blocks
• postStop - Runs after the application terminates

It's not symmetric - but I'm not convinced it needs to be. Does it even make sense to run an application after the App starts? We are already polling the application, which is semantically similar to postStart

[tgross]

It's not symmetric

That's probably fine.

but I'm not convinced it needs to be. Does it even make sense to run an application after the App starts? We are already polling the application, which is semantically similar to postStart

I'm in agreement there.

[tgross]

Released with https://github.com/joyent/containerbuddy/releases/tag/0.0.4