Use a pure Nix approach to building containers #31
Conversation
### Motivations
- To showcase that Nix is fully capable of self-hosting
We don't want to showcase Alpine + Nix, we want to showcase Nix.
- Optimal layering
Thanks to `dockerTools.buildLayeredImage`
- Baked in nixpkgs
No need to wait for nixpkgs to download & unpack on your first invocation of Nix.
- Smaller or similarly sized images despite better tooling
We're now using standard GNU utils instead of their Busybox
equivalents.
This image is roughly the same size despite the better tooling and a baked in nixpkgs.
- Auto-built on Dockerhub
Dockerhub can build images for us on a schedule, no one needs to manually update images.
- Cross compilation
Officially we support many architectures, but only push images for
x86_64-linux.
In the future we want to support all arches officially supported by nixpkgs.
In particular this adds ARM support to the support matrix.
- Declarative support matrix
There is now a file called `matrix.json` in the root of the project.
To add another architecture/channel simply edit this file, a
script will take care of the rest.
### Semantic changes
- Tags
The tags are now based on the Nixpkgs channels, rather than being
based on the version of Nix embedded in the image.
IME this matches much more closely to what people expect these images to behave like.
For example this is now a possibility:
`FROM nixos/nix:nixos-20.09`
### Considerations
I would also consider to relicense this repository under MIT to
match what nixpkgs is using.
Ideally we'd be able to port code back and forth from nixpkgs from
this repo.
|
Ping @peti |
|
See also https://github.com/niteoweb/nix-docker-base that builds docker images for commits so that pinning can be more precise. Also it would be good to have an image also without nixpkgs, when someone is pinning nixpkgs on their own (flakes). |
|
I'm planning to push this through if no response by wednesday (2020-02-10). cc @peti |
There was a problem hiding this comment.
I have discussed my thoughts about this PR in some detail in today's live stream at https://www.twitch.tv/videos/902198158?t=0h34m43s.
The gist of it all is that I agree that this solution is superior to the docker build that we have right now. At the same time, this code is much more involved than our current solution, which is pretty easy to maintain and to understand. Personally, I would not feel comfortable maintaining this new code because I don't know enough about the Docker infrastructure in Nix.
Therefore I'd suggest the following: If @adisbladis wants to be the maintainer of this project and deal with any bugs, fallout, or suggestions that come out of this change, then I am all for it and I'm happy to leave this project to him. If I'm supposed to maintain this project any longer, then I won't merge this PR and would rather stay with the simple straight-forward solution that we currently use.
|
@peti Hey! The code from this PR was merged into nix repo, and the docker image is now being built by hydra. This was step 1. Step 2 is to setup a GitHub Action to keep docker image up to date with the latest development in nix repo. For this I would need to permission to push to Step 3 would be to redirect/update all the links in relevant places:
|
|
@garbas sent you invite for docker hub |
|
This work was upstreamed to |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/addgroup-command-not-found-with-docker-image-nixos-nix-latest/16615/4 |
Motivations
To showcase that Nix is fully capable of self-hosting
We don't want to showcase Alpine + Nix, we want to showcase Nix.
Optimal layering
Thanks to
dockerTools.buildLayeredImageBaked in nixpkgs
No need to wait for nixpkgs to download & unpack on your first invocation of Nix.
Smaller or similarly sized images despite better tooling
We're now using standard GNU utils instead of their Busybox equivalents.
This image is roughly the same size despite the better tooling and a baked in nixpkgs.
Auto-built on Dockerhub
Dockerhub can build images for us on a schedule, no one needs to manually update images.
Cross compilation
Officially we support many architectures, but only push images for x86_64-linux.
In the future we want to support all arches officially supported by nixpkgs.
In particular this adds ARM support to the support matrix.
There is now a file called
matrix.jsonin the root of the project.To add another architecture/channel simply edit this file, a script will take care of the rest.
Semantic changes
The tags are now based on the Nixpkgs channels, rather than being based on the version of Nix embedded in the image.
IME this matches much more closely to what people expect these images to behave like.
For example this is now a possibility:
FROM nixos/nix:nixos-20.09Considerations
I would also consider to relicense this repository under MIT to match what nixpkgs is using.
Ideally we'd be able to port code back and forth from nixpkgs from this repo.
Merge synchronisation
We do need to change some settings on Dockerhub.
I am willing to put in this work if you can give me access @peti
Demo images
https://hub.docker.com/repository/docker/adisbladis/nix-docker
cc @peti