I wish the blog post was just this. So much clearer. Thank you.

Amazon's PR would have not allowed that.

But isn't a "developer advocate" trawling social media for opportunities to dump clarifications also a form of PR? It seems as if data tech has co-evolved the "good cop/bad cop" pattern. I'm not complaining though, so much better than "bad cop" alone.

True, hugs :)

I tried to see any performance characteristics of running bottlerocket, just to understand what the expectations are there. I assume since it was not mentioned it is either similar to Amazon Linux 2 or worse (but with security advantages). Can you request a follow on post on the aws blog that describes the performance impact of Bottlerocket? If performance is better, would be nice to know that as well of course.

AWS-Linux is so slow because of old packages that the new OS is guaranteed to be faster. It has a recent kernel & containerd. Podman would have made it even faster.

Question: Will this be an AMI that can be deployed as an ECS cluster recipient on EC2? End Question.

Yes! It already is in fact. The ECS documentation provides the list of Bottlerocket AMI's you can launch into your ECS clusters: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...

I'd also recommend reading the ECS quickstart in the Bottlerocket repo: https://github.com/bottlerocket-os/bottlerocket/blob/develop...

Well... i'll be modifying some launch configurations then.

Does Fargate use Bottlerocket?

looks like this a beta

Would it be safe to say that bottlerocket is a container host for running containers under a hypervisor? Or is it intended to do full hw interfacing and run bare metal?

Bottlerocket runs containers using containerd, so containers are visible as processes on the host, from its perspective, not currently isolated from each other via a hypervisor. Bottlerocket limits containers ability to interact with the host or each other via SELinux, among other things.

We do have firecracker-containerd (https://github.com/firecracker-microvm/firecracker-container...) which is designed to allow the containerd runtime to launch containers as microVMs via Firecracker, with that additional layer of isolation via the KVM hypervisor. This stack is not currently fully compatible with K8s or ECS though, so it is not implemented using that approach yet. Rather Bottlerocket is built as a progressive improvement on the current state of container hosts, which is that many people are running all their containers on their hosts without any strong security hardening at all.

I think from the similar naming scheme of Firecracker and Bottlerocket you can already see the pieces of the puzzle that are in progress and the future potential though.

Thanks, I was more wondering what the relationship was between something like Debian GNU/linux and bottlerocket. From gp description it sounds like there's no "GNU userland", just the Linux kernel and some utility functions in rust - enough to launch containerd.

So if I have a heterogeneous collection of servers - I could install Debian, and run docker on Debian. It sounds like bottlerocket would more comfortably run on top of a hypervisor abstracting away the actual hw a bit? Eg on top of xen, kvm or VMware?

Obviously the Linux kernel can be made to run on a toaster, but maybe bottlerocket isn't ideal for that purpose?

Answering your initial question and this one: Bottlerocket today only runs in EC2, but we've tried to make it flexible enough to run outside of a hypervisor on bare metal in the future (in fact, a few engineers on the team are really excited to get it running on their RaspberryPi's at home; toasters haven't been added to our roadmap yet ;) ).

Bottlerocket has a GNU userland like many other distros. It is just one that is stripped down of many things including removal of interpreters, shells, and package managers.

If you want to explore more deeply, you can enable the admin container and jump into a shell on the host[1] to look at the filesystem and see what Bottlerocket's userspace looks like up close and personal. You can also see a bit more of this debugging/exploration tooling explained in an AWS Partner Blog[2].

[1] https://github.com/bottlerocket-os/bottlerocket#admin-contai... [2] https://aws.amazon.com/blogs/apn/getting-started-with-bottle...

I just installed Proxmox on a home server, and I’m using its CT containers (LXC) to run various services. Could I use this as a replacement for Proxmox?

Nope. Proxmox is mostly just an administrative UI, containers are a Linux feature. You don't need Proxmox for anything, you can just run containers "natively" in Linux or VMs with KVM + QEMU. The linked above is mostly just a Linux distro geared towards a pretty specific set of use-cases.

I read that this is more intended as the VM you run inside Proxmox, that you then run your (docker/k8) containers inside.

Isn't it somewhat similar in concept to the Container-Optimized OS that is being offered by GCP ?

> Bottlerocket is optimized for running containers with high security isolation. The host OS is extremely minimal, it does not come with bash, an interpreter, ssh, or anything beyond the system basics needed to run containers. In fact it uses an immutable root filesystem. You aren't intended to run or install things directly on the host at all.Bottlerocket is optimized for running containers with high security isolation. The host OS is extremely minimal, it does not come with bash, an interpreter, ssh, or anything beyond the system basics needed to run containers. In fact it uses an immutable root filesystem. You aren't intended to run or install things directly on the host at all.

Sounds exactly like Qubes OS [0], but the latter is probably much more secure (based on Xen and VT-d). So in comparison Bottlerocket seems like trading some of security for performance.

[0] https://qubes-os.org

Qubes is for end user desktop/laptop usage, not service hosting.

Not yet for service hosting: https://www.qubes-os.org/news/2018/01/22/qubes-air/

Could bottlerocket be the basis for desktop system where it would be easy to switch between isolated environments? It would be very handy to have a maximally secure environment, at least from software perspective, for certain operations.

You may want to look into Qubes. It's not specifically designed for running containers like this is, but it does provide a single OS with multiple isolated environments for different programs.

As _underfl0w_ said, you're pretty much describing Qubes. Using it can be eye opening--nothing works together unless you let it, which is a good way to get a feel for your attack surface / unknown dependencies.

Qubes uses VM's. Subgraph OS is another option. It tries to achieve the same thing with containers, but their latest release is pretty old--not sure how alive that project is.

In the intended anyone, anywhere (specifically you wrote outside AWS) scenario you describe, is AWS offering professional support for Bottlerocket?

Hi - Does bottlerocket use glibc or something else?

As you can see here https://github.com/bottlerocket-os/bottlerocket/tree/develop..., Bottlerocket uses glibc.

So did every other vendor. We have two CoreOSes, Flatcar, Container-Optimized OS from Google, Bottlerocket, k3OS, etc. Fortunately these aren't just different in name; there's a lot of experimentation going on around different ways to do updates, security, etc. I hope we'll eventually see some convergence after a few years.

Two CoreOSes? The one being Fedora CoreOS and the other..?

Fedora CoreOS and RHEL CoreOS.

Dead :)

You mean, the CoreOS that was end-of-lifed four months ago?

CoreOS lives on as Flatcar Container Linux. https://twitter.com/kelseyhightower/status/12831024012520980... It's a fully-compatible, drop-in replacement.

At least "Fedora CoreOS" still seems to be a thing.

And Red Hat Core OS (RHCOS) for Red Hat flavored shops.

Red Hat bought the company that created CoreOS so it's not surprising they have Red Hat/Fedora supported versions right?

Yep, very much agree. Container Linux was still very young and growing, but had some great promise. Incorporating the tech into RHEL and Fedora was a great idea IMHO. I think CoreOS was acquired for that specific purpose personally.

Not sure. To me Flatcar brings the original CoreOS spirit..

I'm not able to find concrete examples of the differences between Flatcar and Fedora CoreOS aside from FCOS using rpm-ostree.

What are the differences especially regarding their spirit and philosophy?

I don't think. Fedora CoreOS is more coupled to be an OpenShift node than a plain Container/K8s node. it's sad what they did. And I was a Fedora user for my whole life, but that made me reconsider.