| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
when tar'ing store paths into layered archives when building layered
images, don't use the absolute nix store path so that tar won't complain
if something new is added to the nix store
when building the final docker image, ignore any file changes tar
detects in the layers. they are all immutable and the only thing that
might change is the number of hard links due to store optimization
|
| |\
| |
| |
| |
| | |
grahamc/dockertools/remove-implementation-detail-layers
dockertools.buildLayeredImage: remove implementation detail layers
|
| | | |
|
| | |
| |
| |
| |
| | |
Without changing behavior, since this code is fiddly, make it possible
to add a filtering step before packaging individual paths.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
so it can exclude the top-most level
Before, every docker image had three extra layers:
1. A `closure` layer which is an internal implementation detail of
calculating the closure of the container
2. a `name-config.json` layer which is the images' run-time
configuration, and has no business being *in* the image as a layer.
3. a "bulk-layers" layer which is again and implementation detail
around collecting the image's closure.
None of these layers need to be in the final product.
|
| | | |
|
| |\ \
| | |
| | | |
dockerTools.buildLayeredImage: update maxlayers from 24 to 100 to match documentation
|
| | |/
| |
| |
| |
| |
| | |
documentation
mkManyPureLayers already was changed, and this function was not updated.
|
| |/ |
|
| |
|
|
|
|
| |
dockerTools.buildImageWithNixDb: export USER
Changes to Nix user detection (./src/nix-channel/nix-channel.cc#L-166)
cause this function to error. Exporting USER fixes this.
|
| |
|
|
|
| |
A USER is required by Nix.
See https://github.com/NixOS/nix/blob/9348f9291e5d9e4ba3c4347ea1b235640f54fd79/src/libutil/util.cc#L478.
|
| |
|
|
|
|
| |
The architecture of an image should default to the architecture for
which that image is being composed or pulled. buildPackages.go.GOARCH is
an easy way to compute that architecture with the correct terminology.
|
| | |
|
| |\
| |
| | |
dockerTools: use skopeo on the right platform
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
* treewide: remove unused variables
* making ofborg happy
|
| |\
| |
| | |
Use nativeBuildInputs for building Docker images
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Adapted from grahamc's blog post on layered Docker images in Nix:
https://grahamc.com/blog/nix-and-layered-docker-images
|
| | |
| |
| |
| |
| |
| |
| |
| | |
PR #58431 added /nix/store to each layer.tar. However, the timestamp was
not explicitly set while adding /nix and /nix/store to the archive. This
resulted in different SHA256 hashes of layer.tar between image builds.
This change sets time and owner when tar'ing /nix/store.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The layer order was not correct when a parent image was used: parent
image layers were above the new created layer.
This commits simplifies the code related to layer ordering. In
particular, layers in `layer-list` are ordered from bottom-most to
top-most. This is also the order of layers in the `rootfs.diff_ids`
attribute of the image configuration.
|
| | | |
|
| | |
| |
| |
| |
| | |
fix the executable bit for scripts installed with substituteAll
and some remaining shebangs.
|
| |\ \
| | |
| | |
| | |
| | | |
xtruder/pkgs/dockerTools/storePathToLayer/runtimeShell
dockerTools: storePathToLayer use runtimeShell in script
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
dockerTools: add nix-prefetch-docker script
|
| | |/ / |
|
| |\ \ \
| | | |
| | | | |
dockerTools: add finalImageName parameter for pullImage
|
| | | | | |
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | | |
To be totally consistent with the way Docker builds images we need to
include the /nix/store in the layer tarballs first.
|
| |/ /
| |
| |
| |
| |
| |
| | |
This patch preserves the ordering of layers of a parent image when the
image is unpacked.
Fixes #55290
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
bcf54ce5bbc8c325cfd2b6bcc5cec7661ef49183 introduced a treewide change to
use ${stdenv.shell} where-ever possible. However, this broke a script
used by dockerTools, store-path-to-layer.sh, as it did not preserve the
+x mode bit. This meant the file got put into the store as mode 0444,
resulting in a build-time error later on that looked like:
xargs: /nix/store/jixivxhh3c8sncp9xlkc4ls3y5f2mmxh-store-path-to-layer.sh: Permission denied
However, in a twist of fate, bcf54ce5bbc8c325cfd2b6bcc5cec7661ef49183
not only introduced this regression but, in this particular instance,
didn't even fix the original bug: the store-path-to-layer.sh script
*still* uses /bin/sh as its shebang line, rather than an absolute path
to stdenv. (Fixing this can be done in a separate commit.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| |\ \
| | |
| | |
| | | |
Hydra nixpkgs: ?compare=1505754
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
This patch preserves the ordering of layers of a parent image when the
new image is packed.
It is currently not the case: layers are stacked in the reverse order.
Fixes #55290
|
| |\| |
|
| | |\
| | |
| | |
| | |
| | | |
xtruder/build-support/docker/layered_image_tag_passthru
dockerTools: buildLayeredImage passthru imageTag
|
| | | | |
|
| |/ / |
|
| |\ \
| |/
|/|
| |
| | |
xtruder/pkgs/dockerTools/buildLayeredImage/extraCommands
dockerTools: allow to pass extraCommands, uid and gid to buildLayered image
|
| | | |
|
| |\ \
| | |
| | | |
dockerTools.example.runAsRootParentImage: init
|
| | |/
| |
| |
| |
| | |
Example of running something as root on top of a parent image.
This is a regression test related to the PR #52109.
|
| |/
|
|
| |
c88337c9aca9d91804da7d1d05960c88e17455c9
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|