3 ms·
tl;dr they made a 35MB busybox initrd for containers. Basically they wanted to ship containers everywhere in a "lightweight" way, so they threw away the OS. Th
by peterwwillis 10y ago
tl;dr they made a 35MB busybox initrd for containers.
Basically they wanted to ship containers everywhere in a "lightweight" way, so they threw away the OS. They use multiple justifications for this. Using containers means "you don't need packages anymore". Using immutable servers means "you don't need configuration management anymore". Using an initrd and containers means "you don't need an operating system anymore". Spoiler alert: systemd is gone. Oh, and they use both YAML and JSON for different things.
They say that for security reasons, you can't upgrade the live initrd, you have to boot a brand new initrd. They don't mention how they're going to stop memory-resident attacks, so basically this is just an annoying way to avoid having to provide a way for the user to upgrade their initrd in real time.
"It is encouraged to consider the notion of "reverse uptime" when deploying LinuxKit - because LinuxKit is immutable, it should be acceptable and encouraged to frequently redeploy LinuxKit nodes."
Expect your nodes to go down all the time. Got it.
They talk up kernel security a lot but I don't see anything about live patching (but that's not immutable, so I guess it's bad by default). Oh, and they want to rewrite the initrd daemons in Go and Rust, because dhcp gets owned all the time, and buffer overflows are the only exploits that ever happen, and C is, like, really hard, man. Spoiler alert: expect your system apps to be buggy.
- StreamBright 10y agoI think the biggest reason is the systemd-docker skirmish. Alpine already offers many of the things you need as a lightweight host os, even though it has some shortcomings. I was surprised to find out that Amazon Linux is also systemd-free. For me it is the perfect host os.
- djsumdog 10y agoI agree this seems overly complicated, however I am for anything that helps get away from systemd. > Expect your nodes to go down all the time. Got it. When I deploy containers, our system (marathon on DCOS) does rolling updates where it scheduled new nodes and then gets rid of the old ones in a rolling/rotating fashion. That's how high availability works. If your nodes go down in a controlled fashion for updates, it shouldn't be a problem.
- peterwwillis 10y agoHA was never about replacing whole nodes just to make minor changes. Rolling updates, sure, when the system isn't complex enough to do updates in place. The thing is, initrd's are always read-only anyway. But i'm annoyed that they're trying to justify this by saying it's good for security or more reliable, etc. It's just a legacy of the old design. And they have tools built into it to let it be managed remotely - but refuse to let this configure it live? So it can still be owned, but just not in a persistent state (unless you find persistent storage).
- sagichmal 10y agoRolling updates of immutable artifacts is, on balance, vastly preferable to updating software in-place with e.g. patches.
- peterwwillis 10y agoAnd is there some evidence-based research or white paper that justifies that claim? Because it sounds like the cargo cult of Google container networks.