Repository files navigation

Nixery is a Docker-compatible container registry that is capable oftransparently building and serving container images usingNix.

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

The path components refer to top-level keys innixpkgs and are used to build acontainer image using alayering strategy that optimises for caching popularand/or large dependencies.

A public instance as well as additional documentation is available atnixery.dev.

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

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

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

The subtree is infrequently mirrored totazjin/nixery on Github.

Click the image to see an example in which an image containing an interactiveshell and GNUhello is downloaded.

To try it yourself, head tonixery.dev!

The special meta-packageshell provides an image base with many corecomponents (such asbash andcoreutils) that users commonly expect ininteractive images.

• Serve container images on-demand using image names as content specifications

  Specify package names as path components and Nixery will create images, usingthe most efficient caching strategy it can to share data between differentimages.

• Use private package sets from various sources

  In addition to building images from the publicly available Nix/NixOS channels,a private Nixery instance can be configured to serve images built from apackage set hosted in a custom git repository or filesystem path.

  When using this feature with custom git repositories, Nixery will forward thespecified image tags as git references.

  For example, if a company used a custom repository overlaying their packageson the Nix package set, images could be built from a git tagrelease-v2:

  docker pull nixery.thecompany.website/custom-service:release-v2

• Efficient serving of image layers from Google Cloud Storage

  After building an image, Nixery stores all of its layers in a GCS bucket andforwards requests to retrieve layers to the bucket. This enables efficientserving of layers, as well as sharing of image layers between redundantinstances.

Nixery supports the following configuration options, provided via environmentvariables:

• PORT: HTTP port on which Nixery should listen

• NIXERY_CHANNEL: The name of a Nix/NixOS channel to use for building

• NIXERY_PKGS_REPO: URL of a git repository containing a package set (useslocally configured SSH/git credentials)

• NIXERY_PKGS_PATH: A local filesystem path containing a Nix package set touse for building

• NIXERY_STORAGE_BACKEND: The type of backend storage to use, currentlysupported values aregcs (Google Cloud Storage) andfilesystem.

  For each of these additional backend configuration is necessary, see thestorage section for details.

• NIX_TIMEOUT: Number of seconds that any Nix builder is allowed to run(defaults to 60)

• NIX_POPULARITY_URL: URL to a file containing popularity data forthe package set (seepopcount/)

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

In case theGOOGLE_APPLICATION_CREDENTIALS environment variable is not set, aredirect to storage.googleapis.com is issued, which means the underlying bucketobjects need to be publicly accessible.

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

Currently the available storage backends are Google Cloud Storage and the localfile 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:

• GCS_BUCKET: Name of the Google Cloud Storage bucket to use (required forgcs)
• GOOGLE_APPLICATION_CREDENTIALS: Path to a GCP service account JSON key(optional forgcs)
• STORAGE_PATH: Path to a folder in which to store and from which to servedata (required forfilesystem)

The project started out inspired by thebuildLayeredImage blog post with theintention of becoming a Kubernetes controller that can serve declarative imagespecifications specified in CRDs as container images. The design for this wasoutlined ina public gist.

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

Seeissue #4.

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