onStart, onStop events for containers

[shavrin-ivan]

I use fig for running local development environment (django projects). All works fine, but after each restarting of services I need manually reconfigure hipache (because ip address of www container changed). I try to add some functionality (it's dirty, untested, just idea implementations) for run some commands on start/stop of services.

For example (fig.yml):

www:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    events:
        onStart:
            - redis-cli del frontend:project.dev
            - redis-cli rpush frontend:project.dev project
            - redis-cli rpush frontend:project.dev http://%(.NetworkSettings.IPAddress)s:8000
        onStop:
            - redis-cli del frontend:project.dev

This options should be configure hipache on fig up with www container ip address. Commands executed on host machine. Commands executed in order (as in options). Commands can use container options (for example .NetworkSettings.IPAddress) as in ``docker inspect`. It's work good for me. But there is a question, do fig need this option, or not. I saw those problems:

• Broke fig run functionality, for example if I want to start django shell I can't start it with command fig run www python manage.py shell, because onStart event will be executed (that broke http access to project via hipache). So I must create copy of www services (called shell) and run commands with those service.
• Broke fig scale functionality. I didn't use it, but someone do. Those events binding on containers, for supporting scale functionality they are must bind to service.

Any thoughts, need or not events option?

[prologic]

+1

[pmlopes]

+1

It would be nice to have this. You can have a look at:

https://github.com/discordianfish/docker-spotter

But i would rather have fig as a single tool to do this instead of having several tools...

[prologic]

+1

[pahaz]

-1

I think run something on host server is not good idea.

If you use upstart scripts for that.

something like this: /etc/init/good-work-redeploy.conf

description "some actions on docker start"

start on (started docker)

script
  sleep 2 # give docker some time
  sudo -i -u my_user /home/my_user/super_update.sh arg1 arg2
end script

But uses some actions after build - good.

[koen-serry]

Beside the fact that upstart is only used on ubuntu, having a hook option allows the same docker image to be used in multiple configurations without having to resort to 'magical' scripts.

These scripts:

• make you images a whole lot less usable, ie. on a mac this volume needs to be on the guest machine
• are only required in development (dev to production anyone?)
• allow people 1 central place to edit without resorting to Makefile/shell script/any other wrapper to avoid the above or even a script on the image.

I like fig as it gives me some more control (and less command-line option to remember), but the extra wrappers just to be able to provision the same image is a bridge too far.

[prologic]

+1 same here :)

James Mills / prologic

E: prologic@shortcircuit.net.au
W: prologic.shortcircuit.net.au

On Sun, Sep 28, 2014 at 4:04 PM, Koen Serry notifications@github.com
wrote:

Beside the fact that upstart is only used on ubuntu, having a hook option
allows the same docker image to be used in multiple configurations without
having to resort to 'magical' scripts.

These scripts:

• make you images a whole lot less usable, ie. on a mac this volume
  needs to be on the guest machine
• are only required in development (dev to production anyone?)
• allow people 1 central place to edit without resorting to
  Makefile/shell script/any other wrapper to avoid the above or even a script
  on the image.

I like fig as it gives me some more control (and less command-line option
to remember), but the extra wrappers just to be able to provision the same
image is a bridge too far.

—
Reply to this email directly or view it on GitHub
#74 (comment).

[dnephin]

If these commands are required to build the image, why are they not part of the Dockerfile?

I've found that in general having to run a bunch of commands on the host goes against the docker philosophy. Docker already provides a lot of ways for dealing with this type of thing. One thing I've done is to create a separate container for volumes that change between dev/prod. In your fig file you can link up to the volume containers (for dev configs, etc), and in production you either link to the host or another container to get the production configs. There are many other strategies that work with stock docker and fig that remove the need for any external scripts.

So far this issue has only one example which is easily solved (without this feature), by using the hostname provided by docker links (that way the host never changes).

Maybe some more concrete examples would help illustrate why this feature is necessary (or allow others to suggest a way to do it without the feature)?

[shavrin-ivan]

I agree, that there are a lot of disadvantages of this approach. But, more than half year my workday started with typing fig up. I can run more than one project at time (without any conflict, no more crossing port), and it's make me happy :).

For now I see only two alternative ways to call those commands: docker-spotter (https://github.com/discordianfish/docker-spotter) or some custom scripts. Both are harder than fig up.

Common case for running those commands are: do something on host machine, when container up (or down). For example: doing some network stuff, that require to know context information about runner container (NetworkAddress, etc). May be it will work with fig scale command (will help to configure load balancer).

[thaJeztah]

If you need to run multiple websites, also have a look at https://github.com/jwilder/nginx-proxy/ which requires (almost) no set-up.

After running the nginx-proxy container, start up your containers with with a VIRTUAL_HOST environment-variable containing the host-name of your project (which can be specified in your fig.yml), it will automatically set up a proxy-server for your project. That way, you can access each project by its domain-name, without creating port-conflicts.

The default template used for the proxy is usable for most cases, but can be easily changed (https://github.com/jwilder/nginx-proxy/blob/master/nginx.tmpl)

[dnephin]

As compose moves to support production environments as well as development environment, the addition of "development only" type features is going to be more difficult.

There are some good suggestions in this PR for alternatives, and I think we can look to better support external tooling from compose with #1510.

[dnephin]

Events are being added in #2392

I've included an example of how you could implement this feature using the events command.
https://gist.github.com/dnephin/c56b479810f863527e90