[HN Gopher] How to make Docker images even smaller
___________________________________________________________________
How to make Docker images even smaller
Author : tosh
Score : 37 points
Date : 2022-03-16 19:51 UTC (3 hours ago)
(HTM) web link (symflower.com)
(TXT) w3m dump (symflower.com)
| rad_gruchalski wrote:
| One more. Copy files with the correct chmod, don't chmod copied
| files in a separate run command because that run command will
| create a new layer.
| chriswarbo wrote:
| I build container images using Nix (actually OCI containers; I
| don't use Docker at all, although I think it can run OCI
| containers). Going through these points one at a time:
|
| > Use a smaller base image or libc
|
| By default, Nix will build container images from scratch. No base
| image (although I guess you can add one as a layer to your
| manifest JSON, if you like).
|
| > Make the image context smaller
|
| Nix tracks dependencies very precisely. Our container images will
| only contain the things we asked for, and their dependencies
| (transitively).
|
| > Fully minimize and tidy up image layers
|
| This only seems relevant for imperative images, built "from the
| inside" (e.g. the talk about contents being "overwritten"?)
|
| > Splitting up processes and services for breaking up images
|
| The helper-functions in Nixpkgs contain tricks to automatically
| figure out which content is better kept in separate layers, based
| on how many times they're referenced (as a proxy for how often
| they'll be shared across containers). Docker only supports 128
| layers, so the remaining content gets combined into the final
| layer; e.g. see https://grahamc.com/blog/nix-and-layered-docker-
| images
| emptysongglass wrote:
| I've started building my personal projects like this but the
| end result is an image running as root, which is not best
| practice. Have you been able to build images with Nix that run
| as an arbitrary user?
| flurie wrote:
| There is an example of doing this in the docker-tools
| examples!
|
| https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-
| supp...
| secondcoming wrote:
| What has this got to do with making Docker images smaller?
| dwohnitmok wrote:
| Presumably parent's point is "making Docker images with Nix
| makes them very small [smaller even than the tips mentioned
| in the article]."
| yjftsjthsd-h wrote:
| And it does so more or less by default, for free, without
| having to make any special effort.
|
| Edit: Any special effort beyond using nix, I should say;
| that is a significant cost if you're not already paying it.
| astockwell wrote:
| Blogpost or it didn't happen! (Seriously though, I would love
| to read a post detailing this process start-to-finish for the
| uninitiated)
| emptysongglass wrote:
| Here's [1] my favorite thus far using Nix's new flakes to
| build a Rust project into a container image with Nix.
|
| [1] https://community.fly.io/t/running-reproducible-rust-a-
| fly-a...
| pentium10 wrote:
| I recently blogged about: Integrating DockerSlim container minify
| step on Cloud Build https://medium.com/google-cloud/integrating-
| dockerslim-conta...
| Something1234 wrote:
| Off-topic, but has anyone actually used their product, it seems
| really cool, but I'm trying to decide if it's smoke and mirrors?
|
| Even if it generates a lot of really stupid test cases, including
| them in a separate package would be incredibly powerful for
| handling stupid mistakes.
| winddude wrote:
| What's the advantage of smaller containers?
|
| You should optimise for performance and security. For example
| python's base image is slower, than a container built on ubuntu
| for python apps. This is shown by several tests. Pythons base
| image is built on Alpine, which has shown to also have longer
| build times, and obscure bugs.
|
| So a smaller container image is not always better. Instead
| optimise for performance and security.
| BjoernKW wrote:
| One example from my recent experience: embedded systems and
| industrial facilities, which don't necessarily have a reliable
| or fast internet / network connection.
|
| When updating images on multiple devices on a 10 Mbit
| connection the difference between, say, a 500 MB image and a
| functionally equivalent 50 MB image can be quite significant.
| rsstack wrote:
| > So a smaller container image is not always better.
|
| No one said it is _always_ better. Obviously you can make a
| smaller but worse image.
|
| Making the image smaller, without affecting its performance or
| security, can reduce costs (storage + network) and can make
| deployments much faster (and so improve reliability, and
| Developer Experience).
| Turbots wrote:
| CraftThatBlock wrote:
| Using build stages is usually the biggest contributor to
| reduction in image size.
|
| Usually, images have steps to build (which requires source code,
| dependencies, etc), and the entry point at the end. Splitting the
| build- and run-time means you're shipping an image that only
| includes what's needed to run (not build) the application.
___________________________________________________________________
(page generated 2022-03-16 23:00 UTC)