I use asdf for version manager. With this approach I don’t need to install any Docker or any other virtualization to be able to run different versions of Erlang and Elixir

PS. Sorry, couldn’t help myself

The thing with docker images is, that they are build from docker files, that can be build from other docker files with FROM directive like this: FROM elixir:1.6.1, and it’s recurrent. With ruby, or elixir dependencies you have mix and Gemfile files listing your dependencies, and corresponding mix.lock and Gemfile.lock files that list all dependencies, the one you explicitly want and all transient ones that are dependencies of your dependencies, so you have always full control of what you really are using. Docker does not list anywhere (at least I didn’t find it) what images are going to be used when you run your docker image.

Someone somewhere down the line changed dependencies of it’s dockerfile to use base image with newer version of some libraries I was during build in docker process. And although elixir release built like it always built it suddenly stopped working in production env due to mismatch of library versions (and paths IIRC). It took me sometimes to find what was the cause of the failure, but eventually I did. No instead of using docker images like any other sane dependency management tool would do, I have to vendor all the docker files and images, just like you do when you want keep sanity with this idiotic (no pun intended) dependency-no-mangement in Golang.

Maybe there is better way to keep docker image dependencies, but I did not find any. Maybe I’m doing it wrong, but I don’t want to waste any more energy on docker.

Anyway, the lesson is that you can’t trust dockerfiles dependencies to be reproducible.

The worse thing is that all that gets statically linked into your final container image.

There used to be a time that when you had a very severe C library bug, all you needed to do was update it on your hosts, reboot, done. People in the '80s and '90s worked really hard to add dynamic linking, etcetera, to Unix. Precisely to enable this level of system management.

Now, we’re twenty years later and people actively promote containerized microservices which are exactly the sort of statically linked executables that were so hard to manage and prompted dynamic linking.

Now, you run your 50-microservice PaaS with a couple of thousand instances and the CVE lands on glibc - everybody has to rebuild and redeploy everything.

It’s beyond stupid, frankly, and I’m waiting for the day that Docker will sport “dynamic container linking”, so a perfectly fine wheel gets reinvented in the most horrendously complex way imaginable, because that’s how Sillicon Valley (where, alas, too much of our tooling gets built) rolls.