build(Dockerfile): reduce image size from 2G GB to ~0.4GB

[bentolor]

This uses mulit-stage build to separate the build phase from
the distribution image and signigicantly reduces images size.

You can find more information on Docker multistage builds here:
https://docs.docker.com/develop/develop-images/multistage-build/

[bbernhard]

Many thanks!

Do you maybe have tried running the docker container on an ARM based system (e.g. Raspberry PI)?

The reason why I am asking is, that I've had quite a few problems with alpine based base images on ARM systems in the past (I am not sure if the openjdk image is based on an alpine base image, but by looking at the size of the image it could be).

(Back then, when I wrote the Signal Messenger integration for Home Assistant I didn't plan to create a REST API wrapper for signal-cli. My first attempt was actually to add the signal-cli java application directly to the Home Assistant docker image and just call the commandline tool with the appropriate parameters. This worked well on i386/x64 systems, but didn't work nicely on ARM based systems. For some reason it took up to a minute to run the signal-cli java application on ARM based systems. I spent a few hours debugging the issue and I am fairly certain that it's related to musl - which is used instead of glibc on alpine based systems. That's why I used a (rather large) debian based base image. But it's possible that the issue in alpine is now fixed. :))

[bentolor]

I do not have a ARM environment to test it. But I know that the musl environment sometimes causes issues.

In that case you could simply replace the 11-slim with 11-jre-slim-buster : I realized that I missed the 11-jre-slim and 11-jre-slim-buster variants which only include JRE and are even much more smaller (65MB). The buster variant works on debian so it should make no difference then regarding the musl/glibc variant to your previous setup.

But its obvious that I was only able to quickly test in my environment so i cannot oversee if this change would cause side effects on other platforms.

[bbernhard]

Many thanks for changing!

I just tried to build the docker image for ARM, but unfortunately there seems to be no armv7 openjdk image (not sure yet if this is a conceptual problem or if they forgot/didn't care about armv7)

I guess we could use different base images for different architectures, but I am afraid that this could lead to some strange & hard to reproduce errors in the future. :/

[bentolor]

@bbernhard No – for sure we do not want to deviate here between architectures.

I was not aware that the openjdk project itself only releases arm64 builds, so I switched now to the adoptopenjdk release: They provide builds for nearly all available Java plattforms. The JRE base image is 78MB and very small. See the 11-jre-hotspot Tag

FYI: It seems that you are using manual ways to build the images. The Docker/Github integration is quite easy and offers autobuilds i.e. on any tags of your repository. You can i..e. see an example of the results of that integration here.

[bbernhard]

Cool, many thanks for the quick fix!

I pushed a new image with the dev tag to dockerhub. If you want to give it a try, it should be available via docker pull bbernhard/signal-cli-rest-api:latest-dev. I'll install that version on all of my test machines and let it run there for a few days. If there are no issues, I'll merge the PR :)

FYI: It seems that you are using manual ways to build the images. The Docker/Github integration is quite easy and offers autobuilds i.e. on any tags of your repository. You can i..e. see an example of the results of that integration here.

Awesome! At the moment I am a bit short on time, but I'll definitely look into that when I have a few minutes to spare. Thanks for bringing that to my attention! :)

[bentolor]

Awesome @bbernhard & glad we found a working approach for all environments: Looking forward to your feedback.

[bentolor]

@bbernhard how went the testrun phase?

[bbernhard]

how went the testrun phase?

I am currently running your adapted version in my "productive environment" on an Raspberry Pi. At the moment I have two applications that use the signal docker container - Home Assistant and octoprint. While Home Assistant works fine, I saw some strange issues with octoprint and my 3d printer. Unfortunately, I haven't had time yet to look into this issue - but I should be able to have a look at it in the next days. Although I don't think that it's related to your changes, I would like to have a look at it just to be sure (With Home Assistant I am only sending text messages whereas with octoprint I am also attaching images - so there's definitely a difference how those two integrations use the signal docker container).

I am really sorry that it takes so long for me to merge your PR! As mentioned, I am pretty sure it's not related to your changes, but merging that change without knowing what causes the issues with octoprint makes me a bit nervous. I really don't wanna break other people's setup 😅

[bentolor]

Thanks for your quick feedback! All fine – just stumbled over it in my GH history and wanted to give a quick bump.

I appreciate your precaution to not break people's setup!

[bbernhard]

Today I had a few minutes to spare, so I had a quick look. The issues with octoprint are definitely not caused by the signal integration. So, green lights for the merge! 🎉

Many thanks for the PR @bentolor. A new image will be on dockerhub in a few hours.