Provide process type as $DYNO to container

[mjonuschat]

Heroku has a $DYNO environment variable in the container which shows which process from the Procfile is running in the container. It would be nice to have this variable available (even if hardcoded as „web“ like the start command) on Dokku too.

[josegonzalez]

What would this be used for?

[motin]

It would be nice to have this variable available (even if hardcoded as „web“ like the start command) on Dokku too.

DYNO is a very Heroku-specific concept and albeit modeled after Heroku, Dokku imo does not need to provide the exact same config vars. Deis does not seem to offer the DYNO config var.

If your app depends on the DYNO config var, it seems easier to set it as a config var.

[mjonuschat]

Add the moment that value doesn't do much except to ensure compatibility with a few more buildpacks like https://github.com/dpiddy/heroku-buildpack-runit - should #732 be implement the workaround with a static config var wouldn't work anymore.

[josegonzalez]

@yabawock do you have a PR for this?

[josegonzalez]

Seems like we could set this by default - check if set and set it in pre-deploy - and use it here. Thoughts, @michaelshobbs ? I don't know if we have a dokku config:set --norebuild command yet, but that's the only blocker I can think of.

[michaelshobbs]

To clarify, we'll modify $START_CMD if $DYNO is set in config?

Do we want the default config:set action to rebuild or should that be explicit? I'm leaning towards dokku config:set -r <app> <config> to indicate rebuild and the default to not. Thoughts?

[josegonzalez]

I think we should always have it set and default it to web if it's not set.

Does heroku rebuild or not? If not, we should not, if so, we should, but we should allow people to do either/or.

[michaelshobbs]

According to https://devcenter.heroku.com/articles/config-vars a restart happens on set and unset.

[josegonzalez]

So we should at least do a restart (with the env vars sourced in). Is that not what we do now?

[michaelshobbs]

That is what we do now. Should we offer a flag to bypass the restart? If so, why?

[josegonzalez]

I don't know what I was thinking. Ignore that.

[joshco]

I'm bumping into this (or related) as well. I use a Procfile in my app to specify multiple worker types.that all need to be running to service the app.

This is a rails app that has a web worker and a jobs worker (eg delayed_job)

The procfile is in the tree:

web: bundle exec  rails server -p $PORT
jobs: bundle exec rake jobs:work

For the moment, what I'm doing is manually starting a second docker for it:

sudo docker run -d dokku/vwf /bin/bash -c "/start jobs"

But this doesn't seem optimal. It seems like dokku should examine the procfile and do something useful.

I don't see the Heroku parallel metaphor here, which is their ps settings on each dyno/worker type. In Heroku you specify the number of each dyno, and type/size you want to run. The numbers arent part of the procfile, they are set via the heroku command.

heroku ps:scale web=1, worker=2

That is what tells heroku what to do.

Is there a dokku idiom for this?

[michaelshobbs]

I use the dokku-logging-supervisor plugin to scale my processes at the moment.

[joshco]

Thanks for the tip. I just tried it and it works very well!

[josegonzalez]

@joshco better would be for us to do actual process scaling - which would include this sort of feature. Is this something you're interested in working on?

[michaelshobbs]

So, I've been banging away on this one for a little bit. I had put it down as I ran into some implementation complexities that I haven't flesh out yet. I opened a new issue (#1117) for discussion. @joshco (and anyone else for that matter) any additional input would be greatly appreciated.

[josegonzalez]

Closed by #1118