In order to create a filesystem that contains both debug tools and what is running in the container, Docker Debug uses the Nix tool to create a second filesystem with the tools … Then Docker Debug calls mergerfs to merge both filesystems (the original container plus the debug tools). “The result is a filesystem identical to the original container plus all the debugging tools,” we were told.
I’m trying to find a bit more info on this but I’m coming up short. Wondering if anyone else has seen this in the last day or two or if anyone has anything more on Docker Debug and its use of nix?
Yes, the new experimental extension is nix-env under the hood. You can try it out with Docker Desktop fairly easily and use it to exec into a container that may not have a robust userland. They specifically selected Nix due to its non-interference with any exiating container content.
Docker is very interested in the Nix ecosystem. I gave a talk today with with Jim Clark (Docker Labs) about how Docker and Nix can be used together as well as trying to motivate better integration with buildkit + Nix. Another topic that came up is the possibility to collaborate more closely with upstream runtimes to better understand the non-conflicting nature of Store paths/layers. I’ll try to set up a working group for this in the coming weeks to establish next steps.