Containers in 2019: They're Calling It a Hypervisor Comeback

https://www.infoq.com/articles/containers-hypervisors-2019/

by ingve • 7 years ago

201 192 7 years ago

infoq.com

pjmlp5• 7 years ago

Just waiting for the new re-discovery of hypervisors, but with better marketing names.

pojntfx• 7 years ago

"Workload Orchestrators"

K8s can already do VMs with Kube-virt, so yeah.

tyingq• 7 years ago

K8S is unnecessarily complicated. I fully expect "serverless", warts and all, to take all comers. And, I get the irony. It's basically cgi-bin 2.0. It will win not because it is better, but because it is better "understood".

panpanna7• 7 years ago

Bare-metal containers.

No, that was even worse.

ahartmetz2• 7 years ago

Serverless servers?

PopeDotNinja• 7 years ago

Federated subsystem authoritator

hinkley2• 7 years ago

And let me state again for the record that all of these promises being made by container systems sound an awful lot like the promises I was offered by 'real' operating systems in the early nineties.

I think the only real difference is that there has been a sea change in public opinion on this kind of aggressive isolation by default being worthwhile.

But a hypervisor publishing a bunch of services that talk to the world and each other? Things are beginning to look a bit more like microkernels as time goes on.

BiteCode_dev• 7 years ago

Plus now, the app devs, now all turned devops because talent is scarse and demand is high, get to handle the complexity of concurrency, networking and reliability. This adds to deployment/testing/development setup, and when you change stack or job, the architecture slightly different and you need to learn it all over again.

Funnily enough, we couldn't make the microkernel concept works despite an homogeneous, integrated environment as a basis. But we are fine building frankenstein OS images, hacking multiple graph-shaped systems to make them play together, and call that a success.

Now don't get me wrong, I understand perfectly the benefits of it. But somehow, it feels like we arrived at the right result by the worst possible path, and at a price way higher than it should be.

panpanna7• 7 years ago

What if the pure microkernel approach is flawed and hypervisors offer a sensible middle ground?

zbuf2• 7 years ago

I believe it's because at some point the operating systems (particularly Linux based ones) became semi-closed ecosystems of software, instead of a platform to run other people's software. Also became a 'singleton' mentality too, where the only one version or variant of an app/library is accomodated.

So now we're falling back to the few stable ABIs we have available -- Linus's kernel ABI (containers) and some kind of x86 platform virtualization. I think it's a little sad that this happens because operating systems made a poor job of doing what we needed them to do.

rwmj• 7 years ago

This is simply a side effect of ill-disciplined programmers breaking ABIs whenever they feel like it. It's quite possible to maintain ABIs in the long term and upgrade and deprecate them thoughtfully, and if you do that then you don't need multiple versions of a library or service around.

naasking8• 7 years ago

Things are beginning to look a bit more like microkernels as time goes on.

Hypervisors typically are microkernels. The very first "hypervisor" was L4 in fact, with L4Linux.

Also, you're right that virtualization and containers are fulfilling the promises of operating systems. The problem of earlier OSes is that they didn't take security seriously enough. Modern hypervisors aren't much better at isolation than real microkernels like L4, KeyKOS and EROS. They're better than containers though.

msla• 7 years ago

Hypervisors typically are microkernels.

Except they have vastly different histories (look up IBM's VM) and uses and underlying technologies.

Here's a good post on the difference:

https://utcc.utoronto.ca/~cks/space/blog/tech/HypervisorVsMi...

Microkernels are intended to create a minimal set of low-level operations that would be used to build an operating system. While it's popular to slap a monolithic kernel on top of your microkernel, this is not how microkernel based OSes are supposed to be; a real microkernel OS should have lots of separate pieces that used the microkernel services to work with each other. Using a microkernel as not much more than an overgrown MMU and task switching abstraction layer for someone's monolithic kernel is a cheap hack driven by the needs of academic research, not how they are supposed to be.
(There have been a few real microkernel OSes, such as QNX; Tanenbaum's Minix is or was one as well.)
By contrast, hypervisors virtualize and emulate hardware at various levels of abstraction. This involves providing some of the same things that microkernels do (eg memory isolation, scheduling), but people interact with hypervisors in very different ways than they interact with microkernels. Even with 'cooperative' hypervisors, where the guest OSes must be guest-aware and make explicit calls to the hypervisor, the guests are far more independent, self-contained, and isolated than they would be in a microkernel. With typical 'hardware emulating' hypervisors this is even more extremely so because much or all of the interaction with the hypervisor is indirect, done by manipulating emulated hardware and then having the hypervisor reverse engineer your manipulations. As a consequence, something like guest to guest communication delays are likely to be several orders of magnitude worse than IPC between processes in a microkernel.

jacques_chester7• 7 years ago

The very first "hypervisor" was L4 in fact, with L4Linux.

The term "hypervisor" was coined by Popek and Goldberg in 1974. L4 didn't appear until the 90s.

gnufx2• 7 years ago

Isn't the important thing about KeyKOS and EROS capabilities, and L4 variants aren't all capability-based, are they?

imtringued3• 7 years ago

Yeah all those stupid fools... who needs machine VMs, language VMs, processes, process namespaces... Just compile your software with pointer authentication and run it in kernelspace on bare metal. Why is everyone so stupid and I am the only smart person on this planet?

... If you haven't realized it yet. I'm not serious at all ...

blablabla123• 7 years ago

The Docker engine default seccomp profile blocks 44 system calls today, leaving containers running in this default Docker engine configuration with just around 300 syscalls available.

...preventing devs/ops people to run tools like iotop, unless extra capabilities are added.

I'm all in for containers, cgroups/namespaces but at the moment it's namespace isolation for the price of less features. Unless namespaces become first-class citizens in the Linux kernel, it will always be more efficient to just run on VMs or even Bare Metal. At least for non-planet scale workloads. :-)

panpanna7• 7 years ago

Namespaces _are_ first class citizens in the kernel.

Have you tried any solutions that are not based on docker?

ris3• 7 years ago

...preventing devs/ops people to run tools like

This is because docker makes the fundamental mistake of conflating packaging with isolation. "Packaging" is achieved in docker by using the OS to do an amount of sandboxing and then letting the user perform whatever non-reproducible crap they like before balling the whole thing up and calling it a package.

If instead you make an app author actually figure out what their dependencies are and how to fetch/build them - in a system such as Nix, you not only get reproducible packages, you also get to decide to apply actual os-level isolation on a case by case basis - a developer doesn't necessarily need/want these barriers on their dev machine.

gtirloni5• 7 years ago

So a system like Android's? Honest question, I don't know of that's a good model to exist in general purpose Linux systems. There's also Fuchsia but I'm not sure if it's POSIX.

gdamjan1• 7 years ago

...preventing devs/ops people to run tools like iotop, unless extra capabilities are added.

you run those on the host, not inside containers

depr3• 7 years ago

So you have to give people access to the entire host! Great. And you can't even do that in cloud environments.

And even then you run top on the host and obviously it doesn't know anything about containers because they're not real.

Spivak2• 7 years ago

This is wrong on a fundamental level. Containers are nothing more than regular processes that are launched leveraging some of the kernel’s built-in namespacing features.

When we talk about applying seccomp profiles to containers it just means applying them to the process — exactly how the rest of your system uses them. They are about limiting what the process itself can do, not you as an admin. Denying the ability for sshd to run iotop with SELinux doesn’t stop you from running it.

Running containers on a bare-metal host is exactly the same as running processes on a bare-metal host.

panpanna7• 7 years ago

For the record, hypervisor were introduced almost before operating systems. In the begining it was just a switch to partition memmory and run multiple jobs on a big expensive machine.

So this is not the first time hypervisors are making a comeback.

curt15• 7 years ago

Is there still any place in 2019 for "system containers" like LXC/LXD?

simosx• 7 years ago

They are quite useful as "VMs at the speed of application containers".

When you use application containers, you tend to create a more complicated setup and lose visibility as to what's going on in the system.

Just like you use VMs on a baremetal server, you use system containers in a VM.

But I find more important to use LXD as a tool for software development and also for Linux desktop use.

If you want to setup nodejs or something similar, it makes sense to put it in a LXD container so that it does not mess up your host. Each step of the workflow (creation, deletion, etc) takes a few seconds or less.

You can also setup LXD containers to run GUI applications. It makes big sense if you want to run games (like Steam) so that your desktop does not get polluted with i386 packages. You can also use for development tools, such as those from JetBrains, Android Studio and more.

bonzini• 7 years ago

They're certainly very useful for CI systems.

josteink• 7 years ago

They may not be mainstream but I use them as isolated VM-like application environments, where everything “just works” without having to learn/apply a whole lot of new tools or workflows.

I’m sure there must be others who see the benefit of this approach too?

ris3• 7 years ago

I'm quite hopeful for the limited re-introduction of hypervisors to "containment", if only because I've become disappointed with the lack of power app authors have to specify fine-grained, strict security details. This is because most of the fun lockdown toys that linux has, selinux, seccomp et al aren't easily "stackable", and those toys have been used by the orchestrator to perform the containment. And that's great, but it means containers all end up with broad, generic policies (that only care about container breakout) which can't be further restricted by app/container authors.

My hope is that lightweight virtualisation will give back the ability for app authors to tighten their container's straight jackets. Personally I've got my eye on kata containers.

nunchuckninja2• 7 years ago

So I read something succinct a while back - docker et al are distribution platforms not security platforms . They add "0" security against an adversary (think padlocks). How true is it ? And what high perf securely contained systems are there? OpenVZ?

upofadown• 7 years ago

The generic issue seems to be that stuff like containers can be escaped with pretty much any privilege escalation exploit ... and such exploits are reasonably common in the world of Linux.

nunchuckninja2• 7 years ago

So either take perf hit or don't expect isolation at all?

aritmo• 7 years ago

But if the container is unprivileged?

naasking8• 7 years ago

Sandstorm has had a pretty good track record [1]. Then again, it was designed and run by capability security folks, who take security pretty seriously.

[1] https://sandstorm.io/

angry_octet• 7 years ago

Unfortunately it is shutting down.

Spivak2• 7 years ago

I think the more correct statement is that “containers” (i.e processes running with some kernel namespacing features) don’t replace the need for existing security tools like seccomp, SELinux, apparmor. Namespacing is just another tool in your arsenal to help create some logical separation between security domains but you still likely need more to be sure that the separation is enforced.

“Docker”, the tool that is slowly acquiring the ability to natively use all of these security tools and apply them to the containers it launches is/will be a security platform.

kresten• 7 years ago

Key point: AWS Firecracker does NOT run on AWS.

Unless you want to pay for bare metal instances.

AWS Firecracker DOES run on Google Cloud, Azure and Digital Ocean.

jacques_chester7• 7 years ago

Firecracker is used as the runtime for Lambda, I believe.

denton-scratch3• 7 years ago

I have a Xen hypervisor at home, running on a (well-configured) NUC. VMs boot in about 15 seconds. I'm patient!

I'm not doing devops stuff; I no longer code, so I don't need a testing pipeline.

I looked into containers based on LXC, when it was first introduced. I decided to stay away - I don't want to get tied into Poettering's code. Yeah, I'm running systemd on some of the VMs, but you don't really have much choice nowadays. I still use Debian, but I'm bitter about their adoption of systemd - and my hypervisor machine runs SysV Init, because I know how that works.

I never mixed it with Docker. From what I've been reading, Docker is already old-hat (it's only about 3 years old; how did that happen?) Kubernetes seems to be the thing nowadays. I don't even know how to pronounce "Kubernetes".

What was wrong with LXC? Like, LXC comes with the OS. Nothing to install. Why do people love these 3rd-party container engines?

And "wrappers"? what purpose is served by container wrappers?

Serious questions, I'm not trolling. Promise. I'm just a bit out-of-date.

meddlepal3• 7 years ago

Some of us have problems that are actually well solved by these tools and run on more sophisticated hardware than our home computer... It doesn't sound like you've hit that set of problems.

denton-scratch3• 7 years ago

Yeah, thanks. It's a home computer because I don't work any more - I set-up and operated a continuous production VM pipeline on my boss's rack, back when I had a boss.

Docker had turned up; I evaluated it (quite briefly - I had work to do, and nobody had asked me to evaluate Docker). We had fairly specific requirements that I couldn't match to Docker.

I recall now that Kubernetes is principally a deployment system - sorry. Perhaps it is well-integrated with some container systems, such as Docker. Kubernetes didn't exist when I had a boss. I use Ansible.

I get that LXC is not very friendly. But it works OK, doesn't it? Just wrap a shiny skin around it. Don't re-invent the wheel; we already have enough wheel inventions.

I'm not by any means knowledgeable about containers; I evaluated LXC way back when, and decided that VMs were more secure. And never revisited that decision.

jacques_chester7• 7 years ago

Docker achieved a number of things: they provided a simple user experience and a simple, relatively effective image format. The primitives had been in the kernel for some time and were widely used to implement a variety of systems (Cloud Foundry used these kernel features over 2 generations of its own code before switching to runc).

If you're just running stuff on a single machine for your own satisfaction, you don't need to fret about Kubernetes.

Disclosure: I work for Pivotal, so I've been up close with some of this stuff for a bit.

denton-scratch3• 7 years ago

"you don't need to fret about Kubernetes"

Don't know why you got voted down.

I'm retired, but I want to keep my hand in. I like to be able to throw up a server quickly. I like to be able to automate testing and deployment - Ansible is my friend. But I don't have to throw up and configure 100 servers by 10:00am :-)

tsimionescu2• 7 years ago

Having used both LXC and Docker, the main advantage of Docker is using it as a package manager, with the ability to extremely easily start from a 3rd party container and layer your own changes on top. While I'm sure LXC could technically achieve the same, it is way more difficult to do so than docker's 'FROM 3rdparty-container:$VERSION' / 'docker pull 3rdparty-container:$VERSION'.

On the other hand, Docker for a long time didn't really care about security, which LXC was much better at since the beginning more or less.

As for Kubernetes, that is most often used in conjunction with Docker (though there are alternatives), if you want to deploy containers to a cluster of machines (VM or physical) and get rid of some of the administrative work for doing so.

depr3• 7 years ago

It is popular because of the developer experience. You can get a Postgres database running with one command, and then throw it away (and no this is not equivalent to apt install postgres). Many other things are pretty polished as well, definitely more polished than LXC.

Kubernetes and similar software "solve" some problems and create a bunch of new ones.

I don't think the actual tech is that good (or new for that matter, Solaris had zones in ~2005); for example getting a core dump from a container without going into the host machine is an unsolved problem.

jacques_chester7• 7 years ago

"Containers" is an unfortunate term, since it really better describes the container image than an actual running process with API virtualisation.

I think VMs-as-containers is where we'll wind up. The container image has turned out to be the real thing of interest, the runtime is almost secondary. Virtual machine systems have closed the performance gap in a variety of ways.

For example: tearing out kernel checks for devices that will never be connected to the VM; taking advantage of hyper-privileged CPU instructions; being able to make and restore higher-fidelity checkpoints than an OS can for faster launches etc.

At which point the isolation benefits of VMs really begin to outweigh everything else. A hypervisor has a much smaller attack surface and has a much simpler role than a full monolithic OS kernel. It partitions the hardware and that's about it. It doesn't exist in a constant tension between kernel-as-resource-manager and kernel-as-service-provider.

LIV2• 7 years ago

This is kinda where VMware is going with project pacific & vSphere integrated containers; containers running as individual VMs on a hypervisor. I wonder if we will see others following the same pattern?

I’m not sure what the drawbacks might be though

jacques_chester7• 7 years ago

I think yes. Red Hat and others are working on KubeVirt, plus I believe there are CRI implementations for gVisor and Firecracker.

Disclosure: I work for Pivotal, which is in the middle of acquisition by VMware.

depr3• 7 years ago

Yes and no, there's the attack surface of the guest operating system.

dopylitty2• 7 years ago

I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing.

You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way.

I also have this sneaking suspicion that new generations are re-inventing the wheel in a lot of ways. If you have minimal containers running on a hypervisor how is that different from processes running on an operating system? You have all these CPU provided virtualization instructions to protect guests from each other and the host from the guests but there's no reason those instructions couldn't have been developed to protect processes from each other. You have indirections to protect one guest from accessing another's storage but there's no reason processes couldn't have the same protections (and they do in many operating systems). Why container orchestration and overlay networks instead of OS scheduling and IPC?

I'm sure people in academic computer science have already published many a paper about this but it feels different seeing it from inside an IT organization where people don't seem to apply the lessons from older technologies to newer ones and we end up in this constant churn of reinvention which, as far as I can tell, is mostly a way for people, both in management and in the trenches, to keep their jobs, at least until you're "too old to learn new things" and pushed aside.

BubRoss3• 7 years ago

Threads are not the same because they are separate computation in the same address space.

At some point though, permissions to disk, network, screen, input devices, etc. need to be an integrated part of computing for anything that runs more than one program.

Take a look at QNX though, at some point it will be reinvented and heralded as a breakthrough, 40 years after it happened the first time.

dopylitty2• 7 years ago

That's a good point. But as I think about it in a sense threads are also a form of isolation in that they allow you to isolate units of business code so that they can run independently and be (potentially) protected from other business code monopolizing a shared resource while not actually doing work.

GauntletWizard3• 7 years ago

Processes running on the same host are a "separate computation in the same address space" - They share a filesystem namespace.

Pods running on the same kubernetes cluster are a "separate computation in the same address space" - They share a DNS namespace.

Servers running on the same internet are a "separate computation in the same address space" - They share an IP namespace.

These are the same abstraction at multiple levels, and that's okay, because you often do need that. The L1 and L2 cache are crystaline to inmemory and redis caches in distributed systems. Components with the same shape show up at multiple levels. This is okay. What's important is that those levels each serve a purpose, and that you reduce the abstraction to be as simple and meaningful as it can be.

sansnomme4• 7 years ago

Because current model of processes frankly sucks. If I give you random binary would you run it? You can talk about sandboxing, lecture about permissions and principles of least privilege. But that still doesn't answer the question: can it run hostile code without having side effects on the rest of the system? Other than the newer web tech initiatives like WebAssembly/JS sandboxing, there do not exist any other technology that allows easy compartmentalization with somewhat reasonable security isolation out of the box for existing server code. Containers are not perfect, and hypervisors/unikernels are a pain to deploy on commodity cloud services but we are slowly getting there. (Also if you notice, newer generation of operating systems like Android, iOS, Fuchsia are moving towards strong sandboxing with every single thing locked down where possible. There is an impedance mismatch between the Unix model and current demands. You can't migrate overnight so you build technologies to work around it. From far away, Windows and Fuchsia are very similar, but Windows have to contend with decades of code compatibility needs even if they want to start shoving everything into a locked down app)

taeric4• 7 years ago

This gets silly, though. If you are going for full isolation where applications can't just let the user have data, then you have to coordinate every app talking to every other app.

This is why the share button on a phone is ridiculous. Instead of just copy to clip board, you get a ton of options.

Is it safer? Hard to say. I can do less and have less capabilities without more active work from the developers.

There is something to be said for this, of course. But it seems a losing game. I contend there is no technical panacea to security versus convenience.

eyberg3• 7 years ago

Deploying a hypervisor on top of a hypervisor (eg: a public cloud) usually makes very little sense so I don't see that as a trend. However, outside of the valley bubble many large sectors of the economy do not use public clouds (such as banking, health, defense) so hypervisors typically in the form of ESX is still very much a thing and now that we are seeing tighter integration with things like unikernels that is where the 'comeback' is coming from. I would almost go as far to say that it's becoming hip not to be using public cloud today.

Deploying a unikernel on top of commodity cloud is very achievable and easy today - I know because I'm involved with https://ops.city . I'd argue it's ridiculously easier than trying to deploy a container, clearly way safer and even faster and easier than using something like terraform.

I do very much agree with your impedance mismatch re: unix model thought though.

nostrademons2• 7 years ago

An idea I've been toying around with but don't have time to fully explore or implement:

The unit of isolation should be the library, not the process. Each time you call into another developer's library, the library should have only the privileges you explicitly pass to it as capabilities, and you should be able to specify whether these capabilities may be delegated outside the receiving library and whether they can outlive the method call. So every time you call outside your own code assembly, you know that that call can't access the network, can't write to disk, can't display anything to screen. If you need it to, you explicitly pass the connection to a particular host or a handle to a particular directory, and then it can't access anything outside of that.

Not sure if this is feasible performance-wise: if you do it at the binary level, it seems like it'd require remapping page tables and flushing the TLB with every external function call, which'd absolutely kill frameworks that have to execute callbacks many times a second. But there's a certain intuitive sense to making the unit of trust & communication the code written by a certain organization, and it also fixes attacks like npm malicious modules that haven't gotten all that much attention nor have effective mitigations beyond "audit all your dependencies".

c256• 7 years ago

From far away, Windows and Fuchsia are very similar, but Windows have to contend with decades of code compatibility needs even if they want to start shoving everything into a locked down app)

DOS and such were designed around everything on the device being shared, with conflicts resolved at the application layer. Windows was built to maintain some (even ideological) compatibility with that world, while adding some of the benefits of separation and sharing (for example, moving away from the world where every piece of a job could crash/co-opt/exfiltrate the entire device).

Unix (Multics, CTSS, ITSS, etc) was built to enable a world where multiple jobs (not processes; even then lots of jobs were multi-process) and multiple people could share the device. Threads, jails, cgroups, etc were added to move to a world where sharing wasn’t entirely cooperative and trusting. VMs, containers, and hypervisors are on the recent end of that same movement, along with wasm and JS sandboxing.

In the end, it’s a balancing act between performance (speed, power, cost) versus safety, often starting from different points. Exo-, uni-, and library-kernels are similar efforts that haven’t (yet?) caught on, but there’s a pretty clear direction of movement towards the strongest isolation that our (currently quite flawed) hardware can afford.

rgbrenner• 7 years ago

Other than the newer web tech initiatives like WebAssembly/JS sandboxing

Yes, this is the lightest weight isolation that's somewhat secure for random code.. And considering that we regularly find exploits that escape that sandbox, I would never use it to run some random persons code on a server. Yes, we do that all the time in the browser, but that's a more limited environment where a single user is choosing what to run... whereas on a server, anyone who wants to attack the service can just upload whatever code they want.

I know Cloudflare is doing it in Cloudflare Workers... and I think that's crazy. They're inspecting the code, and they added OS sandboxing... so that's a little better.. but trusting the JS sandbox in that environment is just nuts. Wouldn't surprise me if this ended up being another cloudbleed.

If you want to run random code, the only safe option right now is to use a heavier form of isolation like a VM (and even that is not perfect). The performance loss is the necessary trade off to allow random people to run code (some of whom are deliberately attacking the service). This is the downside to the "cloud"... performance losses to allow random people to share servers.

takeda6• 7 years ago

In a business environment the code you run is typically the code you wrote.

You generally don't run unfamiliar code if you do, you are not being careful. All it takes is to have a container contain a backdoor that phones home, and essentially give someone access to inside of your network.

regularfry2• 7 years ago

From memory, I seem to recall that Genode takes this to its logical conclusion: every process is isolated with virtualization primitives.

As to why: isolating processes the old way needs jails to work properly, BSD lost the popularity contest, and Linux jails didn't get secure enough before VMs and containers took off.

sayhello3• 7 years ago

Did the BSD jails provide enough isolation? Would memory from a process truly be isolated from another? How about FD’s?

Could there be side channel attacks? At what level?

Perhaps the whole kernel design needs to be revisited, which I assume is what’s being taken on by Fuchsia.

sayhello3• 7 years ago

Good point. The current widely used kernels seem to make some assumptions about ‘owning’ the hardware and implicitly trust any running programs at a certain level.

There is a need, however, for some pragmatism.

While a capabilities-based OS could be the right solution, it doesn’t exist today.

What we have is code built for some flavor of POSIX. People demand cost efficiency today.

So, engineers do what’s practical: build a multi-tenant system running code that expects to be the owner of the hardware.

It works good enough! For most people, the cost efficiency math works out. The sand boxing overhead is worth it, as it pales in comparison to the headcount required to manage your machines, or even VMs, if you replace them with Serverless products.

jacques_chester7• 7 years ago

What you're seeing is the endless see-sawing between "performance needs to be higher" and "isolation needs to be stricter".

Each alternative lands on a different balance at different times. Partly because of their own innate qualities, partly because of path dependency, partly because a "new" approach can sometimes reveal previously-unnoticed assumptions and partly because the ratios of CPU, RAM, disk and network performance are ever-shifting and thus favouring this or that architecture in the moment.

What tends to happen is that performance gains draw the first wave to a "new" technology. Then as the bulk of the industry begins to move, isolation, robustness and backwards compatibility become relatively more important. These impose overheads that will eventually be swept away by the next "new" technology.

There are still qualitative differences, though. Where you draw the firm lines in architecture affects the range of possibilities. I can place tenancy boundaries "anywhere", but in practice a VM hypervisor will be able to provide a firmer boundary than asking people not to share passwords.

no_wizard• 7 years ago

What I’ve always failed to Understand is how FreeBSD jails[0] never got very popular (discounting the fact that FreeBSD isn’t very popular on the whole from what I can tell) but Docker is huge. I personally think jails are superior in implementation in that it requires no other abstractions on top of the OS.

The only thing I can surmise is that Docker might have a better secure default, but improvements to Jails could emulate that, and following best practices as well should. Beyond that I’m still baffled how this didn’t take to the mainstream.

[0] https://www.freebsd.org/doc/handbook/jails.html

beaconstudios• 7 years ago

better marketing I would assume.

dasil003• 7 years ago

Because Docker has better dev marketing. Some sizable portion of developers actually believe Docker invented containers.

zzzcpan4• 7 years ago

Jails are more like runC, container tech behind Docker.

jayd163• 7 years ago

But they are popular...

Jails and chroots are used heavily in iOS and Android. I would say its one of the fundamental differences between mobile apps and desktop apps.

Its not enough though. You need docker to handle the DNS, routing, port forwarding etc. if you want to emulate a pocket cloud on a dev machine. I suppose the networking aspect could be done for jails as well but docker and docker-compose just seem more polished in this regard.

icebraining2• 7 years ago

Docker is convenient. You can just download the docker binary and type "docker run postgres" and have a container running Postgres. What's the equivalent for FreeBSD jails?

zbentley3• 7 years ago

This happened because docker, in addition to an isolation system, also bundled a user friendly interface to a per-app persistent filesystem. No matter how many people sing the praises of isolation and security to Docker, I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies.

Docker gives you a very simple way to not think about that (at least until your massive container that bundles ancient versions of a dozen different CVE-filled libraries bites you in the ass down the road).

It's not novel. It's not even particularly elegant. But Docker users don't want elegance; most of them just don't want to think about how to configure a production environment to work like their development environment, so we get the old joke: "It works on my machine!" "Then we'll ship your machine"...and so we got docker.

gigatexal2• 7 years ago

I was just going to post about jails but you beat me to it.

superflit• 7 years ago

I am still waiting all the docker fans to acknowledge bhyve[1]

[1] https://bhyve.org

magicalhippo• 7 years ago

I've tried a few times to get jails working but always stumbled over something. Last time it was inbound connections for a server. After several hours I gave up. There's iocage now, but this was well before that. And iocage still has issues.

Docker I could get up an running in less than an hour and it just worked.

sedachv7• 7 years ago

I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing.

There is a very easy way to articulate it: they are all ways of virtualizing different facilities. Unix processes virtualize the user-mode processor registers and the address space. POSIX threads only virtualize the processor registers and the stack. Linux namespaces let you pick and choose which facilities you want to virtualize (storage, PID namespace, IPC namespace, etc.).

The abstraction is related to what is being virtualized: everything that is virtualized is a namespace (this is what naming things refers to in Phil Karlton's quote "There are only two hard things in Computer Science: cache invalidation and naming things," not to the literal naming of variables in computer programs).

Another way to go instead of virtualization is capabilities.

user_error• 7 years ago

this is what naming things refers to in Phil Karlton's quote "There are only two hard things in Computer Science: cache invalidation and naming things," not to the literal naming of variables in computer programs

That is mighty interesting. Do you happen to have a source for this? It's the first time I've heard it being put in this particular way.

dustingetz• 7 years ago

“function” for suitably principled definition of function

reaperducer• 7 years ago

I also have this sneaking suspicion that new generations are re-inventing the wheel in a lot of ways.

Suspicion fades away, and the older you get, the more often you see this happen.

circute• 7 years ago

Did I write this comment? I've had the same feeling. I work on securing VMs in a hypervisor and part of me wants to look at ring 0 to 3 instead of ring -1 to 0 and see if I can fix that instead of bloating cpu specs with more rings.

louwrentius2• 7 years ago

I think you could build a secure application environment with just bare metal.

The only hip tool I would use is Ansible after paying my respects to cfengine.

No virtualisation No containers No overlay networks

A few VLANs perhaps. If I may.

It can be done.

Just a few dedicated people. The kind of people colonel Kurtz talked about...

drybjed• 7 years ago

I'm working on something like this with the DebOps[1] project. It's a set of Ansible playbooks and roles that lets you manage Debian environments. I aim for it to be agnostic - roles can be used effectively both in LXC containers, virtual machines or bare metal.

You can start with a few machines with Debian netinst + SSH installed, and build them up with the services you want. Applications are installed either from Debian or upstream repositories (via APT), downloaded directly from upstream with proper signature verification, or compiled from git sources. There are no OS images, therefore no containers or VMs are strictly necessary.

It seems that in the age of Kuberenetes projects like this are a niche, but if somebody is working with on-premises infrastructure, bare metal hosts, a good set of tested Ansible roles which you can use as a base for your own deployment might come in handy. I haven't found anything close to what I had in mind back then, so I started my own, going at it for 6 years now. Hopefully it will be useful to somebody else at some point. :-)

[1] https://github.com/debops/debops/

barbecue_sauce• 7 years ago

Is Ansible still hip or has it gone the way of MongoDB?

jasoneckert• 7 years ago

Wait....this isn't new - hypervisor-based container isolation has been in Windows Server since 2016 (it's called Hyper-V containers).

sayhello3• 7 years ago

Did the Windows Server isolation bundle a slim kernel?

One of the core elements of this for the Serverless fast boot requirement is using a kernel that has legacy modules excised.

xfitm3• 7 years ago

I see container systems, such as Docker, as a packaging system more than anything else.

hinkley2• 7 years ago

A Turing complete, language agnostic one.

If you were trying to write one that wasn’t container focused, how would that look?

cwp3• 7 years ago

It would look like NixOS.

sedachv7• 7 years ago

https://nixos.org/nix/

https://guix.gnu.org/

Containers are a very poor substitute for package managers.

spion• 7 years ago

The future is probably WASI: a sandboxed compile target with a capabilities based security model not owned by a single corporation. https://wasi.dev

amscanne• 7 years ago

I’ve been thinking about these problems for a while. Previously, I thought that the “put a VM on it” approach was the right one. In 2015, I wrote novm [1], which I think served as inspiration for some developments that followed. My thinking has changed over the years and I actually work on gVisor today (disclaimer!). I’d like to share some thoughts here.

Hypervisors never left. They are a fundamental building block for infrastructure and will continue to be.

The question is whether there will be a broad shift to start relying on hypervisors to isolate every individual application. In my opinion, just wrapping containers in VMs is not a solution. (Nor do I find it technologically interesting, but that’s me.) I agree that the approach addresses some of the challenges of isolation, but is one step forward, two steps back in other ways.

Virtualizing at the hardware boundary lets you do some things very well. For example, device state is simple, and hardware support lets you track dirty memory passively and efficiently, so you can implement live migration for virtual machines much better than you could for processes. It can divide big machines into fungible, commodity sizes (allowing applications from having to care about NUMA, etc.). It lets you pass though and assign hardware devices. It gives you a strong security baseline.

But abstractions work best when they are faithful. Virtual machines operate on virtual CPUs, memory and devices, and operating systems work best when those abstractions behave like the real thing. That is, CPUs and memory are mostly available, and hardware acts like hardware (works independently, interactions don’t stall).

Containers and applications operate on OS-level abstractions: threads, memory mappings, futexes, etc. These abstractions are the basis for container efficiency — not because startup time is fast, but because these abstractions allow for a lot of statistical multiplexing and over-subscription while still performing well. The abstractions provide a lot of visibility for the OS to make good choices with global information (e.g. informing the scheduler, reclaim policy, etc.).

A problem arises when you decide that you want to bind single applications to single VMs, and then run many VMs instead of many containers. Effectively, the abstractions that you expose are now CPUs and memory, and these just don’t work as well for over-subscription and overall infrastructure efficiency. There’s no shared scheduler or cooperative synchronization (e.g. in an OS, threads waking each other will be moved to the same core), there’s no shared page cache, etc.

There are other problems too: virtualization gives you a very strong security baseline, but you have to start punching significant holes to get the container semantics you want. E.g. the cited virtfs is a great example: it’s easy to reason about the state of a block device, but an effective FUSE api (and shared memory for metadata) is a much larger system surface. The hardware interface itself is not a silver bullet. Devices are still complex (escapes happen), and the last few years have taught us that even the hardware mechanisms can have flaws. For example, AFAIK Kata containers is still vulnerable to L1TF unless you’re using instance-exclusive cpusets or have disabled hyper-threading. (Whereas native processes and containers are not vulnerable to this particular bug.)

The “put a VM on it” approach also may not have the standard image problems that plain hypervisors have, but you’ve got portability challenges. It seems non-ideal that a container isolation solution can run in infrastructure X and Y, but not in standard public clouds or your on-prem VMWare hosts, etc. (There might be specific technologies for each case, but that’s rather the point.)

That’s my 2c. I’m pretty optimistic that we can have strong isolation while still preserving the efficiency, portability and features of container-based infrastructure. I like a lot of these projects (especially the ones doing technologically interesting things, e.g. nabla, x-containers, virtfs, etc.) but I don’t think the straight-up “put a VM on it” approach is going to get us there.

ricarkol1• 7 years ago

Hi, completely agree with all of this. In fact, we've been focusing on the problem you mention about needing FS holes for VMs to regain container semantics (https://www.usenix.org/system/files/hotstorage19-paper-kolle...). Just in case, these are some of the container semantics we care about: FS crash consistency, file sharing (write+write), and efficient use of memory due to having a single page cache. The key question is: what's the smallest hole we can poke (smaller than allowing every single FS operation in the host)?

Containers in 2019: They're Calling It a Hypervisor Comeback

Related Stories