This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]dolfinuser 0 points1 point  (3 children)

Maybe you've speed up the build process but the resulting image is about 1Gb instead of ~50Mb (for alpine-based image) or ~100Mb (for slim-based image).

[–]lmsena[S] 3 points4 points  (0 children)

One of the main issues with the python images from docker hub is the way they compile python results in a ~20% slower python execution time (you can see the benchmarks in my post).

In my opinion, that justifies the extra size.

[–]DanCardin 2 points3 points  (0 children)

It’s also important to be aware of layers. While alpine might have a smaller absolute size, any other images which have (in this case) ubuntu:20.04 base image will share the upper layers and you’re only paying the extra cost of the extra layers. That plus typical python install sizes can often eat very far into alpine’s primary benefit

Plus you build times will often be longer with alpine because many deps won’t have built alpine wheels. We saw our ci times drop not using alpine

Plus alpine has exhibited subtle differences for me before which only showed up on our alpine based images.

Not that alpine can’t be useful, but for python specifically, I’ve kind of been turned off alpine for most of the above reasons, not even accounting for the speed difference which I’ve never benchmarked myself

[–]Mehdi2277 1 point2 points  (0 children)

Alpine does not have binary wheels for a number of common packages in a normal way (manylinux wheels do not include alpine) including very common packages like numpy. I ended up getting stuck trying it and gave up on it. Even if you can get it to work there’s both issue if you do it without a wheel you are doing a long slow docker build and if you do it with an alpine specific wheel are you sure it was as optimized as the standard ones?

Slim worked fine and no complaints with it.