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

reducing image size #2

Closed
kaczmarj opened this issue Jan 17, 2019 · 10 comments
Closed

reducing image size #2

kaczmarj opened this issue Jan 17, 2019 · 10 comments

Comments

@kaczmarj
Copy link

Hi @vsoch - cool project! You might consider using multi-stage builds to reduce the image size. Basically, you install all the compile-time dependencies and build singularity in the first stage, and copy the artifacts and install run-time dependencies in the second stage.

I do this, for example, in this Dockerfile.

This does, however, remove the source code and other potentially useful build artifacts. If those are useful to this project, then I would advise against multi-stage builds.

@vsoch
Copy link
Member

vsoch commented Jan 17, 2019

Hey @kaczmarj! That's a good suggestion! I would say that reproducibility is important, and a part of that is retaining the source code (and as you mention, other build artifacts.) Is the difference in size truly significant? Either way, thanks for showing me this trick! I think I will definitely give it a try for other projects.

@kaczmarj
Copy link
Author

The difference can be large. Building version 3.0.2 in a single stage creates a Docker image that is 732 MB large. With the second stage, the image is 112 MB. A large part of that is that golang and gcc are gone.

Building current 2.x master in a single stage creates a 266 MB image, and with multi-stage creates 57.7 MB image.

So if you would like to use multi-stage builds, you can also copy over the source code and other important things. But to be fully reproducible, you'd probably want to keep the compile-time dependencies (including the compilers!) in there as well.

@vsoch
Copy link
Member

vsoch commented Jan 17, 2019

Agreed! Thanks for the useful info. If this is important to you and you want to provide a multistage build for users, I'd be happy to add a branch with the tag. Let me know - I can create the branch off of another, and then you can PR to it, and then push to Docker Hub to find under the singularityware namespace. I'm a stickler for reproducibility, but this isn't essential for everyone, and I recognize some users might prefer the smaller image.

@vsoch
Copy link
Member

vsoch commented Jan 17, 2019

We can call it 3.0.2-slim since that's how they normally roll the smaller version of these things :)

@kaczmarj
Copy link
Author

This isn't very important to me :) I mostly wanted to let you know that this is possible. But if you'd like, I can create a 3.0.2-slim PR.

@vsoch
Copy link
Member

vsoch commented Jan 17, 2019

Yeah, to be honest I just have fun doing the collaboration / Github things, so let's do it! Give me a few minutes and I'll get you a branch ready.

@vsoch
Copy link
Member

vsoch commented Jan 17, 2019

Okay, we are ready to go (no pun intended)! here is your branch, and it's set up for an automated build on Docker Hub. I've also gone ahead and added a (non slim, very fat) 3.0.2 branch and container for it too.

@kaczmarj kaczmarj mentioned this issue Jan 17, 2019
@vsoch
Copy link
Member

vsoch commented Jan 18, 2019

The build is queued - I'll keep watch and close this issue when it's ready. Thanks for putting this together!

@vsoch
Copy link
Member

vsoch commented Jan 18, 2019

@vsoch vsoch closed this as completed Jan 18, 2019
@kaczmarj
Copy link
Author

Nice and slim :)

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

No branches or pull requests

2 participants