Refactor port resources for application port allocation

[philwinder]

My suggestion for implementation:

// 514 is static requirement. * is any port provided by mesos.
mesos.resources.ports=[{"PORT_514", 514}, {"HTTP_PORT", *}, ...]
// For Docker command
mesos.docker.command="/logstash.sh --syslog_port 514 --http_port $HTTP_PORT"
// Alternatively, the name could be used:
mesos.docker.command="/logstash.sh --syslog_port $PORT_514 --http_port $HTTP_PORT"
// for Command command
mesos.command.command="/logstash.sh --syslog_port 514 --http_port $HTTP_PORT"

* means any port.
I.e. take a Map<String, Port> in the resources section. Map ports to env vars, using the as the env var name. Then use the env var in the command.

• This allows the user to specify required ports and pass them into their application.
• It makes it easy for us, because know exactly what ports are required, how many and what names to allocate them to. We can make this a simple resource filter.
• It satisfies your "named port" requirement.
• Flexible enough to handle static or random ports.

[mwl]

This is definitely a step in the right direction. A few thing I would like to add.

Spring Boot has support for maps in Properties and YAML, so no need to embed JSON.

mesos.resources.ports.SYSLOG=514
mesos.resources.ports.SERVER_PORT=*

Where SYSLOG and SERVER_PORT also will resolve to a environment variable of the same name on the task, so that you in many cases will be able to leave out the mesos.command property.

We don't distinguish between Docker command and Command command. They're just mesos.command.

* means any port.

I'd like to distinguish privileged and unprivileged ports. For security reasons. Eventually by saying that * is ports above 1024 and **. Or going into some names, like ANY, PRIVILEGED and UNPRIVILEGED

[philwinder]

Agree with implementation.

I don't understand how the port property would make it into the command without explicitly setting it. Do you mean that with images that use an env var by default would be able to use the setting? If so, yes. That would be possible in the first method too.

And with regards to the PRIVILEDGE/UNPRIVALEGED distinction. Do you mean replace * (or better yet, set * to mean unprivileged) or a port number with: {A_PORT_NUMBER, ANY, PRIVILEGED, UNPRIVILEGED}?

If so, if a user is setting a port number, 514 for example, are we ok with assuming that the user knows he is using a privileged port?

[mwl]

I don't understand how the port property would make it into the command without explicitly setting it. Do you mean that with images that use an env var by default would be able to use the setting? If so, yes. That would be possible in the first method too.

Quite a few application support picking up environment variables.

And with regards to the PRIVILEDGE/UNPRIVALEGED distinction. Do you mean replace * (or better yet, set * to mean unprivileged) or a port number with: {A_PORT_NUMBER, ANY, PRIVILEGED, UNPRIVILEGED}?

Either removing * or keeping it as an alias for UNPRIVILEGED

If so, if a user is setting a port number, 514 for example, are we ok with assuming that the user knows he is using a privileged port?

Good question… But if it's a label we have no real knowledge of the application port. Removing ANY and * will make it a bit more explicit.

[mwl]

Solved by #39