[erlang-questions] erlang in docker from scratch

[Peter Morgan]

> On 27 Mar 2016, at 16:37, Loïc Hoguin <essen@REDACTED> wrote:
> 
> On 03/27/2016 05:01 PM, Peter Morgan wrote:
>> Much of the above is completely boilerplate, perhaps a erlang.mk “bootstrap-docker” makes sense? Or are people using other/better methods to package applications in Docker that I have missed?
> 
> I am totally open to that.
> 
> What would be great, would be to be able to build on top of the release handling. If the project uses Docker, then "make" should build the container and "make run" should run the container (instead of building the release and running it). Does that make sense?
> 
> If we do that, then the only other important thing is the bootstrap-docker target.


Awesome - I’ve forked. I have some changes, they need a bunch more testing - they’re not going to work on anything other than Linux at the moment. I’ll look at OSX, but that will mean getting a Linux ERTS from somewhere into the container somehow - probably “FROM erlang” - but that is enormous.

I’ve added a docker plugin which is weaved it into the ‘rel’ target, with a ‘bootstrap-docker’ to bootstrap.mk - it probably could do with a “.dockerignore” in there too, and some help. The dynamic libraries probably should be copied using something like http://stackoverflow.com/questions/16929445/makefile-dynamic-rules-based-on-a-file - but I’ve struggled with that - everything being .PHONY seems wrong…

The below works for me on Fedora:

mkdir demo
cd demo

# fetch my fork
wget -q https://github.com/shortishly/erlang.mk/raw/master/erlang.mk

# initial bootstrap, release and docker
make -f erlang.mk bootstrap
make bootstrap-rel 
make bootstrap-docker

# build the release and the docker image
make
===> Starting relx build process ...
===> Resolving OTP Applications from directories:
          /home/pmorgan/src/git/demo/ebin
          /home/pmorgan/opt/erlang/18.2.1/lib
          /home/pmorgan/src/git/demo/apps
          /home/pmorgan/src/git/demo/deps
===> Resolved demo_release-1
===> Including Erts from /home/pmorgan/opt/erlang/18.2.1
===> release successfully created!
 GEN    docker-scratch-cp-dynamic-libs
 GEN    docker-scratch-cp-link-loader
 GEN    docker-scratch-cp-sh
 GEN    docker-strip-erts-binaries
 GEN    docker-build
sha256:76a9383ada7b25dce142880bf321f6399e738a82a0bb4c31811b2040b2219077

# docker image built from scratch image
docker images
REPOSITORY                 TAG                 IMAGE ID            CREATED             SIZE
demo_release               0.0.1               76a9383ada7b        2 minutes ago       22.02 MB

# nothing running in docker
docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

# “docker-run” will kill any existing run for that application and start a new one:
make docker-run
 GEN    docker-rm
 GEN    docker-run
9842e2831927e2717c461c6b0a71ac6acf6f364c1077ce2e42805d360cef496d

# container is running named after the release
docker ps -a
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS              PORTS               NAMES
9842e2831927        demo_release:0.0.1   "/bin/sh -c 'exec ${B"   2 minutes ago       Up 2 minutes                            demo_release

# “docker-logs” is a shortcut to get the logs for the container:
make docker-logs
 GEN    docker-logs
heart_beat_kill_pid = 1

> Looking at your code, it sounds like you would benefit greatly from having Relx configuration built into the Makefile instead of as a separate file. But that can come as a second step.

Yes, that would make sense too. Having some more PROJECT_XYZ variable that describe the release, would be great.

Also - should “-heart” be default in vm.args? Heart is kind of redundant with docker —restart=always and breaks the one-process-per-container rule (similar for epmd).

Thanks,
Peter.