summary refs log tree commit diff
path: root/pkgs/build-support/docker/examples.nix
diff options
context:
space:
mode:
authorGraham Christensen <graham@grahamc.com>2018-12-04 12:18:06 -0500
committerGraham Christensen <graham@grahamc.com>2018-12-05 14:25:54 -0500
commitc88337c9aca9d91804da7d1d05960c88e17455c9 (patch)
tree2e34f1058b8cab8bc27e69cee22c981e19b4ef99 /pkgs/build-support/docker/examples.nix
parent33b9aa4f35fdc0220987c7f87c1204b5b76f21ad (diff)
downloadnixpkgs-c88337c9aca9d91804da7d1d05960c88e17455c9.tar
nixpkgs-c88337c9aca9d91804da7d1d05960c88e17455c9.tar.gz
nixpkgs-c88337c9aca9d91804da7d1d05960c88e17455c9.tar.bz2
nixpkgs-c88337c9aca9d91804da7d1d05960c88e17455c9.tar.lz
nixpkgs-c88337c9aca9d91804da7d1d05960c88e17455c9.tar.xz
nixpkgs-c88337c9aca9d91804da7d1d05960c88e17455c9.tar.zst
nixpkgs-c88337c9aca9d91804da7d1d05960c88e17455c9.zip
dockerTools.buildImage: support using a layered image in fromImage
Docker images used to be, essentially, a linked list of layers. Each
layer would have a tarball and a json document pointing to its parent,
and the image pointed to the top layer:

    imageA  ----> layerA
                    |
                    v
                  layerB
                    |
                    v
                  layerC

The current image spec changed this format to where the Image defined
the order and set of layers:

    imageA  ---> layerA
            |--> layerB
            `--> layerC

For backwards compatibility, docker produces images which follow both
specs: layers point to parents, and images also point to the entire
list:

    imageA  ---> layerA
            |      |
            |      v
            |--> layerB
            |      |
            |      v
            `--> layerC

This is nice for tooling which supported the older version and never
updated to support the newer format.

Our `buildImage` code only supported the old version, so in order for
`buildImage` to properly generate an image based on another image
with `fromImage`, the parent image's layers must fully support the old
mechanism.

This is not a problem in general, but is a problem with
`buildLayeredImage`.

`buildLayeredImage` creates images with newer image spec, because
individual store paths don't have a guaranteed parent layer. Including
a specific parent ID in the layer's json makes the output less likely
to cache hit when published or pulled.

This means until now, `buildLayeredImage` could not be the input to
`buildImage`.

The changes in this PR change `buildImage` to only use the layer's
manifest when locating parent IDs. This does break buildImage on
extremely old Docker images, though I do wonder how many of these
exist.

This work has been sponsored by Target.
Diffstat (limited to 'pkgs/build-support/docker/examples.nix')
-rw-r--r--pkgs/build-support/docker/examples.nix19
1 files changed, 19 insertions, 0 deletions
diff --git a/pkgs/build-support/docker/examples.nix b/pkgs/build-support/docker/examples.nix
index 003e7429a81..090bfafa085 100644
--- a/pkgs/build-support/docker/examples.nix
+++ b/pkgs/build-support/docker/examples.nix
@@ -156,5 +156,24 @@ rec {
     name = "layered-image";
     tag = "latest";
     config.Cmd = [ "${pkgs.hello}/bin/hello" ];
+    contents = [ pkgs.hello pkgs.bash pkgs.coreutils ];
+  };
+
+  # 11. Create an image on top of a layered image
+  layered-on-top = pkgs.dockerTools.buildImage {
+    name = "layered-on-top";
+    tag = "latest";
+    fromImage = layered-image;
+    extraCommands = ''
+      mkdir ./example-output
+      chmod 777 ./example-output
+    '';
+    config = {
+      Env = [ "PATH=${pkgs.coreutils}/bin/" ];
+      WorkingDir = "/example-output";
+      Cmd = [
+        "${pkgs.bash}/bin/bash" "-c" "echo hello > foo; cat foo"
+      ];
+    };
   };
 }