Docker instead of an Elixir version manager (split thread)

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

But you need to install asdf

And I use Docker for other development task and to run Sublime Text 3, Vscode, Postman, Mysql Workbench and any other tool I may need

NOTE: Docker is not a virtualisation, at least in the sense of VM’s.

How do you use GUI tools using Docker? And the more important question, have you paid for a Sublime Text 3 license?!!

Docker needs VM with host linux on an OSX and Windows, but other than You are right.

How does it differ from “But you need to install docker”?

And I do use asdf for Python, Ruby and If I need to touch something in GO it’s installed through asdf too. I only use docker to create an Erlang release for production/staging servers, because we use there Jesse and it’s not compatible with my dev machine, though I probably should use proper VM with the exact copy of production/staging environment, because docker once failed me miserably, though but I was able to recover fairly quickly. I really fail what docker advantages are (in development, or in general) over “native” solutions. Docker doesn’t give you even proper isolation… anyway this it totally off topic.

You just expose the X sockets through it. I’ve done it in the past as a test but I don’t know the steps off hand as I don’t use docker for that stuff.

My Operating system is free o any programming language and all is versions, plus databases, plus many other software… So I can play with many versions of a Software as I want without messing with my Operating System

Another thing is switching from Linux distro or to is new version is not much overhead for me once all my tooling is inside Docker Containers.

Advantages of Docker for development is huge, once you can guarantee parity for the development environment of all developers in the Team, plus if used in production than 100% parity between development and production can be achieved.

Could you tell us more about it? I’m using docker for building releases for linux …

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.

Yes you can and you should… that is all the point of using Docker, to have reproducible builds.

You need to use the Docker Image Digest of an image instead of using the Docker Image Tag.

Dockerfile:

FROM ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2

CMD bash

╭─exadra37@laptop ~/test
╰─➤  sudo docker build -t test .
[sudo] password for exadra37:
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2: Pulling from library/ubuntu
5a132a7e7af1: Pull complete
fd2731e4c50c: Pull complete
28a2f68d1120: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
Status: Downloaded newer image for ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
 ---> 07c86167cdc4
Step 2/2 : CMD bash
 ---> Running in f49d4193090b
 ---> 7422164e3384
Removing intermediate container f49d4193090b
Successfully built 7422164e3384
Successfully tagged test:latest
╭─exadra37@laptop ~/test
╰─➤  sudo docker run --rm -it test
root@22f3f656e58e:/# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.4 LTS
Release:	14.04
Codename:	trusty
root@22f3f656e58e:/#

As you can see this build is immutable and reproducible in many years ahead in the future

More reading:

https://medium.com/@tariq.m.islam/container-deployments-a-lesson-in-deterministic-ops-a4a467b14a03

For security reasons I don’t trust in third part images, just the official ones, thus I always build my ones from officials ones, thus never had issues like the one you described.

Plus building images in top of a chain of other images is asking for trouble, is like using inheritance in OOP languages, that I avoid at all costs.

The problem then of course is, how do you invoke that dockerized IDE? With a very long and complex command line, so the obvious next step - wrapper scripts! Now you “just” install wrapper scripts for everything and that is somehow easier than installing the stuff straight away on your machine ;-).

I really don’t get it. Especially not with a lot of people still on MacOS, where docker<->host file sharing performance is abysmal. At work, some people tried to work-around by having a separate docker-sync container which somehow is faster, and they managed to wrap this:

cd <source root>; asdf install && npm install && npx ember server

into a Dockerfile, two docker-compose files, and a couple of hundred lines of shellscripting to have a user-friendly wrapper around the various invocations for Ember (with, without SSL, as a test server, …).

I’m just baffled

(I use Chef to install the basics - git, asdf-vm, Emacs, some dotfiles and a global ~/.tool-versions - it runs asdf install initially which takes ages, especially on a fresh Pi install, but then everything is just there).