Live data from Hacker News

Bottlerocket, an open source Linux distribution built to run containers

aws.amazon.com

81–90 of 135 posts

Re: Bottlerocket, an open source Linux distribution built to run containers

#81
post #55

Earlier quoted context omitted.

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). Bo…

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.

Re: Bottlerocket, an open source Linux distribution built to run containers

#82

Earlier quoted context omitted.

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

looks like this a beta

Re: Bottlerocket, an open source Linux distribution built to run containers

#84
post #60

Earlier quoted context omitted.

This stuff is probably waaaay over my head, but isn't that why SIGTERM was made for ? To notify a running process that the host needs to be shutdown/restarted and to let the running process finish it's current task (current frame encoding / current multiplayer game / current request / ...) and that the state / cache / progress / ... needs to be saved. The process on aws side would then be : send SIGTERM to all worklo…

Yep you are right about SIGTERM, but let's think back to the original reason why we wanted to update the node: because of a patch, probably a security patch for a CVE? What is the better option here? Implement a SIGTERM based process that allows the user to block the patch for a critical, possibly zero-day CVE for xx hours, remaining in a vulnerable state the entire time? Or implement a system that just patches the u…

If there's a CVE vulnerability that is being actively exploited on your network, you should preempt running processes to deal with it, and absolutely must take the boot+nuke approach, because it already could be affecting any host that has not already been boot+nuked?

If there's not a CVE, AWS can significantly manage the lifecycle of their machines, and have ~5% of all of their machines "unschedulable" at any one time, waiting for existing processes to complete so that they may use an orderly restart before doing a boot+nuke. A SLA of "Tasks may never run longer than X days"(x=10-30) allows them to perform orderly restarts.

Re: Bottlerocket, an open source Linux distribution built to run containers

#86

So, is this available as an ISO? I currently run an Ubuntu VM in bhyve on my FreeNAS home-server to host various containers for experiments, etc... could I run this instead or is it tied to AWS?

It isn't today, but we've built Bottlerocket in a way that it can be extended to work on bare metal or other places outside of AWS. There are a few issues on our github[1][2] that are similar that you're welcome to watch or contribute use cases to.

[1] https://github.com/bottlerocket-os/bottlerocket/issues/841 [2] https://github.com/bottlerocket-os/bottlerocket/issues/1097

Re: Bottlerocket, an open source Linux distribution built to run containers

#87

Earlier quoted context omitted.

Rancher has been around a long time and isn't cloud-specific. Until this distro can prove itself useful outside of the AWS ecosystem, then Rancher will still dominate.

Bottlerocket seems more like a competitor to RancherOS, which is abandonware. ( https://github.com/rancher/os/issues/3000 ) I liked RancherOS's very few moving parts approach (even your shell is a Docker container). Hope Bottlerocket will be somewhat similar.

I don't see any confirmation based on that link that it is abandoned. There was an update in June.

Re: Bottlerocket, an open source Linux distribution built to run containers

#88

Earlier quoted context omitted.

I agree with you. This seems more complex than just having a auto scale group that auto rotates nodes after a certain amount of time and just picking a new update when the node launches.

I can provide a little background on this. In general yes I would recommend that you just use an ASG and roll out a new AMI. However that approach can be very expensive and time-consuming at truly massive scale (1000's or even 10's of thousands of machines). Bottlerocket is built in part based on our experiences operating AWS Fargate, which obviously has as one of its needs the ability to patch a colossal number of h…

A little confused, you say you don't want to disrupt the containers, but https://github.com/bottlerocket-os/bottlerocket#updates seems to indicate you still have to reboot for the update to take hold?

Re: Bottlerocket, an open source Linux distribution built to run containers

#89
post #33

I'm confused about how the documentation recommends using a Kubernetes operator to manage OS updates. That seems weird and backwards to me. I would rather see an immutable OS AMI in an auto-scaled group, and just replace the node instance whenever there is an update. I can see a place for managing OS updates on an instance, but that seems more like "pets" than "cattle"... and I've always treated Kubernetes nodes like…

We use 5000+ CoreOS nodes in production and never want to go back to replacing VMs with new images for each update again. In-place immutable updates are more efficient and faster. Unlike RPM based OSes that are hard to patch, transactional updates provide a safe way to perform safe in-place updates instead of wasteful operations such as replacing full VMs for small OS updates.

As a former CoreOS (now Red Hat) employee, I'm glad to hear of your success with the product and it's awesome to see that scale giving you time back in your day to concentrate on the big picture.
Post reply on HN