Build container filesystem using "mkDerivative" but equivalent to docker tools buildImage

Help
1

I’m using buildImage (docker tools) but it compresses everything into tarballs and loads it into docker.

I’d rather just create a symlink filesystem and run systemd-nspawn on it directly. But systemd-nspawn requires various files, including “os-release”. Apparently buildImage will add files from some base image.

Is there a way to use buildImage but skip tar and just write to the result directory? I’d like the outputs to be identical, so I can either use the container definition locally, and efficiently, using nix/store directly, or create fully cloned OCI artifacts.

2

If I understand you correctly, you basically want a symlink farm that copies rather than links?

That idea could leak build dependencies into the final closure as runtime dependencies though due to the link intended to work within the containers root, is misinterpreted as a link intended to work in the hostsystem.

3

Hmm, I just realized that I could probably use keepContentsDirlinks to preserve symlinks, which would significantly reduce time spent, and SSD wear. And then extract it and run systemd-nspawn on that folder. I’ll have to test that.

But is there another way of building the filesystem of a container? I don’t understand how the “configuration.nix” syntax works, since systemd wouldn’t work in a container? So I’m trying to use mkDerivative or similar, also to keep it similar to the inputs that buildImage use.

4

The syntax just remains nix. Whether it is system config, home config or a derivation. Therefore I do not really understand your question, and how it would be related to systemd in a container.

5

I appreciate your help.

The goal is to have an identical declarative approach for creating containers to be used locally and remotely.

I’ve seen two approaches:

  1. the style that you normally see in configuration.nix

it’s unclear to me what the correct name for this syntax is, but IIUC it is used by “nixosSystem”?

{
          boot.isContainer = true;
          environment.systemPackages = with pkgs; [
            bash
            curl
          ];
        }

I’ve tried using it to build toplevel, but that requires running an activation script, and produces a very heavy filesystem. It can also produce a tarball, but that doesn’t solve my problem.

  1. dockertools buildImage

This produces a tarball, which is unnecessary when running locally.

It compresses/decompresses, and copies everything on the filesystem.

6

Any uncompressed or unencrypted form will cause the leakage described above.

Syntactically, this is an attribute set.

Semantically, this seems to be a nixos configuration, aka a nixOS module.

Can you explain what you consider “heavy”?

edit

It seems to me, that most of the time when you say “filesystem”, you actually mean “file tree”

7

Filesystem: I agree that “filesystem” is awkward terminology, but it seems to be used in container images, e.g. “rootfs” to denote the fake “filesystem” as seen by the container.

Heavy: Small container images are typically 100 MB, but when I used toplevel with “curl” only, it was 1000 MB, or something like that.

From this documentation streamLayeredImage is for skipping compression, but I’m still trying to figure out how to retain the symlinks, as it doesn’t accept keepContentsDirlinks.