Containers in 2019: They're Calling It a Hypervisor Comeback • Hacker News Board

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

#171

Post by imtringued » Sun, Oct 27, 2019, 10:11 AM UTC

zbuf wrote: post #49

rwmj wrote: post #34

Earlier quoted context omitted.

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.

This is totally true, but I think it's the opposite approach that would have actually made a difference here. Saying "we know these ABIs won't be stable, either practically, or by design, so this is where the OS ends" 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…

I install pip dependencies for python into a vendor folder. It is definitively the cleanest solution compared to dicking around with virtualenv

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

#172

Post by gtirloni » Sun, Oct 27, 2019, 10:14 AM UTC

pjmlp wrote: post #147

gtirloni wrote: post #143

Earlier quoted context omitted.

Q1. What is the Portable Application Standards Committee (PASC)? 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 th…

Examples of APIs actually proposed by POSIX, that weren't already in widespread use before adoption by standard updates?

I think you're just making my point.

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

#173

Post by demosito666 » Sun, Oct 27, 2019, 11:14 AM UTC

barbecue_sauce wrote: post #165

louwrentius wrote: post #157

Earlier quoted context omitted.

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...

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

Ansible is still a practical tool for some of configuration management tasks, as opposed to mongo which I have hard time finding a niche for.

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

#174

Post by naasking » Sun, Oct 27, 2019, 2:16 PM UTC

panpanna wrote: post #135

naasking wrote: post #56

Earlier quoted context omitted.

seL4: https://sel4.systems/ The kernel is even formally verified, and it's very widely deployed.

Define wildly. 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)

Not what I think it is? It's a capability secure microkernel, that's literally all I've ever claimed. I'm not sure what you think I've been saying.

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

#175

Post by pjmlp » Sun, Oct 27, 2019, 3:31 PM UTC

gtirloni wrote: post #172

pjmlp wrote: post #147

Earlier quoted context omitted.

Examples of APIs actually proposed by POSIX, that weren't already in widespread use before adoption by standard updates?

I think you're just making my point.

Not really, last serious revision was in 2008, or so.

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

#176

Post by tonyarkles » Sun, Oct 27, 2019, 3:44 PM UTC

magicalhippo wrote: post #138

no_wizard wrote: post #93

Earlier quoted context omitted.

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 coul…

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.

I'm smiling reading your comment, having fought with jails/iocage and networking in the past. The counterpoint is that you likely didn't have inbound connection problems with Docker because it seems to quite effectively bypass all of the iptables rules on the host.

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.

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

#177

Post by takeda » Sun, Oct 27, 2019, 4:22 PM UTC

sansnomme wrote: post #54

dopylitty wrote: post #52

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 suspicio…

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 techno…

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.

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

#178

Post by taeric » Sun, Oct 27, 2019, 4:47 PM UTC

robocat wrote: post #79

taeric wrote: post #55

Earlier quoted context omitted.

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…

> This is why the share button on a phone is ridiculous. Instead of just copy to clip board, you get a ton of options. 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…

copy-then-paste is only more convoluted if you haven't learned how computers have worked for a long time.

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.

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

#179

Post by taeric » Sun, Oct 27, 2019, 4:52 PM UTC

GauntletWizard wrote: post #155

taeric wrote: post #68

Earlier quoted context omitted.

containers are a great tool for corporate servers. For end user machines, it is a tougher sell.

What do you think of the permissions associated with Android apps? Each developer gets a separate and cordoned user account on your phone. They only have access to private storage unless they request it through special APIs. 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…

Isn't that where I said it can get silly? I don't want developers having an account on my phone. I just want to process some data on my phone.

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.

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

#180

Post by takeda » Sun, Oct 27, 2019, 5:22 PM UTC

cwp wrote: post #112

zbentley wrote: post #106

Earlier quoted context omitted.

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 poor…

Yes, this is exactly right. Dependency management is a hard problem, and with Docker you only have to get it right once. I think Docker wouldn't exist if Amazon had shipped a way to build and test an AMI locally.

There is already a solutions such as Guix and Nix, but then people aren't willing to learn a new language that allows expressing dependencies.

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?