5 ms·

I enjoy reading descriptions such as these that start with easily detectable problems and go into a level of debugging far beyond my skill level. Helps to illum

I enjoy reading descriptions such as these that start with easily detectable problems and go into a level of debugging far beyond my skill level. Helps to illuminate some of those "unknown unknowns" that I didn't even ever consider before.

daddykotex 9y ago
I had the exact same feeling. Well written OP.
oneplane 9y ago
I had the same feeling, but this also reinforced my view that Docker and containerization in general (often used as a scapegoat to not have to do proper configuration management) 'for the masses' is more problematic than helpful. In most cases it doesn't solve anything but does add problems that can be hard to debug. The actual 'lack' of isolation wouldn't have happened with true virtualisation, and the method of debugging here is something most people that think they need containers won't have. To me, debugging like this is something that should be far more important to people than slinging words like Docker and NodeJS around all day. (and then mostly on Discord, or to them, the older Slack, but not IRC because that is too hard for that crowd -- totally unfounded opinion/rant)
- dasil003 9y ago
  Docker didn't cause this problem, the point of the article is that Docker doesn't prevent all such problems. On the other hand it does solve a lot of packaging, dependency and environment parity problems that traditional virtualization is too heavy to accomplish. I'm old enough to also be frustrated with buzzword driven development, and it's pretty annoying that so many believe Docker invented containerization, but don't throw the baby out with the bathwater. Containerization is an awesome tool and orthogonal to config management.
  - eropple 9y ago
    Traditional virtualization is "too heavy", now, for solved problems like packaging? How and why?
    - omginternets 9y ago
      For the reasons mentioned in the article: - slow (re)start times - greater resource consumption Granted, "too heavy" is relative, but starting a few hundred VMs on a single host (assuming commodity hardware) is not going to work very well.
      - user5994461 9y ago
        That works just fine. It's typical in a VM farm to have hosts with a hundred VMs.
        omginternets 9y ago
        >It's typical in a VM farm to have hosts with a hundred VMs. Several things: 1. We may have a different definition of "commodity hardware", but you're missing the broader point. 2. The broader point is that VMs are significantly less resource-efficient. 3. 1 & 2 notwithstanding, you're conveniently ignoring the issue of (re)start time 4. It's fine to use VMs, but it's frankly bizarre to fight tooth-and-nail over the ridiculous notion that they should always be preferred over containers.
        user5994461 9y ago
        I am simply addressing the fact that it's perfectly fine and common to have hosts with a hundred VMs and it works flawlessly. VMs are memory intensive because they duplicate the operating system. The starting point is around 500 MB per VM. That's the only meaningful difference in resources compared to containers. I am not discussing that they have different starting and stopping time.
        omginternets 9y ago
  - eikenberry 9y ago
    +1. Docker is not Docker-Swarm/Kubernetes.
  - deleted 9y ago
    [deleted]
  - AlphaSite 9y ago
    Hey, there are plenty of solutions which combine the best of both worlds; for example https://www.vmware.com/products/vsphere/integrated-containers.html https://www.vmware.com/products/vsphere/integrated-container...
    - icebraining 9y ago
      How is that the best? You're still running a full kernel for each container, rather than sharing it.
      - gaius 9y ago
        But, so what? VMWare under the hood is sharing common pages between VMs, and a kernel that isn't doing anything isn't consuming any CPU, so why not?
        icebraining 9y ago
        Nope, common pages are no longer shared between VMs, because it was demonstrated that was a bad idea, security-wise: upcoming ESXi Update releases will no longer enable TPS between Virtual Machines by default https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2080735 https://kb.vmware.com/selfservice/microsites/search.do?langu...
        AstralStorm 9y ago
        Guess what, if it is a bad idea for a VM, it must be exponentially worse for something less isolated.
        icebraining 9y ago
        Yes. Thankfully, the point is that using the regular container model you don't need memory page sharing, because there's only one kernel anyway, not a copy per each container.
- bogomipz 9y ago
  >"I had the same feeling, but this also reinforced my view that Docker and containerization in general (often used as a scapegoat to not have to do proper configuration management) 'for the masses' is more problematic than helpful. In most cases it doesn't solve anything but does add problems that can be hard to debug." The issue described in this post has nothing to do with "config management vs containers." Its' odd that this article would have "reinforced" that view. How would configuration management have prevented a noisy neighbor? From the summary: "The core lesson of this story: just because you are using containers and you get the impression that your applications are perfectly virtualized and isolated, don’t assume the kernel is fully isolating every underlying resource at a container granularity." and "Luckily, the solution is there and rather simple: make sure to deeply monitor all your applications." That's nothing to do with any "configuration management vs containers" argument and everything to do with proper metrics collection and monitoring, which should be part of every "operational readiness" checklist whether Docker is used or not. Lastly saying that Docker "In most cases it doesn't solve anything" is an absurd statement. Do you believe that virtualization does't solve any problems? If so why do you imagine the Linux kernel supports it?
  - gaius 9y ago
    just because you are using containers and you get the impression that your applications are perfectly virtualized and isolated Anyone who believes in the first place this shouldn't be running production systems...
    - bogomipz 9y ago
      Your comment contains two sentence fragments, neither of which is coherent.
      - gaius 9y ago
        Seems perfectly straightforward. If you believe containers give you the level of isolation that VMs would, then you have fundamental misunderstandings of the technology which in a sane organisation would preclude you from operating important systems.
- user5994461 9y ago
  sysdig is a monitoring system for docker that sells for $25 per month per host. Part of the debugging method has to do with "let's show our product".

daddykotex 9y ago

I had the exact same feeling. Well written OP.

oneplane 9y ago

I had the same feeling, but this also reinforced my view that Docker and containerization in general (often used as a scapegoat to not have to do proper configuration management) 'for the masses' is more problematic than helpful. In most cases it doesn't solve anything but does add problems that can be hard to debug. The actual 'lack' of isolation wouldn't have happened with true virtualisation, and the method of debugging here is something most people that think they need containers won't have. To me, debugging like this is something that should be far more important to people than slinging words like Docker and NodeJS around all day. (and then mostly on Discord, or to them, the older Slack, but not IRC because that is too hard for that crowd -- totally unfounded opinion/rant)

dasil003 9y ago
Docker didn't cause this problem, the point of the article is that Docker doesn't prevent all such problems. On the other hand it does solve a lot of packaging, dependency and environment parity problems that traditional virtualization is too heavy to accomplish. I'm old enough to also be frustrated with buzzword driven development, and it's pretty annoying that so many believe Docker invented containerization, but don't throw the baby out with the bathwater. Containerization is an awesome tool and orthogonal to config management.
- eropple 9y ago
  Traditional virtualization is "too heavy", now, for solved problems like packaging? How and why?
  - omginternets 9y ago
    For the reasons mentioned in the article: - slow (re)start times - greater resource consumption Granted, "too heavy" is relative, but starting a few hundred VMs on a single host (assuming commodity hardware) is not going to work very well.
    - user5994461 9y ago
      That works just fine. It's typical in a VM farm to have hosts with a hundred VMs.
      - omginternets 9y ago
        >It's typical in a VM farm to have hosts with a hundred VMs. Several things: 1. We may have a different definition of "commodity hardware", but you're missing the broader point. 2. The broader point is that VMs are significantly less resource-efficient. 3. 1 & 2 notwithstanding, you're conveniently ignoring the issue of (re)start time 4. It's fine to use VMs, but it's frankly bizarre to fight tooth-and-nail over the ridiculous notion that they should always be preferred over containers.
        user5994461 9y ago
        I am simply addressing the fact that it's perfectly fine and common to have hosts with a hundred VMs and it works flawlessly. VMs are memory intensive because they duplicate the operating system. The starting point is around 500 MB per VM. That's the only meaningful difference in resources compared to containers. I am not discussing that they have different starting and stopping time.
        omginternets 9y ago
- eikenberry 9y ago
  +1. Docker is not Docker-Swarm/Kubernetes.
- deleted 9y ago
  [deleted]
- AlphaSite 9y ago
  Hey, there are plenty of solutions which combine the best of both worlds; for example https://www.vmware.com/products/vsphere/integrated-containers.html https://www.vmware.com/products/vsphere/integrated-container...
  - icebraining 9y ago
    How is that the best? You're still running a full kernel for each container, rather than sharing it.
    - gaius 9y ago
      But, so what? VMWare under the hood is sharing common pages between VMs, and a kernel that isn't doing anything isn't consuming any CPU, so why not?
      - icebraining 9y ago
        Nope, common pages are no longer shared between VMs, because it was demonstrated that was a bad idea, security-wise: upcoming ESXi Update releases will no longer enable TPS between Virtual Machines by default https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2080735 https://kb.vmware.com/selfservice/microsites/search.do?langu...
        AstralStorm 9y ago
        Guess what, if it is a bad idea for a VM, it must be exponentially worse for something less isolated.
        icebraining 9y ago
        Yes. Thankfully, the point is that using the regular container model you don't need memory page sharing, because there's only one kernel anyway, not a copy per each container.
bogomipz 9y ago
>"I had the same feeling, but this also reinforced my view that Docker and containerization in general (often used as a scapegoat to not have to do proper configuration management) 'for the masses' is more problematic than helpful. In most cases it doesn't solve anything but does add problems that can be hard to debug." The issue described in this post has nothing to do with "config management vs containers." Its' odd that this article would have "reinforced" that view. How would configuration management have prevented a noisy neighbor? From the summary: "The core lesson of this story: just because you are using containers and you get the impression that your applications are perfectly virtualized and isolated, don’t assume the kernel is fully isolating every underlying resource at a container granularity." and "Luckily, the solution is there and rather simple: make sure to deeply monitor all your applications." That's nothing to do with any "configuration management vs containers" argument and everything to do with proper metrics collection and monitoring, which should be part of every "operational readiness" checklist whether Docker is used or not. Lastly saying that Docker "In most cases it doesn't solve anything" is an absurd statement. Do you believe that virtualization does't solve any problems? If so why do you imagine the Linux kernel supports it?
- gaius 9y ago
  just because you are using containers and you get the impression that your applications are perfectly virtualized and isolated Anyone who believes in the first place this shouldn't be running production systems...
  - bogomipz 9y ago
    Your comment contains two sentence fragments, neither of which is coherent.
    - gaius 9y ago
      Seems perfectly straightforward. If you believe containers give you the level of isolation that VMs would, then you have fundamental misunderstandings of the technology which in a sane organisation would preclude you from operating important systems.
user5994461 9y ago
sysdig is a monitoring system for docker that sells for $25 per month per host. Part of the debugging method has to do with "let's show our product".