9 ms·

* If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a co

* If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write. * We have a whole lot of HTTP services in a range of languages. Managing them all with fat binaries would be a chore - the author would have to give me a way to set port and listen address, and I have to keep track of every way to set a port. With a net namespace and clever iptables routing, docker can do that for me. * sometimes, I have to deploy and insecure app. Usually, it's a badly configured memcache or similar. With net namespaces, I can make sure only a certain server has access to that service, and that the service cannot ruin my host server. * Its possible for me to namespace everything myself with unshare(1) and "ip netns" and cgroups and chroot and iptables... but that would consume all my available time. Docker can do that for me. * When you reach more then 20 or so services to keep track of, you need tools to help you out. * load balancing. Luckily, I don't have to deal with extreme network loads which would require hand-made solutions, but just pushing up that number a little to do ad-hoc load balance makes things a lot easier.

dsr_ 9y ago
This argument appears to be: when the application is crap, putting it in a container lets me deal with it without getting my hands dirty. This is probably true, but it isn't good.
- geofft 9y ago
  Why is it not good? It is in line with the robustness / Worse-is-Better ethos, and importantly, it lets you get on with delivering business value, which is what we're supposed to be doing. (At least in a business context. If you want to rewrite code to perfection on weekends, for fun, so do I, I am all for that, but that's almost never what my employer needs.)
  - lightedman 9y ago
    "Why is it not good?" Because it still allows the base problem of crap coding practice to proliferate.
    - gcb0 9y ago
      and don't forget that crap code == insecure code. but nobody have to worry about it. just start a container the last guy left. /sarcasm
      - geofft 9y ago
        > and don't forget that crap code == insecure code. I don't think I believe that equality is nearly as neat you'd hope. Unless we're willing to call all code crap code, a lot of projects with well-respected code and development practices have had serious zero days, and we've also found that sandboxing software is highly effective. Insecure code in a secure, well-written sandbox can get you a secure deployment, and you probably want to have your "good" code in a well-written sandbox anyway.
        gcb0 9y ago
        zero days and the privilege escalation are a luxury. bad code is often plaged with injection/sql injection. Which sandbox does an absolute NOTHING to protect you from. After all, it is all within the expected side effects of your code.
        bm1362 9y ago
        What does this have to do with Docker then?
        gcb0 9y ago
        because a flawed argument in defense of containers is that it is safer, since it's harder to escalate priviledges. my point is that false sense of security makes it even easier for an attacker to use readily available privileges in the badly coded application.
- eeZah7Ux 9y ago
  Spot on. Both fat binaries and containers very often translate in: "Nobody here cares about security. We deploy opaque blobs that will be unmaintained."
- twic 9y ago
  This seems to be the main point of the article to me. If your language's toolchain makes it easy to make sufficiently* self-contained 'fat binaries' (like Go or Java), then Docker doesn't add much. If it doesn't, like Ruby or Python, then Docker is very useful. * 'sufficiently' is doing a lot of work here. Go binaries might still need libc; Java tars-of-jars (or fat jars, if you're confused) still need a JVM, which needs a handful of shared libraries. But those things are relatively stable, generally backward-compatible, and one single big thing (libc or JVM), so it's fairly easy to manage having multiple versions installed anyway. More than zero work? Yes. Less work than managing a Kubernetes or Docker installation? Also yes.
notyourday 9y ago
> * If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write. Of course you do, you just moved the logic into the "orchestration" and "management" layer. You still need to write the code to correctly handle it. Throwing K8S at it is putting lipstick on a pig. It is still a pig. > * We have a whole lot of HTTP services in a range of languages. Managing them all with fat binaries would be a chore - the author would have to give me a way to set port and listen address, and I have to keep track of every way to set a port. With a net namespace and clever iptables routing, docker can do that for me. Nope, you wrote a set of rules and as long as everyone adheres to those rules things kind of work ( in a clever way ). Of course if you had the same kind of rules written and followed in any other method, you would arrive at the exactly the same place. In fact, you probably would arrive at a better place because you would stop thinking that your application works because of some clever namespace and iptables thing. > * sometimes, I have to deploy and insecure app. Usually, it's a badly configured memcache or similar. With net namespaces, I can make sure only a certain server has access to that service, and that the service cannot ruin my host server. You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container. > load balancing. Luckily, I don't have to deal with extreme network loads which would require hand-made solutions, but just pushing up that number a little to do ad-hoc load balance makes things a lot easier The time to build a template and instrumentation for your haproxy/nginx/varnish layer is when you don't have enough traffic and enough complexities.
- snuxoll 9y ago
  > You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container. I can guarantee it pretty well on my RHEL and CentOS systems, SELinux prevents containers from accessing things they shouldn’t just like it prevents Apache from dumping /etc/passwd.
  - lightedman 9y ago
    "I can guarantee it pretty well on my RHEL and CentOS systems" Slashdot tried that with CentOS and failed miserably. I have my doubts regarding your guarantee.
pacala 9y ago
Extra scenarios: * Not all our libraries are available in the same ecosystem. We need to mix JVM with C++ with a sprinkle of Python [via jep]. * We run a lot of small variations over the same code base. We'd rather not wait to re-deploy 99% of a fat binary for each run.
- seabrookmx 9y ago
  Another good point is that Docker's layered filesystem allows for caching that greatly benefits the use case you're describing. We have an old .net app we pushed to servers via zip files, and the sheer size of the zip ended up being a burden after many deployments. Docker's caching and "docker prune" make things a lot easier.

dsr_ 9y ago

This argument appears to be: when the application is crap, putting it in a container lets me deal with it without getting my hands dirty. This is probably true, but it isn't good.

geofft 9y ago
Why is it not good? It is in line with the robustness / Worse-is-Better ethos, and importantly, it lets you get on with delivering business value, which is what we're supposed to be doing. (At least in a business context. If you want to rewrite code to perfection on weekends, for fun, so do I, I am all for that, but that's almost never what my employer needs.)
- lightedman 9y ago
  "Why is it not good?" Because it still allows the base problem of crap coding practice to proliferate.
  - gcb0 9y ago
    and don't forget that crap code == insecure code. but nobody have to worry about it. just start a container the last guy left. /sarcasm
    - geofft 9y ago
      > and don't forget that crap code == insecure code. I don't think I believe that equality is nearly as neat you'd hope. Unless we're willing to call all code crap code, a lot of projects with well-respected code and development practices have had serious zero days, and we've also found that sandboxing software is highly effective. Insecure code in a secure, well-written sandbox can get you a secure deployment, and you probably want to have your "good" code in a well-written sandbox anyway.
      - gcb0 9y ago
        zero days and the privilege escalation are a luxury. bad code is often plaged with injection/sql injection. Which sandbox does an absolute NOTHING to protect you from. After all, it is all within the expected side effects of your code.
        bm1362 9y ago
        What does this have to do with Docker then?
        gcb0 9y ago
        because a flawed argument in defense of containers is that it is safer, since it's harder to escalate priviledges. my point is that false sense of security makes it even easier for an attacker to use readily available privileges in the badly coded application.
eeZah7Ux 9y ago
Spot on. Both fat binaries and containers very often translate in: "Nobody here cares about security. We deploy opaque blobs that will be unmaintained."
twic 9y ago
This seems to be the main point of the article to me. If your language's toolchain makes it easy to make sufficiently* self-contained 'fat binaries' (like Go or Java), then Docker doesn't add much. If it doesn't, like Ruby or Python, then Docker is very useful. * 'sufficiently' is doing a lot of work here. Go binaries might still need libc; Java tars-of-jars (or fat jars, if you're confused) still need a JVM, which needs a handful of shared libraries. But those things are relatively stable, generally backward-compatible, and one single big thing (libc or JVM), so it's fairly easy to manage having multiple versions installed anyway. More than zero work? Yes. Less work than managing a Kubernetes or Docker installation? Also yes.

notyourday 9y ago

> * If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write. Of course you do, you just moved the logic into the "orchestration" and "management" layer. You still need to write the code to correctly handle it. Throwing K8S at it is putting lipstick on a pig. It is still a pig. > * We have a whole lot of HTTP services in a range of languages. Managing them all with fat binaries would be a chore - the author would have to give me a way to set port and listen address, and I have to keep track of every way to set a port. With a net namespace and clever iptables routing, docker can do that for me. Nope, you wrote a set of rules and as long as everyone adheres to those rules things kind of work ( in a clever way ). Of course if you had the same kind of rules written and followed in any other method, you would arrive at the exactly the same place. In fact, you probably would arrive at a better place because you would stop thinking that your application works because of some clever namespace and iptables thing. > * sometimes, I have to deploy and insecure app. Usually, it's a badly configured memcache or similar. With net namespaces, I can make sure only a certain server has access to that service, and that the service cannot ruin my host server. You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container. > load balancing. Luckily, I don't have to deal with extreme network loads which would require hand-made solutions, but just pushing up that number a little to do ad-hoc load balance makes things a lot easier The time to build a template and instrumentation for your haproxy/nginx/varnish layer is when you don't have enough traffic and enough complexities.

snuxoll 9y ago
> You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container. I can guarantee it pretty well on my RHEL and CentOS systems, SELinux prevents containers from accessing things they shouldn’t just like it prevents Apache from dumping /etc/passwd.
- lightedman 9y ago
  "I can guarantee it pretty well on my RHEL and CentOS systems" Slashdot tried that with CentOS and failed miserably. I have my doubts regarding your guarantee.

pacala 9y ago

Extra scenarios: * Not all our libraries are available in the same ecosystem. We need to mix JVM with C++ with a sprinkle of Python [via jep]. * We run a lot of small variations over the same code base. We'd rather not wait to re-deploy 99% of a fat binary for each run.

seabrookmx 9y ago
Another good point is that Docker's layered filesystem allows for caching that greatly benefits the use case you're describing. We have an old .net app we pushed to servers via zip files, and the sheer size of the zip ended up being a burden after many deployments. Docker's caching and "docker prune" make things a lot easier.