5 ms·

I had a feeling this would happen. Containerisation as a trend has just as much to offer desktop OSes as it does for cloud clusters.

motoboi 11y ago
Is this really containerization as we know it, like Docker? To me, Android and alike just have a good separation between processes. This is, of course, the core of linux containers. But I don't need to deploy a system image to run an Android application.
- riskable 11y ago
  Snappy packages are definitely containers in the sense that they 'contain' an application along with all its (runtime library) dependencies. Think of containers in order of size/scope like this: 1. Physical appliances. 2. Virtual machine images. 3. Docker images. 4. Snappy packages (and similar) At the top we have an actual physical piece of vendor-chosen hardware that "contains" a vendor-controlled application and execution environment. The end user has almost no control. Then comes virtual machine images which "contain" a vendor-controlled application inside a vendor-chosen operating system. Up next we have Docker images which "contain" a vendor-chosen execution environment and application but run inside the end user's chosen operating system (in a special sandbox). Lastly we have Snappy packages which "contain" an application and it's build/run time dependencies but run just like a regular application with user-controlled restrictions (via AppArmor).
  - e12e 11y ago
    As docker still doesn't really provide security (by design) - the main thing that docker brings with it is an awareness of dependencies. Now anyone can whip up a microservice that's ready to run in chroot, with minimal access to the rest of the system. Looks like Snappy packages does much the same thing. Try to hand-craft a chroot for Firefox, and see how far you get (at least without cheating and doing something like xhost+). Even some daemons can be a bit of work do chroot - eg: a working webserver/webapp-server with php that needs to resize images (pictures). If we can get more people to target docker/snappy (and we do) we get more applications and daemons that are easy(ish) to run in a chroot (or jail).
    - nickstinemates 11y ago
      Can you point to the security tradeoff/design decisions regarding Docker? I would really appreciate it.
      - e12e 11y ago
        First there was OpenVZ, then there was LXC - which essentially allow running an isolated instance of the kernel (very much like BSD jails). LXC can be locked down with capabilities, kernel namespaces, cgroups, and allow for quite fine-grained isolation. But the focus of Docker is more on use ability: the equivalent of asking a process to sit in the corner and stare at the wall. It's an easy way to get a lot of unruly children to stop interfering with each other, if you have many corners. But they're kind-a-sorta still in the same room. Not chained to their desks, not blindfolded. But generally, docker doesn't do all that much locking down - if you have the libc/code to do something in a docker container, you can in general do it. The layered fs is mostly like a chroot - it's safe as long as the kernel is safe, and then it's completely unsafe - if the kernel isn't safe. The flip side of this is that if you write a program/daemon that works on regular gnu/linux, it'll work (as long as you provide the needed library code) in a docker container. And docker helps focus dependencies, in particular data dependencies (the other tricky part of getting something to run in a chroot - where's /etc/shadow? Where's /etc/group etc)). I'm sure we'll see Docker move in a stricter direction, as more people are wrapping their minds around isolation -- apart from the running under same kernel, LXC can do more. And we have things like rkt with kvm backend that takes all the hard work put into containers and magically(ish) transplants that to work with minimal vms. Docker did/do(?) one thing: it didn't allow you to run Docker in docker (you need/needed to run a "privileged" container for that). I'm not sure if that was as coherent as what you hoped for, but that's sort of what I tried to imply wrt design tradeoff.

motoboi 11y ago

Is this really containerization as we know it, like Docker? To me, Android and alike just have a good separation between processes. This is, of course, the core of linux containers. But I don't need to deploy a system image to run an Android application.

riskable 11y ago
Snappy packages are definitely containers in the sense that they 'contain' an application along with all its (runtime library) dependencies. Think of containers in order of size/scope like this: 1. Physical appliances. 2. Virtual machine images. 3. Docker images. 4. Snappy packages (and similar) At the top we have an actual physical piece of vendor-chosen hardware that "contains" a vendor-controlled application and execution environment. The end user has almost no control. Then comes virtual machine images which "contain" a vendor-controlled application inside a vendor-chosen operating system. Up next we have Docker images which "contain" a vendor-chosen execution environment and application but run inside the end user's chosen operating system (in a special sandbox). Lastly we have Snappy packages which "contain" an application and it's build/run time dependencies but run just like a regular application with user-controlled restrictions (via AppArmor).
- e12e 11y ago
  As docker still doesn't really provide security (by design) - the main thing that docker brings with it is an awareness of dependencies. Now anyone can whip up a microservice that's ready to run in chroot, with minimal access to the rest of the system. Looks like Snappy packages does much the same thing. Try to hand-craft a chroot for Firefox, and see how far you get (at least without cheating and doing something like xhost+). Even some daemons can be a bit of work do chroot - eg: a working webserver/webapp-server with php that needs to resize images (pictures). If we can get more people to target docker/snappy (and we do) we get more applications and daemons that are easy(ish) to run in a chroot (or jail).
  - nickstinemates 11y ago
    Can you point to the security tradeoff/design decisions regarding Docker? I would really appreciate it.
    - e12e 11y ago
      First there was OpenVZ, then there was LXC - which essentially allow running an isolated instance of the kernel (very much like BSD jails). LXC can be locked down with capabilities, kernel namespaces, cgroups, and allow for quite fine-grained isolation. But the focus of Docker is more on use ability: the equivalent of asking a process to sit in the corner and stare at the wall. It's an easy way to get a lot of unruly children to stop interfering with each other, if you have many corners. But they're kind-a-sorta still in the same room. Not chained to their desks, not blindfolded. But generally, docker doesn't do all that much locking down - if you have the libc/code to do something in a docker container, you can in general do it. The layered fs is mostly like a chroot - it's safe as long as the kernel is safe, and then it's completely unsafe - if the kernel isn't safe. The flip side of this is that if you write a program/daemon that works on regular gnu/linux, it'll work (as long as you provide the needed library code) in a docker container. And docker helps focus dependencies, in particular data dependencies (the other tricky part of getting something to run in a chroot - where's /etc/shadow? Where's /etc/group etc)). I'm sure we'll see Docker move in a stricter direction, as more people are wrapping their minds around isolation -- apart from the running under same kernel, LXC can do more. And we have things like rkt with kvm backend that takes all the hard work put into containers and magically(ish) transplants that to work with minimal vms. Docker did/do(?) one thing: it didn't allow you to run Docker in docker (you need/needed to run a "privileged" container for that). I'm not sure if that was as coherent as what you hoped for, but that's sort of what I tried to imply wrt design tradeoff.