![]() Since the deletion occurs in the same RUN directive, the resulting change is only the added packages.ĭebian: RUN DEBIAN_FRONTEND=noninteractive apt-get update \ The metadata is likely not needed in the final image (but may be for additional packages to be installed) and is bloat.Ī practical example to consolidate these into a single layer is to chain the commands together, including the delete. In the original example, the repository metadata refresh (apt-get update/apk update) and the install (apt-get install/apk add) are on two separate lines this results in two layers- one which will have the metadata and one adding the ffmpeg + dependencies. results in a separate layer in the container image. To expand on this- each Dockerfile directive such as USER, COPY, RUN, etc. I just can't believe the ffmpeg layer was 473MB (using image history command). RUN apt-get install -y ffmpeg -> 473MB !!!Īt this point, it seems like adding all the needed compilation tools to the alpine image would be a lot more efficient than using slim-bullseye. I made a few very simple Dockerfiles as a test, and here are the results: But my project also requires ffmpeg, and adding ffmpeg to the debian based image I chose added 473MB to my image! I just figured great, I will use a different base image and the problem will be solved. Reading around the internet, I read opinions about how crappy alpine is for just such reasons, and that one shouldn't use it for Python images. It turns out this package doesn't have a precompiled binary for alpine, and I would have to compile with who knows what, and I didn't want to get into that. I was happily using an alpine base image for my Python project, but then I needed to use a package called pycryptodomex.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |