<none>                                  <none>             1d42dba415e9   4 seconds ago   32.6MB
```
:::

:::{.example #ex-dockerTools-exportImage-naming}
# Exploring output naming with `dockerTools.exportImage`

`exportImage` does not require a `name` attribute if `fromImage` is a derivation, which means that the following works:

```nix
{ dockerTools, hello }:
dockerTools.exportImage {
  fromImage = dockerTools.buildLayeredImage {
    name = "hello";
    contents = [ hello ];
  };
}
```

However, since [`dockerTools.buildLayeredImage`](#ssec-pkgs-dockerTools-buildLayeredImage)'s output ends with `.tar.gz`, the output of `exportImage` will also end with `.tar.gz`, even though the archive created with `exportImage` is uncompressed:

```shell
$ nix-build
(output removed for clarity)
/nix/store/by3f40xvc4l6bkis74l0fj4zsy0djgkn-hello.tar.gz
$ file /nix/store/by3f40xvc4l6bkis74l0fj4zsy0djgkn-hello.tar.gz
/nix/store/by3f40xvc4l6bkis74l0fj4zsy0djgkn-hello.tar.gz: POSIX tar archive (GNU)
```

If the archive was actually compressed, the output of file would've mentioned that fact.
Because of this, it may be important to set a proper `name` attribute when using `exportImage` with other functions from `dockerTools`.
:::

:::{.example #ex-dockerTools-exportImage-fromImagePath}
# Using `dockerTools.exportImage` with a path as `fromImage`

It is possible to use a path as the value of the `fromImage` attribute when calling `dockerTools.exportImage`.
However, when doing so, a `name` attribute **MUST** be specified, or you'll encounter an error when evaluating the Nix code.

For this example, we'll assume a Docker tarball image named `image.tar.gz` exists in the same directory where our package is defined:

```nix
{ dockerTools }:
dockerTools.exportImage {
  name = "filesystem.tar";
  fromImage = ./image.tar.gz;
}
```

Building this will give us the expected output:

```shell
$ nix-build
(output removed for clarity)
/nix/store/w13l8h3nlkg0zv56k7rj0ai0l2zlf7ss-filesystem.tar
```

If you don't specify a `name` attribute, you'll encounter an evaluation error and the package won't build.
:::

## Environment Helpers {#ssec-pkgs-dockerTools-helpers}

When building Docker images with Nix, you might also want to add certain files that are expected to be available globally by the software you're packaging.
Simple examples are the `env` utility in `/usr/bin/env`, or trusted root TLS/SSL certificates.
Such files will most likely not be included if you're building a Docker image from scratch with Nix, and they might also not be included if you're starting from a Docker image that doesn't include them.
The helpers in this section are packages that provide some of these commonly-needed global files.

Most of these helpers are packages, which means you have to add them to the list of contents to be included in the image (this changes depending on the function you're using to build the image).
[](#ex-dockerTools-helpers-buildImage) and [](#ex-dockerTools-helpers-buildLayeredImage) show how to include these packages on `dockerTools` functions that build an image.
For more details on how that works, see the documentation for the function you're using.

### usrBinEnv {#sssec-pkgs-dockerTools-helpers-usrBinEnv}

This provides the `env` utility at `/usr/bin/env`.
This is currently implemented by linking to the `env` binary from the `coreutils` package, but is considered an implementation detail that could change in the future.

### binSh {#sssec-pkgs-dockerTools-helpers-binSh}

This provides a `/bin/sh` link to the `bash` binary from the `bashInteractive` package.
Because of this, it supports cases such as running a command interactively in a container (for example by running `docker container run -it <image_name>`).

### caCertificates {#sssec-pkgs-dockerTools-helpers-caCertificates}

This adds trusted root TLS/SSL certificates from the `cacert` package in multiple locations in an attempt to be compatible with binaries built for multiple Linux distributions.
The locations currently used are: