Crystal multi-arch docker images available

Crystal Contrib
1

Multi-architecture docker images are now available at Docker Hub. They’re are build daily by a Github Action.

These images uses the fact that alpine have (outdated) builds of crystal in their repository, for multiple architectures, so we use that compile to build the latest (or any version, it’s configurable) of Crystal, and then using a multi-layer approach copy that resulting binaries to a fresh alpine image (to not leave behind unnecessary crystal build dependencies).

For our software we normally use a multi-stage process to build static binaries into a scratch image, see example: websocket-tcp-relay/Dockerfile at main · cloudamqp/websocket-tcp-relay · GitHub

But we also use the 84codes/crystal:1.1.1-ubuntu-* images to build deb packages: websocket-tcp-relay/Dockerfile.deb at main · cloudamqp/websocket-tcp-relay · GitHub

9 Likes
2

Nice, we moved to using your images as the basis of our images

1 Like
3

@carlhoerberg I did notice that openssl dev is left behind, not sure if that was intentional

4

Nope?

1 Like
5

not sure the version of OpenSSL on the Alpine image is supported yet

WARNING: Unsupported BIO ctrl call (133)
WARNING: Unsupported BIO ctrl call (128)
Invalid memory access (signal 11) at address 0x7ffdbf0650b0
[0x55d680829ca6] print_backtrace at /usr/share/crystal/src/exception/call_stack/libunwind.cr:100:5
[0x55d68068c5e6] -> at /usr/share/crystal/src/signal.cr:151:5
[0x7f6062743c9f] ?? +140051945372831 in /lib/ld-musl-x86_64.so.1

I noticed @straight-shoota opened an issue about it the other day

6

If you refer to Support for libreSSL 3.5 · Issue #12647 · crystal-lang/crystal · GitHub, that’s about libreSSL but the dockerfiles appear to be using OpenSSL.

7

Ahh yeah, my bad.
I’ve seen this issue when running Alpine:edge but the 84codes image isn’t running alpine edge so wasn’t expecting to see it, but definitely some new BIO ctrl codes incoming

8

actually the

Invalid memory access (signal 11) at address 0x7ffdbf0650b0
[0x55d680829ca6] print_backtrace at /usr/share/crystal/src/exception/call_stack/libunwind.cr:100:5
[0x55d68068c5e6] -> at /usr/share/crystal/src/signal.cr:151:5
[0x7f6062743c9f] ?? +140051945372831 in /lib/ld-musl-x86_64.so.1

is unrelated, resolved by reverting back to crystal 1.5…

9

I’m definitely conflating two different issues here.
I find that with our services, using the 84code Alpine images both 1.5 and 1.6 versions of crystal constantly output

WARNING: Unsupported BIO ctrl call (133)
WARNING: Unsupported BIO ctrl call (128)

our specs pass on 1.5 and we have the segfault Invalid memory access (signal 11) occurring on the 1.6 image, but the BIO warnings on both

10

Are you doing something funny with openssl? Looks like code 128 = seek and 133 = tell: openssl/bio.h.in at master · openssl/openssl · GitHub

11

There’s no longer stacktrace for the invalid memory access error? you don’t have source code available? or a shorter reproducable snippet?

12

Might also get a better stacktrace if you don’t compile/run with --static

13

stack trace is unrelated to the 84codes image as have the same issue with official images.
the BIO codes only happen on the 84codes images.

Not doing anything special, just standard HTTP lib requests
I think a few more cases need to be added for the newer versions of OpenSSL3

1 Like
14

Ok! yes, you’re right, was able to reproduce TLS errors, with openssl3, but when using openssl1.1.1 it works as expected. I’m reverting the alpine images to use openssl1.1.1 for now.

3 Likes