Bottlerocket: An operating system designed for hosting containers

Post by ailideex » Wed, Mar 11, 2020, 9:06 AM UTC

rfrfee wrote: post #68

whalesalad wrote: post #10

A link to the actual source code (90% Rust) and README: https://github.com/bottlerocket-os/bottlerocket And here is a post from AWS with more technical details: https://aws.amazon.com/blogs/aws/bottlerocket-open-source-os...

Given that Red Hat recently killed CoreOS, it's great to see new alternatives coming up. I cannot wait to give it a spin!

Post by akvadrako » Wed, Mar 11, 2020, 9:26 AM UTC

alkonaut wrote: post #80

akvadrako wrote: post #71

Earlier quoted context omitted.

Desktop and mobile is actually where you want containers most. Servers rarely run untrusted or semi-trusted code because everything comes from a trusted source, usually open source, or in house. But users want to run lots of shady apps, either that they find on random websites or places like the Google Play store.

It's also the rare case where you can't accept a 5% performance hit because that's 5fps in a game or 5 seconds on a 100 second render time or 5ms instead of 95ms wait in an interactive app. I find that the key to running desktop OS/apps is never use sensitive data and always be ready to wipe your machine and start over.

Post by kchr » Wed, Mar 11, 2020, 10:11 AM UTC

sourcesmith wrote: post #83

hardwaresofton wrote: post #67

Earlier quoted context omitted.

As far as I'm concerned, this is an obvious truth. Linux containers are processes with better sandboxing -- who would not want this? As kinks in the kernel support and tech get worked out, and OSs deepen support I can't imagine that it will ever make sense to say something like "I could have run the process with cgroup and namespace isolation but I chose not to, choosing to make a new user-level isolation or run ever…

"I could have run the process with cgroup and namespace isolation"... using systemd.

Post by rkangel » Wed, Mar 11, 2020, 10:27 AM UTC

arianvanp wrote: post #77

yjftsjthsd-h wrote: post #38

Earlier quoted context omitted.

How does this compare to something like nix or Fedora Silverblue?

Nix has upside that you just need to flip a symlink to do the same . Downside is that you don't have thinks like dm-verity that can prove that your update wasn't tampered with. In nix the nix store is remounted over itself read-only, but nothing stops someone from ripping out the disk and flipping bits. This is not possible with these kind of 2-partition schemes if you have dm-verity set up

Post by bogomipz » Wed, Mar 11, 2020, 10:37 AM UTC

jhaynes wrote: post #6

jrhill85 wrote: post #4

The subject says "for hosting containers" but the README says "for AWS EKS Kubernetes" which sounds a little less general... How tied in to the AWS model is this? Are the places that would need to be expanded known? Also at least at a glance, this is a neat use of real-world Rust

While our first variant is focused on Kubernetes and EKS, we have designed Bottlerocket in a way that new variants can be built that work with other orchestrators, or even without one (we have ECS support on our roadmap already). Also, we really enjoyed working in Rust for big chunks of this!