search

dani-garcia / vaultwarden

Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs
GNU Affero General Public License v3.0
34.78k stars 1.69k forks source link

Optimize Dockerfiles #4532

Closed dfunkt closed 1 month ago

dfunkt commented 2 months ago

Move some ARGs closer to the build stage (potentially improving caching): Example: I usually set VW_VERSION to be the latest commit hash, without this change I'd have to also rebuild the dependencies even if they didn't change since the previous layers would get invalidated.

Remove redundant COPY commands: They can be combined, no point in using extra layers if it can be avoided.

Remove redundant RUN command: apt-get and xx-apt-get commands can be moved into the same RUN command, thus saving another layer.

Move CARGO_HOME's "&&" operator to the first line (improves consistency)

BlackDex commented 2 months ago

Saving a lot of layers at the top is not that efficiënt i think. Ill have to check, there were some reasons i didn't combined the apt's, but not sure.

dfunkt commented 2 months ago

Fair enough, if there's stuff here that you don't like just tell me and I'll remove it.

I've been running my builds for a while with these changes and I figured other people might benefit from them as well.

BlackDex commented 2 months ago

Fair enough, if there's stuff here that you don't like just tell me and I'll remove it.

I've been running my builds for a while with these changes and I figured other people might benefit from them as well.

Do you build all arch's?

dfunkt commented 2 months ago

amd64 and arm64, both for personal use

williamdes commented 2 months ago

A good tool to check this PR is https://github.com/wagoodman/dive

BlackDex commented 2 months ago

A good tool to check this PR is https://github.com/wagoodman/dive

I use that too indeed. But that will only work for the final image, not for the build layer.

dfunkt commented 2 months ago

What do you guys think about including this as well for apt? https://docs.docker.com/build/cache/#use-the-dedicated-run-cache

BlackDex commented 2 months ago

It doesn't really add anything useful i think. The main reason is that we went fresh images which have the latest packages available to keep up-to-date and all CVE's are gone as good as possible.

Also, docker buildx does some nice caching by it self. And we already use build caches during our release pipeline.

We used that before btw, which was useful back then, and not building in parallel. When building in parallel it gave some issues, which can be solved, but then it loses its benefits.

BlackDex commented 2 months ago

While optimizing for layers does not have any benefit for the build part, it also doesn't hurt in this case. The only time it will hurt is when you are testing/debugging the last apt commands in the same RUN. But that will not be often i hope.