Crystal multi-arch docker images available

carlhoerberg · September 30, 2021, 9:41pm

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

stakach · October 28, 2022, 9:53am

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

stakach · October 28, 2022, 12:06pm

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

carlhoerberg · October 28, 2022, 4:23pm

Nope?

github.com

84codes/crystal-container-images/blob/75553a82bea1b00f5480d48105d32fb474de0bf3/debian/Dockerfile#L111


      
          COPY --from=pkg-builder /tmp/pkg/*.deb .
          
          
# start from a clean image
          FROM $base_image:$codename
          ARG codename
          ARG llvm_version
          # add dependencies commonly required for building crystal applications
          ARG DEBIAN_FRONTEND=noninteractive
          RUN apt-get update && \
              apt-get install -y curl gnupg gcc make git pkg-config \
              libpcre3-dev libevent-dev libssl-dev libgmp-dev libyaml-dev libxml2-dev zlib1g-dev libffi-dev llvm-$llvm_version && \
              rm -rf /var/lib/apt/lists/*
          # copy the binaries + stdlib + libgc from the build stage
          COPY --from=builder /tmp/crystal/*.md /usr/share/doc/crystal/
          COPY --from=builder /tmp/crystal/man/crystal.1.gz /usr/share/man/man1/
          COPY --from=builder /tmp/shards/man/shards.1.gz /usr/share/man/man1/
          COPY --from=builder /tmp/shards/man/shard.yml.5.gz /usr/share/man/man5/
          COPY --from=builder /tmp/crystal/src /usr/share/crystal/src
          COPY --from=target-builder /tmp/crystal/.build/crystal /usr/bin/
          COPY --from=target-builder /tmp/shards/bin/shards /usr/bin/
          COPY --from=target-builder /usr/lib/libgc.a /usr/lib/

github.com

84codes/crystal-container-images/blob/75553a82bea1b00f5480d48105d32fb474de0bf3/alpine/Dockerfile#L61


      
          RUN make llvm_ext
          RUN sh -ex .build/crystal.sh && strip .build/crystal
          # Link shards
          WORKDIR /tmp/shards
          COPY --from=builder /tmp/shards/bin bin
          RUN sh -ex bin/shards.sh && strip bin/shards
          
          
# start from a clean image
          FROM alpine:$alpine_version
          # add dependencies commonly required for building crystal applications
          RUN apk add --update --no-cache musl-dev gcc pcre-dev libevent-dev libevent-static openssl3-dev openssl3-libs-static libxml2-dev zlib-dev zlib-static git make yaml-dev
          # copy the binaries + stdlib + libgc from the build stage
          COPY --from=builder /tmp/crystal/*.md /usr/share/doc/crystal/
          COPY --from=builder /tmp/crystal/man/crystal.1.gz /usr/share/man/man1/
          COPY --from=builder /tmp/shards/man/shards.1.gz /usr/share/man/man1/
          COPY --from=builder /tmp/shards/man/shard.yml.5.gz /usr/share/man/man5/
          COPY --from=builder /tmp/crystal/src /usr/share/crystal/src
          COPY --from=target-builder /tmp/crystal/.build/crystal /usr/bin/
          COPY --from=target-builder /tmp/shards/bin/shards /usr/bin/
          COPY --from=target-builder /usr/lib/libgc.a /usr/lib/
          # set the default cmd, example usage: docker run --rm 84codes/crystal eval 'puts "hello world"'

stakach · November 1, 2022, 10:25am

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

straight-shoota · November 1, 2022, 10:30am

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.

stakach · November 1, 2022, 10:44am

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

stakach · November 1, 2022, 11:56am

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…

stakach · November 1, 2022, 1:25pm

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

carlhoerberg · November 1, 2022, 8:36pm

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

carlhoerberg · November 1, 2022, 8:37pm

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

carlhoerberg · November 1, 2022, 8:44pm

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

stakach · November 1, 2022, 10:58pm

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

carlhoerberg · November 1, 2022, 11:51pm

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.