Updating to alpine 3.17 broke our multibuild setup.

[Preen]

This commit broke our docker multibuild setup completely. Because the bump of alpine version is not compatible with older alpine versions. Is this a common thing that's done? Is there any stale versions where you dont update the alpine versions?

50796c7

[olafura]

Maybe they should use a tag rather than a specific version because it's also always breaking our builds.

[olafura]

or maybe a docker image that could be used for running a prebuild deploy-in that would also be the base for this image?

[airton-soares]

Having the same error here:

Error relocating /app/erts-12.3.2.7/bin/beam.smp: __extendhfdf2: symbol not found
Error relocating /app/erts-12.3.2.7/bin/beam.smp: __truncdfhf2: symbol not found
Error relocating /app/erts-12.3.2.7/bin/beam.smp: __truncxfhf2: symbol not found

Any idea on how can I work this around?

[ogabriel]

For those having problems with nodejs (mostly web developers using elixir/phoenix), the upgrade to alpine 3.17 upgraded the nodejs versiont to 18, which uses a newer version of openssl and may break some nodejs packages.

If you wanna fix your problem with minimal work being done, just the line below before any npm or phx.digest command:

ENV NODE_OPTIONS=--openssl-legacy-provider

[ogabriel]

Erased my previous comments, as I also found the solution to this problem:

Error relocating /app/erts-12.3.2.7/bin/beam.smp: __extendhfdf2: symbol not found
Error relocating /app/erts-12.3.2.7/bin/beam.smp: __truncdfhf2: symbol not found
Error relocating /app/erts-12.3.2.7/bin/beam.smp: __truncxfhf2: symbol not found

The suggested way to bulid release images on elixir/phoenix, is by having a multi stage build that firstly uses a elixir image (which inherent the erlang image) and them using a base alpine image to move your release file and deploy.

So, after this upgrade on alpine on the base version, you also have to change the final release image, like this:

So, update your Dockerfile, from:

FROM alpine:3.16 AS app

to this;

FROM alpine:3.17 AS app

Otherwise, the problem with the missing libgcc dependencies will still happen as those dependencies does not exist on the libgcc version of alpine 3.16 (on the final release).

[olafura]

The last time we had this problem was because of libcrypto ( openssl ) which you can statically compile but ultimately we need to be able to reliably use the same version of alpine as the Dockerfile and the easiest way I feel is to create a new Dockerimage that is used as the base for a multi-stage build
https://gist.github.com/lrascao/6880485b8dc4c51c74392b0fa5b9d358

[airton-soares]

Erased my previous comments, as I also found the solution to this problem:

Error relocating /app/erts-12.3.2.7/bin/beam.smp: __extendhfdf2: symbol not found
Error relocating /app/erts-12.3.2.7/bin/beam.smp: __truncdfhf2: symbol not found
Error relocating /app/erts-12.3.2.7/bin/beam.smp: __truncxfhf2: symbol not found

The suggested way to bulid release images on elixir/phoenix, is by having a multi stage build that firstly uses a elixir image (which inherent the erlang image) and them using a base alpine image to move your release file and deploy.

So, after this upgrade on alpine on the base version, you also have to change the final release image, like this:

So, update your Dockerfile, from:

FROM alpine:3.16 AS app

to this;

FROM alpine:3.17 AS app

Otherwise, the problem with the missing libgcc dependencies will still happen as those dependencies does not exist on the libgcc version of alpine 3.16 (on the final release).

Thank you for the follow up!

I've tried this also but the problem still there. Here's my Dockerfile:

FROM elixir:1.14.3-alpine as build

RUN apk add --update alpine-sdk coreutils

WORKDIR /build

RUN mix do local.hex --force, local.rebar --force

ENV MIX_ENV=prod

COPY mix.exs mix.lock ./
COPY config config
RUN mix do deps.get, deps.compile

COPY priv priv
COPY lib lib

RUN mix do compile, release

FROM alpine:3.17 AS app

RUN apk add --update openssl openssh libgcc libstdc++

RUN mkdir /.ssh && chmod 700 /.ssh && chown -R nobody: /.ssh

WORKDIR /app

RUN chown -R nobody:nobody /app

USER nobody

COPY --chown=nobody:nobody start.sh ./
COPY --from=build --chown=nobody:nobody /build/_build/prod/rel/project .

CMD ["sh", "./start.sh"]

[ogabriel]

@airton-soares maybe there is some build cache in action, so try to make sure its not using any cache at all on your build

The only other thing that maybe is incorrect, is that it is missing ncurses-dev on the app step

[d-wire]

We're still seeing this issue in our Dockerfile as well. We tried upgrading the release step to alpine:3.17, but we still had to add ENV NODE_OPTIONS=--openssl-legacy-provider to get through the build step. Are there any other ideas why we're not able to use OpenSSL 3.0? For additional context, we're running Elixir 1.12.3 and Erlang 24.

[airton-soares]

@airton-soares maybe there is some build cache in action, so try to make sure its not using any cache at all on your build

The only other thing that maybe is incorrect, is that it is missing ncurses-dev on the app step

Now is everything ok! It was still in error because of the Kubernete pods not beeing healthy. Thank you!

[d-wire]

@airton-soares maybe there is some build cache in action, so try to make sure its not using any cache at all on your build
The only other thing that maybe is incorrect, is that it is missing ncurses-dev on the app step

Now is everything ok! It was still in error because of the Kubernete pods not beeing healthy. Thank you!

@airton-soares did you just add ncurses-dev in the build step?

[airton-soares]

@airton-soares maybe there is some build cache in action, so try to make sure its not using any cache at all on your build
The only other thing that maybe is incorrect, is that it is missing ncurses-dev on the app step

Now is everything ok! It was still in error because of the Kubernete pods not beeing healthy. Thank you!

@airton-soares did you just add ncurses-dev in the build step?

No, just upgrading the alpine version to 3.17 in my Dockerfile. It haven't work on the first try because my kubernete in production was in error status. Now is everything ok. Thank you guys.

[tosie]

I am very sorry for having caused this trouble. The best solution would be to be able to specify the alpine version when referencing the builder image. This requires that both the erlang and elixir projects include such tags when releasing their docker images. Not sure if that is something that is going to happen anytime soon.

[ogabriel]

For those that do not want "rolling changes" on their images, which may cause problems when building the app in production, the better solution is simply use hexpm/elixir or hexpm/erlang images, as they have many images with fixed erlang and alipine versions.

Using a fixed alpine version may avoid problems with dependencies (like nodejs).