mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tvl-depot/tools/nixery
History
Vincent Ambo 980f5e2187 refactor(server): Move package source management logic to server 
Introduces three new types representing each of the possible package
sources and moves the logic for specifying the package source to the
server.

Concrete changes:

* Determining whether a specified git reference is a commit vs. a
  branch/tag is now done in the server, and is done more precisely by
  using a regular expression.

* Package sources now have a new `CacheKey` function which can be used
  to retrieve a key under which a build manifest can be cached *if*
  the package source is not a moving target (i.e. a full git commit
  hash of either nixpkgs or a private repository).

  This function is not yet used.

* Users *must* now specify a package source, Nixery no longer defaults
  to anything and will fail to launch if no source is configured.
2019-09-10 11:32:37 +01:00
..
build-image refactor(server): Move package source management logic to server 2019-09-10 11:32:37 +01:00
docs docs: Add information about NIX_TIMEOUT variable 2019-09-02 23:44:57 +01:00
popcount feat(popcount): Clean up popularity counting script 2019-08-14 00:02:04 +01:00
server refactor(server): Move package source management logic to server 2019-09-10 11:32:37 +01:00
.gitattributes docs: Replace static page with mdBook site 2019-08-05 00:32:53 +01:00
.gitignore chore: Prevent accidental key leaks via gitignore 2019-08-03 01:25:36 +01:00
.travis.yml refactor(server): Move package source management logic to server 2019-09-10 11:32:37 +01:00
CONTRIBUTING.md docs(CONTRIBUTING): Mention commit message format 2019-07-29 21:10:04 +01:00
default.nix refactor(server): Move package source management logic to server 2019-09-10 11:32:37 +01:00
LICENSE chore: Add license scaffolding & contribution guidelines 2019-07-23 23:32:56 +01:00
README.md docs: Add information about NIX_TIMEOUT variable 2019-09-02 23:44:57 +01:00
shell.nix style: Apply nixfmt to trivial Nix files 2019-08-14 00:02:04 +01:00

README.md

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.

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.

This is not an officially supported Google project.

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

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

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

  • 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 a package set hosted in a custom git repository or filesystem path.

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

    For example, if a company used a custom repository overlaying their packages on the Nix package set, images could be built from a git tag release-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 and forwards requests to retrieve layers to the bucket. This enables efficient serving of layers, as well as sharing of image layers between redundant instances.

Configuration

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

  • BUCKET: Google Cloud Storage bucket to store & serve image layers
  • 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 (uses locally configured SSH/git credentials)
  • NIXERY_PKGS_PATH: A local filesystem path containing a Nix package set to use for building
  • NIX_TIMEOUT: Number of seconds that any Nix builder is allowed to run (defaults to 60
  • GCS_SIGNING_KEY: A Google service account key (in PEM format) that can be used to sign Cloud Storage URLs
  • GCS_SIGNING_ACCOUNT: Google service account ID that the signing key belongs to

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.