Inspired by this post I saw on hackernews yesterday. I had a quite look at my own homelab setup docker container wise. I quickly realized that quite a few of my services run a socat image in between. This is mostly because I have a docker network exposed directly to my wireguard vpn, complete with automatic dns entries to them. And of course a good chunk of the docker images of services have their web interface on a port other than 80, so I would run a socat image next to it just as a dumb proxy.

Inspecting the docker image I would use previously, it’s just over 7MB. And inspecting its Dockerfile, it would install socat from the alpine repository directly. Which is as to be expected, a dynamically linked binary. So off to building from source instead it is.

I basically took the same approach as the linked post. So a Dockerfile with a builder step, followed by a FROM scratch step which would just copy the binary into a layer. Upon adjusting this to wget and build the socat source I quickly ran into issues like this.

/usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld: libxio.a(fdname.o): in function `sockname':
fdname.c:(.text+0x25f): undefined reference to `getprotobynumber_r'
collect2: error: ld returned 1 exit status
make: *** [Makefile:115: socat] Error 1

Oh the joys of alpine and musl. But after a quick visit to the alpine package build scripts, I quickly realized there were a few tweaks that had to be made. Notably I had to disable getprotobynumber_r as this isn’t supported on alpine due to musl. Which is done by setting obscure environment variable sc_cv_getprotobynumber_r to 2. I initially thought that applying this patch was needed as well and included -DNETDB_INTERNAL=-1 in the cflags, which is basically the same. But upon writing this I realized that this wasn’t needed and I removed it.

Now to go replace the previous image with this image in my homelab setup. Perhaps in the future I’ll look into properly making this image for multiple architectures, so it could be used on ARM devices like a raspberry pi as well. Where of course the smaller container size could have a noticeable impact.

The end result of all this can be found over at https://gitlab.com/schoentoon/socat. And automatically build images are available at registry.gitlab.com/schoentoon/socat, although at this point of time only amd64 is supported.