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

31–40 of 66 posts

Re: Show HN: Smallest Node.js Docker images

#31

Post by choosegoose »

bloopernova wrote: post #17

Figure 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?

We use Twistlock (https://www.twistlock.com/) as it does the CVE scanning but you can setup rules for compliance, binary monitoring and a whole plethora of other security/auditing type things. It also has a jenkins plugin so you can fail builds if a certain threshold of CVEs/compliance failures are introduced by developers (the only way to actually get the team to care about security).

Our security folks haven't really decided what to do with containers although some people are just using RHEL7 base images since its "enterprise-y". Our group personally uses alpine base images. If we have something like a java service hosted by Tomcat, we build alpine then build tomcat and then build our "service" container. While most people are fine pulling from Dockerhub, we do work in closed-loop environments and have a private docker registry where we host our "chain" of docker images which are versioned and updated regularly.

Re: Show HN: Smallest Node.js Docker images

#32

Post by james-mcelwain »

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.

Re: Show HN: Smallest Node.js Docker images

#33

Post by bloopernova »

choosegoose wrote: post #31
bloopernova wrote: post #17

Figure 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?

We use Twistlock ( https://www.twistlock.com/ ) as it does the CVE scanning but you can setup rules for compliance, binary monitoring and a whole plethora of other security/auditing type things. It also has a jenkins plugin so you can fail builds if a certain threshold of CVEs/compliance failures are introduced by developers (the only way to actually get the team to care about security). Our security folks haven't re…

Thank you, I will check that out.

Re: Show HN: Smallest Node.js Docker images

#34

Post by hinkley »

drinchev wrote: post #30
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.

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 ( owni…

Make it Work, Make it Right, Make it Fast.

On several projects the management and sales team were at odds with the dev team about app performance. They wanted it faster and the dev team was full of premature optimization cargo cult members. By cult member, I mean people who say that phrase to get out of thinking.

The line between right and fast is blurry. There’s a big chunk of refactorings that improve readability and performance and if you work with those you get better at your job, avoid the cult members and please the business.

Now that I’ve typed that last paragraph I want to go through Refactoring and categorize the ones that fall under “right and fast”...

Re: Show HN: Smallest Node.js Docker images

#35

Post by heavenlyblue »

always_good wrote: post #15
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.

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.

Then the next day you realise the next feature actually requires a copy anyway... :)

Re: Show HN: Smallest Node.js Docker images

#36

Post by ajuhasz »

There’s also google cloud’s distroless project: https://github.com/GoogleContainerTools/distroless

We’ve used the Node.js containers in production and investigated the other languages, but never deployed them. We did have some issues with devops not being able to log into the running containers, but always found a solution that I believe in the end was a better long term pattern for ops.

Re: Show HN: Smallest Node.js Docker images

#37

Post by tzaman »

Honestly, the size doesn't matter.

I was once in the camp of small Docker images, but realized it's simply not worth the tradeoff, since there's only one upside to them, and that upside is fast transfer of images.

However, that argument becomes pointless when using a proper CI/CD stack. As a developer, you don't normally upload images yourself, but push changes to GitHub, then Jenkins/Travis/whatever takes over, builds the image, and pushes it into production/staging/whatever. Since CD tool of choice is usually also on the cloud, we don't have to worry about image size, nor to any of the CD vendors charge for data transfer.

I'd rather have bigger images (I base mine off Debian now, used to be Alpine) and not have to worry with lack of ported tools and libraries, than vice-versa.

Re: Show HN: Smallest Node.js Docker images

#38

Post by jay-anderson »

hinkley wrote: post #34
drinchev wrote: post #30

Earlier quoted context omitted.

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 ( owni…

Make it Work, Make it Right, Make it Fast. On several projects the management and sales team were at odds with the dev team about app performance. They wanted it faster and the dev team was full of premature optimization cargo cult members. By cult member, I mean people who say that phrase to get out of thinking. The line between right and fast is blurry. There’s a big chunk of refactorings that improve readability a…

Very much agreed. Like all things balance is needed. Often it's worth thinking about performance during initial design. There's the idea that fixing bugs earlier in development is cheaper. This also applies to performance issues. That's not to say you spend an inordinate amount of time focusing on just that, but it needs to be given its due.

Re: Show HN: Smallest Node.js Docker images

#40

Post by kpcyrd »

phamilton wrote: post #23
kpcyrd wrote: post #16

Earlier quoted context omitted.

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.

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

Post reply on HN