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

Containers vs. Zones vs. Jails vs. VMs (2017)

blog.jessfraz.com

Post reply on HN
Print view View original

41–50 of 134 posts

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#41

Post by nurpax »

mulmen wrote: post #7
outworlder wrote: post #4

> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…

I think it is widespread because containers are (seemingly) marketed as being some kind of magic. The impression I get is that the benefit to containers is that you don't have to think about them. This may be more a product of Docker but I think containers and Docker have become synonymous. I'm not sure this is a fair comparison but that is my impression. I could be in a bubble too.

I’d like to think so too. It’s hard to actually understand how Docker works by reading their documentation.

Everything looks so simple.. and it magically runs on macOS and Windows too. No wonder people think it’s some sort of a VM.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#42

Post by cortesoft »

outworlder wrote: post #4

> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…

Part of it might be that many developers target linux but code on a mac... and on a mac, docker containers DO run in a VM.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#43

Post by lmm »

wmf wrote: post #6
outworlder wrote: post #4

> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…

People love to bring this up, but if Linux did have first-class containers, how would the developer's experience be different?

There would maybe be more consistency. E.g. currently if I say an application is running in a container, do you expect there is virtual networking in place, or not?

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#44

Post by Thaxll »

outworlder wrote: post #4

> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…

Overhead is close to 0.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#45

Post by Disposition »

aprdm wrote: post #38
MuffinFlavored wrote: post #31

Earlier quoted context omitted.

> A sizable fraction will be concerned about 'container overhead' (and "scalability issues") when asked to move workloads to containers. They are usually not able to explain what the overhead would be, and what could potentially be causing it. For what it's worth, one of the biggest "containerization" recommendations is to not run your database (example: Postgres) in a container, correct? Due to I/O performance decre…

I think it is more because containers should be stateless and you cannot make a database stateless. We do run databases that do 100k`s ops/s in containers but we don't run them in kubernetes. We just mount the VM hard drive in it.

A DB container may and should be stateless, but when configured correctly the volumes specific to the storage engine are persistent. I've been running production databases in Docker since 2014 without any data loss, it makes a lot of system-level administrative work much easier.

With a healthy understanding of how the individual storage engines commit to disk, upgrading, backing up, etc. can be done in parallel and without impact to a running production system thanks to the power of overlayfs.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#46

Post by Harlekuin »

CBLT wrote: post #29
outworlder wrote: post #4

> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…

> To this day, I've heard CGroups being mentioned only once. See https://www.kernel.org/doc/Documentation/cgroup-v2.txt > "cgroup" stands for "control group" and is never capitalized. The singular form is used to designate the whole feature and also as a qualifier as in "cgroup controllers". When explicitly referring to multiple individual control groups, the plural form "cgroups" is used. To this day, I've heard cgr…

> everybody has a layer of abstraction they do not peek under

Reminds of this xkcd: https://xkcd.com/435/

The beauty of programming is abstraction - you write a function to do one thing, do it well, and then you can abstract that concept away and reuse that abstraction. Although it's only an abstraction - a container is "like" a lightweight VM, and you can use it like that until it doesn't act like a lightweight VM. In which case, you have to dabble one layer deeper just to understand enough to know why the abstraction of your layer isn't a perfect analogy.

In which case, if you're looking for an expert in layer n, then basic knowledge of layer n - 1 might be a decent proxy for expertise

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#47

Post by xelxebar »

CBLT wrote: post #29
outworlder wrote: post #4

> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…

> To this day, I've heard CGroups being mentioned only once. See https://www.kernel.org/doc/Documentation/cgroup-v2.txt > "cgroup" stands for "control group" and is never capitalized. The singular form is used to designate the whole feature and also as a qualifier as in "cgroup controllers". When explicitly referring to multiple individual control groups, the plural form "cgroups" is used. To this day, I've heard cgr…

> To put forth a more substantive argument, everybody has a layer of abstraction they do not peek under.

Sure. Though it's reasonable to want your level N developers to have some idea of what goes on at levels N-1 and perhaps N-2, cf. Law of Leaky Abstractions etc. It's similar to wanting your developers to be aware of their users' needs, which are level N+1 concerns.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#48

Post by potta_coffee »

dielectrikboog wrote: post #18
icedchai wrote: post #16

Earlier quoted context omitted.

Most "DevOps" folks I know are actually former sysadmins who evolved to work more with cloud technologies. To say sysadmin hasn't evolved in a bit of an exaggeration. Titles follow the trend. What people actually do is often similar.

No, it isn’t an exaggeration. They ceded one particular competency, systems administrator, and now pay cloud providers to do it instead. The job didn’t go anywhere. Capacity planning, change management, peering, supply chain management, all of that stuff is still happening, they just willingly tapped out of it and took another job (probably because the DevOps people came in with a slide deck and hand waved them out o…

As a developer, I'm not happy about it either. I'm now expected to write code, as fast as possible, and then handle all the ops / sysadmin tasks too, which I don't enjoy and am not really equipped to handle.

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#49

Post by tyingq »

outworlder wrote: post #4

> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…

Have them look at bocker (docker-like in ~100 lines of bash).

It makes it very clear what docker is, and isn't.

https://github.com/p8952/bocker

Specifically, the bocker_run function: https://github.com/p8952/bocker/blob/master/bocker#L61

Re: Containers vs. Zones vs. Jails vs. VMs (2017)

#50

Post by mav3rick »

matharmin wrote: post #11
outworlder wrote: post #4

> A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. Amen. Somewhat tangential note: most developers I have met do not understand what a 'container' is. There's an aura of magic and mystique around them. And a heavy emphasis on Docker. A sizable fraction will be concerned about 'container overhead' (a…

I feel nowadays containers generally refer to the concept, and cgroups and namespaces are the implementation details of a specific container runtime. These are very important implementation details for security and performance, but it doesn't fundamentally impact how you structure your containerized application. You can take the same container image, and run using Docker, Firecracker, gVisor, or many other container…

Please don't propagate this. Running in a hypervisor with a possible different kernel vs running on the same kernel in the same ring as the host are two very different things. Implications of these are very different.
Post reply on HN