Kubernetes and the Erlang VM: orchestration on the large and the small, by José Valim

Our very handsome and humble José Valim (@josevalim) just published Kubernetes and the Erlang VM: orchestration on the large and the small.
It’s a very nice read, and I’m sure you guys will love it.

After reading this blog post I felt a need once again for a very detailed book on Elixir (Phoenix) deployment, like I and many others asked at the forum about a very detailed book even if there are resources like Distillery’s detailed documentation.

18 Likes

Thank you for sharing.

2 Likes

I am mulling the idea of writing an Elixir deployment book covering multiple deployment methods. Ansible will be used for server setup/deployment (build servers and run-time servers), then CI/CD deployment to Kubernetes was going to be covered in the second half. Initially I was going to aim for LeanPub for distribution. Wasn’t sure how many folks would be interested in such a book TBH.

11 Likes

I agree that comparing k8s and OTP is not apples to apples as these two works on different level. However with time I started to understood anti-systemd guys when I tried to learn how to operate k8s. It is big, it is hairy, it requires enormous amount of time to understand it correctly. K8s is nice when it isn’t your job to maintain it, but when you need to maintain it it became as easy as understanding Azathoth’s doings.

In my humble opinion using Elixir without k8s is much easier, as all I need is to spawn new VM with properly configured init system and I will get almost the same features as I have with k8s without all complications from k8s.

1 Like

Me! Just do it, now!

4 Likes

I’d suggest trying not to go into ansible and server setup. That is a large topic in itself which will distract from the main topic.

I think there are 2 audiences (well really 3 but the third can look elsewhere for details on setting up servers with ansible, since that is not specific to Elixir): 1) those who need to run small projects and act as the main ops person as well – likely good enough to discuss how to use with systemd in their case 2) those at a company who need to fit into the existing organizations infrastructure.

The direction we are going with adoptingerlang.org is to mainly cover (2) when the organization is using kubernetes. The systemd case is covered in an appendix.

Since your book is solely about deployment I wouldn’t restrict to just k8s like adoptingerlang but just like we don’t cover setting up k8s (besides pointing to dev tools like microk8s and to google kubernetes engine for prod) I’d warn against it becoming an operations book instead of an Elixir book :slight_smile:

5 Likes

Thank you for the feedback! I now think jumping in with ansible first would be out of scope although if time permits I will cover it in its own section last. Starting with the basics of compiling/building a release and running the release on a server appears to solve a number of questions about Elixir.

What tooling are you using for adoptingerlang.org?

1 Like

The tooling for writing and publishing? It is a Hugo site hosted on netlify (which is great for CI because it has a “preview” deploy feature that gives us a live url for every PR) and written in org-mode https://github.com/adoptingerlang/adoptingerlang. There is an Emacs tool ox-hugo that converts from org-mode to hugo, but the org-mode is also converted to a pdf.

1 Like

Sometimes Ansible is used for both server provisioning and also for distributing upgrades and restarting services.

1 Like

True. A chapter on using ansible for deploying, unpacking, starting/upgrading a release might be good.

Another suggestion, stick to what you actually use. If you (frigidcode) have experience with production ansible deloyment then maybe don’t also include a puppet/chef chapter. You could instead get collaborators who do use puppet or chef (or one of the many other offerings) to write those chapters.

The reason being, those who have used these tools in anger will know bits that are important to highlight – though obviously need someone who isn’t experienced with these tools to do a review because someone experienced will also accidentally leave out plenty of useful information that someone new will need.

Not to say writing and publishing guides while learning a tool isn’t really useful, I’m just referring explicitly to a book about real world production deployment, as opposed to a “getting up and running with Puppet and Elixir” post.

3 Likes

Agreed, I only planned on writing about what I used in anger :wink:

2 Likes

I’d also be interested and I’m sure more folks would be too. This is kind of hidden inside of the post on Jose’s article. Maybe a unique post posing the question will get more attention and give you an accurate gage of interest. A lot of the information that is out there is outdated, especially with releases baked in now and the change in how configuration is done.

Speaking of, would you be covering both pure releases and Distillery (and maybe when to choose one over the other)?

1 Like

Curious what you are referring to? The init system is doing more to “replace” k8s in that case than beam.

And using anything without k8s is much easier :). Whether to use k8s or not is separate from the language you are using, once you are requiring multiple nodes running various services is when you start to benefit and where Elixir provides nothing out of the box that is equivalent.

A deployment book would rock! Go for it! :slight_smile:

1 Like

That is my point.

Agree.

True, but IMHO it would be interesting to run BEAM as a system supervisor and use OTP to supervise all other services within that machine. I am thinking about writing PoC for something like that, just for fun and giggles.

Sure. But that would be implementing such a system in Elixir/Erlang, very different from those who say it is already builtin.

I too have wanted to play around with building similar, thinking containerd for running containers and lasp for sharing around what the current state of the cluster should look like to each node which then checks that what should be running on it is. Obviously nothing like the complex k8s scheduler or feature set, just a toy. Deciding on how to do networking between running containers is what has kept me from moving forward. Well that and time.

1 Like

I want to write alternative epmd_module and proto_dist to use Consul instead of EPMD for connecting distributed nodes with each other. But I have similar problem with:

To me, that sounds similar to Nerves. There are a couple of semi-experimental systems that run on non-embedded hardware:

Please, please, please!

Please don’t forget to add a full section on deploying to physical servers. That’s the cheapest way of deployment, and that’s what I learnt Elixir for, otherwise if I was to deploy to Heroku or to AWS with K8s, any technology could work there, may be Crystal did better.

I strongly Agree! I love Elixir and hate K8s tooooooo much!, and I think there are many Elixir developers who think the same.

I think people like me will need the detail about Ansible and server setup, those people who are not very experienced and not very skillful and can’t easily find the material outside the book. The book should make things easier for us, not put us on another journey of homework.

I’d love if the book covers the following things,

  1. Deploying to (a network of) Physical servers.
  2. Deploying to AWS / GCP or Azure.
  3. Deploying to DigitalOcean / Linode etc.

I would definitely purchase it. I would recommend pitching the idea to PragProg