Giters

erlang / docker-erlang-otp

the Official Erlang OTP image on Docker Hub

Home Page:https://hub.docker.com/_/erlang/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Update of 24 base image is a braking change

kaaboaye opened this issue · comments

commented

After changing the base image of erlang:24 from buildpack-deps:buster to buildpack-deps:bullseye it transitively introduced a braking change to elixir:* images which use erlang:24.

Referring to this commit f14a791cec08903d5ac34a562861bae675cf2ff8 by @getong

There is a feature in Elixir called releases https://hexdocs.pm/mix/1.12/Mix.Tasks.Release.html which are creating a stand alone bundle which can be easily deployed to the production servers.

However for this bundle to work both build-time and run-time OS have to have exactly the same version.

So changing the underlying OS version effectively forces everyone using mix.release with separated build-time and run-time environments to upgrade their run-time OS with 0 time notice.

This is how image build with buildpack-deps:bullseye and deployed with debian:buster looks like.

/app/erts-12.2/bin/beam.smp: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /app/erts-12.2/bin/beam.smp)
commented

I think the solution for you is to not use the erlang:24 tag as it is a mutable tag. If you want to have a stable tag you should use a specific version, such as 24.1.7.

If you use a mutable tag this type of problem is bound to pop up whenever a change to the base OS is made. The hexpm team has taken this one step further and provide a bunch of pinned OS/Erlang/Elixir versions for docker.

commented

I think the solution for you is to not use the erlang:24 tag as it is a mutable tag. If you want to have a stable tag you should use a specific version, such as 24.1.7.

I partially agree but it's still erlang:24 not erlang:latest and having sem-ver in mind I would expect no breaking changes with major release locked. Sure it's erlang version not os version but the entire point of docker is to not have think about underlying os.

Here we're entering into elixir territory but as far I'm aware at least part of contributors maintain both images so I'll continue the thread here.

Locking into specific erlang version is not possible when using elixir tag. In my Dockerfile I've specified FROM elixir:1.12.3 which should lock on exact docker image without possibility of such change but since elixir:12.* have all specified erlang:24 as it's base it got rebuild with up different underlying os.

Interesting is fact that previous Elixir versions still have buster as it's base.

➜  ~ docker run -it --rm --entrypoint /bin/cat elixir:1.12.2 /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
➜  ~ docker run -it --rm --entrypoint /bin/cat elixir:1.12.3 /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

If you use a mutable tag this type of problem is bound to pop up whenever a change to the base OS is made. The hexpm team has taken this one step further and provide a bunch of pinned OS/Erlang/Elixir versions for docker.

This is a good solution but it would be great if I could rely on official images not being breaking changed in the friday afternoon.

commented

There is no semver here. Docker tags are mutable and images are kept up to date. It is a must that users not rely on these mutable tags for production, a copy should be made, or at the very least the full docker ref be used instead of the tag.