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

Optimize Dockerfile performance #55

Closed
1 of 3 tasks
Tracked by #130
christophe-f opened this issue Feb 27, 2023 · 6 comments
Closed
1 of 3 tasks
Tracked by #130

Optimize Dockerfile performance #55

christophe-f opened this issue Feb 27, 2023 · 6 comments

Comments

@christophe-f
Copy link
Contributor

christophe-f commented Feb 27, 2023

What do you want to improve?

Optimize Dockerfile to run faster. We have many contributions and it takes a long time to get feedback, merge and deploy.

What is the current behavior?

The build time was already too long and doubled in the last week.

What is the new behavior?

Build faster. Much faster

⚠️ Is this a breaking change?

Put an x in the boxes that apply

  • Yes
  • No
  • Don't know
@christophe-f christophe-f mentioned this issue Mar 17, 2023
6 tasks
@christophe-f christophe-f changed the title Improve build time Optimize Dockerfile performance Mar 17, 2023
@schultzp2020
Copy link
Member

Currently, the majority of the dockerfile build time is allocated to running the fix-permissions script. Is there a way we could cut down the time required to run this script? @sabre1041 @tumido

@tumido
Copy link
Member

tumido commented Mar 23, 2023

@schultzp2020 I think you can make the Dockerfile to use the fix-permissions script earlier in multiple layers instead of just as the last one. What that would result into is incremental changes - container layers work in a way that they store all that is changed compared to the previous layer. So, if the fix-permissions was already executed for some files, it means the permissions don't have to be updated for them again + these files are already cached in their final state in previous layers. This should potentially (and counterintuitively) result in smaller and faster builds.

@schultzp2020
Copy link
Member

schultzp2020 commented Mar 27, 2023

@tumido I have yet to try it; however, I do not believe that will work because the last (prod) stage doesn't copy files directly from the build stage. Instead the build stage creates tarballs, which are then extracted during the prod stage. Therefore, the majority of the files are not from previous stages that would benefit from running fix-permissions in an earlier stage.

@tumido
Copy link
Member

tumido commented Mar 28, 2023

I think tarball preserves permissions, doesn't it? Let's try it and if it doesn't work we can try to come up with something else... 🙂

@Zaperex Zaperex self-assigned this Jul 11, 2023
@Zaperex
Copy link
Member

Zaperex commented Jul 11, 2023

End users will no longer be building their own backstage showcase images, so this issue is mainly for improving our own build times for showcase and RHDH.

Currently I have only identified optimizations for the first stage (dependency installations) by only copying package.json files rather than the entire repository.

@schultzp2020 schultzp2020 closed this as not planned Won't fix, can't repro, duplicate, stale Jul 11, 2023
@schultzp2020
Copy link
Member

There are no optimizations we can do for the dockerfile since the fix-permissions script takes the most amount of time and we do not control the script.

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

No branches or pull requests

4 participants