What does scratch mean in this context?
Show HN: Smallest Node.js Docker images
11–20 of 66 posts
Re: Show HN: Smallest Node.js Docker images
#12The new game of Docker Golf. I once spent like a day trying to debug an issue with pruning dev dependencies from my prod docker image before I stopped to realized how much money I was wasting to save $0.0001 of cloud disk space. It is kinda fun though.
Cloud disk space for an executable file costs nothing compared to potential losses if that executable is used for cracking into your installation.
It could be either via a hole in that executable, or just by using the executable to greatly simplify the penetration and / or privilege escalation.
Re: Show HN: Smallest Node.js Docker images
#13What does scratch mean in this context?
The scratch image in docker is an image containing nothing.
Re: Show HN: Smallest Node.js Docker images
#14Earlier quoted context omitted.
wait, do you mean adding another layer for npm installing other deps?
No, doing npm install in a different container and copying over the result. Docker has multi-stage build, which allows using a container to build and copying over in a different result container.. I suspect this could be relevant many place, keeping images small also hardens security.
Oh, what are the advantages of doing that in a different container as opposed to a different layer? Trying to understand the pros/cons..
Isn't it faster to add extra layers, than extra containers?
Re: Show HN: Smallest Node.js Docker images
#15The new game of Docker Golf. I once spent like a day trying to debug an issue with pruning dev dependencies from my prod docker image before I stopped to realized how much money I was wasting to save $0.0001 of cloud disk space. It is kinda fun though.
Reminds me of how I'll spend an afternoon avoiding a copy in Rust. It's kinda fun, but hard to remain deluded that you're doing it for serious technical purposes.
Re: Show HN: Smallest Node.js Docker images
#16This is neat! However I don't think I've ever seen a node project who's node_modules wasn't at least 10x the size as one of these images.
Size is only part of the equation. Fewer binaries you have to worry about security updates of is another.
I see that argument a lot, but this assumes that vulnerabilities in binaries that are never executed are magically exploitable from the internet.
It doesn't really matter if a container contains a 5 year old imagemagick binary if that binary is never used by anything. It's the equivalent of a bug in unreachable code.
Re: Show HN: Smallest Node.js Docker images
#17Figure I would ask here: Have any DevOps or build folks had to deal with compliance audits regarding their docker containers?
It's something certain developers I've encountered seem to ignore, even when creating something that might handle health or financial information.
Did you have to build your docker images from scratch, or did the security audit folks certify upstream images? What about updates?
Re: Show HN: Smallest Node.js Docker images
#18Earlier quoted context omitted.
No, doing npm install in a different container and copying over the result. Docker has multi-stage build, which allows using a container to build and copying over in a different result container.. I suspect this could be relevant many place, keeping images small also hardens security.
Oh, what are the advantages of doing that in a different container as opposed to a different layer? Trying to understand the pros/cons.. Isn't it faster to add extra layers, than extra containers?
Different layer means you have to carry around that layer in your final image. If you do a multi-stage build, you can copy over just the bits you need into the final image.
Re: Show HN: Smallest Node.js Docker images
#19Earlier quoted context omitted.
No, doing npm install in a different container and copying over the result. Docker has multi-stage build, which allows using a container to build and copying over in a different result container.. I suspect this could be relevant many place, keeping images small also hardens security.
Oh, what are the advantages of doing that in a different container as opposed to a different layer? Trying to understand the pros/cons.. Isn't it faster to add extra layers, than extra containers?
Layers are add only. If you removea file, it still exists in the parent layer, propagating bloat
Re: Show HN: Smallest Node.js Docker images
#20Figure I would ask here: Have any DevOps or build folks had to deal with compliance audits regarding their docker containers? It's something certain developers I've encountered seem to ignore, even when creating something that might handle health or financial information. Did you have to build your docker images from scratch, or did the security audit folks certify upstream images? What about updates?
Gitlab has a bunch of features around this: licensing, package scanning and docker CVE scanning.