Use slim node image, clean cache #1309
Conversation
lognaturel
force-pushed
the
slim-image
branch
2 times, most recently
from
7e2e67d
to
2bb36d0
Compare
| # Remove dev dependencies after build | ||
| RUN yarn install --production --frozen-lockfile --ignore-scripts | ||
| # Install and build, first with dev dependencies, then with production only (yarn 1 has no prune) | ||
| RUN yarn install --frozen-lockfile \ |
There was a problem hiding this comment.
Is the build step implicit in yarn install?!
There was a problem hiding this comment.
This is weird, I agree. I decided to leave it because I don’t want to build yet another time. All of the necessary packages end up being built because of the dependencies between them.
There was a problem hiding this comment.
I ran https://github.com/wagoodman/dive on this and it says it's very efficient (as far as Docker is concerned).
You could add && apt-get autoremove && apt-get clean to the first RUN to clean up everything, but https://docs.docker.com/develop/develop-images/instructions/ says that images like node slim based on Debian already do that.
I had to add ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD true to get the thing to build on my M1 Mac.
Reduce the image size. It was over 1.6Gb compressed because of the double
yarn install. The secondyarn installwas not doing anything:yarnv1 doesn't do any pruning of existing installed deps with--production: yarnpkg/yarn#6373, yarnpkg/yarn#696I have verified this PR works with
What else has been done to verify that this works as intended?
Tried integrated with ODK Central.
Why is this the best possible solution? Were any other approaches considered?
There's more to do but I think we should start with this which gets to a compressed image of about 800Mb. This makes a big difference in install time, even on fast connections.
I had hoped to prune dev dependencies and I think 2469791 is a reasonable way but @alxndrsn is less comfortable with it. I'd rather go with an approach we all feel is safe, the diff is 70mb and the dev dependencies should not pose any risk. I think the next step will be to come back to this and take a multistage approach.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
I think given that I've run it with a form server the risks are very low. The changes are all implementation details and shouldn't change anything for downstream users.
Do we need any specific form for testing your changes? If so, please attach one.
No.