The Curious Case of Linux Containers • Hacker News Board

Re: The Curious Case of Linux Containers

#11

Post by gingerlime » Sat, Dec 05, 2015, 10:46 PM UTC

> Did you know that even with all the advances with technology the amount of time that a housewife spends maintaining a household today is the exact same as it was in the 1950s!

Unrelated to the core of the article, I know. But it seemed odd to me. Is this true? Or was it a metaphor?

EDIT: did a bit of googling and found a couple[0][1] of not-extremely-academic references that claim that it's less than half... but couldn't find anything more authoritative.

[0] http://www.telegraph.co.uk/women/womens-life/9721147/Women-s...

[1] https://www.anglianhome.co.uk/50years

Re: The Curious Case of Linux Containers

#12

Post by contingencies » Sat, Dec 05, 2015, 11:03 PM UTC

tobbyb wrote: post #7

What I find curious about all the container discussions and narrative is the strange lack of context. Sure discuss Docker but also discuss namespaces, cgroups, overlayfs, aufs, and all the other critical enabling technologies where a lot of major problems with containers exist and will be solved. For instance user namespaces, cgroups are not namespace aware, how to integrate overlayfs or aufs so they can be mounted b…

LXC containers which have a normal init

Incorrect. You can do custom application (eg. single-process) or init-based containers with LXC.

Re: The Curious Case of Linux Containers

#13

Post by powera » Sat, Dec 05, 2015, 11:03 PM UTC

"Also be warned — I have no idea what I’m talking about. Take everything in this article with a grain of salt." - pretty much. I'm not sure whether the author thinks "platforms" even are. And the complaints that "linux cgroups aren't the entire platform so why call it containers" seem pedantic.

I don't see why "handling MySQL failover", "resource management", "upgrading OpenSSL" should all be handled by the same piece of software in any case.

Re: The Curious Case of Linux Containers

#14

Post by shykes » Sat, Dec 05, 2015, 11:05 PM UTC

icebraining wrote: post #9

tobbyb wrote: post #7

What I find curious about all the container discussions and narrative is the strange lack of context. Sure discuss Docker but also discuss namespaces, cgroups, overlayfs, aufs, and all the other critical enabling technologies where a lot of major problems with containers exist and will be solved. For instance user namespaces, cgroups are not namespace aware, how to integrate overlayfs or aufs so they can be mounted b…

Docker chooses to run containers without an init. I don't think Docker chooses one way or the other, and people do run Docker with an init: http://phusion.github.io/baseimage-docker/

Correct, Docker doesn't care what you run inside the container. You provide a command to run, and it runs it. That command may be your application server or a traditional init process which in turn will fork multiple children.

Docker does make it easier to follow an "application container" pattern, and that pattern avoids (with good reason) booting an entire traditional init system inside the container. But following that pattern is not mandatory. Not forcing too many patterns upon users all at once was part of the original Docker philosophy. Unfortunately that aspect was drowned in the cacophony as a few loud and passionate people interpreted Docker through the lens of their own favorite patterns.

In retrospect I wish we had been more assertive in reminding everyone to respect the philosophy behind Docker: that you can share tools with people without forcing everyone to use them in the same way as you.

Re: The Curious Case of Linux Containers

#15

Post by krakensden » Sun, Dec 06, 2015, 12:41 AM UTC

icebraining wrote: post #9

tobbyb wrote: post #7

What I find curious about all the container discussions and narrative is the strange lack of context. Sure discuss Docker but also discuss namespaces, cgroups, overlayfs, aufs, and all the other critical enabling technologies where a lot of major problems with containers exist and will be solved. For instance user namespaces, cgroups are not namespace aware, how to integrate overlayfs or aufs so they can be mounted b…

Docker chooses to run containers without an init. I don't think Docker chooses one way or the other, and people do run Docker with an init: http://phusion.github.io/baseimage-docker/

Prominent Docker, Inc., employees have spent years arguing against it, and they don't prioritize bugs around that use case. Which matters.

Re: The Curious Case of Linux Containers

#16

Post by joombaga » Sun, Dec 06, 2015, 12:54 AM UTC

digi_owl wrote: post #10

tobbyb wrote: post #7

What I find curious about all the container discussions and narrative is the strange lack of context. Sure discuss Docker but also discuss namespaces, cgroups, overlayfs, aufs, and all the other critical enabling technologies where a lot of major problems with containers exist and will be solved. For instance user namespaces, cgroups are not namespace aware, how to integrate overlayfs or aufs so they can be mounted b…

> Docker chooses to run containers without an init. The big problem here is most if not all apps you want to run in a container are not designed to work in an init less environment and require daemons, services, logging, cron and when run beyond a single host, ssh and agents. Do this not confuse init with a process supervisor?

A process supervisor (foreman, monit, etc. ) is just one of the things an init system starts. The set of items you want to ensure are always running isn't usually the same as the set of items you want to start with the system.

Re: The Curious Case of Linux Containers

#17

Post by davexunit » Sun, Dec 06, 2015, 1:22 AM UTC

tobbyb wrote: post #7

What I find curious about all the container discussions and narrative is the strange lack of context. Sure discuss Docker but also discuss namespaces, cgroups, overlayfs, aufs, and all the other critical enabling technologies where a lot of major problems with containers exist and will be solved. For instance user namespaces, cgroups are not namespace aware, how to integrate overlayfs or aufs so they can be mounted b…

Overlayfs, aufs, etc. are really irrelevant to containers. They are used in Docker because it's built around opaque binary disk images that do not compose, which I believe is a big flaw, but it doesn't have to be this way. For example, GNU Guix has a container implementation that does not use disk images at all but still achieves system-wide deduplication of software across all containers running on the host via simple bind mounts.

Re: The Curious Case of Linux Containers

#18

Post by iheartmemcache » Sun, Dec 06, 2015, 1:25 AM UTC

sumbry wrote: post #8

tinco wrote: post #2

We solve all of those use cases in our cluster management system of which Docker is a key enabling component, except for point 5, though we do have other components that require multiple steps to provision. I bet we could run Hadoop if we needed it. It's easy to point at Docker and say it's a trivial wrapper around some technologies that have been around for years and call everyone crazy for buying into the 'Docker i…

Someone once said that the public cloud was never about virtualization but rather automation. I would contend that the container revolution we're going through now isn't really about containers but ultimately distributed system platforms. And if it changes the way many have traditionally approached problems great! My main point is that we're really just at the beginning of all of this. I'm not picking on Docker (I'm…

Ha you weren't kidding about the number of HA MySQL drop-in engine replacements out there, damn. At least most people follow the ANSI-SQL standard, which is something.

I'm not being snarky, but what are the use-cases that everyone have? I'd argue authentication and authorization would be one of the few things, and it was already solved with JSR 196 like 15 years ago. It worked, had a well defined spec, and most importantly it had interop with PAM on UNIX, Kerberos, LDAP, raw db's, mixed mode, you name it. Everyone complained it was too enterprisey and no one used it, so they re-invented the wheel in the early 00s with Rails and Devise and Authlogic and a billion other non-standards. Transactions? Persistence? Java's spec took care of that too, and fairly rigorously. So I'm with 100% with you on this being a solved problem.

We're making gradual progress (i.e., the option to develop in a language where the correctness of our code can be formally verified thanks to more readily available, mathematically sound type-systems) but like any society there are trends, and where there are trends you'll have the recurrence of many old things (Interpol ripping off Joy Division) and the invention of a few new things (where are often the composition of two older ideas, or the implementation of a new idea which wasn't computationally feasible previously but now is, or a concept from another industry like signal analysis or three-phase road traffic theory applied to our code-monkey'ing domain).

RE: Overall progress - Microsoft is doing some fantastic things in Powershell, effectively taking concepts like package management, man pages, and the shell, extracting the best elements from each of those, and implementing them in a consistent manner. No more choosing between systemd or init.d or other holy wars. If you want to do it differently, you effectively have a standardized interface to write your new implementation against within most of the platform. Don't like ASP.NET's templating system? No problem, it's all open source, and you can swap your own in, but it's all modular so nothing will break, and your co-workers can continue working in the traditional Razor templating.

Re: The Curious Case of Linux Containers

#19

Post by contingencies » Sun, Dec 06, 2015, 2:26 AM UTC

The author's 'platform' concerns are in fact infrastructure automation concerns generic to any service-oriented architecture and not specific to containers.

My take as an early LXC adopter (way pre docker) and from-concept builder of two production clusters using custom automation:

1. Service state. The author essentially requests master-slave promotion. Corosync/pacemaker is an excellent place to look for well tested solutions here. The normal approach used there is superior to the author's, ie. a floating IP used by all clients is switched to an already live replacement master, which is first jabbed in to action, and which shares the same backing storage as the nodes which has failed. (A great solution for shared backing storage on standard hardware is DRBD)

2. MySQL update. Change management with SOA has to be far more rigid due to complex interdependencies. Typically you version your entire service, exhaustively test it against peer services, and only then deploy the updated service. This implies a workflow process more formalized than the series of manual operations the author hand-waves about. That said, in a typical database scenario it is often possible to upgrade across minor versions simply by updating the binary, since it will read the old on-disk database store fine.

3. Heartbleed. With an appropriately automated approach to service builds, this should be trivial. Mask the affected packages or versions, rebuild all services, test and deploy. This really goes back again to overall workflow formalization and automation. (Solid infrastructure would have cryptographic signoff on stuff before it runs, eg. production demands a signature from test infrastructure that all tests have passed before executing a new service)

4. Service dependencies. This is far more complex than people assume. My advice is to use corosync/pacemaker, a well tested approach. (There are others)

5. Hadoop. Same as any other service.

There are many other problems with SOA-type infrastructure automation; some ideas I wrote up ages ago can be seen at http://stani.sh/walter/pfcts/ as well as the sketch/documentation of the solution I built.

Re: The Curious Case of Linux Containers

#20

Post by ketralnis » Sun, Dec 06, 2015, 3:34 AM UTC

anotherhue wrote: post #3

Many of the author's desires are handled in SmartOS ( https://www.joyent.com/blog/triton-docker-and-the-best-of-al... )

Totally agreed. I don't like Docker but I do like both SmartOS and FreeBSD jails. If you're even somewhat interested in containers you need to take a look at SmartOS (I liked http://timboudreau.com/blog/smartos/read as an approachable "getting started") and FreeBSD jails (https://www.freebsd.org/doc/handbook/jails.html). For Jails I like ezjail and iocage as good wrappers so you may want to start there. You can't have a coherent opinion on the technology if you haven't seen how other people are doing it.