4 ms·

I am not sure how you define 2015-class, but building a release with distillery, and running docker build on a Dockerfile that copies the tarball (that includes

I am not sure how you define 2015-class, but building a release with distillery, and running docker build on a Dockerfile that copies the tarball (that includes everything needed to run your app (ERTS, app code, NIFs, etc)) makes a docker container that you can deploy as you'd expect. If you want to use clustering it's a bit more setup, but I was able to get a simple phoenix app running clustered on Google Container Engine (Kubernetes) in about 4-5 hours, starting with zero knowledge about Kubernetes or Elixir deployment. I pushed my code to github[1], and I did a talk on it at our local Elixir meetup[2]. Now that I have it figured out it's totally painless to upgrade, especially because of the Kubernetes tools. Simply make a new release, build a new container, push it to your docker registry, and then do a rolling update with kubernetes using the new version of the container. You can also add/remove scale on the fly, libcluster handles it all. [1]https://github.com/bbhoss/k8sexamplephx https://github.com/bbhoss/k8sexamplephx [2]https://www.youtube.com/watch?v=SNll1r6ZtO0&feature=youtu.be&t=4788 https://www.youtube.com/watch?v=SNll1r6ZtO0&feature=youtu.be...

gamache 10y ago
It fits into industry-standard deployment systems, yes, but not without sacrificing some inherent benefits of the Erlang platform. In particular, hot upgrades and downgrades are no longer there, as Docker images try pretty hard to be immutable. Of course there are also the effects of flushing all server-local cache and/or memoization upon deploys too. Probably a bunch of other stuff I can't think of now also. So far I've preferred to stick to the Erlang way of doing things because it let me be laziest and it hasn't failed me, but someday I would like to see tools that allow the Erlang way and the e.g., K8s way to work together.
- vertex-four 10y ago
  On the other hand, most people seem never to touch hot upgrades, even in Erlang, preferring the traditional rolling update across a cluster of machines. A lot of libraries aren't built for it either.
  - andy_ppp 10y ago
    Yes, hot upgrades sound incredible but the other advantages of docker seem to outweigh them. There is no reason you can't write a script to download the release and do the hotupdate but it feels like you are treating your containers as mutable then which is frowned upon.
odammit 10y ago
Hey liked the video, did you upload your slides anywhere?

gamache 10y ago

It fits into industry-standard deployment systems, yes, but not without sacrificing some inherent benefits of the Erlang platform. In particular, hot upgrades and downgrades are no longer there, as Docker images try pretty hard to be immutable. Of course there are also the effects of flushing all server-local cache and/or memoization upon deploys too. Probably a bunch of other stuff I can't think of now also. So far I've preferred to stick to the Erlang way of doing things because it let me be laziest and it hasn't failed me, but someday I would like to see tools that allow the Erlang way and the e.g., K8s way to work together.

vertex-four 10y ago
On the other hand, most people seem never to touch hot upgrades, even in Erlang, preferring the traditional rolling update across a cluster of machines. A lot of libraries aren't built for it either.
- andy_ppp 10y ago
  Yes, hot upgrades sound incredible but the other advantages of docker seem to outweigh them. There is no reason you can't write a script to download the release and do the hotupdate but it feels like you are treating your containers as mutable then which is frowned upon.

odammit 10y ago

Hey liked the video, did you upload your slides anywhere?