Hooks to run tasks after container launch / shutdown about deimos HOT 5 CLOSED

Interesting ideas. I mentioned this to @solidsnack a while back since it's something I was interested in using. The third option would get a +1 from me... or even just a set of pluggable modules that a user could chose between, rather than choosing a specific way of announcing.

I think this would work pretty well given the kill/rm invocation of deimos.

from deimos.

(3) has a lot going for it, in terms of flexibility. What arguments do you think the script should receive?

from deimos.

I was picturing something like cli flags --start-hook-path and --decommission-hook-path, and deimos would make the whole TaskInfo available to those scripts.

from deimos.

So I've tried to implement this myself...

My original thought was that I could add arbitrary fields to the marathon task like so

{
   "container": {
    "image": "docker:///myregistry/runner",
    "options": ["-v", "/mnt/log/containers/:/mnt/log/containers/", "//", "start", "web"],
    "exec": {
        "prelaunch": ["/bin/sh", "-c", "/usr/bin/touch", "/var/notify"],
        "postdestroy": ["/bin/sh", "-c", "/usr/bin/touch", "/var/destroy"]
    }
  },
  "cmd": "",
  "env": {"NODE_ENV":"myenv", "STATSD":"my.graphite.host", "SLUG_URL":"http://example.com:8080/my.api/######.tar.gz"},
  "cpus": 0.16,
  "mem": 256.0,
  "instances": 1
}

And then parse the new fields in containerizer/docker.py

But unfortunately, the Marathon API strips arbitrary fields.

My next thought was that I could add it to the deimos config, but that's much less generic on a container basis.
Something like:

[hooks]
prelaunch: ["/bin/sh", "-c", "/usr/bin/touch", "/var/notify"]
postdestroy: ["/bin/sh", "-c", "/usr/bin/touch", "/var/destroy"]

As far as script arguments, the easiest way to handle that in a generic way would be to use subprocess.Popen(command, env=hook_env), where hook_env could contain the docker container port, uuid, et cetera.

Then it's up to the user to do what they will with that information.

Any thoughts or ideas on my approach(es)?

from deimos.

This is quite interesting. The reason you won't see any additional fields go through when defining things inside container is because that dictionary maps directly onto the ContainerInfo protobuf message, which is a static structure.

I'd vote for the second one, not only because the former would be difficult to implement, but the use case I had in mind would probably be something quite generic and a feature of the slave rather than a feature of the container itself. If you're doing something specific for a certain type of container when it launches and terminates, you're probably better off doing that elsewhere, perhaps inside the executor even. A good example of the former could be something like registering DNS entries automatically.

from deimos.