Hi I'm a developer advocate in the container engineering org at AWS. I think there are a few misunderstandings here that I may be able to explain better.

First Bottlerocket is not Amazon Linux 2, it is its own minimal operating system, with most components built from the ground up in Rust. This is totally different than the Amazon Linux 2 you may be familiar with (and most other operating systems for that matter). 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.

Everything that is installed and runs on Bottlerocket runs as containers, which are kept isolated from each other and the host with best practice security features such as SELinux. For example you can connect to a container on the host via AWS Systems Manager, or you can optionally enable a container that lets you connect to it via SSH. Once again the thing you are connecting to is the container on the host though, not directly to the host.

For this initial release of Bottlerocket we are focusing on providing image variants that are prepackaged with the requirements to serve as underlying container hosts for an ECS or EKS cluster. However we also intend Bottlerocket to eventually be something that anyone can use, anywhere, even outside of AWS, if they wanted to benefit from the secure by default, container first design of Bottlerocket.

You can read more about the security features of Bottlerocket here: https://github.com/bottlerocket-os/bottlerocket/blob/develop...

And you can find a bit more of the charter / goals for the project here: https://github.com/bottlerocket-os/bottlerocket/blob/develop...

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.

If you're using an ECS or EKS Cluster, you still have to run some operating system on the ECS Container Instances. The containers have to run somewhere.

There are a variety of options currently, including one from Amazon, but Bottlerocket seems designed to be a next-generation OS for container instances. It's extremely minimal, and designed to be as secure as possible, with transactional automatic updates.

Ideally, I would just deploy Bottlerocket as the underlying OS on my ECS Cluster, and then never have to actually do any management of the Instance OSes whatsoever. I would deploy containers on top of my ECS Cluster, Bottlerocket would keep itself up to date and secure, and my containers would live happily ever after. It would hopefully feel more similar to using Fargate than not, except without paying the higher price for Fargate, and having access to the wider variety of hardware configurations available to regular ECS.

Amazon has specifically said this in the Bottlerocket repo:

> Bottlerocket is architected such that different cloud environments and container orchestrators can be supported in the future.

It's mainly useful in concert with ECS or EKS right now, but it is architected to be useful in other places as well.

I'm excited about Bottlerocket as a project, and I'm glad it's open source instead of just an opaque AMI that you can use on ECS or EKS.

> It's mainly useful in concert with ECS or EKS right now, but it is architected to be useful in other places as well.

Right, this is the big question. If a community forms to support Bottlerocket off of AWS, then that's one thing, but until then, it basically just seems like a better option for ECS or EKS.

>>> I'm not entirely sure who they built it for, except as a foundational component for AWS's managed offerings.

>> <snip>

> If a community forms to support Bottlerocket off of AWS, then that's one thing, but until then, it basically just seems like a better option for ECS or EKS.

I'm failing to see why that's a problem or a source of confusion. There's a clearly defined market of "who they built it for", and there's a community option to expand Bottlerocket's target market.

The code is open source, so anyone could fork Bottlerocket and modify it to suit their needs immediately. Will Bottlerocket see success beyond ECS and EKS? Only time will tell... literally no one knows yet.

> If you're using an ECS or EKS Cluster, you still have to run some operating system on the ECS Container Instances. The containers have to run somewhere.

Forgetting Fargate there?

I literally mentioned Fargate in the same comment:

>> It would hopefully feel more similar to using Fargate than not, except without paying the higher price for Fargate, and having access to the wider variety of hardware configurations available to regular ECS.

If you're using an ECS Fargate Cluster or EKS Fargate Cluster, I don't consider those the same as an ECS Cluster or EKS Cluster. Unfortunately, there's no specific term commonly used for non-Fargate Clusters that I know of. AWS offers ECS Clusters and ECS Fargate Clusters.

If you were legitimately confused by my comment, I’m sorry. I could have said "non-Fargate" repeatedly, if it would have helped, but I thought the context made things clear, especially with the additional explicit mention of Fargate as a separate thing.

I refer to it as fargate compute or ec2 compute. It’s not a cluster level thing, you can have clusters with both fargate and ec2 for your compute.

Like most of the rest of AWS product people and AWS users do, IME.

There are varying levels of lock-in. A Linux distribution to run containers is a lot easier to replace than, say, a database with a proprietary query language custom semantics.

>sure who they built it for

Anytime AWS finds many of its customers using something outside of AWS, they want to build it in-house. AWS customers were using CoreOS a lot, hence this.