<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">Having tried Docker with Erlang, I have a question about hot code swapping. </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">Does using Docker get rid of that benefit? It seems to me that every Docker</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#3366ff">image will be a new release.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 28, 2016 at 10:51 AM, Peter Morgan <span dir="ltr"><<a href="mailto:peter.james.morgan@gmail.com" target="_blank">peter.james.morgan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 27 Mar 2016, at 16:37, Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br>
><br>
> On 03/27/2016 05:01 PM, Peter Morgan wrote:<br>
>> Much of the above is completely boilerplate, perhaps a <a href="http://erlang.mk" rel="noreferrer" target="_blank">erlang.mk</a> “bootstrap-docker” makes sense? Or are people using other/better methods to package applications in Docker that I have missed?<br>
><br>
> I am totally open to that.<br>
><br>
> 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?<br>
><br>
> If we do that, then the only other important thing is the bootstrap-docker target.<br>
<br>
<br>
</span>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.<br>
<br>
I’ve added a docker plugin which is weaved it into the ‘rel’ target, with a ‘bootstrap-docker’ to <a href="http://bootstrap.mk" rel="noreferrer" target="_blank">bootstrap.mk</a> - it probably could do with a “.dockerignore” in there too, and some help. The dynamic libraries probably should be copied using something like <a href="http://stackoverflow.com/questions/16929445/makefile-dynamic-rules-based-on-a-file" rel="noreferrer" target="_blank">http://stackoverflow.com/questions/16929445/makefile-dynamic-rules-based-on-a-file</a> - but I’ve struggled with that - everything being .PHONY seems wrong…<br>
<br>
The below works for me on Fedora:<br>
<br>
mkdir demo<br>
cd demo<br>
<br>
# fetch my fork<br>
wget -q <a href="https://github.com/shortishly/erlang.mk/raw/master/erlang.mk" rel="noreferrer" target="_blank">https://github.com/shortishly/erlang.mk/raw/master/erlang.mk</a><br>
<br>
# initial bootstrap, release and docker<br>
make -f <a href="http://erlang.mk" rel="noreferrer" target="_blank">erlang.mk</a> bootstrap<br>
make bootstrap-rel<br>
make bootstrap-docker<br>
<br>
# build the release and the docker image<br>
make<br>
===> Starting relx build process ...<br>
===> Resolving OTP Applications from directories:<br>
/home/pmorgan/src/git/demo/ebin<br>
/home/pmorgan/opt/erlang/18.2.1/lib<br>
/home/pmorgan/src/git/demo/apps<br>
/home/pmorgan/src/git/demo/deps<br>
===> Resolved demo_release-1<br>
===> Including Erts from /home/pmorgan/opt/erlang/18.2.1<br>
===> release successfully created!<br>
GEN docker-scratch-cp-dynamic-libs<br>
GEN docker-scratch-cp-link-loader<br>
GEN docker-scratch-cp-sh<br>
GEN docker-strip-erts-binaries<br>
GEN docker-build<br>
sha256:76a9383ada7b25dce142880bf321f6399e738a82a0bb4c31811b2040b2219077<br>
<br>
# docker image built from scratch image<br>
docker images<br>
<span class="">REPOSITORY TAG IMAGE ID CREATED SIZE<br>
</span>demo_release 0.0.1 76a9383ada7b 2 minutes ago 22.02 MB<br>
<br>
# nothing running in docker<br>
docker ps -a<br>
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br>
<br>
# “docker-run” will kill any existing run for that application and start a new one:<br>
make docker-run<br>
GEN docker-rm<br>
GEN docker-run<br>
9842e2831927e2717c461c6b0a71ac6acf6f364c1077ce2e42805d360cef496d<br>
<br>
# container is running named after the release<br>
docker ps -a<br>
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br>
9842e2831927 demo_release:0.0.1 "/bin/sh -c 'exec ${B" 2 minutes ago Up 2 minutes demo_release<br>
<br>
# “docker-logs” is a shortcut to get the logs for the container:<br>
make docker-logs<br>
GEN docker-logs<br>
heart_beat_kill_pid = 1<br>
<span class=""><br>
> 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.<br>
<br>
</span>Yes, that would make sense too. Having some more PROJECT_XYZ variable that describe the release, would be great.<br>
<br>
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).<br>
<br>
Thanks,<br>
Peter.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>