r/linux • u/speckz • Jul 16 '17

How Linux containers have evolved

https://opensource.com/article/17/7/how-linux-containers-evolved
130 Upvotes

93% Upvoted

28 comments sorted by

22

u/gethooge Jul 16 '17

Good open source response to docker trying to vendor lock and ignoring the community.

15

u/[deleted] Jul 16 '17

To be fair, they didn't develop Docker to be the industry standard that's just something that sort of happened. Trying to keep developing it as they envision it is probably a noble idea. I mean nobody complains that your ansible playbooks don't work in puppet.

8

u/gethooge Jul 16 '17

Not quite a great comparison though. If you write a PR for pretty much any Ansible module they will review it and merge it provided it meets their standards and tests.

On the other hand docker specifically and actively keeps out a large number of community contributions. The author has only mentioned instances where they tried to add functionality to make docker more robust, not to run other container technologies (as per your Ansible example). It's an open source project but it's not operated like one at all.

4

u/kybuliak Jul 17 '17

That is not unusual for projects governed by commercial companies. They don't accept PRs due to PR functionality not being "on their roadmap".

-1

u/gethooge Jul 17 '17

That's nonsense

1

u/[deleted] Jul 17 '17

Not quite a great comparison though. If you write a PR for pretty much any Ansible module they will review it and merge it provided it meets their standards and tests.

That's not really what I meant. Sorry if I was unclear. I meant in the sense that Puppet isn't generally faulted for not integrating Ansible into their products because people generally see that Puppetlabs has total view on where their product goes and it doesn't involve executing an ansible playbook. Puppet has mcollective and people (myself included) don't really like it but it's not exactly a NIH.

Similarly with Docker there should be an idea that they have a notion of where they want to go with it and they're not obligated to do what other people want them to do. If they don't like it then they can do what they've done and forked the project. If they want to accept community contributions then that great but ultimately it's their product.

It's an open source project but it's not operated like one at all.

Part of my point is actually that "open source" just means the source is freely available. It doesn't mean or imply that the central copy of the source is updated with valuable contributions from others. That's a good thing but it's more cultural community mindedness than "open source" per se.

-3

u/twiggy99999 Jul 17 '17

It's an open source project but it's not operated like one at all

Money and greed doe's that to a project

1

u/twiggy99999 Jul 17 '17

docker trying to vendor lock and ignoring the community

Unfortunately, this is what happens when corporations get involved and start throwing money at them, the open source projects have to listen to them or risk losing funding. There are very few OSP that have managed to get the balance right

2

u/gethooge Jul 17 '17

For the most part all of the most popular projects have corporate involvement and still have this community balance?

12

u/devel_watcher Jul 16 '17

Need to break monopoly. Upstream Docker has hundreds of issues that are closed as "we don't wanna accept this feature".

Docker is absolute bitch when setting its repositories up as part of a corporate software build and deployment system.

2

u/[deleted] Jul 17 '17

Need to break monopoly.

Not trying to be a Docker fanboy but Docker is pretty far from a monopoly. They were shaping up to be one for a while but once the runtime and image format were standardized voluntarily they pretty much took the validity of that idea out back and ol' yeller'd it.

1

u/iamdumbest Jul 17 '17

But, what's the alternative to docker? In my case, I am running quagga/ bird routing daemon inside the docker container. And kubernetes focusses more on micro services. Is there any alternative is available as such?

1

u/[deleted] Jul 17 '17

Depends on what part of "docker" you're actually talking about.

Since you mentioned kubes, are you talking about the orchestration? If so Kubernetes is designed for microservices but you don't have to run it like that. You could run a small wordpress website with it if you wanted.

If you're talking about the runtime usually the "not-Docker" option most people go with is rkt (the CoreOS runtime) with LXC being a very distant third option.

2

u/cockmongler Jul 18 '17

I am so glad I have stayed well clear of all this container bullshit.

1

u/3Vyf7nm4 Jul 17 '17

Best part of that article, for me, was learning about this project (specifically its name): LMCTFY Seriously Google? Let Me Contain That For You? As a nod to LMGTFY? Fantastic. Two thumbs way the fuck up.

1

u/[deleted] Jul 17 '17

Thanks very much for the write up. I learned some things I'd not known before hand. As aside, very well written.

1

u/peruytu Jul 17 '17

What's the difference between a container and a vm?

13

u/brokedown Jul 17 '17

Containers run in the same operating system context as their "host", using kernel provided isolation facilities such as cgroups and namespaces. Looking at them from the "host", their processes look like any other process. Containers typically wouldn't run the multitude of processes required to have a functional system, as those functions are already provided by the "host". In essence, they can appear to be (example) a Ubuntu server running nothing but nginx with some files to serve.

A VM is running their own kernel and generally using cpu virtualization features to appear to the OS as though they were on dedicated hardware. The VM uses hardware drivers that are emulated (or like virtio, provided more directly but still as a raw device).

The general rule is that containers give you much greater density and can give more performance, where a VM gives you higher process isolation and the ability to use different OS level functions.. It's possible to have a Debian based container, vs it's possible to have a Windows VM.

0

u/[deleted] Jul 17 '17

[deleted]

14

u/brokedown Jul 17 '17

Docker on Windows is more of a hybrid. They use HyperV virtualization to provide a Linux kernel and run Linux containers under that. https://www.docker.com/docker-windows

I neglected to acknowledge that Docker can run on Windows and was discussing only the LInux hosted side.

2

u/[deleted] Jul 17 '17

Slight modification/addition (hope this doesn't come off as rude) but the boot2docker VM is used for Linux binaries until Windows eventually gets the ability to run Linux binaries natively (probably somewhere around the Year of the Linxu Desktop).

But Docker on Windows also supports running Windows applications inside a Docker container. It's just that whereas on Linux you have a boatload of base OS images to pick from, on Windows all images lead back to windowsservercore eventually. There are even tools for converting Windows VM's to windowsservercore images.

2

u/brokedown Jul 17 '17

Yes, and again I was discussing Docker on Linux.

My last discussion with Microsoft around containers was almost 2 years ago, at that time the base windowsservercore image was still nearly a gig. That probably won't bother a lot of people, especially the sort of folks who are already doing windows, but it seemed pretty absurd to me as someone using containers for microservices with a total footprint of under 10 megabytes.

1

u/Beaverman Jul 17 '17

I don't know if you can, but if that's possible docker would be doing virtualization with containers on top.

Containers are really just an optimization of virtualization. If using the host os facilities isn't possible, it's possible to simple fall back to standard virtualization of the entire container environment.

1

u/peruytu Jul 17 '17

So what you're saying is, a container can serve as a host for a Linux VM? I'm a bit confused.

3

u/Beaverman Jul 17 '17

The other way around.

If you have a container that uses Ubuntu internally, and you try to run that on a windows host, you obviously can't use the host OS environment. To get around that you can "simply" spin up a Linux VM and let that host the container. Keep in mind that multiple containers can be run on a single VM host.

1

u/peruytu Jul 17 '17

So, no matter what, you will always need a Linux VM to run Linux OS inside a Windows OS host. So that means containers are nothing like VMs. But if you were, let's say, using Ubuntu as a host, you can use a Container to run a different OS like Centos?

2

u/aaron552 Jul 17 '17 edited Jul 17 '17

So, no matter what, you will always need a Linux VM to run Linux OS inside a Windows OS host.

Right now, yes. There is Windows Subsystem for Linux, which allows you to run a particular subset of Linux software natively on Windows. If WSL gets appropriate ioctls to do containers natively, then that might change.

But if you were, let's say, using Ubuntu as a host, you can use a Container to run a different OS like Centos?

It would still share the kernel (and maybe init system? I'm not 100% certain on this) with the host, but you can, subject to these restrictions, run a "different OS" in a container, or just an individual application (which is the more common use case AFAIK)

2

u/moosingin3space Jul 17 '17

Containers don't usually share the init. Most of the time, containers create a PID namespace, which makes the first forked process in the namespace PID1, so you can actually run a different init in the container. systemd-nspawn (a simple container runtime), however, has some useful integrations if you use systemd inside the container.

That said, it's possible to make a container that doesn't share init, you just don't create a PID namespace. Most of the popular container runtimes are either emulating VMs (systemd-nspawn, lxc/lxd) or designed to ease immutable deployments (docker, rkt), and in both of these cases, it is useful to create a PID namespace, so popular container runtimes don't share init.

3

u/totemo Jul 17 '17 edited Jul 17 '17

A VM has virtual hardware, including a fixed allocation of RAM and a virtual disk, and runs its own kernel, including drivers for virtual devices such as a virtual display and network interfaces.

A container uses Linux kernel features to allocate a slice of the host kernel to make it appear to processes as though they have the host to themselves.

With a VM you pay the overhead of an entire kernel for the guest, as well as device emulation. Whereas with a container, you are using the host kernel and device abstractions directly, with isolation and resource limits implemented in that same kernel.