Exporting of docker runtime variables as tags

[asinitsa]

Required for all PRs:

• CHANGELOG.md updated (we recommend not updating this until the PR has been approved by a maintainer)
• Sign CLA (if not already signed)
• README.md updated (if adding a new plugin)

[danielnelson]

What about using labels? These are exported as tags by default.

[schneidexe]

The problem with labels is, they are not easily accessible from within containers, that's why it's convenient to use ENV variables. This way if those are used as metadata by the application inside the container they are consistent with the container's metadata.

[asinitsa]

@danielnelson labels are part of docker image and can not be changed on run time, but ENV variables are independent of image. Real world example: running official docker images (like nginx or mongo) in test/prod environments.

[danielnelson]

@asinitsa Does this set labels at runtime? https://docs.docker.com/engine/reference/commandline/run/#set-metadata-on-container--l---label---label-file

[schneidexe]

Yes, it should. So it's more about making the metadata accessible inside the container in a consistent (and convenient) way

[schneidexe]

Also to add some background: we use docker together with Mesos and Marathon/Chronos. When using Mesos' docker containerizer it injects automagically metadata to the ENV like MARATHON_APP_ID, MESOS_TASK_ID, CHRONOS_JOB_NAME, etc. which is very valuable meta information for us on metrics.

[ssorathia]

@asinitsa

@danielnelson labels are part of docker image and can not be changed on run time, but ENV variables are independent of image.

This is not accurate. You can add labels to a docker container at run time with the --label flag to docker run. For example: docker run -ti --label my_label=my_label_values ubuntu bash If you do a docker inspect you will see the label being set at runtime.

[danielnelson]

@asinitsa Is there a reason you closed the PR? We now have this pull request that uses a similar method #2580

[schneidexe]

Closing of this PR was an accident since the fork repo got deleted (before being moved). We can also focus on the new PR or I can re-create this PR with the code changes.

We also figured out, that besides whitelisting wanted env vars and labels it would make sense to make some hard-coded fields configurable, e.g. the containerId could have quite high cardinality causing some issues inside influxdb when used as "indexed" tag.

[danielnelson]

The new PR has tests, so maybe we should focus on it. Do you think you could review it?

The hard-coded fields sounds like a seperate issue, unless it needs to be done along with this lets open a new issue.

[schneidexe]

Yes, sounds good. I'll have a look asap and cross-check with our version.

For the hard-coded parts I'd open another issue/PR. Just wanted to mention it here since it is kind of related.