The BEAM docker release GitHub action builds a tiny from scratch container as part of your GitHub workflow. With a minimal attack surface, of tens rather than hundreds of megabytes. We are building containers not virtual machines here!
Multi-platform. linux/arm64 crashes and burns with a qemu uncaught signal. It should work, and I would really like it to work! I would appreciate any collaboration into why. Hoping that it is something simple that I’ve done wrong. linux/arm/v7 works fine…
Other BEAM languages should be reasonably simple to support providing they use relx, with some updates to the dependency copying script.
I think that this comes from the fact that qemu doesn’t handle dual mapping which the erlang JIT relies on. You can try exporting the env var ERL_AFLAGS="+JPperf true" during the build (enabling perf has a side effect of disabling the dual mapping), on master you could use +JMsingle true instead (see https://github.com/erlang/otp/pull/6340)
I’ve updated the build platform default to linux/amd64 and linux/arm64, so that a multi-platform build is created. I’ve updated the HelloWorlds on Elixir and Erlang with multi-platform builds.
I’ve run the HelloWorld container on an arm64 Raspberry PI. It would be great to hear whether it works on Apple Silicon too.
this is very inconvenient for debugging. Do I understand you correctly that main idea of this inconvenience is reducing amount of things that can be attacked?
You can use nsenter to run any OS command within the context of the container. They don’t have to be in the container to run them.
If you want to run an interactive command line on the running BEAM, then I would look at running a ssh daemon within your application. Or embedding (shameless plug!) something like shelly with your OTP application. That is usually my goto, usually with recon also installed.
Obviously, you also need to instrument your application so that you know what “good” (normal) looks like.
If you are on AWS then SSM integrated with IAM might also make sense. Other cloud providers probably have something similar to SSM.
One man’s inconvenience, is another’s convenience! I generally get the phone call at 3am when log4shell is discovered asking whether “Can you be sure it isn’'t present in the container?”. My motivation is:
“right size” containers that can run on low memory/bandwidth/footprint systems
no unnecessary dependencies outside of the application (patching, security, bloat… etc).
I added the +JPperf true flag to build the Elixir image for the arm64 architecture, and the image size will increase significantly. I deleted the jit-*.dump and perf-*.map files in the /tmp path to reduce the size. But this phenomenon seems to only exist when building Elixir, and does not happen when building Elixir apps.