Containers in 2019: They're Calling It a Hypervisor Comeback
infoq.com
infoq.com
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.
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.
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.
Several references to the quote "There are only two hard things in Computer Science: cache invalidation and naming things" can be found, such as Martin Fowler's blog and others.
I'm unable to find the source of this quote, has he ever said it?
- As his only son, and colleague with him at Netscape from 95-97, I can attest that my dad did indeed throw that quote around, on more than one occasion. I'm fairly confident that he originated it (he was fond of coming up with clever quippets), though I haven't been able to figure out how it disseminated so widely over the past couple of decades. I'll keep looking around in old web archives and mails to see if I can dig something up.
0. cache invalidation
1. naming things
47. asynchronous callbacks
2. off by one errors
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.
I work in traditional finance, outside of Silicon Valley and there is a huge drive to move to the public cloud. For the same reason banks do not own their office buildings anymore - managing computing infrastructure is not their core business and - to be honest - they are not very good at it. I know people who have to move servers and applications to a different data centre because the lease on an old DC is ending, it is a huge headache, and they would much rather concentrate on their core business.
https://www.geekwire.com/2019/interview-jpmorgan-chase-ceo-j...
“Jamie Dimon: The cloud and AI are real, huge, powerful and they’re going to change a lot for us. Of course, good companies are going to adapt to it in due course. They can’t just do it overnight, but it changes a lot more than just using the cloud — how you write your code, how you can do agile, it even changes how you organize your company. Managers start to think about using data in a far different way than they ever did before. It changes everything. It’s a huge opportunity.”
...
“When cloud first got started, there was no reason to use someone else’s data center or their networks. You know, I wasn’t completely wrong, if I can run my data center as efficiently as a cloud guy, which fundamentally is true.”
”But here’s what I missed: the bursting part of the cloud. It reduces the peak capacity that we’ve got to keep in our own data centers, and you can burst excess workloads into the cloud. And it directly relates to AI. There’s just so much compute power in one split second that I simply can’t do in one of my data centers. So if you want to apply AI and these tools, and also the services that are built into some of these platforms [the cloud offers an advantage.]”
// Disclaimer: I work at a global bank.
Google Cloud has this option (nested hypervisors) but not for security reasons - it's used to run other software that comes packaged as a vm yet that comes with a serious perf hit and which is why I don't see that ever catching on as a trend. Selling bare metal servers w/pre-installed hosted firecracker would make much more sense (if you want/need hosting).
If you are interested in isolating a particular application to a given interpreter or a given binary the aforementioned unikernels are precisely what you are looking for and those can be provisioned on t2.micros.
The parts of k8s that are sticky and hard to change are the API abstractions like Services, Deployments, and Nodes. That's also where a lot of the value add is. Like AWS cloud formation. The only part that is docker-specific are the docker images.
I don't think the sandboxing techniques (i.e. docker) will stay the same for long. There are already multiple initiatives to implement hypervisor-based pods. I think firecracker has a lot of inertia right now, and I'm pretty sure RKT containers with KVM isolation were in beta a couple year ago.
The point is, I don't see how kubernetes has all that much to do with security (at least as far as isolation goes). Docker alternatives will gain traction and k8s will offer them as pod runtimes. Maybe the direction you mean we should be running is the opposite one from Docker?
I opened the 'Why' tab and found blurbs I wanted to see more about. For example, security through smaller code+attack surface sounds interesting, 'no ops' (didn't grok the bullets here, but I was interested to know more), and higher performance are all interesting
The bullets were interesting enough for me to want more, so I opened the video.
Unfortunately, the video was really vanilla and didn't expand on these concepts at all. It shows how easy ops.city is, but gives me nothing more on why it is better than ten other technologies that have similar 'easy intro' videos.
What I was hoping for was a 5-10 minute video focused on benefits of your approach vs alternatives. For example, some talk or demo on improved performance, data on how much code/attack surface is reduced, comments on OS/kernel memory footprint (this is a problem for us - clients like using 500MB "tiny" VMs on public clouds that hang running cadvisor), etc.
I could leave your site to answer these questions on my own. I did this and found some promising looking links over on the nanovm website. But that is an awkward experience - leaving your site to try and understand your offering.
Perhaps I'm not your target audience. For context, I do a minor amount of devops as part of delivering initial R&D products to multiple clients. We are not ops experts, but we try to deliver future proof work, which involves us staying apprised of new approaches and making them available to clients when they are a fit.
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.
Remembering these times it makes me wonder why should there be only one direction, and that maybe there is an alternative to putting all our most sensitive data in every internet connected devices? In old times when you had a computer to do some hobby like games, photo editing, music, etc... the data was only related to that activity, and in the worst case of nuking the hard drive you lost only that work.
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.
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".
But imagine a future where using a traditional OS means there's close to a 100% chance that you will have your identity and/or financial assets stolen, or where these computers are widely used in the military and a security failure literally means you're dead. We're headed there anyway, judging from all the headlines on data breaches and identity theft. There'll be system failure at that point, as well as a strong incentive to rewrite everything as a secure system.
And what is wrong with that? JavaScript source-code-only is by orders of magnitude the most popular and successful software distribution method.
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.
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.
Off topic, but I don't understand your objection...
On Android Chrome the share button shows you a context sensitive choice of apps that will accept the object (a link, some text, etc), followed by a second choice of what the app can do with the object.
The flow for copy-then-paste is more convoluted and is waaay less discoverable. Copy then paste is still available for the situations where it has an advantage.
And things have gotten some better for the phone option. But I don't have or want all apps installed. So, my sharing is dominated by copy/paste, still.
This doesn't save you if you do dumb things, like have open ports that allow administrative access that are exposed to the rest of your (potentially malicious) system. They do force you to think about some of the questions, though, like "Where is my data stored and how do other tools interact with it?"
Most of the problems that people complain containers don't solve are ones that are open ended, and have no definite solution.
Android apps are run in containers, for some broad sense of the word. That's how it should be. Every app I run should be run with a simply configured set of permissions, and "per app" or "as user" makes sense, even in the desktop space. That's what snap originally tried to do (but failed at, and have now broken)
Consider that on my phone, I am limited to accessing my data for most apps through the apps. On my computer, I typically know where the data is stored.
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.
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.
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.
Here is a quote from Eberhard Wolff's _A Practical Guide to Continuous Delivery_:
"It is laborious to install a real application including all components. Of course, it is even more laborious to automate this process... When an installation crashes, it has to be restarted. In such a scenario the system is in a state where some parts have already been installed. Just to start the installation again can create problems. The script usually expects to find the system in a state without any installed software... This problems is also the reason why updates to a new software version are problematic. In such a case there is already an old version of the software installed on the system that has to be updated. This means that files might already be present and have to be overwritten. The script has to implement the necessary logic for this. In addition, superfluous elements that are not required anymore for the new version have to be deleted. If this does not happen, problems can arise with the new installation because old values might still be read out and used. However, it is very laborious to cover and automate all update paths that occur in practice."
If a self-professed expert that writes books on the subject does not realize that package managers exist, and proposes that the only alternatives for software installation are either hand-hacked shell scripts or Docker, what do you think the average developer knows?
Docker solves dependencies in same way a disk image does, you save the image and it should look the same way each time you look at it. The Dockerfile is not a reproducible though, you just list steps iteratively to generate an image, but it doesn't guarantee to produce the same result. I saw multiple times scenario that docker image built fine for one person and didn't work for another.
The main reason for it is that majority of Dockerfiles rely on network to build the image and files received (or even your apt-get command) might produce different results for different people.
Recently I saw example where even a docker image built on build system didn't work on deployments system. Both machines of course were x86_64. Turned out that one of dependencies enabled compile optimizations for the CPU it was built on. You could argue that it isn't Docker's fault, but isn't its promise to provide reproducible builds?
Docker is trying to sell itself as something more than it is, in reality it is just an overglorified zip file.
Static linking solves a lot of these deployment issues. But I guess people are worried about duplicating libraries and security vulnerabilities. So we end up with Docker which has these problems, but even worse.
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.
If you do IPv6, there is no need for all of these layers of IPv4 overlay network crap.
nix-env -iA nixpkgs.postgresql_11
initdb ~/data
pg_ctl -D ~/data start
createdb
Docker I could get up an running in less than an hour and it just worked.
I didn't dig too deep into it, but I had iptables rules set up to only allow inbound 22 and 443, but all of the exposed ports on the containers were still externally available.
[1] - https://bhyve.org
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.
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.
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.
Not that this is a bad thing, but someone please correct me if there is something fundamentally recent in Zircon.
My post was in response to 'sayhello' that is wondering whether jails provide enough isolation.
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.
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.
Mixing this up with a filesystem or any shared resource is completely nonsensical. Naive oversimplifications like this indicate a lack of understanding of how and why computers are architected as they are in the first place.
Virtualization could be said to be an extrapolation of virtual memory and in fact does offer sub virtual memory, but to equate threads, processes, virtualization and shared resources as the same thing is grasping for simplicity that isn't there by making comparisons that aren't true.
Convergent evolution doesn't mean we should all become the same organism.
Suspicion fades away, and the older you get, the more often you see this happen.
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...
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. :-)
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.
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.
Building them that way from scratch is pretty much just as easy as writing programs in UNIX, modulo the lack of tooling that is mostly POSIX-based.
Is there a microkernel API that has more acceptance nowadays? In other words, where should anyone wanting to work on real world / enterprise systems based on microkernel look?
You nailed it: From day 2 or so we imagined to develop Genode as the future common API for the diverse range of microkernels and showcased the approach with all L4 kernels we could get our hands on. The vision is still to provide a replacement for POSIX in the microkernel world ;-)
Regarding POSIX, we don't think that tools and applications developed for this interface do not fit the microkernel world but on the traditional systems level POSIX (and its tools) is not sufficient to make the best of out of the microkernel advantages. For example, we run libcurl, GPG, libarchive, and coreutils in an orchestrated scenario to implement a robust and secure deployment/installation subsystem in the Genode-based Sculpt OS https://genode.org/documentation/articles/sculpt-19-07.
The kernel is even formally verified, and it's very widely deployed.
The Okl4 kernel in iPhones is extremely limited in its functionality, you could probably run that code even without an Os. It could also be argued if in its current form it is really a microkernel. Furthermore, sel4 and okl4 are not the same product.
(nothing bad on sel4, I have used it myself and I personally know the people behind the project. But it's not what you think it is)
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.
The term "hypervisor" was coined by Popek and Goldberg in 1974. L4 didn't appear until the 90s.
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.
Microkernels over time have also employed vastly different technologies. All the "differences" you note are "intended system design/interaction", which frankly isn't meaningful. For instance:
> 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.
Who cares how they interact with it? A microkernel is defined by the sorts of abstractions it provides and the isolation properties those abstractions entail. Hypervisors are effectively less expressive microkernels.
I found this interesting. Can you or anyone else say what the context was where academic researchers have needed to do this? What problem was it solving for them in a cheap way?
>the whole 'normal kernel on microkernel' idea of porting an existing OS kernel to live on top of your microkernel gives you at least the hope of creating a usable environment on your microkernel with a minimum amount of work (ie, without implementing all of a POSIX+ layer and TCP/IP networking and so on). Plus some grad student can probably get a paper out of it, which is a double win.
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.
Then Linux package managers would have made it easy to eg. install local (eg. per user, or in a folder) libraries or software.
Of course it was always possible, setting various $PATH variables etc. but because it wasn't easy (and you're immediately out of the ecosystem) all focus has been on the root user and singleton approach. Static linking was put to one side too.
In doing so we made the presentation of the "operating system" a full ecosystem of libraries, too complex to be a defined layer to interface with. But the kernel realised the importance of stable ABI layer, so now we have containers instead.
POSIX is just a common API across UNIX clones.
And besides the AT&T original design, UNIXes have disagreed in almost everything else, hence UNIX wars.
The IEEE Computer Society's Portable Application Standards Committee (PASC) is the group that has and continues to develop the POSIX family of standards. Historically, the major work has been undertaken within Project 1003 (POSIX) with the best known standard being IEEE Std 1003.1 (also known as POSIX 1003.1, colloquially termed "dot 1"). The goal of the PASC standards has been to promote application portability at the source code level.
... If you haven't realized it yet. I'm not serious at all ...
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.
I’m not sure what the drawbacks might be though
Disclosure: I work for Pivotal, which is in the middle of acquisition by VMware.
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.
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.
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.
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.
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.
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.
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 :-)
...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. :-)
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.
Not really, I'm essentially describing nix/guix.
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.
Have you tried any solutions that are not based on docker?
you run those on the host, not inside containers
And even then you run top on the host and obviously it doesn't know anything about containers because they're not real.
If you were trying to write one that wasn’t container focused, how would that look?
Containers are a very poor substitute for package managers.
K8s can already do VMs with Kube-virt, so yeah.
Excuse me while I go implement a servlet over there....
I'm skeptical it will. To adopt serverless you need to be willing to rearchitect your product and retool your developers... that's expensive.
They'd get more uptake if it was easier I think. Not re-architect your product...but small things here and there.
I wanted to play with azure python functions but despite vs enterprise & lots of credits I can't. Without admin rights on local machine it's basically impossible. (Need VSCode & AZ toolkit)
(Unrelated - that kinda blew my mind - no you can't do that in the 2,000 USD VS enterprise...you need to use the free one)
I’m guessing this is because Microsoft wants it to be more accessible—they probably realize that there isn’t much money to be made in $2,000 developer tools. Visual Studio was never a Python IDE; VS Code is much more language-agnostic.
If I'm buying the top end product I'm expecting full feature set, no?
Virtual machines are everywhere, from SME to large enterprises, tech hubs, industrial software et al.
Containers are mainly used for modern web and app development.
More like "fancy inetd."
No, that was even worse.
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.
I’m sure there must be others who see the benefit of this approach too?
Unless you want to pay for bare metal instances.
AWS Firecracker DOES run on Google Cloud, Azure and Digital Ocean.
So this is not the first time hypervisors are making a comeback.
One of the core elements of this for the Serverless fast boot requirement is using a kernel that has legacy modules excised.
“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.
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.