Use more specific otp version for elixir 1.7
AlexKovalevych opened this issue · comments
Is it possible to use more specific OTP version, than OTP:21 for 1.7 or at least 1.7.4 elixir? Since new OTP image update breaks the elixir image (this is the second time on my memory, but different error). E.g., with the latest OTP 21.2.5 (16 hours ago) getting this error:
":load_failed, Failed to load NIF library: 'Error loading shared library libcrypto.so.1.1: No such file or directory (needed by ./lib/crypto-4.4/priv/lib/crypto.so)'"
Solved: we used 3.8 alpine, but OTP updated to 3.9.
@AlexKovalevych Can you be a bit more specific? We have the same issue and would love to get some help on this.
@namxam yes, here is how it was in my case:
elixir:1.7.4-alpine -> erlang:21-alpine->alpine:3.8
And in my image we used alpine 3.8 to run it.
After recent OTP update erlang:21 image was updated to alpine:3.9. So we updated our image to use alpine:3.9. E.g.: https://github.com/edenlabllc/ehealth.api/pull/4128/files#diff-3254677a7917c6c01f55212f86c57fbfR21
Had the exact same issue, but with elixir:1.8-alpine.
Specifically, I am doing a multi-stage build using elixir:1.8-alpine to build, and then alpine:3.8 to run.
When erlang:21-alpine bumped its base image from alpine:3.8 to alpine:3.9, it caused my application to fail to start.
@c0b is there a way to prevent a similar issue from happening again in the future?
could you share some failure logs? might it be related to SSL issues to #105 ?
is there a way to prevent a similar issue from happening again in the future?
generally, the more people look at it (not really just look, but also ready to touch some code, send a PR), the less probability it has problems, or the sooner being fixed when a problem happens
or the approach to push it to upstream to maintain #64 that would have a better position in the community
It was related to openSSL changing between alpine 3.8 and 3.9.
Would it be possible to put the alpine version in the image name? I have seen other images use this approach. Example: elixir:1.8-alpine3.8, elixir:1.8-alpine3.9.
yes, it is possible to support multiple alpine versions, then a problem follows is the output is a x * y * z combinations, it's not only the extra maintenance effort, but sometimes also lack of clarity; for example when 1.6 series have 3 normal variants (regular debian-buildpack + slim + alpine) were coming out when erlang-otp was 20, then erlang21 comes out during 1.6 was still the latest, but erlang21 brought in some incompatibilities, we did a special -otp-21 variants to support that, resulted a total of 5 variants, the same situation could happen again, and now alpine3.9 brought in incompatibilities at libssl layer
https://hub.docker.com/_/elixir/
- 1.6.6, 1.6 (1.6/Dockerfile)
- 1.6.6-slim, 1.6-slim (1.6/slim/Dockerfile)
- 1.6.6-alpine, 1.6-alpine (1.6/alpine/Dockerfile)
- 1.6.6-otp-21, 1.6-otp-21 (1.6/otp-21/Dockerfile)
- 1.6.6-otp-21-alpine, 1.6-otp-21-alpine (1.6/otp-21-alpine/Dockerfile)
it could be good if more voices appear, or when you're asking something, the willingness to contribute a PR also matters