32b9b5099e
Adds a NIX_TIMEOUT environment variable which can be set to a number of seconds that is the maximum allowed time each Nix builder can run. By default this is set to 60 seconds, which should be plenty for most use-cases as Nixery is not expected to be performing builds of uncached binaries in most production cases. Currently the errors Nix throws on a build timeout are not separated from other types of errors, meaning that users will see a generic 500 server error in case of a timeout. This fixes #47 |
||
|---|---|---|
| .. | ||
| build-image | ||
| docs | ||
| popcount | ||
| server | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| default.nix | ||
| LICENSE | ||
| README.md | ||
| shell.nix | ||
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.
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 layersPORT: HTTP port on which Nixery should listenNIXERY_CHANNEL: The name of a Nix/NixOS channel to use for buildingNIXERY_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 buildingGCS_SIGNING_KEY: A Google service account key (in PEM format) that can be used to sign Cloud Storage URLsGCS_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.