about summary refs log tree commit diff
path: root/tools/nixery/static/index.html
blob: dc37eebc210622f0b61bdf546fd5b8336a48bdd8 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
<!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
      }

      .logo {
          max-width: 650px;
      }

      h1, h2, h3 {
        line-height: 1.2
      }
    </style>
  </head>
  <body>
    <header>
      <div align="center">
        <img class="logo" src="nixery-logo.png">
      </div>
      <aside>ad-hoc container images - powered by <a href="https://nixos.org/nix/">Nix</a></aside>
      <hr>
    </header>

    <p>
      This is an instance
      of <a href="https://github.com/google/nixery">Nixery</a>, which
      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 ignored. 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>
      The special meta-package <i>shell </i> provides default packages
      you would expect in an interactive environment (such as an
      interactively configured bash). If you use this package
      you <b>must</b> specify it as the first package in an image.
    </p>
    <h3>FAQ</h3>
    <ul>
      <li>
        <strong>Where is the source code for this?</strong>
        <br>
        Over <a href="https://github.com/google/nixery">on Github</a>.
      </li>
      <li>
        <strong>Which revision of <code>nixpkgs</code> is used?</strong>
        <br>
        Nixery imports a Nix channel
        via <code>builtins.fetchTarball</code>. Currently the channel
        to which this instance is pinned is NixOS 19.03.
      </li>
      <li>
        <strong>Is this an official Google project?</strong>
        <br>
        <strong>No.</strong> Nixery is not officially supported by
        Google.
      </li>
      <li>
        <strong>Can I depend on the demo instance in production?</strong>
        <br>
        <strong>No.</strong> The demo instance is just a demo. It
        might go down, move, or disappear entirely at any point.
        <br>
        To make use of Nixery in your project, please deploy a private
        instance. Stay tuned for instructions for how to do this on
        GKE.
      </li>
      <li>
        <strong>Who made this?</strong>
        <br>
        <a href="https://github.com/tazjin">tazjin</a>
      </li>
    </ul>
  </body>
</html>