Similar one here https://github.com/mhart/alpine-node, base-* versions are static.
Show HN: Smallest Node.js Docker images
21–30 of 66 posts
Re: Show HN: Smallest Node.js Docker images
#22Figure 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?
Docker actually does this for you via Cloud when you store your images. It performs static analysis of all files/libs in your container to check for vulnerabilities, as opposed to the simpler `dpkg` list check which is not accurate.
Re: Show HN: Smallest Node.js Docker images
#23Earlier quoted context omitted.
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.
Unless the exploit makes unreachable code reachable.
Security (and privacy) are largely about minimizing surface area.
Re: Show HN: Smallest Node.js Docker images
#24The 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.
It's not (only) about the storage space; it's the upload too. That time investment will get paid back over multiple deployments.
That said, now I have "good" broadband, I pay a lot less attention to the image size.
Re: Show HN: Smallest Node.js Docker images
#25Figure 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.
Cool, I had no idea. Thank you!
Re: Show HN: Smallest Node.js Docker images
#26Earlier 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?
This is the builder pattern in docker. You do things in one "throw away" container, use results from this container and copy them into another. The final container gets only one layer now, instead of maybe 10s that your "throw away" container had.
Re: Show HN: Smallest Node.js Docker images
#27Earlier quoted context omitted.
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.
No, it assumes that there is a risk that other vulnerabilities may allow you to trigger local executables, and the less code is accessible, the more remote that possibility becomes.
Re: Show HN: Smallest Node.js Docker images
#28Figure 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?
Docker actually does this for you via Cloud when you store your images. It performs static analysis of all files/libs in your container to check for vulnerabilities, as opposed to the simpler `dpkg` list check which is not accurate.
Cool, so at least some folks are thinking about this sort of thing. Thank you for the response!
Re: Show HN: Smallest Node.js Docker images
#29but will it work on armv7 or later?
Re: Show HN: Smallest Node.js Docker images
#30The 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.
That's something that I ask myself everyday. Is it worth it to push the big O notation to the limit, saving couple of megabytes RAM or I can simply deliver and have a happy boss.
I've always been fond of "premature optimisation is the root of all evil" [1], but still... wasting resources makes me feel bad. I feel like the guy that buys 10 plastic bottles of 0.5l water instead of 2x2.5 litres.
The guys building ( owning ) Slack, cryptocurrencies, e-commerce websites are on the other end though. I hardly can count a day when my MacBook's fan doesn't spin like crazy, because I'm just visiting an HTML page to read the text.
In other words. Yeah ... you can save some precious time to optimise that, because you don't want to be the person that starts the fans of colleagues' Macs ( having a docker image with your app running on my Mac ). Energy is what you are saving and that's priceless in today's polluted world.