5d9b32977d
Rather than migrating to Bazel, it seems more appropriate to use Nix for this project. The project is split into several different components (for data dependencies and binaries). A derivation for building an image for Nixery itself will be added.
90 lines
3.3 KiB
HTML
90 lines
3.3 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<title>Nixery</title>
|
|
<style>
|
|
body {
|
|
margin: 40px auto;
|
|
max-width: 650px;
|
|
line-height: 1.6;
|
|
font-size: 18px;
|
|
color: #444;
|
|
padding: 010px
|
|
}
|
|
|
|
h1, h2, h3 {
|
|
line-height: 1.2
|
|
}
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<header>
|
|
<h1>Nixery</h1>
|
|
<aside>ad-hoc container images - powered by <a href="https://nixos.org/nix/">Nix</a></aside>
|
|
</header>
|
|
<h3>What is this?</h3>
|
|
<p>
|
|
Nixery provides the ability to pull ad-hoc container images from a Docker-compatible registry
|
|
server. The image names specify the contents the image should contain, which are then
|
|
retrieved and built by the Nix package manager.
|
|
</p>
|
|
<p>
|
|
Nix is also responsible for the creation of the container images themselves. To do this it
|
|
uses an interesting layering strategy described in
|
|
<a href="https://grahamc.com/blog/nix-and-layered-docker-images">this blog post</a>.
|
|
</p>
|
|
<h3>How does it work?</h3>
|
|
<p>
|
|
Simply point your local Docker installation (or other compatible registry client) at Nixery
|
|
and ask for an image with the contents you desire. Image contents are path separated in the
|
|
name, so for example if you needed an image that contains a shell and <code>emacs</code> you
|
|
could pull it as such:
|
|
</p>
|
|
<p>
|
|
<code>nixery.appspot.com/shell/emacs25-nox</code>
|
|
</p>
|
|
<p>
|
|
Image tags are currently <i>ignored</i>. Every package name needs to correspond to a key in the
|
|
<a href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix">nixpkgs package set</a>.
|
|
</p>
|
|
<p>
|
|
There are some special <i>meta-packages</i> which you <strong>must</strong> specify as the
|
|
first package in an image. These are:
|
|
</p>
|
|
<ul>
|
|
<li><code>shell</code>: Provides default packages you would expect in an interactive environment</li>
|
|
<li><code>builder</code>: Provides the above as well as Nix's standard build environment</li>
|
|
</ul>
|
|
<p>
|
|
Hence if you needed an interactive image with, for example, <code>htop</code> installed you
|
|
could run <code>docker run -ti nixery.appspot.com/shell/htop bash</code>.
|
|
</p>
|
|
<h3>FAQ</h3>
|
|
<p>
|
|
Technically speaking none of these are frequently-asked questions (because no questions have
|
|
been asked so far), but I'm going to take a guess at a few anyways:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<strong>Where is the source code for this?</strong>
|
|
<br>
|
|
Not yet public, sorry. Check back later(tm).
|
|
</li>
|
|
<li>
|
|
<strong>Which revision of <code>nixpkgs</code> is used?</strong>
|
|
<br>
|
|
Currently whatever was <code>HEAD</code> at the time I deployed this. One idea I've had is
|
|
to let users specify tags on images that correspond to commits in nixpkgs, however there is
|
|
some potential for abuse there (e.g. by triggering lots of builds on commits that have
|
|
broken Hydra builds) and I don't want to deal with that yet.
|
|
</li>
|
|
<li>
|
|
<strong>Who made this?</strong>
|
|
<br>
|
|
<a href="https://twitter.com/tazjin">@tazjin</a>
|
|
</li>
|
|
</ul>
|
|
</body>
|
|
</html>
|