In this blog post from our July DOXLON meetup we have Jonas Chevalier who quit his job in order to do Nix consulting and his presentation on that. In his talk Jonas goes over how you can use Nix as a replacement for Docker files.
Key: "/nix/store/${sha256(build inputs)}"
Value: sandbox-build(build inputs)
=> tree
The language is a bit different as it’s similar to JSON with functions and may take a bit to get use to but is fairly simple to learn. Because Nix is pure you have to specify everything and you don’t want to write packages for Ruby, Python, and Haskell so there’s a package repository that is maintained by the community which you can access here. There you can find over 12,000 packages and prebuilt binaries for all the packages in the repository.
In order to create a CI/CD pipeline you start with a Monorepo with a couple of services and then you build a Docker image that is pushed to registry and then deploy the changes. Jonas will then go into building the Docker images and in the end it will stay the same.
The main properties that you should want when you build the change are below:
- Only build what has changed
- Run tests when the code has changed
- Build containers from each services
- Only ship the runtime dependencies
- Managed security updates
As a developer you’re looking for:
- Application dependencies available
- Reduced dev/prod parity for debugging
- Access to pre-built binaries
Jonas then went into a demo where he started his todo list and then took the hot scale implementation of the back end where you can see the common library and a back end that’s actually the web server and where the front end is JaveScript with nothing special.
Following up with that he goes into his Nix folder where he built the front end. Just to decipher a bit the below image is showing the building points at the top and the whole and the whole file is a function showing all the parameters to the function. Under that is a yarn project where Jonas used a yarn like file to pull all of the dependencies and the build is just to yarn build. The output will then be the value. The backend is pretty much the same but with two components and then they are tied together. (For a more in depth view we’d recommend to watch the above video)
The process may seen difficult and complicated but once you have it set up it works fairly well. There are still some downsides to using this though:
- Not mainstream yet, less StackOverflow juice
- Developers are not required to install Nix
- Limited incremental builds compared to language-specific
- Missing tool to cull the container images
- Nix slower than Yarn to fetch
This content came from DevOps Exchange London (#DOXLON), a monthly DevOps Meetup in London.
If you’d like to speak at a future DOXLON or join the Meetup, please visit the DOXLON Meetup page.