Docker 1.8 - no longer able to pass Spring config settings in env-file

[rlwclawson]

Problem Description

After upgrading from Docker 1.7.1 to 1.8 I'm unable to pass environment variables with "." or "-" via env-file. Most of our app is based on Spring and is built to use Spring "style" config settings (e.g. "messaging.rmq.broker.url").

Passing the same collection of settings on the command line via "-e" still works as before.

Actual results

Error message from Docker when parsing the env-file

Expected results

Able to pass in app settings via env-file.

Steps to reproduce the problem

1. Create env-file "repro.list" with the following config settings (any Spring "style" config):

  messaging.rmq.broker.url=localhost
  messaging.rmq.broker.username=guest
  messaging.rmq.broker.password=guest
  messaging.rmq.broker.virtualhost=reprohost

1. Run any image, passing this file
   docker run --env-file=repro.list hello-world
2. Observe error "docker: poorly formatted environment: variable 'messaging.rmq.broker.url' is not a valid environment variable."

System information

docker version:

Docker version 1.8.1, build d12ea79

docker info:

Containers: 0
Images: 75
Storage Driver: aufs
Root Dir: /mnt/sda1/var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 75
Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.0.9-boot2docker
Operating System: Boot2Docker 1.8.1 (TCL 6.3); master : 7f12e95 - Thu Aug 13 03:24:56 UTC 2015
CPUs: 1
Total Memory: 996.2 MiB
Name: riclaw
ID: SQYV:M5J4:4RAR:6DKG:4IVN:J4RB:H3AN:FRBT:N635:WVZF:OW67:O2SR
Debug mode (server): true
File Descriptors: 11
Goroutines: 19
System Time: 2015-09-24T23:41:00.367346747Z
EventsListeners: 0
Init SHA1:
Init Path: /usr/local/bin/docker
Docker Root Dir: /mnt/sda1/var/lib/docker
Labels:
provider=virtualbox

uname -a:

Darwin belclar1114.local 14.5.0 Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64

Provide additional environment details (AWS, VirtualBox, physical, etc.):

Mac running w/ Docker Toolbox

----------END REPORT ---------

[calavera]

@vdemeester do you mind revert the regular expression you added to validate env variables in #13694? I don't think we should restrict the variable names that way. I think making sure there are no white spaces in the name is more than enough.

[vdemeester]

@calavera ohh 😓 🙀 Yeah sounds ok to me 😉. I'll do it real quick 😝

I'm just wondering if we should remove it altogether or just make it less restrictive (like having . and few other chars…), WDYT ?

[vdemeester]

Hum, after a little more thoughts, I'll ping @duglin @tianon to back me up a bit on the environment variables 😝.

@calavera It's not possible to do something like export MY.VAR=value in a shell (bash, zsh at least). The definition of environment variables are here :

Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names. Uppercase and lowercase letters shall retain their unique identities and shall not be folded together. The name space of environment variable names containing lowercase letters is reserved for applications.

@rlwclawson according to the spring-boot documentation, the environment variable should not contain dot (.) chars but underscores (_). It should work and is, I think, the way to do it (with or without docker).

If you use environment variables rather than system properties, most operating systems disallow period-separated key names, but you can use underscores instead (e.g. SPRING_CONFIG_NAME instead of spring.config.name).

So now, I'm more balanced about reverting the change.. WDYT ?

[tianon]

Yeah, POSIX is pretty clear that we're supposed to be tolerant of env strings we don't understand (but spells out exactly what we are permitted to ignore as "invalid" in our own handling/syntax parsing), so I'm +1 for allowing these to be passed in as-is to the process -- any process that can't handle (either by using or ignoring) badly named environment variables is in violation of POSIX. 👍