-
Notifications
You must be signed in to change notification settings - Fork 96
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
perf: re-order Dockerfile stages to significantly optimize build speed #58
perf: re-order Dockerfile stages to significantly optimize build speed #58
Conversation
Previously, build stages were ordered like this in the rendered Dockerfile (dependencies in paranthases): * base * i18n (base) * app1-src (base) * app1-i18n (base, app1-src) * app1-dev (base, app1-src, app1-i18n) * app1 (app1-dev) * app2-src (base, app2-src) * app2-i18n (base, app2-src) * app2-dev (base, app2-src, app2-i18n) * app2 (app2-dev) * ... * production (app1, app2, ..., appN) MFEs in dev mode only use the output of the *-dev stages. However, because some of the *-dev stages came after the intermediate production stages in the Dockerfile (app1, app2, etc), Docker unnecessarily built the prod stages whenever `tutor dev start` was run, which often forced users to wait through the prod-only `npm run build`. This commit reorders the build stages to look like this: * base * i18n (base) * app1-src (base) * app1-i18n (base, app1-src) * app1-dev (base, app1-src, app1-i18n) * app2-src (base, app2-src) * app2-i18n (base, app2-src) * app2-dev (base, app2-src, app2-i18n) * ... * app1 (app1-dev) * app2 (app2-dev) * ... * production (app1, app2, ..., appN) Now that the *-dev stages are all before the production stages, the MFE dev build should be significantly quicker.
FYI @regisb (when you're back). I realized this issue while working on https://github.com/overhangio/2u-tutor-adoption/issues/87. |
In the issue I was referring is this part of code: tutor-mfe/tutormfe/templates/mfe/build/mfe/Dockerfile Lines 48 to 49 in 0b695b9
The part of When mfe is installing its depds, it can uses .npm cahches of other mfe that are already installed, but however apps can be installed in parrallel, (if you enable docker buildkit), so probably if we can have the base base to already cahces common pacakges, then defeinilty would decrease network bandwidth usage (i.e install time),. All of this would more possible or easier to implement when we have or agree on set of depends that are consistant among the mfes, which is I opened a some PRs against nutmeg branch for few mfes. |
@kdmccormick, will review/test ASAP. Thanks for this! |
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 changes make sense. I also tested the build, and it works fine. Approved.
This is a great contribution, thanks! |
Description
Previously, build stages were ordered like this in the
rendered Dockerfile (dependencies in parenthases):
MFEs in dev mode only use the output of the *-dev stages.
However, because some of the *-dev stages came after
the intermediate production stages in the Dockerfile (app1, app2, etc),
Docker unnecessarily built the prod stages whenever
tutor dev start
was run, which often forced users to wait through the prod-only
npm run build
.This commit reorders the build stages to look like this:
Now that the *-dev stages are all before the production stages,
the MFE dev build should be significantly quicker.
Review
@arbrandes Can you take a look?