4 ms·

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

by 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.

by 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.