summary refs log tree commit diff
path: root/nixos/tests/docker-tools.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 /nixos/tests/docker-tools.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 'nixos/tests/docker-tools.nix')
-rw-r--r--nixos/tests/docker-tools.nix4
1 files changed, 4 insertions, 0 deletions
diff --git a/nixos/tests/docker-tools.nix b/nixos/tests/docker-tools.nix
index 360b32faae7..ecd14b274eb 100644
--- a/nixos/tests/docker-tools.nix
+++ b/nixos/tests/docker-tools.nix
@@ -62,5 +62,9 @@ import ./make-test.nix ({ pkgs, ... }: {
       # Ensure Layered Docker images work
       $docker->succeed("docker load --input='${pkgs.dockerTools.examples.layered-image}'");
       $docker->succeed("docker run --rm ${pkgs.dockerTools.examples.layered-image.imageName}");
+
+      # Ensure building an image on top of a layered Docker images work
+      $docker->succeed("docker load --input='${pkgs.dockerTools.examples.layered-on-top}'");
+      $docker->succeed("docker run --rm ${pkgs.dockerTools.examples.layered-on-top.imageName}");
     '';
 })