diff options
author | Frederik Rietdijk <fridh@fridh.nl> | 2020-07-02 17:14:53 +0200 |
---|---|---|
committer | Frederik Rietdijk <fridh@fridh.nl> | 2020-07-02 17:14:53 +0200 |
commit | c33ca7c5ce4d80246fd656dd8a5ab078cc90c03d (patch) | |
tree | d1a10ef8a3e8fe00ac12ac1437ec46a856521084 /doc | |
parent | 798c2d8bc1e947eb26e249b326bfaba49a91b735 (diff) | |
parent | 3ee58112693c11cd8157495e09714cf9ddb599b3 (diff) |
Merge staging-next into staging
Diffstat (limited to 'doc')
-rw-r--r-- | doc/builders/images/dockertools.xml | 23 | ||||
-rw-r--r-- | doc/using/configuration.xml | 6 |
2 files changed, 25 insertions, 4 deletions
diff --git a/doc/builders/images/dockertools.xml b/doc/builders/images/dockertools.xml index e7f37fdaaf00..126698d0a9ed 100644 --- a/doc/builders/images/dockertools.xml +++ b/doc/builders/images/dockertools.xml @@ -166,7 +166,7 @@ hello latest de2bf4786de6 About a minute ago 25.2MB <title>buildLayeredImage</title> <para> - Create a Docker image with many of the store paths being on their own layer to improve sharing between images. + Create a Docker image with many of the store paths being on their own layer to improve sharing between images. The image is realized into the Nix store as a gzipped tarball. Depending on the intended usage, many users might prefer to use <function>streamLayeredImage</function> instead, which this function uses internally. </para> <variablelist> @@ -327,6 +327,27 @@ pkgs.dockerTools.buildLayeredImage { </section> </section> + <section xml:id="ssec-pkgs-dockerTools-streamLayeredImage"> + <title>streamLayeredImage</title> + + <para> + Builds a script which, when run, will stream an uncompressed tarball of a Docker image to stdout. The arguments to this function are as for <function>buildLayeredImage</function>. This method of constructing an image does not realize the image into the Nix store, so it saves on IO and disk/cache space, particularly with large images. + </para> + + <para> + The image produced by running the output script can be piped directly into <command>docker load</command>, to load it into the local docker daemon: + <screen><![CDATA[ +$(nix-build) | docker load + ]]></screen> + </para> + <para> + Alternatively, the image be piped via <command>gzip</command> into <command>skopeo</command>, e.g. to copy it into a registry: + <screen><![CDATA[ +$(nix-build) | gzip --fast | skopeo copy docker-archive:/dev/stdin docker://some_docker_registry/myimage:tag + ]]></screen> + </para> + </section> + <section xml:id="ssec-pkgs-dockerTools-fetchFromRegistry"> <title>pullImage</title> diff --git a/doc/using/configuration.xml b/doc/using/configuration.xml index f19eddb58686..690bb3d34a12 100644 --- a/doc/using/configuration.xml +++ b/doc/using/configuration.xml @@ -85,19 +85,19 @@ <title>Installing packages on unsupported systems</title> <para> - There are also two ways to try compiling a package which has been marked as unsuported for the given system. + There are also two ways to try compiling a package which has been marked as unsupported for the given system. </para> <itemizedlist> <listitem> <para> - For allowing the build of a broken package once, you can use an environment variable for a single invocation of the nix tools: + For allowing the build of an unsupported package once, you can use an environment variable for a single invocation of the nix tools: <programlisting>$ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</programlisting> </para> </listitem> <listitem> <para> - For permanently allowing broken packages to be built, you may add <literal>allowUnsupportedSystem = true;</literal> to your user's configuration file, like this: + For permanently allowing unsupported packages to be built, you may add <literal>allowUnsupportedSystem = true;</literal> to your user's configuration file, like this: <programlisting> { allowUnsupportedSystem = true; |