4 ms·

If you really want to optimize image size, use Nix! Ex: https://gist.github.com/sigma/9887c299da60955734f0fff6e2faeee0 https://gist.github.com/sigma/9887c299da

by sriku 5y ago

If you really want to optimize image size, use Nix! Ex: https://gist.github.com/sigma/9887c299da60955734f0fff6e2faeee0 https://gist.github.com/sigma/9887c299da60955734f0fff6e2faee... Since it captures exact dependencies, it becomes easier to put just what you need in the image. Prior to nix, my team (many years ago) built a redis image that was about 15MB in size by tracking the used files ans removing unused files. Nix does that reliably.

steve-chavez 5y ago
Can second Nix! With Nix we were able to reduce PostgREST image size[1] from over 30 MB to about 4 MB. [1]: https://github.com/PostgREST/postgrest/tree/main/nix/tools/docker#docker-image-built-with-nix https://github.com/PostgREST/postgrest/tree/main/nix/tools/d...
jvolkman 5y ago
We use Nix + Bazel. Nix builds the base image with Python and whatever else we want. Bazel layers our actual Python app on top of it. No dockerfiles at all. Example: https://github.com/jvolkman/bazel-nix-example https://github.com/jvolkman/bazel-nix-example
- kristjansson 5y ago
  It sounds so cool, but then I don’t get out of the base image before you’re writing your own Python launcher in a heredoc in a shell script in a docker image builder in a nix derivation[0]? Curiosity compels me to ask: how did all that become necessary? [0]: https://github.com/jvolkman/bazel-nix-example/blob/e0208355fc8cc891c17c851bcd2c271b355bc58a/python38_base_image.nix#L29 https://github.com/jvolkman/bazel-nix-example/blob/e0208355f...
  - jvolkman 5y ago
    It mostly grew out of using Nix to fetch a python interpreter for builds and tests. By default, Bazel will use whichever python binary is on the host (if any), which can lead to discrepancies between build hosts and various developer machines.
chriswarbo 5y ago
The main difference between Dockerfiles and something like Nix is that the former is run "internally" and the latter "externally". For example, a Dockerfile containing 'my-package-manager install foo' will create an image with foo and my-package-manager (which usually involves an entire OS, and at least a shell, etc.). An image built with Nix will only contain foo and its dependencies. Note that it's actually quite easy to make container images "externally", using just `tar`, `jq` and `sha256sum`. The nice thing about using Nix for this (rather than, e.g. Make) is the tracking of dependencies, all the way down to the particular libc, etc.

by sriku 5y ago

steve-chavez 5y ago

Can second Nix! With Nix we were able to reduce PostgREST image size[1] from over 30 MB to about 4 MB. [1]: https://github.com/PostgREST/postgrest/tree/main/nix/tools/docker#docker-image-built-with-nix https://github.com/PostgREST/postgrest/tree/main/nix/tools/d...

jvolkman 5y ago

We use Nix + Bazel. Nix builds the base image with Python and whatever else we want. Bazel layers our actual Python app on top of it. No dockerfiles at all. Example: https://github.com/jvolkman/bazel-nix-example https://github.com/jvolkman/bazel-nix-example

kristjansson 5y ago
It sounds so cool, but then I don’t get out of the base image before you’re writing your own Python launcher in a heredoc in a shell script in a docker image builder in a nix derivation[0]? Curiosity compels me to ask: how did all that become necessary? [0]: https://github.com/jvolkman/bazel-nix-example/blob/e0208355fc8cc891c17c851bcd2c271b355bc58a/python38_base_image.nix#L29 https://github.com/jvolkman/bazel-nix-example/blob/e0208355f...
- jvolkman 5y ago
  It mostly grew out of using Nix to fetch a python interpreter for builds and tests. By default, Bazel will use whichever python binary is on the host (if any), which can lead to discrepancies between build hosts and various developer machines.

chriswarbo 5y ago

The main difference between Dockerfiles and something like Nix is that the former is run "internally" and the latter "externally". For example, a Dockerfile containing 'my-package-manager install foo' will create an image with foo and my-package-manager (which usually involves an entire OS, and at least a shell, etc.). An image built with Nix will only contain foo and its dependencies. Note that it's actually quite easy to make container images "externally", using just `tar`, `jq` and `sha256sum`. The nice thing about using Nix for this (rather than, e.g. Make) is the tracking of dependencies, all the way down to the particular libc, etc.