no npm, no shell, not practical :)
See the example multi-stage Dockerfile in the README: https://github.com/astefanutti/scratch-node#usage
Show HN: Smallest Node.js Docker images
51–60 of 66 posts
Re: Show HN: Smallest Node.js Docker images
#52Figure 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?
Assuming you have a shell within your container, InSpec can be a great tool (https://www.inspec.io/) as you can pass a "docker" target for your compliance profiles.
Works great for us :)
Re: Show HN: Smallest Node.js Docker images
#53Earlier quoted context omitted.
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
Re: Show HN: Smallest Node.js Docker images
#54That'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…
Agreed. Makes the Dockerfile much more portable as you don't need build-tooling on the host to make a Docker image of the program. It is also really great when doing CI because you can use the Docker image layer cache to cache build/dev dependencies.
Re: Show HN: Smallest Node.js Docker images
#55This is great! Thanks for sharing. I can recommend a small change to get most out of docker caching and reducing docker build times to the maximum extent.
In the "builder" you only need package.json and package-lock.json files to install dependencies. The rest of the sources can be copied in the "scratch-node" image. This would make caching work till the last line where only code changes are included. Code is modified much more frequently than dependencies.
You sample can look like this:
FROM node as builder
WORKDIR /app
COPY package.json package-lock.json index.js ./
RUN npm install --prod
FROM astefanutti/scratch-node
COPY --from=builder /app/node_modules /node_modules
COPY ./ ./
ENTRYPOINT ["./node", "index.js"]
Re: Show HN: Smallest Node.js Docker images
#56Honestly, 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, buil…
What if you need to release a hot fix and your image is 1Gb?
Re: Show HN: Smallest Node.js Docker images
#57Does it work with statically linked modules?
Re: Show HN: Smallest Node.js Docker images
#58Honestly, 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, buil…
What if you need to release a hot fix and your image is 1Gb?
And this is why we need a better image format so that people don't cripple their images to get around the misuse of tar archives.
Re: Show HN: Smallest Node.js Docker images
#59That'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…
What's really frustrating is that this isn't a new idea at all. RPMs have had BuildRequires forever, debs have had a similar concept for a similarly long time.
Sure, multistage builds are useful, but you could always get the same features (and more) by making packages for whatever distribution you use and installing it in your container. I get that's it's not as easy as writing a shell script in your Dockerfile to build all your dependencies, but sometimes better solutions aren't free.
(Also this is one of the reasons why the layer model of deduplication is flawed, and why I'm working on improving it. You shouldn't have to care how large your logical image size is.)
Re: Show HN: Smallest Node.js Docker images
#60The 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…
The thing is, Docker Golf is possibly the worst way to optimise the real costs of container images -- because it comes at the cost of maintenance (distributions exist for a reason).
A much better solution is to fix the image format to better handle the usecases that it needs to handle. (This is what I'm working on at the moment.)