Rocket: Respect PORT environment variable

[pimeys]

When running services in Mesosphere/Marathon cgroups, the framework sets a random number to PORT variable for the service. It would make Mesos deployments way easier if Rocket would respect the variable and override the service port with the value if set.

[SergioBenitez]

I've considered being able to pass the default configuration options via command line arguments (--port 312) _or_ environment variables (ROCKET_PORT=312), or both, with some definition of precedence. Either of these would let you start rocket with a different port. The former can lead to confusion when an application has its own command line arguments, and so I prefer it less. I believe the latter would work for your use case, is that right?

An alternative, more radical solution is to allow _any_ parameter to be set via _any_ environment variable by specifying the variable in the Rocket.toml file. Something like this:

[dev]
port = $PORT

Rocket would recognize the $ and require that the PORT environment variable is set when parsing the config and use the variable's value (which must also parse) as the value of the parameter. But this seems very specialized. Kinda neat though.

[pimeys]

We've used all these options in our projects and I'd say the environment variables are for me the best possible way of giving configuration for a running application. This way the deployment configuration handles the environment the application uses, including the secret keys.

Right now I don't really see the reasoning behind the specific configuration files.

The last solution you listed is actually the same Scala uses in its application.conf. And if you go with the environment variables, please use the standard PORT so there's no need for specific deployment configuration when deploying to Mesos.

[SergioBenitez]

I'm leaning towards adding an environment variable. If I do go that route, I'm strongly in favor of using a ROCKET_ namespaced variable. I want to avoid accidental collisions, where a Rocket configuration parameter is accidentally set because some common environment variable was set for a different application.

How big is the impact from having the environment variable not be named PORT? I imagine it would be a simple change to add ROCKET_PORT=$PORT, and there's something nice about the self documenting nature of that line.

[sethlopezme]

The ability to set _any_ parameter in Rocket.toml via _any_ environment variable is interesting. This would make it easier to build an application using the Twelve Factor App methodology. I think if this were to happen, there should be a way to define a "default" configuration, and then specify other options depending on the environment. Something like this?

# maybe omit "[default]"?
[default]
address = $APP_HOST
port = $APP_PORT
log = $APP_LOG_LEVEL
session_key = $APP_SESSION_KEY

[dev]
hi = "Hello!"
is_extra = true

This would be similar to having a .env file with a little extra configurability. What are your thoughts?

[SergioBenitez]

@sethlopezme You can already do this via the [global] table. Check out the configuration API Docs for more details.

[SergioBenitez]

Slating the ROCKET_{PARAM} configuration method for 0.2.

[SergioBenitez]

This has been implemented and will ship in 0.2. From the docs:

+//! ## Environment Variables
 +//!
 +//! All configuration parameters, including extras, can be overridden through
 +//! environment variables. To override the configuration parameter `param`, use
 +//! an environment variable named `ROCKET_PARAM`. For instance, to override the
 +//! "port" configuration parameter, you can run your application with:
 +//!
 +//! ```sh
 +//! ROCKET_PORT=3721 ./your_application
 +//! ```
 +//!
 +//! Environment variables take precedence over all other configuration methods:
 +//! if the variable is set, it will be used as the value for the parameter.
 +//!