Live data from Hacker News

Bottlerocket: An operating system designed for hosting containers

github.com

91–100 of 121 posts

Re: Bottlerocket: An operating system designed for hosting containers

#91
post #34

Opening line from their announcement blog post: >It is safe to say that our industry has decided that containers are now the chosen way to package and scale applications. Curious how the HN community feels about that statement. Not so much about the truth of the statement but about the fact that containers are becoming the de facto method of packaging applications.

We rarely use containers for our deployments because you can get the same features that containerization provides by other means. The biggest issue with containers is the stability of Docker both the operational stability of containerd and the API stability with the tooling (like to rename command-line switches). As far as Kubernetes goes, my problem is visibility. I have very limited knowledge about what the containers are doing, the provided metrics that you can access are much less than I need to try to operate a k8s cluster. Once you need to look at the actual host-level metrics (CPU, IO, mem, ...) you need to have a map of what runs where. One of the reasons people are pushing for k8s is that you do not actually need to know what runs where.

As far as complexity goes, I would much rather have a nodes where a single application is running and using 100% of resources (instead of having containerd or k8s services running) and do simple autoscaling, having access to host-level metrics that I can map back to applications easier than use Docker, k8s & co. Maybe is it only me, but I care about efficiency. Why waste energy?

The counter-argument is that developer time is more valuable than setting up clusters or autoscaling groups. Well, this breaks down when you have SRE team(s) maintaining the k8s clusters (literally every company I worked for). If you already have SRE people either embedded into your dev teams or separately then you can just build out a CI/CD pipeline that produces that production setup based on blueprints. We usually use Terraform and Ansible with tempalte variables (stage = test|qa|prod, cluster size = x, version = y) that makes it easy for everybody to provision clusters on their own. Does this mean more work than k8s deployments? Yes. Does this mean we have less complexity we need to care about? Yes. In my experience containerization is a development tool to make it extremely easy to achieve fast development cycles but right now the accidental complexity to take that with you to production is not worth it. There are very nice projects like LXC/LXD that I would consider using for security separation and resource management but we usually have clusters where 100% of resources go to a single services. Example: Hadoop cluster, Elasticsearch cluster, Web application (mostly API) clusters. I need to care about the underlying hardware because of financial reasons (what is the cheapest node type I can use to run workload X). k8s would not help here.

To sum it up: I do not think that the industry has decided on this. I also think that we are in the era of wasteful computing which will be finished soon because of reliability and unnecessary CO2 production reasons. Running containers has to be much less fragile and efficient to be considered the way to scale applications. I personally think that Firecracker is a step in the right direction in this while Docker & k8s in the wrong direction.

Re: Bottlerocket: An operating system designed for hosting containers

#92
post #47

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...

From the AWS Compliance Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-mode... Operating system maintenance falls under the Customer responsibility side. With using this new OS, would this responsibility shift back to AWS?

No, although it might reduce your effort needed. AWS offers that responsibility shift under the Fargate ECS/EKS launch types, which might run this underneath.

Re: Bottlerocket: An operating system designed for hosting containers

#93

Earlier quoted context omitted.

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.

Containers don't have a 5% performance hit.

That sounds good but I’ll believe it when I see it. There aren’t many desktop container/sandbox implementations out there and most are “vm light” e.g the windows sandbox and sandboxie. I haven’t seen anything more lightweight that can run desktop apps (in Windows at least).

Re: Bottlerocket: An operating system designed for hosting containers

#94

Earlier quoted context omitted.

Honestly, reading the glossary gives me Urbit [1] vibes :( > bork: A setting generator called by sundog to generate the random seed for updog, determining where the host falls in the update order. [1]: https://urbit.org/docs/glossary/

Agree. It's cool so long as the number of names is small, and the names actually are a pun on the function and not just e.g. names of planets. If "updog" is what brings something "up" that's a good name. WiX (windows installer creation) has a multi-phase command line interface where the compiler/linker/.. has different names indicating the order they are applied: candle, light, smoke... Also a working system I guess.

"bork" is dog-talk for "bark", and so something that randomly gets an updog going being named such makes sense too, it's just a slightly more obscure joke.

Re: Bottlerocket: An operating system designed for hosting containers

#95
post #58

Earlier quoted context omitted.

You're correct. Debian and Ubuntu are technically different operating-systems. Due to the similarity of 'operating-systems' built around the Linux kernel they're typically referred to as 'Linux distributions'. In the context of software development, if you tell someone you're developing a new operating-system you're probably going to conjure up images of writing a new kernel. If you tell people you're developing a ne…

It’s not that simple. I wouldn’t use the word distribution for GUIX, NixOS, Android and several OSes that use the Linux kernel.

This is true. Android is a good example of where the line between a Linux distribution and an outright OS blurs. I'm not convinced that this really affects my overall point all that much though.

Re: Bottlerocket: An operating system designed for hosting containers

#96
post #68

Earlier quoted context omitted.

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

Not even once ... https://docs.fedoraproject.org/en-US/fedora-coreos/

That first needs to prove itself in practice, so far it seems more like a desperate try to tie it to Fedora and have it catch up with the popularity in cloud of the likes of Ubuntu and to eventually have people paying by locking into RHEL CoreOS.

Re: Bottlerocket: An operating system designed for hosting containers

#97

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

This is possible in nix with "nix-store --verify --check-contents" .

Re: Bottlerocket: An operating system designed for hosting containers

#98

Earlier quoted context omitted.

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

This is possible in nix with "nix-store --verify --check-contents" .

That's different though. that's verification _after_ the fact, whilst dm-verity does it any time during block-level access.

Also an attacker could modify the nix-store sqlite database and spoof the hashes, rendering this check moot

Re: Bottlerocket: An operating system designed for hosting containers

#99
post #34

Opening line from their announcement blog post: >It is safe to say that our industry has decided that containers are now the chosen way to package and scale applications. Curious how the HN community feels about that statement. Not so much about the truth of the statement but about the fact that containers are becoming the de facto method of packaging applications.

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…

> Linux containers are processes with better sandboxing

simply not true: https://github.com/google/gvisor#why-does-gvisor-exist

Re: Bottlerocket: An operating system designed for hosting containers

#100
post #79

Earlier quoted context omitted.

They are using tradicional RPM for packaging. The cargo.toml workspaces relates more to make IMHO.

Wouldn’t something like Bazel make more sense? Using cargo to track inter-dependencies seems a bit weird to be honest.

well it's interesting since they only need to learn the rust toolchain, not something else.
Post reply on HN