-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dockerfile build approach doesn't ensure consistent openssl lib at runtime #178
Comments
@dentarg - Do you have a preferred way of solving this ? Typically the build process and the run image are the same image, rather than different images - but if we do that here then the run image ends up being almost 400MB due to all of the build tools. If we simply change to build static then we're making a 32MB image, which seems acceptable.
The other options I can see are:
|
32MB sounds acceptable to me too, but I will let other people move this forward. |
22MB when a scratch image is used: #183 |
But what we really should do is to build a new |
Thank you for narrowing down the issue! |
Version incompabilities between library versions in the build image and the runtime image can otherwise cause segfaults and other problems. See: cloudamqp/amqproxy#178
This problem has been discovered while investigating:
The build approach at https://github.com/cloudamqp/amqproxy/blob/main/Dockerfile results in a dynamically linked amqpproxy, but does not ensure the same library version is used at runtime compared to compile time.
It might be the case they match, as https://github.com/84codes/crystal-container-images/blob/main/alpine/Dockerfile defaults to
alpine:latest
as well, but it depends on when the builds are run.Not using the same version at runtime can lead to illegal instruction errors as noted in issue #174 , when using TLS for an upstream host.
For example in our build environment right now:
Workarounds
shard build --static
for amqproxy.The text was updated successfully, but these errors were encountered: