4 ms·

I think the virtual machine analogy is a bit dicey because lxc+cgroups/Docker containers have to be much more aware of the host kernel api and devices. edit: y

by 3am 13y ago

I think the virtual machine analogy is a bit dicey because lxc+cgroups/Docker containers have to be much more aware of the host kernel api and devices. edit: yes derefr, I agree. My point was also if there was a distribution or kernel specific Ruby or Ruby library bug, for example, then you might have to account for it in your code if you ran in containers (if you don't control the host on which your code is running), whereas you control the whole stack in the virtual machine.

derefr 13y ago
But it's not idiomatic to take advantage of those close ties (by, say, having two containers share a named pipe mounted from the host.) I suppose what you mean is that containers aren't applicable in every instance that VMs are--like, say, providing VPS instances, where some of the instances might want to do funny fiddling things with their virtualized "hardware." This is true. But for the situations where the applicability of VMs and containers intersect--using them to run Heroku-like isolated "app slugs", for example--then you can think of containers as lighter-weight VMs, and you won't really go wrong.
- k3oni 13y ago
  Yep, this is more like it
- gaius 13y ago
  But there should be no such thing as a VPS. You should be able to just give n people a shell on a box and quotas, permissions etc would suffice. That you can't is a shortfall of the OS and a hypervisor is a bandaid.
  - tbrownaw 13y ago
    Which could be made to work until someone wants to run an alternative OS (ie, not Linux) or use features that are only available in newer kernel versions. Or until someone realizes that a shared kernel with a security policy is a larger attack surface than a tiny hypervisor with no concept of sharing.
  - dpark 13y ago
    And what's your security model? Each user that needs to run services has to run them under their user account? Or are you going to also allocate some number of service accounts to each user and pay the cost to manage these accounts and the combined quotas they entail? Now how do your users' service accounts share resources? Someone will need a web server running under one account and a job processor running under a different account (different accounts in order to allow for limited privileges). Are they restricted to communicating through named pipes (hope no one else binds the pipe)? What if they want to share some disk-based resources? Shove them all in a group and set someone's home directory to 770? How do you handle it when one of your users needs a SQL server? Do they need to install this in their home directory, too? And lock down their install so that hopefully other users on the box can't call it? What about port binding? Just luck of the draw, and everyone binds on what they want? Then they file a request for you to forward to the port they happened to grab? And they hope that they never lose the port due to a server reboot, or a service crash? People could work in the environment you describe, but it would be miserable. And you (the server owner) would have to sink a massive amount of resources into maintenance. This isn't a shortcoming of the OS. It's a fundamental mismatch between the goal of sharing a server among many users and giving those users sufficient control to build what they need.
    - chongli 13y ago
      How do you handle it when one of your users needs a SQL server? Do they need to install this in their home directory, too? And lock down their install so that hopefully other users on the box can't call it? NixOS can handle situations like this. It enables per-user package management with deterministic, immutable installs. If multiple users install the same package, it only puts one copy on the system. Each user gets their own environment where they can customize the package without affecting the other users.
      - dpark 13y ago
        How does that work when you factor in quotas? What if a malicious user installs every possible package? Do they kill the system? How are versions handled? Can N users install N versions of a package? (Looks like the answer is yes.) This sounds like a nice system. I'm just wondering how much of the core issue is really addressed.
  - memracom 13y ago
    If you could do this, it would be implemented by using LXC. I used to use an MAI OS that was based on Charles River Unix which used something like this. Instead of just executing /bin/sh on login, they started a chroot jail and ran /bin/sh inside that. To the user it did look a lot like a private machine. Only admin user accounts could see the whole system. It would be trivial to do this with LXC too.

by 3am 13y ago

derefr 13y ago

But it's not idiomatic to take advantage of those close ties (by, say, having two containers share a named pipe mounted from the host.) I suppose what you mean is that containers aren't applicable in every instance that VMs are--like, say, providing VPS instances, where some of the instances might want to do funny fiddling things with their virtualized "hardware." This is true. But for the situations where the applicability of VMs and containers intersect--using them to run Heroku-like isolated "app slugs", for example--then you can think of containers as lighter-weight VMs, and you won't really go wrong.

k3oni 13y ago
Yep, this is more like it
gaius 13y ago
But there should be no such thing as a VPS. You should be able to just give n people a shell on a box and quotas, permissions etc would suffice. That you can't is a shortfall of the OS and a hypervisor is a bandaid.
- tbrownaw 13y ago
  Which could be made to work until someone wants to run an alternative OS (ie, not Linux) or use features that are only available in newer kernel versions. Or until someone realizes that a shared kernel with a security policy is a larger attack surface than a tiny hypervisor with no concept of sharing.
- dpark 13y ago
  And what's your security model? Each user that needs to run services has to run them under their user account? Or are you going to also allocate some number of service accounts to each user and pay the cost to manage these accounts and the combined quotas they entail? Now how do your users' service accounts share resources? Someone will need a web server running under one account and a job processor running under a different account (different accounts in order to allow for limited privileges). Are they restricted to communicating through named pipes (hope no one else binds the pipe)? What if they want to share some disk-based resources? Shove them all in a group and set someone's home directory to 770? How do you handle it when one of your users needs a SQL server? Do they need to install this in their home directory, too? And lock down their install so that hopefully other users on the box can't call it? What about port binding? Just luck of the draw, and everyone binds on what they want? Then they file a request for you to forward to the port they happened to grab? And they hope that they never lose the port due to a server reboot, or a service crash? People could work in the environment you describe, but it would be miserable. And you (the server owner) would have to sink a massive amount of resources into maintenance. This isn't a shortcoming of the OS. It's a fundamental mismatch between the goal of sharing a server among many users and giving those users sufficient control to build what they need.
  - chongli 13y ago
    How do you handle it when one of your users needs a SQL server? Do they need to install this in their home directory, too? And lock down their install so that hopefully other users on the box can't call it? NixOS can handle situations like this. It enables per-user package management with deterministic, immutable installs. If multiple users install the same package, it only puts one copy on the system. Each user gets their own environment where they can customize the package without affecting the other users.
    - dpark 13y ago
      How does that work when you factor in quotas? What if a malicious user installs every possible package? Do they kill the system? How are versions handled? Can N users install N versions of a package? (Looks like the answer is yes.) This sounds like a nice system. I'm just wondering how much of the core issue is really addressed.
- memracom 13y ago
  If you could do this, it would be implemented by using LXC. I used to use an MAI OS that was based on Charles River Unix which used something like this. Instead of just executing /bin/sh on login, they started a chroot jail and ran /bin/sh inside that. To the user it did look a lot like a private machine. Only admin user accounts could see the whole system. It would be trivial to do this with LXC too.