6 ms·

Nixpacks takes a source directory and produces an OCI compliant image

152 points by ghuntley 4y ago

jonringer117 4y ago
Nice, really interesting usage of nixpkgs :). Almost a command line friendly version of docker build. I like it.
- justjake 4y ago
  That's the ideal! We want to make it more trivial to build OCI compliant images without all the knowledge required to understand how Dockerfiles/Container Filesystem/BuildLayers/etc work BuildKit makes this possible and we've got lots of stuff planned. Would love to hear anything you can think of that would make this more friendly!
justjake 4y ago
Oh neat. We've been meaning to post this on HN! We're the people behind nixpacks; happy to answer any questions just holler
- ghuntley 4y ago
  It’s a small world. Shoutout to Domen (https://www.cachix.org/ https://www.cachix.org/) who introduced me to nixpacks.
  - justjake 4y ago
    Shoutout Domen indeed!
  - ditsuke 4y ago
    Small world indeed!
  - domenkozar 4y ago
    I've mentioned them at my talk yesterday :) https://youtu.be/WuWZqSSoLxY https://youtu.be/WuWZqSSoLxY
0xferruccio 4y ago
Loved this! Tried this on a rails app for a side project and it worked out of the box
gavinray 4y ago
Neato -- so basically Buildpacks[0] redone with Nix? [0]: https://buildpacks.io/ https://buildpacks.io/
- justjake 4y ago
  It's in the same vein, but our goal is to create a standard for fully reproducible builds Nixpacks can also spit out a plan (https://nixpacks.com/docs/how-it-works#plan https://nixpacks.com/docs/how-it-works#plan) which, when run again, will assure that the build artifacts the exact same every time it's run against that plan. The result is that any code that's built with nixpacks has all it's dependencies snapshotted so it won't break over time. For us, that means anytime someone comes to our platform (http://railway.app/ http://railway.app/) and deploys an Template, it won't be broken
0x69420 4y ago
name is eerily similar to `nixpkgs`, i.e. the monorepo that defines all packages and one of the underlying technologies here. i get the play on buildpacks, but still, as a nix user it makes me do a double take reading the name this is neat though, and in political terms, the elevator pitch mentions nix itself as an implementation detail in passing. hopefully, if this catches on, it'll function as a non-threatening gateway drug to nix itself, when users inevitably go digging into the weeds for anyone interested, prior art on the nix container front: https://nixery.dev https://nixery.dev
- justjake 4y ago
  The similarity is definitely on purpose. It pulls ideals from both nixpkgs as well as the cloud native buildpacks. Our goal is to make reproducibility more approachable/less cumbersome, and for people to be able to define additional nix/apt/etc packages added to the container . You can add package you'd like via the environment variables NIXPACKS_PKGS (or NIXPACKS_APT_PKGS for apt)
jbboehr 4y ago
Do builds use sandboxing? It appears not[0], is this in the roadmap? Based on my experiences with node2nix, composer2nix, carnix, etc, I don't blame you for not going that route. Not to knock on the developers of those tools - it's a difficult problem. I apologize if my interpretation is incorrect. [0]: https://github.com/railwayapp/nixpacks/blob/60ab563fdc9bf4fb5540388680a2f368e0436db2/src/providers/php.rs#L82 https://github.com/railwayapp/nixpacks/blob/60ab563fdc9bf4fb...
xelxebar 4y ago
Somewhat tangential, but I'm curious how big the bootstrap seed for Nix is. That is, if you wanted to build the entire world, what's a minimum set of binaries you'd need? Guix has put quite a bit of work into this, AFAIU, and it's getting close to being bootstrappable all the way from stage0 [0]. Curious if some group is also working on similar things for Nix. [0]:https://github.com/oriansj/stage0 https://github.com/oriansj/stage0
- xyzzy_plugh 4y ago
  I would think the bootstrap for cross-compile would be pretty close to the answer to your question. Guix has pretty radical goals in comparison to Nix, which is itself relatively radical. Bootstrapping Nix is... maybe less useful to optimize? I'm not saying it's not worth solving, but as an end user I really don't care if my packages are built from source or not, as long as I can, for example, use Spotify.
chriswarbo 4y ago
Looks like this requires Docker to be available? Personally I've been making OCI images using Nix, just by running tar, sha256sum and jq: - We can get a Nix derivation's dependencies using `writeDependenciesToFile` - We can put these dependencies (alongside anything else we like) into an OCI "layer" using GNU tar: the `--hard-dereference` and `--mode=755` options work well, and we can include directories using `-C /foo --filesFrom=foo.txt` where foo.txt comes from `cd /foo && find . -maxdepth 1`, with the leading `./` removed. - A "digest" is just a JSON file like `{size: 123, digest: "abc"}`, e.g. generated using `stat` and `sha256sum` - Those sha256sums can be referenced in a config.json, like `{"rootfs": {"type": "layers", "diff_ids": [...]}}`; along with the application-specific config (EntryPoint, WorkingDir, etc.) - Finally, a "manifest" is just another JSON file; with `{"mediaType": "application/vnd.oci.image.config.v1+json"}` for the config digest, and `{"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip"}` for each layer digest. Unlike Docker, these commands can all be run directly (from the "host", although it's not really hosting anything, since we don't need any containers or VMs to run the above); their contents are completely declarative (since we're just zipping up pre-existing files, e.g. built/fetched by Nix; rather than mutating a filesystem in-place); we can do it on any OS (e.g. no need for a Linux VM on macOS); etc.
- ris 4y ago
  Um.. `dockerTools`/`ociTools`? https://nixos.org/manual/nixpkgs/stable/#chap-images https://nixos.org/manual/nixpkgs/stable/#chap-images
  - chriswarbo 4y ago
    > dockerTools "Tags", "registries", "base images", "extraCommands"... no thanks > ociTools IIRC, this generates a runnable container (i.e. a directory, with accompanying config); not a container image, e.g. suitable for uploading to AWS ECS.
    - kam 4y ago
      > "Tags", "registries", "base images", "extraCommands"... no thanks All of which are optional. It's just doing the same thing as your tar commands.
ris 4y ago
It's interesting/neat, but it doesn't make use of e.g. nixpkgs' beautifully maintained python package distribution, leaving you with all the same pitfalls of pip/pypi as any other buildpack. And I don't imagine the end result will be a "pure" artefact, and so I can't see how they'd be able to safely remove the build-time packages from the final image.
- justjake 4y ago
  Sorry which distribution exactly? We utilize the python's nixpkgs versioned packages See: https://github.com/railwayapp/nixpacks/blob/f88718efe1156671a9da0178fd9d161a25f6a854/src/providers/python.rs#L21 https://github.com/railwayapp/nixpacks/blob/f88718efe1156671...
  - zevisert 4y ago
    Do you? I think they're referring to these packages[0]. For me `nixpacks plan .` seems to generate a plain old pip (or poetry) install. The problem with the python packaging ecosystem is that since the start, in order to figure out which dependencies a package has, we needed to run arbitrary python code (setup.py). I can write a package in 5 minutes that declares its deps with `random.choice`. If you're installing from pypi.org, then there's no reproducibility guarantee. Though, I know nothing about Nix or how it works, so maybe you're changing pip's index-url somewhere else.. [0]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/python-packages.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
    - coffee-cup 4y ago
      You are correct in that Nixpacks uses the languages own package manager instead of installing all dependencies with Nix using tools like node2nix, cargo2nix, or poetry2nix. This was a choice as the main problems Nixpacks aims to solve are with system dependencies and getting an environment where your app can install and build with as little configuration as possible. While continuing to use the same tooling that app authors are likely using locally (e.g. npm, pip, cargo). We have found that nixifying all possible deps often creates situations where the app author must know that Nix is being used under the hood and modify their app accordingly. Nothing against these tools, but using them didn't provide the experience we set out to have. If a user of Nixpacks wants to override the install command to `do_something && npm install`, they should be able to without worrying about how it affects the Nix store. However, any Nix package can be installed, including from python-packages.nix, and we are planning on allowing more Nix config and customization in the future.
mrkurt 4y ago
We added experimental support to Nixpacks for Fly.io (it's baked into our CLI). I'm very excited about it, buildpacks have been a nightmare.
- xyzzy_plugh 4y ago
  > buildpacks have been a nightmare. Can you share more? I thought a Fly.io person said _the opposite_ some time ago so I would love to know what the pain points are.
aliasxneo 4y ago
I've been using nix2container[1] for awhile now. It looks like this depends on Docker, have you guys considered removing that dependency? It shouldn't be necessary to create an OCI compliant image with Nix. [1]: https://github.com/nlewo/nix2container https://github.com/nlewo/nix2container
mathfailure 4y ago
I don't like the docs / project description. Everything is made 'so simple' that important parts are now gone and everything is now pure magic, I guess. > We want to make it more trivial to build OCI compliant images without all the knowledge required to understand how Dockerfiles/Container Filesystem/BuildLayers/etc work As someone who understands how the above mentioned stuff works - I feel like I'm being forcefully excluded from the tool's target audience as I need explanations and the docs are written with such an idea in mind that it is something I shouldn't know. https://nixpacks.com/docs/how-it-works https://nixpacks.com/docs/how-it-works > Nixpacks works in two steps > Plan > Analyze the app source directory and generates a reproducible build plan. This plan can be saved (in JSON format) and re-used at a later date to build the image in the exact same way every time. How about an example of how a simple plan for a few projects would look like? Plus, the tool seems to assume too much: > To create the plan, language providers are matched against the app source directory and suggest Nix packages I don't need no Nix in my images, no thanks.
pxc 4y ago
This is really cool, and reminds me of some parts of Domen Kozar's recent talk titled 'Nix is going mainstream'¹. The crucial work of putting together this kind of really simple frontend seems like what he's talking about when he says we need 'our Docker', like how Docker built upon old tech (chroots, jails, LXC) to make it radically more usable. -- 1: https://youtu.be/WuWZqSSoLxY https://youtu.be/WuWZqSSoLxY
ev0xmusic 4y ago
I've just published a feedback article on Nixpacks since I experimented it 2 months ago. https://www.qovery.com/blog/my-feedback-about-nixpacks-an-alternative-to-buildpacks https://www.qovery.com/blog/my-feedback-about-nixpacks-an-al... TLDR; it's promising

152 points by ghuntley 4y ago

jonringer117 4y ago

Nice, really interesting usage of nixpkgs :). Almost a command line friendly version of docker build. I like it.

justjake 4y ago
That's the ideal! We want to make it more trivial to build OCI compliant images without all the knowledge required to understand how Dockerfiles/Container Filesystem/BuildLayers/etc work BuildKit makes this possible and we've got lots of stuff planned. Would love to hear anything you can think of that would make this more friendly!

justjake 4y ago

Oh neat. We've been meaning to post this on HN! We're the people behind nixpacks; happy to answer any questions just holler

ghuntley 4y ago
It’s a small world. Shoutout to Domen (https://www.cachix.org/ https://www.cachix.org/) who introduced me to nixpacks.
- justjake 4y ago
  Shoutout Domen indeed!
- ditsuke 4y ago
  Small world indeed!
- domenkozar 4y ago
  I've mentioned them at my talk yesterday :) https://youtu.be/WuWZqSSoLxY https://youtu.be/WuWZqSSoLxY

0xferruccio 4y ago

Loved this! Tried this on a rails app for a side project and it worked out of the box

gavinray 4y ago

Neato -- so basically Buildpacks[0] redone with Nix? [0]: https://buildpacks.io/ https://buildpacks.io/

justjake 4y ago
It's in the same vein, but our goal is to create a standard for fully reproducible builds Nixpacks can also spit out a plan (https://nixpacks.com/docs/how-it-works#plan https://nixpacks.com/docs/how-it-works#plan) which, when run again, will assure that the build artifacts the exact same every time it's run against that plan. The result is that any code that's built with nixpacks has all it's dependencies snapshotted so it won't break over time. For us, that means anytime someone comes to our platform (http://railway.app/ http://railway.app/) and deploys an Template, it won't be broken

0x69420 4y ago

name is eerily similar to `nixpkgs`, i.e. the monorepo that defines all packages and one of the underlying technologies here. i get the play on buildpacks, but still, as a nix user it makes me do a double take reading the name this is neat though, and in political terms, the elevator pitch mentions nix itself as an implementation detail in passing. hopefully, if this catches on, it'll function as a non-threatening gateway drug to nix itself, when users inevitably go digging into the weeds for anyone interested, prior art on the nix container front: https://nixery.dev https://nixery.dev

justjake 4y ago
The similarity is definitely on purpose. It pulls ideals from both nixpkgs as well as the cloud native buildpacks. Our goal is to make reproducibility more approachable/less cumbersome, and for people to be able to define additional nix/apt/etc packages added to the container . You can add package you'd like via the environment variables NIXPACKS_PKGS (or NIXPACKS_APT_PKGS for apt)

jbboehr 4y ago

Do builds use sandboxing? It appears not[0], is this in the roadmap? Based on my experiences with node2nix, composer2nix, carnix, etc, I don't blame you for not going that route. Not to knock on the developers of those tools - it's a difficult problem. I apologize if my interpretation is incorrect. [0]: https://github.com/railwayapp/nixpacks/blob/60ab563fdc9bf4fb5540388680a2f368e0436db2/src/providers/php.rs#L82 https://github.com/railwayapp/nixpacks/blob/60ab563fdc9bf4fb...

xelxebar 4y ago

Somewhat tangential, but I'm curious how big the bootstrap seed for Nix is. That is, if you wanted to build the entire world, what's a minimum set of binaries you'd need? Guix has put quite a bit of work into this, AFAIU, and it's getting close to being bootstrappable all the way from stage0 [0]. Curious if some group is also working on similar things for Nix. [0]:https://github.com/oriansj/stage0 https://github.com/oriansj/stage0

xyzzy_plugh 4y ago
I would think the bootstrap for cross-compile would be pretty close to the answer to your question. Guix has pretty radical goals in comparison to Nix, which is itself relatively radical. Bootstrapping Nix is... maybe less useful to optimize? I'm not saying it's not worth solving, but as an end user I really don't care if my packages are built from source or not, as long as I can, for example, use Spotify.

chriswarbo 4y ago

Looks like this requires Docker to be available? Personally I've been making OCI images using Nix, just by running tar, sha256sum and jq: - We can get a Nix derivation's dependencies using `writeDependenciesToFile` - We can put these dependencies (alongside anything else we like) into an OCI "layer" using GNU tar: the `--hard-dereference` and `--mode=755` options work well, and we can include directories using `-C /foo --filesFrom=foo.txt` where foo.txt comes from `cd /foo && find . -maxdepth 1`, with the leading `./` removed. - A "digest" is just a JSON file like `{size: 123, digest: "abc"}`, e.g. generated using `stat` and `sha256sum` - Those sha256sums can be referenced in a config.json, like `{"rootfs": {"type": "layers", "diff_ids": [...]}}`; along with the application-specific config (EntryPoint, WorkingDir, etc.) - Finally, a "manifest" is just another JSON file; with `{"mediaType": "application/vnd.oci.image.config.v1+json"}` for the config digest, and `{"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip"}` for each layer digest. Unlike Docker, these commands can all be run directly (from the "host", although it's not really hosting anything, since we don't need any containers or VMs to run the above); their contents are completely declarative (since we're just zipping up pre-existing files, e.g. built/fetched by Nix; rather than mutating a filesystem in-place); we can do it on any OS (e.g. no need for a Linux VM on macOS); etc.

ris 4y ago
Um.. `dockerTools`/`ociTools`? https://nixos.org/manual/nixpkgs/stable/#chap-images https://nixos.org/manual/nixpkgs/stable/#chap-images
- chriswarbo 4y ago
  > dockerTools "Tags", "registries", "base images", "extraCommands"... no thanks > ociTools IIRC, this generates a runnable container (i.e. a directory, with accompanying config); not a container image, e.g. suitable for uploading to AWS ECS.
  - kam 4y ago
    > "Tags", "registries", "base images", "extraCommands"... no thanks All of which are optional. It's just doing the same thing as your tar commands.

ris 4y ago

It's interesting/neat, but it doesn't make use of e.g. nixpkgs' beautifully maintained python package distribution, leaving you with all the same pitfalls of pip/pypi as any other buildpack. And I don't imagine the end result will be a "pure" artefact, and so I can't see how they'd be able to safely remove the build-time packages from the final image.

justjake 4y ago
Sorry which distribution exactly? We utilize the python's nixpkgs versioned packages See: https://github.com/railwayapp/nixpacks/blob/f88718efe1156671a9da0178fd9d161a25f6a854/src/providers/python.rs#L21 https://github.com/railwayapp/nixpacks/blob/f88718efe1156671...
- zevisert 4y ago
  Do you? I think they're referring to these packages[0]. For me `nixpacks plan .` seems to generate a plain old pip (or poetry) install. The problem with the python packaging ecosystem is that since the start, in order to figure out which dependencies a package has, we needed to run arbitrary python code (setup.py). I can write a package in 5 minutes that declares its deps with `random.choice`. If you're installing from pypi.org, then there's no reproducibility guarantee. Though, I know nothing about Nix or how it works, so maybe you're changing pip's index-url somewhere else.. [0]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/python-packages.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
  - coffee-cup 4y ago
    You are correct in that Nixpacks uses the languages own package manager instead of installing all dependencies with Nix using tools like node2nix, cargo2nix, or poetry2nix. This was a choice as the main problems Nixpacks aims to solve are with system dependencies and getting an environment where your app can install and build with as little configuration as possible. While continuing to use the same tooling that app authors are likely using locally (e.g. npm, pip, cargo). We have found that nixifying all possible deps often creates situations where the app author must know that Nix is being used under the hood and modify their app accordingly. Nothing against these tools, but using them didn't provide the experience we set out to have. If a user of Nixpacks wants to override the install command to `do_something && npm install`, they should be able to without worrying about how it affects the Nix store. However, any Nix package can be installed, including from python-packages.nix, and we are planning on allowing more Nix config and customization in the future.

mrkurt 4y ago

We added experimental support to Nixpacks for Fly.io (it's baked into our CLI). I'm very excited about it, buildpacks have been a nightmare.

xyzzy_plugh 4y ago
> buildpacks have been a nightmare. Can you share more? I thought a Fly.io person said _the opposite_ some time ago so I would love to know what the pain points are.

aliasxneo 4y ago

I've been using nix2container[1] for awhile now. It looks like this depends on Docker, have you guys considered removing that dependency? It shouldn't be necessary to create an OCI compliant image with Nix. [1]: https://github.com/nlewo/nix2container https://github.com/nlewo/nix2container

mathfailure 4y ago

I don't like the docs / project description. Everything is made 'so simple' that important parts are now gone and everything is now pure magic, I guess. > We want to make it more trivial to build OCI compliant images without all the knowledge required to understand how Dockerfiles/Container Filesystem/BuildLayers/etc work As someone who understands how the above mentioned stuff works - I feel like I'm being forcefully excluded from the tool's target audience as I need explanations and the docs are written with such an idea in mind that it is something I shouldn't know. https://nixpacks.com/docs/how-it-works https://nixpacks.com/docs/how-it-works > Nixpacks works in two steps > Plan > Analyze the app source directory and generates a reproducible build plan. This plan can be saved (in JSON format) and re-used at a later date to build the image in the exact same way every time. How about an example of how a simple plan for a few projects would look like? Plus, the tool seems to assume too much: > To create the plan, language providers are matched against the app source directory and suggest Nix packages I don't need no Nix in my images, no thanks.

pxc 4y ago

This is really cool, and reminds me of some parts of Domen Kozar's recent talk titled 'Nix is going mainstream'¹. The crucial work of putting together this kind of really simple frontend seems like what he's talking about when he says we need 'our Docker', like how Docker built upon old tech (chroots, jails, LXC) to make it radically more usable. -- 1: https://youtu.be/WuWZqSSoLxY https://youtu.be/WuWZqSSoLxY

ev0xmusic 4y ago

I've just published a feedback article on Nixpacks since I experimented it 2 months ago. https://www.qovery.com/blog/my-feedback-about-nixpacks-an-alternative-to-buildpacks https://www.qovery.com/blog/my-feedback-about-nixpacks-an-al... TLDR; it's promising