Change in environment variable setting behaviour in 3.6 image?

[liamjones]

I'm not entirely sure if this issue is here, docker, docker-compose or alpine itself. I'm starting here and I'm hoping you'll be able to tell me if it's elsewhere. :)

Something seems to have changed with environment variable setting behaviour between alpine 3.5 and 3.6's docker images when using it via docker-compose.

I've created the simplest project I can to reproduce this: https://github.com/liamjones/alpine-docker-environment-issue. This project creates containers from the 3.5 and 3.6 images and runs the env command.

If you docker-compose up --build alpine-35 you'll see that foo.bar and FOO_BAR are set in the environment.

If you docker-compose up --build alpine-36 you'll see that foo.bar is not set in the environment but FOO_BAR still is.

Interestingly, if the Dockerfile's CMD is overridden in docker-compose.yml (with the exact same command) then foo.bar starts working again for 3.6. See docker-compose up --build alpine-36-overriddencommand for a demonstration of this.

[ncopa]

foo.bar is not a valid variable name in POSIX shell. If it worked in alpine 3.5, then that was unintentional.

[johannesjasper]

I had the same issue as @liamjones and I can confirm what @ncopa suggested: changing the env format from foo.bar-spam to foo_barSpam solves the issue.

[liamjones]

@ncopa Yeah, I'm aware it's non standard for a POSIX shell variable, was just wondering if the change in behaviour was intentional or not.

I also find it interesting that the CMD in the Dockerfile on 3.6 doesn't work but the command: in the docker-compose.yml does...

[xordspar0]

We also noticed this in our own Alpine-derived docker image.

I think I found out why this happened. When Apline updated to version 3.6, it included an update of busybox to version 1.26, which includes the following change to the shell: https://git.busybox.net/busybox/commit/?id=b6838b520afa8346751577cd7ccbe0b906cd3a52

From what I can see, the previous behavior where dashes were accepted was a bug.

[andyshinn]

Thanks for researching this. The commit in question looks specifically for dashes (-) and I don't see anything about periods (.). But I would agree that it smells like a change in BusyBox. I'm concerned that this will affect a lot of OpenJDK based images that commonly set Java properties as environment variables. I'll try to research more into the BusyBox side when I have some time.

[mattnelson]

I'm concerned that this will affect a lot of OpenJDK based images that commonly set Java properties as environment variables

Came here because of this exact issue. My java containers no longer work with 3.6.

[josef-pones]

Can i ask here how i can set properties for spring with alpine linux 3.6? Which are always in format 'something.else.another'. Thank you for help

[liamjones]

@pepanek Are you using Spring Boot? If so you can use its relaxed binding feature to avoid the issue: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config-relaxed-binding