Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bottlerocket: An operating system designed for hosting containers

github.com

Post reply on HN
Print view View original

101–110 of 121 posts

Re: Bottlerocket: An operating system designed for hosting containers

#101

Post by dirtydroog »

StreamBright wrote: post #91
nstart wrote: 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 contain…

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

Hallelujah! I'd imagine inefficient containered architectures do more for the cloud provider's bottom line rather than help the customer.

Re: Bottlerocket: An operating system designed for hosting containers

#102

Post by AnIdiotOnTheNet »

nstart wrote: 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.

It's about damn time? I, for one, do not like having to deal with shared library hell, conflicts, and compiling from source because some unpaid repo maintainer is responsible for integrating code into my system. Not to mention the security enhancements.

The only thing that would make them better is if we stopped over-complicating them and made them portable [0].

[0] As in, could be moved to different disks and run from there without a bunch of hoop-jumping.

Re: Bottlerocket: An operating system designed for hosting containers

#103

Post by AnIdiotOnTheNet »

zokier wrote: post #62
unlinked_dll wrote: post #60

Earlier quoted context omitted.

You need to prefix "applications" with "web" or "cloud."

Flatpaks and snaps, while maybe not as popular, are also containers

Unfortunately, they're over-complicated as a means of application packaging and distribution, at least in my opinion.

Now AppImage, that's pretty great. It doesn't really bring any of the security benefits of containerization, but that can be tacked on separately.

Re: Bottlerocket: An operating system designed for hosting containers

#104

Post by jhaynes »

bogomipz wrote: post #90
jhaynes wrote: post #6

Earlier quoted context omitted.

While our first variant is focused on Kubernetes and EKS, we have designed Bottlerocket in a way that new variants can be built that work with other orchestrators, or even without one (we have ECS support on our roadmap already). Also, we really enjoyed working in Rust for big chunks of this!

>"While our first variant is focused on Kubernetes and EKS..." So is the idea that people create a Bottlerocket AMI and use that as their EKS worker node images? Is that correct?

Correct! Or you can spin up one of the AMIs we've already built. You can find current AMIs via public SSM parameters: https://github.com/bottlerocket-os/bottlerocket/blob/develop...

Re: Bottlerocket: An operating system designed for hosting containers

#106

Post by antonvs »

unlinked_dll wrote: post #60
nstart wrote: 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.

You need to prefix "applications" with "web" or "cloud."

Unless you want to roll the traditional telecom industry under the "web" or "cloud" label, you have to add "telecom" to the list as well.

Containers have been gaining ground in telecoms since at least 2015 (https://www.sdxcentral.com/articles/analysis/telecom-opens-u...). Network function virtualization solutions rely increasingly on containers.

Re: Bottlerocket: An operating system designed for hosting containers

#107

Post by bbgm »

dang wrote: post #69
bbgm wrote: post #30

I am from AWS. Could we please change the title to say “Bottlerocket from AWS“. Like Firecracker [1] it’s explicitly not AWS branded. 1. https://github.com/firecracker-microvm/firecracker

"Bottlerocket from AWS" sounds like a commercial. I've just taken AWS out of the title above.

That makes sense. Thanks a ton

Re: Bottlerocket: An operating system designed for hosting containers

#108

Post by hardwaresofton »

merb wrote: post #99
hardwaresofton wrote: post #67

Earlier quoted context omitted.

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

The word "sandbox" is a bad choice -- "isolation and resource limiting" might have been a better term to use, but the idea that containerization does not sandbox at all is not a fair characterization.

It's not a good sandbox, but if we are pedantic about the definition of a sandbox, it fits, especially when we think of the benefits of namespacing (effectively removing access to resources like networks, filesystems, etc).

gVisor is a more focused on sandboxing processes specifically, so it's relevant but gVisor is not relevant to the wider discussion about a packaging format -- unless you're suggesting to run gvisor'd processes instead of containerized ones and containerization is still beneficial in that scenario.

Re: Bottlerocket: An operating system designed for hosting containers

#109

Post by AnIdiotOnTheNet »

ajxs wrote: post #32

This is somewhat false advertising. This is not an operating system in the sense of being a new kernel. It looks like it's a set of build tools for building a Linux distribution.

Sadly that plane sailed about 15 years ago when everyone who made a new Linux distribution decided to call it an OS.

Re: Bottlerocket: An operating system designed for hosting containers

#110

Post by jpeeler »

It looks like this supports automated updates within a specific time window, but it's not clear to me how the "waves" are defined. (Note that this is something that is currently lacking in Fedora CoreOS: https://github.com/coreos/zincati/issues/34.)

I do wonder if the dual partition approach was deemed more stable than using OSTree or why the latter wasn't used.

Post reply on HN