Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Smallest Node.js Docker images

github.com

Post reply on HN
Print view View original

41–50 of 66 posts

Re: Show HN: Smallest Node.js Docker images

#41

Post by web007 »

martin-adams wrote: post #2

That's pretty cool. What it appears to do is to build Node statically in one builder container, then exports a scratch container and copies the one binary and one user config into it. So what's built is extremely minimal.

Multi-stage Docker builds are an underutilized pattern.

Go ahead, go crazy and add all of the dev dependencies you need to build your package. Once you've done that, take the built package and put it into another container that has only the runtime dependencies.

The ideal use-case for this is compiling Go, since you end up with a 1GB build container and a 12MB single-binary production container if you compile with static linking. Just beware when going the FROM SCRATCH route that you get nothing to go with it, you can't shell into the container or run "ps" or "lsof" for debugging because none of those exist.

Re: Show HN: Smallest Node.js Docker images

#43

Post by bloopernova »

11235813213455 wrote: post #39

no npm, no shell, not practical :)

Why? Containers are supposed to be idempotent. They shouldn't need npm, a shell, or other stuff really.

(not looking to argue, if there's another reason to keep these tools around, please let me know, I'm always looking to learn more)

Re: Show HN: Smallest Node.js Docker images

#44

Post by weberc2 »

tootie wrote: post #10

The 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.

If there is a practical advantage, I think it's reducing the attack surface. I recently made an image that was a single statically-linked binary, some certs, and an /etc/passwd file all on top of a scratch base image. I did this because our organization's compliance team has only greenlighted Centos and scratch base images (no idea whether or not this is a particularly good policy) and I opted for scratch because it was marginally more effort for several small gains (reduced attack surface, faster deploys, faster builds, faster pulls, etc).

Re: Show HN: Smallest Node.js Docker images

#45

Post by weberc2 »

web007 wrote: post #41
martin-adams wrote: post #2

That's pretty cool. What it appears to do is to build Node statically in one builder container, then exports a scratch container and copies the one binary and one user config into it. So what's built is extremely minimal.

Multi-stage Docker builds are an underutilized pattern. Go ahead, go crazy and add all of the dev dependencies you need to build your package. Once you've done that, take the built package and put it into another container that has only the runtime dependencies. The ideal use-case for this is compiling Go, since you end up with a 1GB build container and a 12MB single-binary production container if you compile with st…

> Just beware when going the FROM SCRATCH route that you get nothing to go with it, you can't shell into the container or run "ps" or "lsof" for debugging because none of those exist.

Your image processes run on the host anyway, so just `ps` or `lsof` from the host. I've never had to exec into a Go/scratch container.

Re: Show HN: Smallest Node.js Docker images

#46

Post by vidarh »

kpcyrd wrote: post #40
phamilton wrote: post #23

Earlier quoted context omitted.

Unless the exploit makes unreachable code reachable. Security (and privacy) are largely about minimizing surface area.

The "surface" in "attack surface" implies reachability. Your argument doesn't make any sense, how would "the exploit" make an unreachable vulnerability reachable without being able to execute the vulnerable code in the first place? Please don't say "using a different vulnerability that allows us to execute arbitrary code".

Plenty of real security flaws have involved finding ways of obtaining the ability to execute binaries already present on a system.

Such flaws have not even always required a direct connection - years ago someone found a flaw in common USENET software that let them execute command lines via specially crafted newsgroup posts, and effectively get a really slow (store and forward via multiple servers slow) interactive shell.

Their ability to exploit it was directly dependent on what else was reachable from a shell. Run it in a chroot without binaries, and they could do quite little. Run it somewhere the attacker had access to tools and they suddenly had a shell behind your firewall.

The increased risk from more binaries is not hypothetical, but something many of us have experienced the difference of first hand.

I've personally reviewed more than one set of logs from intrusion attempts where the attackers had found a way to execute commands but were unable to do harm because they were fumbling around looking for ways to penetrate further but didn't find any of the tools they needed.

Re: Show HN: Smallest Node.js Docker images

#47

Post by vidarh »

alexnewman wrote: post #42

Good this way I can't debug my docker container by jumping into it. Also I wouldn't actually want to call any OS features, so this protects me from that. Just kidding. This is a cool project, but probably isn't super productiony

Pretty much everything you might need to do to debug it can either be done from the outside or can be achieved by copying binaries in temporarily,or execute the same image with a volume mounted.

Re: Show HN: Smallest Node.js Docker images

#48

Post by weberc2 »

james-mcelwain wrote: post #32
mikepurvis wrote: post #3

A scratch container doesn't even have busybox in it, does it? If not, this wouldn't be able to run npm, much less install anything which has bindings to other libraries. Definitely a cute experiment, but probably of limited real-world use. I wonder what the smallest _practical_ node container would look like?

`npm` should be included in a final container anyway. Best practices for Docker are to have a separate build and run container. The build container can contain anything you want, but the run container should have only the bare minimum required to execute the artifact produced by the build container.

s/should/shouldn't

Re: Show HN: Smallest Node.js Docker images

#50

Post by tomcam »

weberc2 wrote: post #44
tootie wrote: post #10

The 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.

If there is a practical advantage, I think it's reducing the attack surface. I recently made an image that was a single statically-linked binary, some certs, and an /etc/passwd file all on top of a scratch base image. I did this because our organization's compliance team has only greenlighted Centos and scratch base images (no idea whether or not this is a particularly good policy) and I opted for scratch because it…

Would love to see a more detailed writeup on this
Post reply on HN