2 ms·

This feels very hand-wavey to me. I can patch and ship my docker images the same way I might patch a server. apt-get update && apt-get upgrade rinse, repeat.

This feels very hand-wavey to me. I can patch and ship my docker images the same way I might patch a server. apt-get update && apt-get upgrade rinse, repeat. Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not. The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my server load is still only 20%.

andrewzah 6y ago
"apt-get update && apt-get upgrade" You can do this exactly the same in alpine, with "apk update" and "apk add". "Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not." The default docker python image is 885MB. python:buster-slim is 114MB which is much more reasonable. Even if you're not "cramming resources", pushing 885MB vs 115MB vs 20MB across the wire does add up over time. In my case, we do quickly iterate and pull docker images so it does make a difference for my colleagues if the image is 30MB vs 500MB. Even if we're all on gigabit internet. "Cargo culting" implies doing it without knowing why we're doing it. The benefits of reducing the size of docker images is apparent to everyone, although there are diminishing returns. With dive[0] it is very easy to figure out where the waste is. "The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my server load is still only 20%. " Optimizing docker images has nothing to do with being over-provisioned. I will concede that it's very different as a solo developer vs even a small team. [0]: https://github.com/wagoodman/dive https://github.com/wagoodman/dive
- CameronNemo 6y ago
  Shouldn't the base image be cached? So you would not be pulling it all the time.
  - andrewzah 6y ago
    If it's cached, yes. However at my job we manage our own base images and we do update those somewhat frequently.
- hinkley 6y ago
  Not just over time, it adds time. Push new versions of one of those to 50 machines, versus the other.
cbushko 6y ago
Yes, you can patch them but with a compiled binary like go, you don't have to. You don't have to watch security lists for vulnerabilities. You don't have to scan your docker containers because the dockerfile is 4 lines long. You don't have to worry about a coworker adding a bad tool to your production container. That frees up cognitive load to write your code. Note: I am an infrastructure engineer for a small SaaS that builds and runs production.
- acdha 6y ago
  > Yes, you can patch them but with a compiled binary like go, you don't have to. > You don't have to watch security lists for vulnerabilities. These two statements are incompatible. You have fewer things to watch but you’re definitely still going to track your dependencies. Static linking still means you have to do that, and nobody else can do it for you.
  - cbushko 6y ago
    Not exactly. You have to watch your libraries for vulnerabilities no matter what language you use. Link or apt-getting the library will pull in a vulnerability I am more concerned about pulling in Linux binaries that are full of vulnerabilities.
    - acdha 6y ago
      This is a valid concern but in general you should be most worried about code you actually run. If you have curl in a container but your app only uses it during the startup process, the fact that it has an issue with, say, FTP almost certainly has no effect on you. OTOH, if you’re using something like libjpeg your Go code needs to be recompiled either way and you might have to manually backport a patch just like a Linux distribution will.
vageli 6y ago
It's not only about the resources allocated to your project. Bigger images also leads to longer deployment times, which increases the feedback loop for issues. Not to mention increased costs associated with storage, bandwidth, layer caching, etc.
- simplecto 6y ago
  I'm quite opinionated here, but these things only matter at significant scale. Most one-person-SaaS or SMEs never really graduates out of the first pricing tier for this stuff.

andrewzah 6y ago

"apt-get update && apt-get upgrade" You can do this exactly the same in alpine, with "apk update" and "apk add". "Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not." The default docker python image is 885MB. python:buster-slim is 114MB which is much more reasonable. Even if you're not "cramming resources", pushing 885MB vs 115MB vs 20MB across the wire does add up over time. In my case, we do quickly iterate and pull docker images so it does make a difference for my colleagues if the image is 30MB vs 500MB. Even if we're all on gigabit internet. "Cargo culting" implies doing it without knowing why we're doing it. The benefits of reducing the size of docker images is apparent to everyone, although there are diminishing returns. With dive[0] it is very easy to figure out where the waste is. "The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my server load is still only 20%. " Optimizing docker images has nothing to do with being over-provisioned. I will concede that it's very different as a solo developer vs even a small team. [0]: https://github.com/wagoodman/dive https://github.com/wagoodman/dive

CameronNemo 6y ago
Shouldn't the base image be cached? So you would not be pulling it all the time.
- andrewzah 6y ago
  If it's cached, yes. However at my job we manage our own base images and we do update those somewhat frequently.
hinkley 6y ago
Not just over time, it adds time. Push new versions of one of those to 50 machines, versus the other.

cbushko 6y ago

Yes, you can patch them but with a compiled binary like go, you don't have to. You don't have to watch security lists for vulnerabilities. You don't have to scan your docker containers because the dockerfile is 4 lines long. You don't have to worry about a coworker adding a bad tool to your production container. That frees up cognitive load to write your code. Note: I am an infrastructure engineer for a small SaaS that builds and runs production.

acdha 6y ago
> Yes, you can patch them but with a compiled binary like go, you don't have to. > You don't have to watch security lists for vulnerabilities. These two statements are incompatible. You have fewer things to watch but you’re definitely still going to track your dependencies. Static linking still means you have to do that, and nobody else can do it for you.
- cbushko 6y ago
  Not exactly. You have to watch your libraries for vulnerabilities no matter what language you use. Link or apt-getting the library will pull in a vulnerability I am more concerned about pulling in Linux binaries that are full of vulnerabilities.
  - acdha 6y ago
    This is a valid concern but in general you should be most worried about code you actually run. If you have curl in a container but your app only uses it during the startup process, the fact that it has an issue with, say, FTP almost certainly has no effect on you. OTOH, if you’re using something like libjpeg your Go code needs to be recompiled either way and you might have to manually backport a patch just like a Linux distribution will.

vageli 6y ago

It's not only about the resources allocated to your project. Bigger images also leads to longer deployment times, which increases the feedback loop for issues. Not to mention increased costs associated with storage, bandwidth, layer caching, etc.

simplecto 6y ago
I'm quite opinionated here, but these things only matter at significant scale. Most one-person-SaaS or SMEs never really graduates out of the first pricing tier for this stuff.