-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: uninstall download helpers from slim image #1182
Conversation
|
@@ -17,7 +17,7 @@ RUN buildDeps='xz-utils' \ | |||
*) echo "unsupported architecture"; exit 1 ;; \ | |||
esac \ | |||
&& set -ex \ | |||
&& apt-get update && apt-get install -y ca-certificates curl wget gnupg dirmngr $buildDeps --no-install-recommends \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe ca-certificates
should not be moved to buildDeps
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we don't uninstall ca-certificates
we're back at square one since it's ca-certificates
which pull in openssl
How does it fix the issue @SimenB ? |
By not including openssl at all anymore - it's not part of the base image we extend from, it's installed as a side-effect of us downloading node |
Oooh, I see! |
This is a potentially breaking change for any image relying on that side-effect (Not that I am opposed ot it, just saying we might received a few bug reports afterwards). |
10/buster-slim/Dockerfile
Outdated
RUN set -ex \ | ||
RUN buildDeps='ca-certificates curl wget gnupg dirmngr' \ | ||
&& set -ex \ | ||
&& apt-get update && apt-get install -y $buildDeps --no-install-recommends \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it need to install again for the second RUN?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or should the apt-get purge just be moved down
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can't be moved down because of how layers work. It should be reinstalled again in the yarn step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I thought if the apt-get purge was removed from the previous RUN block, the packages would be available when running this layer too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the layers will be larger though. Ideally we'd have one large RUN
which install both node and yarn in the same layer, but I didn't want to make such a big change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, thanks for clearing that up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the downside of the power of docker layers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In many repositories we've stopped using an explicit list of "things to install then remove later" exactly because of this problem of dependencies that we didn't install getting removed (or hand-maintaining a list of library dependencies after we've compiled something using them), instead opting to get "clever" with apt-mark
to let APT itself do the heavy lifting (which then will only remove things we haven't explicitly said need to stay):
RUN set -eux; \
savedAptMark="$(apt-mark showmanual)"; \
apt-get update; \
apt-get install -y --no-install-recommends ca-certificates curl dirmngr gnupg wget; \
rm -rf /var/lib/apt/lists/*; \
\
# ... do stuff here ...
\
apt-mark auto '.*' > /dev/null; \
apt-mark manual $savedAptMark > /dev/null; \
apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false
See https://github.com/docker-library/php/blob/ae3f372b446b6457326504d9b9984ce708f20c3d/Dockerfile-debian.template#L65-L97 for one example of this pattern being used, and https://github.com/docker-library/php/blob/ae3f372b446b6457326504d9b9984ce708f20c3d/Dockerfile-debian.template#L196-L207 for a more complicated example of keeping appropriate lib*
packages automatically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, nice! I've never even heard of apt-mark
😅 I'll change to use that, seems ideal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed that now. apt-mark showmanual
was empty, so I dropped that part
96ebc38
to
f99660d
Compare
@SimenB this needs to be reverted, we can simply not "break" all existing slim images that relies on curl being there. Inadvertent or not. Going forward these types of changes needs to be reserved for major version (ref. SemVer) As a minimum potentially and unintentionally breaking changes needs to be communicated or noted somewhere as opposed to a single comment in a pull request (ref. @LaurentGoderre). |
@Starefossen Just to note, you already did. I am guessing that the docker images are released automatically and at least our build pipeline already broke on this and we had to switch to full images. |
@Tapppi you could install it as part of your image (or were you using the stock image as is?) |
We also noticed a regression in our build system because of this patch... In our case, the image cannot be built anymore because the Although I have no problem with this patch per se, I find it not very nice that such patches can break everything so easily and finding the root cause took more time that it should have taken (some sort of versioning/changelog would be appreciated). |
@LaurentGoderre We could've, but we already swapped to the full image instead at least while this situation plays out. We do very few modifications to the image at that point, adding maintenance burden feels like an anti-goal in this case :) |
To add a data point, this broke our deployment with the following error:
We reverted to Update: installing |
@cosmith I believe you only need |
Should fix #1181.
/cc @tianon does this make sense?