docker: more params: extraPkgs, (trusted)Substituters and extraEnv

[jlamur]

This allows for users to build nix docker images tuned for their substituters, ca and custom packages.

For example, I would use it this way:

{ nixpkgs }:

let
  nixRepo = ./nix;
  # nixRepo = builtins.fetchTarball { ... };
  proxyChannelURL = "https://github.proxy/channel-nixos-21.11.tar.gz";
  substituterURL = "https://nixos-cache.proxy";
  myCa = ./ca.crt;
in 
(import (nixRepo + "/docker.nix") {
  pkgs = nixpkgs;
  channelURL = proxyChannelURL;
  extraPkgs = [ nixpkgs.nixops ];
  extraEnv = [
    "SSL_CERT_FILE=${myCa}"
    "GIT_SSL_CAINFO=${myCa}"
    "NIX_SSL_CERT_FILE=${myCa}"
  ];
  substituters = [ substituterURL ];
  trustedSubstituters = [ substituterURL ];
})

[thufschmitt]

Isn’t already exposed one way or another by dockerTools? With some kind of override or overrideAttrs function

[jlamur]

I am quite new to nix & nixpkgs but I am pretty sure that it is impossible as most of these parameters are defined / used in intermediate variables (in let scope). As I said I am new so I may have missed a possibility.

Also, the certs override does not work in some CRI (an "old" one from a ubuntu repo on one of my servers fails to compute env variables correctly if they are duplicated). So I ended up re-creating an image from scratch for my own needs, it works pretty well for now. If that helps someone, it looks like this:

nixpkgs.dockerTools.buildLayeredImageWithNixDb {
  name = "nix";
  tag = "latest";

  contents = [
    pkgs.bashInteractive
    pkgs.coreutils-full
    pkgs.curl
    pkgs.git
    pkgs.nix
    pkgs.openssh
    pkgs.vim
    (pkgs.cacert.override {
      extraCertificateFiles = [ certificates.all ];
    })
    (pkgs.writeTextFile {
      name = "nix.conf";
      text = ''
        build-users-group =
        sandbox = false
        substituters = ${proxies.nixosCache}
        trusted-substituters = ${proxies.nixosCache}
        experimental-features = nix-command flakes
      '';
      destination = "/etc/nix/nix.conf";
    })
    (pkgs.writeTextFile {
      name = ".nix-channels";
      text = "${proxies.nixpkgs "nixos-${version}"} nixpkgs";
      destination = "/.nix-channels";
    })
  ];

  extraCommands = ''
    mkdir -p tmp var/tmp
    chmod 1777 tmp var/tmp
  '';

  config = {
    Cmd = [ "bash" ];
    Env = [
      "USER=root"
      "PATH=/.nix-profile/bin:/bin"
      "NIX_PATH=/.nix-defexpr/channels"
      "SSL_CERT_FILE=/etc/ssl/certs/ca-bundle.crt"
      "GIT_SSL_CAINFO=/etc/ssl/certs/ca-bundle.crt"
      "NIX_SSL_CERT_FILE=/etc/ssl/certs/ca-bundle.crt"
    ];
  };
}

I am pretty sure the lack of a shadow & a passwd file may cause problems in some use-cases / for some softwares, but for my own needs (mainly nix-build / nix build) it works and is way easier to maintain.

[thufschmitt]

it is impossible as most of these parameters are defined / used in intermediate variables (in let scope).

Oh, that’s annoying :/

I’ll defer this to @garbas since he’s the author of this file. I’m not too fond of adding these kind of ad-hoc parameters but maybe he has a better solution to this issue

[garbas]

@jlamur If you look at the initial PR when we added this file (docker.nix) it was said that this functionality should be actually moved to nixpkgs. Therefore we didn't really work on improving it.

I left one comment, but generally this PR looks like improvement and I would merge once the comment gets addressed.

But if you have time I would love if you can move it to nixpkgs.

Thank you @jlamur for working on this. 🚀

[garbas]

I think it would be better to extend nix.conf via some more general extraNixConf variable (as simple string) instead of having specialized arguments for each option in nix.conf.

[roberth]

it was said that this functionality should be actually moved to nixpkgs.

NixOS/nixpkgs#148456 demonstrates the refactoring of NixOS modules so that they can efficiently and accurately construct a "partial" configuration that is a container. (as well as be used in "complete" NixOS systems)
I believe this is the direction we should be taking, to avoid creating ever more interfaces that people have to learn (or more realistically, look up and translate).