nixpkgs/nixos/tests/docker-tools.nix

79 lines
4.1 KiB
Nix
Raw Normal View History

# this test creates a simple GNU image with docker tools and sees if it executes
import ./make-test.nix ({ pkgs, ... }: {
name = "docker-tools";
meta = with pkgs.stdenv.lib.maintainers; {
maintainers = [ lnl7 ];
};
nodes = {
docker =
{ ... }: {
2018-02-16 17:24:48 +00:00
virtualisation = {
diskSize = 2048;
2018-02-16 17:24:48 +00:00
docker.enable = true;
};
};
};
testScript =
2018-02-16 17:24:48 +00:00
''
$docker->waitForUnit("sockets.target");
# Ensure Docker images use a stable date by default
2018-02-16 17:24:48 +00:00
$docker->succeed("docker load --input='${pkgs.dockerTools.examples.bash}'");
$docker->succeed("[ '1970-01-01T00:00:01Z' = \"\$(docker inspect ${pkgs.dockerTools.examples.bash.imageName} | ${pkgs.jq}/bin/jq -r .[].Created)\" ]");
$docker->succeed("docker run --rm ${pkgs.dockerTools.examples.bash.imageName} bash --version");
$docker->succeed("docker rmi ${pkgs.dockerTools.examples.bash.imageName}");
# Check if the nix store is correctly initialized by listing dependencies of the installed Nix binary
2018-02-16 17:24:48 +00:00
$docker->succeed("docker load --input='${pkgs.dockerTools.examples.nix}'");
$docker->succeed("docker run --rm ${pkgs.dockerTools.examples.nix.imageName} nix-store -qR ${pkgs.nix}");
$docker->succeed("docker rmi ${pkgs.dockerTools.examples.nix.imageName}");
2018-02-16 17:24:48 +00:00
# To test the pullImage tool
$docker->succeed("docker load --input='${pkgs.dockerTools.examples.nixFromDockerHub}'");
$docker->succeed("docker run --rm nix:2.2.1 nix-store --version");
$docker->succeed("docker rmi nix:2.2.1");
2018-02-16 17:24:48 +00:00
# To test runAsRoot and entry point
$docker->succeed("docker load --input='${pkgs.dockerTools.examples.nginx}'");
$docker->succeed("docker run --name nginx -d -p 8000:80 ${pkgs.dockerTools.examples.nginx.imageName}");
$docker->waitUntilSucceeds('curl http://localhost:8000/');
$docker->succeed("docker rm --force nginx");
$docker->succeed("docker rmi '${pkgs.dockerTools.examples.nginx.imageName}'");
# An pulled image can be used as base image
$docker->succeed("docker load --input='${pkgs.dockerTools.examples.onTopOfPulledImage}'");
$docker->succeed("docker run --rm ontopofpulledimage hello");
$docker->succeed("docker rmi ontopofpulledimage");
# Regression test for issue #34779
$docker->succeed("docker load --input='${pkgs.dockerTools.examples.runAsRootExtraCommands}'");
$docker->succeed("docker run --rm runasrootextracommands cat extraCommands");
$docker->succeed("docker run --rm runasrootextracommands cat runAsRoot");
$docker->succeed("docker rmi '${pkgs.dockerTools.examples.runAsRootExtraCommands.imageName}'");
# Ensure Docker images can use an unstable date
$docker->succeed("docker load --input='${pkgs.dockerTools.examples.bash}'");
$docker->succeed("[ '1970-01-01T00:00:01Z' != \"\$(docker inspect ${pkgs.dockerTools.examples.unstableDate.imageName} | ${pkgs.jq}/bin/jq -r .[].Created)\" ]");
2018-09-27 19:16:23 +01:00
# 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}");
$docker->succeed("docker run --rm ${pkgs.dockerTools.examples.layered-image.imageName} cat extraCommands");
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.
2018-12-04 17:18:06 +00:00
# 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}");
# Ensure order of layers is correct
$docker->succeed("docker load --input='${pkgs.dockerTools.examples.layersOrder}'");
$docker->succeed("docker run --rm ${pkgs.dockerTools.examples.layersOrder.imageName} cat /tmp/layer1 | grep -q layer1");
# This is to be sure the order of layers of the parent image is preserved
$docker->succeed("docker run --rm ${pkgs.dockerTools.examples.layersOrder.imageName} cat /tmp/layer2 | grep -q layer2");
$docker->succeed("docker run --rm ${pkgs.dockerTools.examples.layersOrder.imageName} cat /tmp/layer3 | grep -q layer3");
2018-02-16 17:24:48 +00:00
'';
})