You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an issue thread I'd like to maintain for ideas for making the image smaller. It's currently a fairly chunky 134MB, most of which is Python and its Packages.
Ideas I've tried
Combining the sites-packages directories - Same size, much higher potential corruption possibilities
Using pip's --no-cache-dir option - The cache dir doesn't end up in /opt/venv, so it gets deleted during the multi-stage build process anyway, so it makes no difference
Ideas I haven't tried yet
Delete psutil earlier - This would remove the delete layer and psutil's footprint from the final image, saving about 1.5MB
Use system packages instead of pip install - They might be smaller and faster to install? Need to check what's available in Alpine's packages
Use a small alpine Python container and add Nginx on top of that instead - I don't think this will make much of a difference since python:alpine is already 49MB (the layer adding python+util-linux in the current Dockerfile adds 54MB, so there might be a couple of MB savings), but there might be smaller images that can be used as a base. This makes parity with nginx:alpine and Don't replace the entrypoint - add to the current one (current method breaks nginx:alpine's startup scripts) #1 more difficult though.
Use scratch instead of Alpine - that would be a fun weekend project. It's slightly out of the realm of this repository but definitely something I want to try.
Find a tree-shaking/bundling library - This is probably the most likely candidate, but that's based on my experience of JS, so iuno.
Current Layer Details
As of 12:47 12/09/22, makeshift27015/nginx-alpine-amplify:latest on amd64 looks like this, according to dive:
According to Dive, there's 2.6 MB we could potentially recover, but I think in practice that would be difficult. Most of the files that are being replaced between the base nginx:alpine layer and the apk add layer are python dependencies that get updated during install, eg ca-certificates and the Alpine installed db which I doubt I could do anything with. I could stop apk from updating these, but they're kinda nice to have up to date anyway.
The easiest option would be to recover as much of this 2.6 MB as possible would be to create another stage based on alpine:latest and simply copy / from the (current) final stage, but that's dirty as hell for 2.6MB and probably wouldn't recover that much because most of those files will exist in the base alpine image also.
Please reply with more ideas :)
The text was updated successfully, but these errors were encountered:
This is an issue thread I'd like to maintain for ideas for making the image smaller. It's currently a fairly chunky 134MB, most of which is Python and its Packages.
Ideas I've tried
sites-packages
directories - Same size, much higher potential corruption possibilities/opt/venv
, so it gets deleted during the multi-stage build process anyway, so it makes no differenceIdeas I haven't tried yet
delete
layer andpsutil
's footprint from the final image, saving about 1.5MBpython:alpine
is already 49MB (the layer adding python+util-linux in the current Dockerfile adds 54MB, so there might be a couple of MB savings), but there might be smaller images that can be used as a base. This makes parity withnginx:alpine
and Don't replace the entrypoint - add to the current one (current method breaksnginx:alpine
's startup scripts) #1 more difficult though.Current Layer Details
As of 12:47 12/09/22,
makeshift27015/nginx-alpine-amplify:latest
onamd64
looks like this, according to dive:According to Dive, there's 2.6 MB we could potentially recover, but I think in practice that would be difficult. Most of the files that are being replaced between the base
nginx:alpine
layer and theapk add
layer are python dependencies that get updated during install, egca-certificates
and the Alpine installed db which I doubt I could do anything with. I could stopapk
from updating these, but they're kinda nice to have up to date anyway.The easiest option would be to recover as much of this 2.6 MB as possible would be to create another stage based on
alpine:latest
and simply copy/
from the (current) final stage, but that's dirty as hell for 2.6MB and probably wouldn't recover that much because most of those files will exist in the basealpine
image also.Please reply with more ideas :)
The text was updated successfully, but these errors were encountered: