diff options
author | Graham Christensen <graham@grahamc.com> | 2018-12-04 12:18:06 -0500 |
---|---|---|
committer | Graham Christensen <graham@grahamc.com> | 2018-12-05 14:25:54 -0500 |
commit | c88337c9aca9d91804da7d1d05960c88e17455c9 (patch) | |
tree | 2e34f1058b8cab8bc27e69cee22c981e19b4ef99 /pkgs/build-support/docker/examples.nix | |
parent | 33b9aa4f35fdc0220987c7f87c1204b5b76f21ad (diff) | |
download | nixpkgs-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.nix | 19 |
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" + ]; + }; }; } |