tvl-depot/tools/nixery
Vincent Ambo 2db92243e7 feat(nix): Support package set imports from different sources
This extends the package set import mechanism in
build-registry-image.nix with several different options:

1. Importing a nixpkgs channel from Github (the default, pinned to
   nixos-19.03)

2. Importing a custom Nix git repository. This uses builtins.fetchGit
   and can thus rely on git/SSH configuration in the environment (such
   as keys)

3. Importing a local filesystem path

As long as the repository pointed at is either a checkout of nixpkgs,
or nixpkgs overlaid with custom packages this will work.

A special syntax has been defined for how these three options are
passed in, but users should not need to concern themselves with it as
it will be taken care of by the server component.

This relates to #3.
2019-07-31 15:28:36 +01:00
..
static docs(static): Update index page with post-launch information 2019-07-30 13:42:43 +01:00
.gitignore feat(static): Add logo & favicon resources 2019-07-30 13:42:43 +01:00
.travis.yml feat(build): Add Travis configuration to build everything 2019-07-30 13:42:43 +01:00
build-registry-image.nix feat(nix): Support package set imports from different sources 2019-07-31 15:28:36 +01:00
CONTRIBUTING.md docs(CONTRIBUTING): Mention commit message format 2019-07-29 21:10:04 +01:00
default.nix feat(build): Add dependencies for custom repo clones 2019-07-31 15:28:36 +01:00
go-deps.nix feat(build): Introduce build configuration using Nix 2019-07-23 21:48:27 +01:00
LICENSE chore: Add license scaffolding & contribution guidelines 2019-07-23 23:32:56 +01:00
main.go refactor(main): Introduce more flexible request routing 2019-07-30 13:42:43 +01:00
README.md docs(README): Add logo & build status 2019-07-30 13:42:43 +01:00


Build Status

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

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

Currently it focuses on the ad-hoc creation of container images as outlined below with an example instance available at nixery.appspot.com.

This is not an officially supported Google project.

Ad-hoc container images

Nixery supports building images 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 Nix's buildLayeredImage functionality.

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.

Usage example

Using the publicly available Nixery instance at nixery.appspot.com, one could retrieve a container image containing curl and an interactive shell like this:

tazjin@tazbox:~$ sudo docker run -ti nixery.appspot.com/shell/curl bash
Unable to find image 'nixery.appspot.com/shell/curl:latest' locally
latest: Pulling from shell/curl
7734b79e1ba1: Already exists
b0d2008d18cd: Pull complete
< ... some layers omitted ...>
Digest: sha256:178270bfe84f74548b6a43347d73524e5c2636875b673675db1547ec427cf302
Status: Downloaded newer image for nixery.appspot.com/shell/curl:latest
bash-4.4# curl --version
curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.0.2q zlib/1.2.11 libssh2/1.8.0 nghttp2/1.35.1

Roadmap

Custom Nix repository support

One part of the Nixery vision is support for a custom Nix repository that provides, for example, the internal packages of an organisation.

It should be possible to configure Nixery to build images from such a repository and serve them in order to make container images themselves close to invisible to the user.

See issue #3.

Kubernetes integration (in the future)

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

See issue #4.