Home

Awesome

<div align="center"> <img src="https://nixery.dev/nixery-logo.png"> </div>

Build status

Nixery is a Docker-compatible container registry that is capable of transparently building and serving container images using Nix.

Images are built on-demand based on the image name. Every package that the user intends to include in the image is specified as a path component of the image name.

The path components refer to top-level keys in nixpkgs and are used to build a container image using a layering strategy that optimises for caching popular and/or large dependencies.

A public instance as well as additional documentation is available at nixery.dev.

You can watch the NixCon 2019 talk about Nixery for more information about the project and its use-cases.

The canonical location of the Nixery source code is //tools/nixery in the TVL monorepository. If cloning the entire repository is not desirable, the Nixery subtree can be cloned like this:

git clone https://code.tvl.fyi/depot.git:/tools/nixery.git

The subtree is infrequently mirrored to tazjin/nixery on Github.

Demo

Click the image to see an example in which an image containing an interactive shell and GNU hello is downloaded.

asciicast

To try it yourself, head to nixery.dev!

The special meta-package shell provides an image base with many core components (such as bash and coreutils) that users commonly expect in interactive images.

Feature overview

Configuration

Nixery supports the following configuration options, provided via environment variables:

If the GOOGLE_APPLICATION_CREDENTIALS environment variable is set to a service account key, Nixery will also use this key to create [signed URLs][] for layers in the storage bucket. This makes it possible to serve layers from a bucket without having to make them publicly available.

In case the GOOGLE_APPLICATION_CREDENTIALS environment variable is not set, a redirect to storage.googleapis.com is issued, which means the underlying bucket objects need to be publicly accessible.

Storage

Nixery supports multiple different storage backends in which its build cache and image layers are kept, and from which they are served.

Currently the available storage backends are Google Cloud Storage and the local file system.

In the GCS case, images are served by redirecting clients to the storage bucket. Layers stored on the filesystem are served straight from the local disk.

These extra configuration variables must be set to configure storage backends:

Background

The project started out inspired by the buildLayeredImage blog post with the intention of becoming a Kubernetes controller that can serve declarative image specifications specified in CRDs as container images. The design for this was outlined in a public gist.

Roadmap

Kubernetes integration

It should be trivial to deploy Nixery inside of a Kubernetes cluster with correct caching behaviour, addressing and so on.

See issue #4.

Nix-native builder

The image building and layering functionality of Nixery will be extracted into a separate Nix function, which will make it possible to build images directly in Nix builds.