I agree, the application runs at too high level. Recently, I built an app in Elixir and found that containers bring more trouble than benefit. Elixir is stable enough to run standalone.
manhvu
rhcarvalho
Docker would, in addition, allow you to “declare” and provision additional system-level dependencies that are not tracked in mix.exs and not packaged in a BEAM release. An example was already given earlier, ffmpeg.
Docker also allows you to upgrade OS packages more frequently without requiring a server reboot. And you can test those changes before moving forward with a zero-downtime deploy. Upgrades on the server directly either would go untested, or requires you to maintain a copy of the production environment that you can perform the test upgrade (this tends to be much harder to maintain and do correctly than Docker images, in my experience).
Do we necessarily need Docker? No, I don’t think so. But if you want to express those other dependencies, then you need other tooling. Old-school config management system like Ansible, building OS images like with Packer, or a combination of those and/or other tools.
If your project only ever depends on the BEAM release and you guarantee your BEAM matches the OS well (e.g. compatible libc, etc) then going without the extra abstractions could be long term viable.
1
manhvu
A long time ago, I worked with Golang (web services). I found that Kubernetes (K8s) is perfect for backend development—handling deployment, security, and being simply easy to use for developers.
Recently, when I built a distributed system using Elixir, I spent a lot of time solving problems and troubleshooting. This was quite challenging because K8s uses dynamic hostnames and IPs, which presents a difficulty for those who want to run an Elixir cluster on K8s and use NIFs for low-level tasks.
0
rhcarvalho
Yep, I feel you. I worked on the OpenShift team (Red Hat’s Kubernetes distribution) for some years.
The thing is Docker doesn’t mean Kubernetes. You can use Docker without Kubernetes as an orchestration layer.
Docker still plays the role of packaging your application and OS-level dependencies.
In fact, Kamal uses Docker and is one of the “anti-K8S complexity” solutions out there.
2
Dmk
Yeah you are 100% spot on. I’m using Ansible currently. And funny enough for one of my projects I needed to use a Docker container to actually build the release to ensure compatible libraries with the VPS.
Certainly trade-offs no matter which way you slice it.
1
aesmail
This is fantastic! Do you intend to add accessories support? Or how do you currently handle non-elixir dependencies (database, etc)?
0
Dmk
I don’t think there will be accessory support within Xamal.
If you are using this you are probably already using something to manage your server (IE Ansible, Chef, Puppet, etc). And it would be handled there. That is how I do it.
0
bbangert
The problem with using a reverse proxy like caddy, is that you’re going to reduce the concurrency options as you’re now terminating the connection before forwarding it, running into socket pair limitations and a CPU hit for Caddy to be running. Maybe if Caddy supported DSR the socket limitation would be avoidable, but putting the BEAM VM behind a Golang router doesn’t feel great to me.
If the goal is to be on bare metal, why not use eBPF with a user-land configurable API for deploys that changes the traffic routing? This avoids the socket limitations while providing superior performance and retaining imperative configuration change options during deploys. It seems a little young, but there’s Honey Potion that could make that pretty simple, and nowadays it feels like the big players in scalability and routing are all using eBPF based solutions.
1
egze
I’m using Caddy as reverse proxy and it works very well for my projects. Not using Xamal, but I guess my setup is similar.
The socket/concurrency concern is theoretical, not practical. Caddy proxying to BEAM adds one local TCP hop per connection. On a single VPS serving a consumer SaaS app, you’d need tens of thousands of concurrent connections before this matters. The Linux kernel handles local socket pairs extremely efficiently - this is the same path nginx/HAProxy/Caddy take for millions of production apps.
The CPU overhead is negligible. Caddy’s reverse proxy for HTTP is minimal - it’s just shuffling bytes between sockets. The TLS termination has to happen somewhere, and Caddy does it well with automatic cert management via Cloudflare DNS challenge (how I configured it).
3