7 ms·

Django drives the choice here. Batteries included, huge community support, and AMAZING documentation. Half the software I write is from stackoverflow. LOL I do

Django drives the choice here. Batteries included, huge community support, and AMAZING documentation. Half the software I write is from stackoverflow. LOL I dont see dockerizing as a problem. Once copied out from my template I never think about it. I do admit that familarity with the underlying Image OS (Debian in this case) makes debugging / fussing about a non-issue.

cbushko 6y ago
For local development that debian container is fine but for production you want something small like scratch or alpine. The fewer binaries in the container, the better and more secure. This is one of the benefits of golang. You compile it into a binary and copy just the binary into your scratch container. Maybe it is 20MB in size.
- simplecto 6y ago
  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.
- AYBABTME 6y ago
  There's no difference between a 1000MB or 10MB image, aside from how much time it takes to download new versions and how much disk space it uses.
  - CameronNemo 6y ago
    Debian slim is certainly not 1GB. It is maybe 50-60MB larger than Alpine. And that is shared if you have multiple containers based on Debian slim.
    - AYBABTME 6y ago
      I didn't mention any specific distro. However, lots of ppl use ubuntu as a base image, or other non-slim images. It's not what I do but it's a reality.
- wiredfool 6y ago
  It depends what you're optimizing for. Alpine is subtly different for python builds: * It uses musl-c. It's not glibc, it's different. Not necessarily better or worse. * You can't use manylinux1 wheels with alpine, so if you've got python/c extensions, you're going to be building them instead of installing upstream binaries. So cue the need for a dev toolchain, and a much longer install time. And once you have all that, you're running a different version in dev/prod, which is one of those things that docker is supposed to be good at fixing.

cbushko 6y ago

For local development that debian container is fine but for production you want something small like scratch or alpine. The fewer binaries in the container, the better and more secure. This is one of the benefits of golang. You compile it into a binary and copy just the binary into your scratch container. Maybe it is 20MB in size.

simplecto 6y ago
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.
AYBABTME 6y ago
There's no difference between a 1000MB or 10MB image, aside from how much time it takes to download new versions and how much disk space it uses.
- CameronNemo 6y ago
  Debian slim is certainly not 1GB. It is maybe 50-60MB larger than Alpine. And that is shared if you have multiple containers based on Debian slim.
  - AYBABTME 6y ago
    I didn't mention any specific distro. However, lots of ppl use ubuntu as a base image, or other non-slim images. It's not what I do but it's a reality.
wiredfool 6y ago
It depends what you're optimizing for. Alpine is subtly different for python builds: * It uses musl-c. It's not glibc, it's different. Not necessarily better or worse. * You can't use manylinux1 wheels with alpine, so if you've got python/c extensions, you're going to be building them instead of installing upstream binaries. So cue the need for a dev toolchain, and a much longer install time. And once you have all that, you're running a different version in dev/prod, which is one of those things that docker is supposed to be good at fixing.