4 ms·
> If you have one image based on Ubuntu in your stack, you may as well base them all on Ubuntu, because you only need to download (and store!) the common base i
by dharmab 3y ago
> If you have one image based on Ubuntu in your stack, you may as well base them all on Ubuntu, because you only need to download (and store!) the common base image once
This is only true if your infrastructure is static. If your infrastructure is highly elastic, image size has an impact on your time to scale up. A great example is using spot instances; in my line of work we need to create thousands of spot instances to run many millions of time-sensitive batch jobs at certain times and dates, then scale those instances down rapidly to reduce the bill.
Of course, there are better choices than Alpine to optimize image size. Distroless (https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless) is a good example.
- chatmasta 3y agoThat's true. But the size difference between alpine and debian:*-slim (for example) is on the order of < 20mb. Datacenter hardware can download this in milliseconds. There may be some rare scenarios where this is a meaningful delay, but usually provisioning time is bottlenecked somewhere else. Heck, it probably takes longer to download the VM image (and if you're optimizing for provisioning speed, you shouldn't be downloading Docker images on boot anyway - you should be baking VM images ahead of time.)
- dharmab 3y agoBaking the VM images trades a lot of flexibility for some latency, and it doesn't apply to container-as-a-service infrastructure where you don't control the VM. My point is you can get most of the way there with slim/distroless without making the tradeoffs of Alpine, and that's probably enough for most use cases.
- pella 3y ago> But the size difference between alpine and debian:-slim (for example) is on the order of < 20mb. compressed size(amd64): 17.59MB vs. 45.35MB ( > 2.5x ) uncompressed size(amd64):52.00MB vs. 130.00MB ( > 2.5x ) $ docker images python:3.12.1* REPOSITORY TAG IMAGE ID CREATED SIZE python 3.12.1-alpine3.19 0108959914c2 2 weeks ago 51.7MB python 3.12.1-slim-bookworm 7c5c05471c3a 2 weeks ago 130MB**
- mikeravkine 3y agoThere is no difference in download time for 20mb vs 50mb in a datacenter, but the amount of time lost to alpine being "quirky" is incalculable.
- dharmab 3y agoThe compressed size is what matters when discussing image download time- CPUs made after around 2010 can uncompress files ludicrously quickly.
- chatmasta 3y agoThose are Python images. The base Debian slim image [0] is 28mb, compared to 3mb from Alpine [1]. So that's a difference of 25mb, or "on the order of 20mb." A machine in the datacenter will probably spend more time opening the connection to the registry than it will downloading that extra 25mb. [0] https://hub.docker.com/_/debian/tags https://hub.docker.com/_/debian/tags [1] https://hub.docker.com/_/alpine/tags https://hub.docker.com/_/alpine/tags
- pella 3y agoand check the "VULNERABILITIES" bookworm-slim : 0H 0M 19L VULNERABILITIES alpine 3.19.0 : No Vulnerabilities Found python:3.12.1-slim-bookworm : 0H 1M 22L VULNERABILITIES python:3.12.1-alpine3.19 : 0H 1M 0L VULNERABILITIES
- mkesper 3y agoDistroless is Debian packages with worse security and without package management.
- lkjasdlfwfasd 3y ago> without package management. distroless is for the TERMINAL layer, you should already be done with the package manager prior to entering distroless.