@tianon I've left a few questions for you in the Dockerfile as TODOs.
A few highlighlights:
* I've added capture the way I build this image locally in the build script
* ha.pool.sks-keyservers.net is not as stable as pgpkeys.eu,
there are many unstable PGP keyservers https://sks-keyservers.net/status/
* GitHub SSL was failing in wget when grabbing gosu, curl is more reliable
* docker-entrypoint.sh fails if rabbitmq-plugins is not invoked with the -q flag,
a fix since 3.7.10 2da98843a4 (commitcomment-31470432)
This is a first commit, the feature as a whole is WIP. The next steps
are captured in a TODO at the tail of the Dockerfile. Sharing this
early so that we can discuss the direction that this is going in.
Various decisions made in the Dockerfile have been captured inline in
comments, should make for a good PR discussion.
The primary goal is to upgrade the Erlang/OTP version to latest stable,
which is v21.2.2 at the time of this commit. RabbitMQ v3.7.x will stop
supporting Erlang v20.x in September 2019 (~8 months from now). RabbitMQ
v3.8.x will only support Erlang v21.x. RabbitMQ Erlang/OTP release
support policy was announced on the rabbitmq-users mailing list in
October 2018:
https://groups.google.com/forum/#!msg/rabbitmq-users/G4UJ9zbIYHs/tyt_kDoFBgAJ
The secondary goal is to only ship the required artefacts in the final
image. For example, all Erlang/OTP applications & features which are not
required by RabbitMQ are disabled. I suspect that the final Erlang/OTP
release can be shrunk further (it currently stands 130MB), but this is a
minor concern right now.
Related to the secondary goal, we enable certain features in Erlang/OTP
which are useful when debugging:
* extra microstate accounting is not known to negatively affect
performance, this feature is exposed via the `rabbitmq-diagnostics
runtime_thread_stats` command added in v3.7.10
* lock counting is only enabled if the Erlang VM is started in a
specific mode, this feature doesn't impact the default beam.smp runtime
The final goal is to be explicit about the OpenSSL version that
Erlang/OTP uses. Using a shared OpenSSL might be convenient, but it
has the following drawbacks:
* depending on the base image for OpenSSL updates
* not knowing which OpenSSL version we compile against
* not knowing how OpenSSL was configured
* not being able to change OpenSSL configuration
Compiling OpenSSL adds an extra concern and definitely complicates this
Dockerfile, but one possible mitigation would be to automate version
bumps when a new OpenSSL version gets published. I am also expecting
that images will be automatically built & published from this
Dockerfile. Since OpenSSL is compiled with all defaults, I do not expect
things to stop working and become a maintenance overhead - we are not
using any advanced compilation flags.
I am including the full docker build log, I always find the information
captured in build logs to be helpful.
Resources which I found helpful while putting this Dockerfile together:
* 816bb377a5/packages/erlang-21.1/packaging
* e2e804aeeb/21/Dockerfile
* https://github.com/erlang/docker-erlang-example#2-build-stage-1-create-a-minimal-docker-image
* https://bugs.erlang.org/browse/ERL-823
* http://erlang.org/pipermail/erlang-questions/2019-January/097012.html
* https://github.com/lrascao/erlang-ec2-build
* https://github.com/kerl/kerl/blob/master/kerl
Gerhard Lazu