Skip to content
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

Merged
merged 1 commit into from
Jan 8, 2020

Conversation

SimenB
Copy link
Member

@SimenB SimenB commented Jan 4, 2020

Should fix #1181.

/cc @tianon does this make sense?

@SimenB SimenB requested a review from a team January 4, 2020 12:28
@SimenB
Copy link
Member Author

SimenB commented Jan 4, 2020

jessie-slim fails since it wants to delete apt. Any ideas on how to fix it?

@@ -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 \
Copy link
Member

@LaurentGoderre LaurentGoderre Jan 6, 2020

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not?

Copy link
Member Author

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

@LaurentGoderre
Copy link
Member

How does it fix the issue @SimenB ?

@SimenB
Copy link
Member Author

SimenB commented Jan 6, 2020

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

@LaurentGoderre
Copy link
Member

Oooh, I see!

@LaurentGoderre
Copy link
Member

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).

RUN set -ex \
RUN buildDeps='ca-certificates curl wget gnupg dirmngr' \
&& set -ex \
&& apt-get update && apt-get install -y $buildDeps --no-install-recommends \
Copy link
Member

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?

Copy link
Member

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

Copy link
Member

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.

Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

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

Copy link
Member

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

Copy link
Contributor

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.

Copy link
Member Author

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

Copy link
Member Author

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

@SimenB SimenB requested a review from a team January 8, 2020 08:30
@SimenB SimenB merged commit add2e3f into nodejs:master Jan 8, 2020
@SimenB SimenB deleted the uninstall-slim-helpers branch January 8, 2020 14:38
@Starefossen
Copy link
Member

Starefossen commented Jan 9, 2020

@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).

@Tapppi
Copy link

Tapppi commented Jan 9, 2020

@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.

@LaurentGoderre
Copy link
Member

@Tapppi you could install it as part of your image (or were you using the stock image as is?)

@willdurand
Copy link

We also noticed a regression in our build system because of this patch... In our case, the image cannot be built anymore because the gnupg has been removed.

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).

@Tapppi
Copy link

Tapppi commented Jan 10, 2020

@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 :)

@cosmith
Copy link

cosmith commented Jan 10, 2020

To add a data point, this broke our deployment with the following error:

Step 7/10 : RUN yarn install --frozen-lockfile --no-cache
---> Running in ba0b9a8ebe73
yarn install v1.21.1
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error Command failed.
Exit code: 128
Command: git
Arguments: ls-remote --tags --heads https://<user>:<key>@github.com/<org>/<repo>.git
Directory: /
Output:
fatal: unable to access 'https://<user>:<key>@github.com/<org>/<repo>.git/': Problem with the SSL CA cert (path? access rights?)

We reverted to node:lts from node:lts-slim but I'm still not sure what was removed that prevents yarn from accessing github (gnupg? openssl?). Adding curl only didn't solve the issue.

Update: installing gnupg and ca-certificates seems to do the trick

@LaurentGoderre
Copy link
Member

@cosmith @Tapppi if you only need curl for npm or yarn install, you could use multi-stage builds that use full debian for the build stage and slim for the final stage.

@LaurentGoderre
Copy link
Member

@cosmith I believe you only need ca-certificates

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

node:12.13/14-slim ships with unsupported OpenSSL?
8 participants