Live data from Hacker News

Nixery – Docker images on the fly with Nix

nixery.dev

31–40 of 90 posts

Re: Nixery – Docker images on the fly with Nix

#31
post #29

In the same spirit but in the form of a readily-usable command (rather than a service), 'guix pack' can produce application bundles in a reproducible fashion, in the Docker format as well as in other formats: https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix... Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'!

> Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'!

I've been meaning to extract it into a more standalone tool that can output a layer distribution, that way it could also be used in things like Nix's `dockerTools.buildLayeredImage`. The main annoyance is that creating the popularity data inside of a build is not easily possible for the entirety of the package set. Still working on that one ...

I'm not sure how much Guix internals have diverged since they forked Nix, but if the dependency analysis of store paths can be done the same way then this should also be straightforward to port to Guix.

Re: Nixery – Docker images on the fly with Nix

#32

This is really cool, but I don’t know if I see the appeal for actual nix users — if you are a nix user and have it set up in CI, you can easily build docker images yourself using buildLayeredImage. And then if you aren’t a nix user, why would you use this? Installing packages with, say, apt, is decidedly not where my pains with docker have arose.

If I need an image with a specific set of tools it's cumbersome to build a whole workflow to build, store and maintain these images. Having a service that can receive a custom list of Nix packages and returns an image that I can instantly use would be really, really, really nice.

That's what most users of nixery.dev (i.e. the public instance) do, afaict. Ad-hoc images for CI, and for debugging purposes.

Re: Nixery – Docker images on the fly with Nix

#33
post #4

Oh great! More indirection. Now when I want to deploy my web app I can check my private nixery.dev deployment is properly configured in Nix to build my Docker images so I can deploy my containers to the cloud so someone can access me Rest API. And the cost of guaranteeing builds will probably work? Running your own nixery service, learning Nix, and learning Docker. I would love someone to do a cost-benefit analysis o…

Nix makes a lot of sense if you really understand build system. But makes less sense if you understand operations, or management. Real world engineering is about trade-offs, and Nix has no wiggle room for compromise. It’s optimizes on one dimension: Reproducible builds. But an organisation won’t succeed when it places the needs of build system engineers on a pedestal.

It adds some effort and complexity to the "build" dimension of your multi-dimension optimization, yes.

But it also removes a whole bunch of complexity from every other dimension, by removing variability from the equation.

If you cannot rely on /what/ you are running, then what, exactly, are you testing? Do you really know?

I've found that most "managers" (in fact, most programmers) don't seem to appreciate this. The "well, I don't know what happened -- maybe reboot the system, and it'll work?" approach is insane.

Re: Nixery – Docker images on the fly with Nix

#34
I like how they optimize for layer reuse, but at the same time, nix doesn't really fit docker layer caching because it's better. With a unique prefix per package, you don't need stacking of layers. You can just download a bunch of packages in parallel, extract them in parallel, and finally "merge" the prefixes to get those combined bin/ and lib/ dirs.

Re: Nixery – Docker images on the fly with Nix

#35
post #4

Oh great! More indirection. Now when I want to deploy my web app I can check my private nixery.dev deployment is properly configured in Nix to build my Docker images so I can deploy my containers to the cloud so someone can access me Rest API. And the cost of guaranteeing builds will probably work? Running your own nixery service, learning Nix, and learning Docker. I would love someone to do a cost-benefit analysis o…

Nix makes a lot of sense if you really understand build system. But makes less sense if you understand operations, or management. Real world engineering is about trade-offs, and Nix has no wiggle room for compromise. It’s optimizes on one dimension: Reproducible builds. But an organisation won’t succeed when it places the needs of build system engineers on a pedestal.

Id disagree its uni-dimensional. It optimizes for reproducibility and hermeticity without using virtualization (i.e. better performance).

Re: Nixery – Docker images on the fly with Nix

#36
post #6

Is there a clean way to do reuse this for multistage builds? ``` FROM nixery.dev/shell/git/node14/python3.8 as debug_extras FROM our/production:1.2.3 COPY --from=debug_extras /nixstuff /ubuntu/stuff RUN python -c "print('nice!')" ```

It depends on what you are trying to get out of the builder pattern. I think it wouldn't provide any benefit to you but hard to say without knowing exactly what you want to achieve.

e.g. if you want to remove all the stuff that you aren't using then nix already does that with a GC

Re: Nixery – Docker images on the fly with Nix

#37
post #31
post #29

In the same spirit but in the form of a readily-usable command (rather than a service), 'guix pack' can produce application bundles in a reproducible fashion, in the Docker format as well as in other formats: https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix... Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'!

> Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'! I've been meaning to extract it into a more standalone tool that can output a layer distribution, that way it could also be used in things like Nix's `dockerTools.buildLayeredImage`. The main annoyance is that creating the popularity data inside of a build is not easily possible for the entirety of the package set. Stil…

With https://github.com/nlewo/nix2container, I'm trying to make a more standalone tool. Basically, a Go binary takes a reference graph and produces a JSON file describing a container image. This JSON file is then ingested by a Skopeo fork (it adds a new `transport`) to produce images (to file, registries,...).

Currently, it supports the dockerTools layering algorithm and is designed to work with Guix [1] as well;)

[1] https://github.com/nlewo/nix2container/blob/065e5b108650ee4c...

Re: Nixery – Docker images on the fly with Nix

#38
post #37
post #31

Earlier quoted context omitted.

> Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'! I've been meaning to extract it into a more standalone tool that can output a layer distribution, that way it could also be used in things like Nix's `dockerTools.buildLayeredImage`. The main annoyance is that creating the popularity data inside of a build is not easily possible for the entirety of the package set. Stil…

With https://github.com/nlewo/nix2container , I'm trying to make a more standalone tool. Basically, a Go binary takes a reference graph and produces a JSON file describing a container image. This JSON file is then ingested by a Skopeo fork (it adds a new `transport`) to produce images (to file, registries,...). Currently, it supports the dockerTools layering algorithm and is designed to work with Guix [1] as well;) […

Ah, I've actually seen this before. Since it's written in Go, you might be able to pretty much copy&paste the Nixery layering strategy into it. I wouldn't mind!

Re: Nixery – Docker images on the fly with Nix

#39

I don’t know if it’s just because I hopped on the bandwagon in the past few months, but it really is starting to feel like Nix is gaining momentum. You can use it on Mac, WSL, Ubuntu multiuser, Docker, in an nspawn container, or through NixOS on a drive. You can build a livecd iso or a Raspberry Pi image from the same flake that you use for everything else. I work in embedded with Yocto every day, and I can’t help bu…

I love nix, but you're a lot more optimistic and forgiving of its cons than I am :D

To be clear, I've not used NixOS and it might be a more reasonable experience. Nix package manager though is the most useful tool I have integrated into my dev-life and also the one I am most hesitant to recommend to anyone else. The UX of the whole thing still has a long way to go and the initial installation experience on Mac has been all over the place quality-wise in recent years. Now that flakes are officially a thing (even though they are still unofficial!!!) it again will take a while to stabilize.

My hope is that once that flake transition stabilizes we will have a much more reasonable baseline of UX to begin recommending to others without nearly as many caveats.

Re: Nixery – Docker images on the fly with Nix

#40

I don’t know if it’s just because I hopped on the bandwagon in the past few months, but it really is starting to feel like Nix is gaining momentum. You can use it on Mac, WSL, Ubuntu multiuser, Docker, in an nspawn container, or through NixOS on a drive. You can build a livecd iso or a Raspberry Pi image from the same flake that you use for everything else. I work in embedded with Yocto every day, and I can’t help bu…

To all the folks using Nix at scale: How are you doing it? Are you still using Kubernetes and friends, custom images, etc? How are you deploying apps or making changes to your Nix instances across a fleet of servers?
Post reply on HN