Hacker News Reader

Comment by whalesalad | Hacker News Reader

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

View on HN

> To improve security, there's no SSH server in a Bottlerocket image, and not even a shell.

Consider my interest to be piqued.

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

https://github.com/coreos/fedora-coreos-tracker has some activity, but it's far from robust.

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.

No, let's pay a premium and lock ourselves into a trillion dollars company's last day project instead :-)

There is MicroOS from openSUSE: https://en.opensuse.org/Kubic:MicroOS

https://www.flatcar-linux.org/

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?

Unlikely, I'd say. If you fail to upgrade when a new release is made, are they at fault?

You'd need to look towards providers that specifically take on more responsibility like https://compliantkubernetes.com/ (disclaimer: I have worked at Elastisys, the company behind Compliant Kubernetes).

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.

Thanks!

I miss the part where it explains how it works. Is it all just containers?

It's buried a bit in the GitHub docs, but it looks like it runs two containerds. One is for Kubernetes. The other is for running administrative containers, including the API server for normal interaction with the host, a server that implements AWS's remote command protocol (enabled by default), and a container that runs sshd (disabled by default).

Packages are built with RPM but RPM isn't used at runtime. Instead, the system is image-based and reboots for updates.

I'm really sad that my comment was removed, not even the usual [flagged] edit can be seeing anymore.

Reply on news.ycombinator.com