Hacker News Reader

Comment by FpUser | Hacker News Reader

Pi is not exactly speed daemon. I do not see much point in running containers in it. I'd rather assembler cluster and consider each Pi as a container.

View on HN

Containerisation makes it a lot easier to manage a fleet of Raspberry Pis being used as appliances. Rather than having to manage in-place updates, including potentially updates across multiple versions, or rolling back to previous releases, you simple push a new container image then ask the supervisor layer to switch to the new one.

Thank you for explaining the use case to me.

I run couple of my apps on Raspberry Pi. As soon as I release new version they're automatically pulled from common source and restarted. I do not see any difficulty here at all as I do not have to lift my finger right after I've pushed the new code. And I can also revert to the old version just as easy. I've been doing those things (not on Raspberry Pi of course) long before all this CI/CD had become a buzzword. One of my products was running in thousands commercial locations all across North America in the starting in 2001 and all updates were completely automatic. 15 years run time after which it was retired.

There's nothing stopping you from doing your development, testing, and deployment against the base OS on your Pis.

Even beyond pure learning opportunities, though, there are good reasons to containerize applications even on a system as low-powered as a Raspberry Pi.

For example: if you have a k8s, Docker Swarm, Nomad (disclaimer: I work on the Nomad team @ HashiCorp), etc. orchestrator in place you can keep workloads up and running even as you take down individual machines. (This can help a lot for OS upgrades, replacing failing hardware, disk upgrades, etc. on a running cluster.)

Likewise, you can develop + test your containers on a more performant or convenient machine (like a PineBook Pro, or VMC on a Chromebook) and deploy to the Pi(s) without having to manually map your FS layout, dependencies, etc. to Raspbian or another Pi-specific distro.

It's not something you _need_ to do, necessarily, but neither does that mean there isn't value, esp. for folks already comfortable with a container-based deployment workflow.

>"...It's not something you _need_ to do, necessarily..."

I completely agree with you that there is a value in containers but everything has a price and so far I have yet to find project with the scale that does require all this overhead.

I had no problems making / working with / deploying containers on Azure when it was required by client. Since client is the king I do as instructed. For my own business or when I am the one making deployment decisions for a client I get away without containers.

> I work on the Nomad team @ HashiCorp

I've been setting up Nomad on my pi cluster. I really like it. But the documentation really isn't up to speed, and there isn't really many avenues to get support. Sometimes I regret not doing K8s instead.

I guess then you agree that doing exactly what you just described is a good idea. You just prefer it your way vs. using what is described in the article.

This is exactly the reason we would like to use FC on RPI (and similar devices).

Pi 4B is actually pretty powerful and Firecracker is pretty lean. The combination of these two makes super slick to run FC microVMs on RPI4. There are a ton of possibilities opening up once you can run a fully virtualized yet also containerized kernel + app. Once i figure out how to have an arbitrary combination of kernel + rootfs I will post an update about that. We would like to use it primary for deploying apps securely on a device that is living in a untrusted environment.

Speed demonicity and use of containers are mostly orthogonal things.

But Firecracker is VMs, not containers.

A lot of tasks don’t need speed, as long as the work is done within a few hours, all is well.

Reply on news.ycombinator.com