-
- trim boto3/botocore, to remove all stuff I did not use, that sucker on it's own is over 100MB
The thing is what you need to understand is that the packages are primarily targeting the NixOS operating system, where in normal situation you have plenty of disk space, and you rather want all features to be available (because why not?). So you end up with bunch of dependencies, that you don't need. Alpine image for example was designed to be for docker, so the goal with all packages is to disable extra bells and whistles.
This is why your result is bigger.
To build a small image you will need to use override and disable all that unnecessary shit. Look at zulu for example:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
you add alsa, fontconfig (probably comes with entire X11), freetype, xorg (oh, nvm fontconfig, it's added explicitly), cups, gtk, cairo and ffmpeg)
Notice how your friend carefully extracts and places only needed files in the container, while you just bundle the entire zulu package with all of its dependencies in your project.
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
-
My experience with building Docker images for Java applications using Nix wasn't very pleasant though. After the deprecation of gradle2nix, there doesn't seem to be a clear alternative method for building Docker images for Gradle-based Java applications. I challenged a friend to create the smallest possible Docker image for a simple Spring Boot application. While I was using Nix, the resulting image was twice the size of the image built without Nix. You can check out the code for yourself here: https://github.com/jossephus/Docker_challenge/blob/main/flak... .
-
Having the author do this for a service written in Go is a mistake. Your first address for containerizing Go services should be ko: https://ko.build/ , and similar solutions like Jib in the Java ecosystem: https://github.com/GoogleContainerTools/jib . No need to require everyone to install something heavy like Nix, no need for privileged containers in CI to connect to a Docker daemon so that actual commands can be executed to determine filesystem contents, just the absolute bare minimum of a manifest defining a base layer + the compiled artifacts copied into the tarball at the correct positions. More languages should support this kind of model - when you see that pnpm's recipe (https://pnpm.io/docker), ultimately, is to pick a pre-existing node base image, then copy artifacts in and set some manifest settings, there's really no technical reason why something like "pnpm build-container-image", without a dependency on a Docker daemon, hasn't been implemented yet.
Using nix, or Dockerfile, or similar systems are, today, fundamentally additional complications to support building containerized systems that are not pure Go or pure Java etc. So we should stop recommending them as the default.
-
Since there are a plethora of dagger projects, lazyweb: https://github.com/dagger/dagger#readme
They also recently released their "github actions" replacement <https://news.ycombinator.com/item?id=39550431> but holy hell their documentation is just aggressively bad
-
Does anyone here have any experience using https://github.com/pdtpartners/nix-snapshotter ?
I build a lot of Docker images using Nix, and while yes it’s generally more pleasant than using Dockerfiles, the 128 layer limit is really annoying and easy to hit when you start building images with Nix. The workaround of grouping store paths makes poor use of storage and bandwidth.
-
No discussion about Nix-built containers is complete with nix2container:
https://github.com/nlewo/nix2container
It is truly magical for handling large, multi-layered containers. Instead of building the container archives themselves and storing them in the nix store, it builds a JSON manifest that is consumed by a lightly patched version of skopeo that streams the layers directly to either your local container engine or the registry.
This means you never rebuild or reupload a container layer that is unchanged.
-
https://github.com/gytis-ivaskevicius/high-quality-nix-conte...
This sort of twenty-minute adventure?
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
https://github.com/gytis-ivaskevicius/high-quality-nix-conte...
This sort of twenty-minute adventure?
-
Newcomer here. Could anyone tell if std [0] is a good way to bring more sanity into flake design, esp. in avoiding ivory towery custom approaches? Using devenv.sh is another option, but I liked emphasis on having a common mental picture and focus on SLDC that std provides.
[0] https://std.divnix.com
-
There are attempts like
https://flake.parts/
or
https://github.com/nix-community/flakelight
Their aim is to create an ecosystem of reusable Nix libraries. But it is tiny.
-
There are attempts like
https://flake.parts/
or
https://github.com/nix-community/flakelight
Their aim is to create an ecosystem of reusable Nix libraries. But it is tiny.
-
There's not much else that can be done here. glibc is the next largest dependency at ~30MB. This large size seems to be because Nixpkgs configures glibc to be built with support for many locales and character encodings. I don't know if it would be possible or practical to split these files out into separate derivations or outputs and make them optional that way. If you're using multiple images built by dockerTools.buildLayeredImage, glibc (and everything else) will be shared across all of them anyway (given you're using roughly the same Nixpkgs commit).
https://github.com/max-privatevoid/hackernews-docker-challen...
-
There's not much else that can be done here. glibc is the next largest dependency at ~30MB. This large size seems to be because Nixpkgs configures glibc to be built with support for many locales and character encodings. I don't know if it would be possible or practical to split these files out into separate derivations or outputs and make them optional that way. If you're using multiple images built by dockerTools.buildLayeredImage, glibc (and everything else) will be shared across all of them anyway (given you're using roughly the same Nixpkgs commit).
https://github.com/max-privatevoid/hackernews-docker-challen...
-
Yes, fantastic work. Downside is that snapshot.debian.org is extremely slow, times out / errors out regularly - very annoying. See also e.g. https://github.com/spesmilo/electrum/issues/8496 for complaints (but it's pretty apparent once you integrate this in your builds).
-
Ubuntu now has snapshot.ubuntu.com, see https://ubuntu.com/blog/ubuntu-snapshots-on-azure-ensuring-p...
Related discussion about reproducible builds by the Docker people: https://github.com/docker-library/official-images/issues/160...
-
Yes it’s going to depend on which k8s distribution you’re using. We have work in-progress for k3s to natively support nix-snapshotter: https://github.com/k3s-io/k3s/pull/9319
For other distributions, nix-snapshotter works with official containerd releases so it’s just a matter of toml configuration and a systemd unit for nix-snapshotter.
We run Kubernetes outside of NixOS, but yes the NixOS modules provided by the nix-snapshotter certainly make it simple.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
