3 ms·

I was really upset when I ran into this problem with Docker. Like, I thought the whole point of virtualization was that, no matter how old it is, it will Just W

by SilasX 5y ago

I was really upset when I ran into this problem with Docker. Like, I thought the whole point of virtualization was that, no matter how old it is, it will Just Work, so long as the virtualization software works, and it has enough resources. It’s supposed to sidestep the problem having to constantly patch everything that might have changed since. Then one day, our startup brought some new employees on, who read the README and ran the indicated Docker command … and it failed with a mysterious bug requiring dev resources to debug! The exact thing you try to avoid by freezing the machine environment. It turned out that Docker had silently pushed a backward-incompatible change in the format of docker-compose YAML files.

seba_dos1 5y ago
That's not what containerization is about as can be easily demonstrated by simply running your container on a kernel that's built without some config option you rely on.
- SilasX 5y ago
  Wait, what? So this isn’t a problem because you can just make a container for your containers that preserves the original API? Then what do you depend on for that container? It’s like Office Space, “what would you say it is you do here?”
  - hedora 5y ago
    Containers standardize user space, and let processes think they're listening on ports that are already taken. They do some resource isolation, and provide similar security guarantees as painting the back of your laptop with snake oil. They don't help at all with kernel API drift, and barely help with libc drift.
    - SilasX 5y ago
      I didn’t say anything about security guarantees. Where did that come from? You’re saying that using a container — which defines a specific version of an OS — shouldn’t protect against differences between that version and a new OS version? And shouldn’t save any effort whatsoever in reproducing the environment in which I got code working? The sole purpose is so that I can leave an app configured to talk to port 8000 even though my machine is already using port 8000? That feels like it falls short of the conventional case for virtualization or containerization.
      - seba_dos1 5y ago
        > shouldn’t protect against differences between that version and a new OS version What does "should" in this context even mean? They don't, because they're not meant to do that. They can be used to shield you from some differences, and for many use cases that subset is all that matters, but they don't and can't shield you from all of them.
        SilasX 5y ago
        I was asking to clarify what your very confusing sentence meant. Because it seemed to be saying that, if I define a VM to use OS 1.2.3, because I know my app will work with that version, then my app on that VM should cease to work when 1.3.0 is released. And that seems dubious.
        seba_dos1 5y ago
        You seem to confuse containers with virtual machines. Those are very different concepts that solve different problems. You can't rely on containers alone if your goal is to ensure that your app will work on future operating systems. That's not something containers do. They only let you provide your own user space to run in a quasi-isolated environment, no more than that. You're still using the host's kernel which can still screw you up in multitude of ways (which is exactly what I said in my earlier comment), and you're still limited by API guarantees that the tools you use to make containers are providing you.
        hedora 5y ago
        This can definetly happen in both directions (kernel too old, app too old). For example, apache can no longer run with SSL enabled on current synology NAS's docker environments.
      - hedora 5y ago
        You asked what they do. One of the main selling points is security. (They don't do much for security, but that sort of thing doesn't matter much to sales). The most useful feature is they reduce the pain associated having negligently-large build and runtime dependency trees. They also add a few ulimit style tricks. Think "better than chroot, arguably worse than BSD jails", but with a standardized cross-linux-distro build system (dockerfiles)

by SilasX 5y ago

seba_dos1 5y ago

That's not what containerization is about as can be easily demonstrated by simply running your container on a kernel that's built without some config option you rely on.

SilasX 5y ago
Wait, what? So this isn’t a problem because you can just make a container for your containers that preserves the original API? Then what do you depend on for that container? It’s like Office Space, “what would you say it is you do here?”
- hedora 5y ago
  Containers standardize user space, and let processes think they're listening on ports that are already taken. They do some resource isolation, and provide similar security guarantees as painting the back of your laptop with snake oil. They don't help at all with kernel API drift, and barely help with libc drift.
  - SilasX 5y ago
    I didn’t say anything about security guarantees. Where did that come from? You’re saying that using a container — which defines a specific version of an OS — shouldn’t protect against differences between that version and a new OS version? And shouldn’t save any effort whatsoever in reproducing the environment in which I got code working? The sole purpose is so that I can leave an app configured to talk to port 8000 even though my machine is already using port 8000? That feels like it falls short of the conventional case for virtualization or containerization.
    - seba_dos1 5y ago
      > shouldn’t protect against differences between that version and a new OS version What does "should" in this context even mean? They don't, because they're not meant to do that. They can be used to shield you from some differences, and for many use cases that subset is all that matters, but they don't and can't shield you from all of them.
      - SilasX 5y ago
        I was asking to clarify what your very confusing sentence meant. Because it seemed to be saying that, if I define a VM to use OS 1.2.3, because I know my app will work with that version, then my app on that VM should cease to work when 1.3.0 is released. And that seems dubious.
        seba_dos1 5y ago
        You seem to confuse containers with virtual machines. Those are very different concepts that solve different problems. You can't rely on containers alone if your goal is to ensure that your app will work on future operating systems. That's not something containers do. They only let you provide your own user space to run in a quasi-isolated environment, no more than that. You're still using the host's kernel which can still screw you up in multitude of ways (which is exactly what I said in my earlier comment), and you're still limited by API guarantees that the tools you use to make containers are providing you.
        hedora 5y ago
        This can definetly happen in both directions (kernel too old, app too old). For example, apache can no longer run with SSL enabled on current synology NAS's docker environments.
    - hedora 5y ago
      You asked what they do. One of the main selling points is security. (They don't do much for security, but that sort of thing doesn't matter much to sales). The most useful feature is they reduce the pain associated having negligently-large build and runtime dependency trees. They also add a few ulimit style tricks. Think "better than chroot, arguably worse than BSD jails", but with a standardized cross-linux-distro build system (dockerfiles)