3 ms·

One thing people forget is containers don’t necessarily not to be created with Docker. Lately I’ve been creating containers using NixOS and couldn’t be more ha

One thing people forget is containers don’t necessarily not to be created with Docker. Lately I’ve been creating containers using NixOS and couldn’t be more happy with the ability to have everything in the container configured by a configuration.nix file. https://nixos.org/nixos/manual/#ch-containers https://nixos.org/nixos/manual/#ch-containers The idea of a Docker Ubuntu, Arch, Alpine, etc base image is kind of silly when you think about it. The idea that we have separate repo for sharing massive container images sometimes multiple GB rather that a simple file that can be tracked in git and will produce the same image every-time has been very eye opening. Note: NixOS isn’t perfect but it has a growing community and hands down the best thing out there except for maybe guix which has container support too https://guix.gnu.org/blog/2018/tarballs-the-ultimate-container-image-format/ https://guix.gnu.org/blog/2018/tarballs-the-ultimate-contain...

silviogutierrez 6y ago
Huge nix fan. Question: how do you deploy these with k8s? Do you just build a NixOS docker image "wrapper" around all the other stuff?
- rudolph9 6y ago
  Haven’t actually deployed to k8s, currently using them to isolate local development but there I know (at least at one point) kubernetes supported other images than just docker images but even if they do t NixOS containers supports generating docker images... I imaging a ci/cd flow where it build the image and installs your app via a local Nix package built from source in your git repo and all that needs to be shared is the git repo and you have everything you need to reproduce the container er running in production.
root_axis 6y ago
How is a configuration.nix any different than a Dockerfile?
- rudolph9 6y ago
  Dockerfiles are imperative and the order of steps changes the container image that ultimately gets built. Nix packages are declarative and idempotent. Everything is based on a functional package manager and when you configure your container via nix you get the same thing every time and can easily mix and match other packages and dependencies. A contrived example is you have a program that depends on multiple versions of python, because nix does not globally set dependencies rather links them locally you can have both with versions of python without any conflicts Containers built from Dockerfiles are difficult to exactly reproduce too. A very common practice is to update the package manager in which depending on what the server returns will be different from one day to the next where as nix hash addresses and builds from source everything (you can use caches to speed this up) and you get the same thing every time. Note: NixOS isn’t perfect in terms of being purely functional as many package builds use scripts in pearl,bash,etc but from my understanding these are usually source specific reproducibility issues with Building particular packages and generally speaking things works as expected.
  - jmchuster 6y ago
    Then have your Dockerfile build from source. Many of the public layers that people build their containers upon do that for that exact reason. If NixOS is only "generally speaking" correct because of the order it runs its scripts, then put it in a Docker container, where the whole point is to perfectly reproduce the order you run your scripts in order to minimize the errors that arise from doing otherwise. Still worried? That's why layers exist, so that every step you run you now have a static binary that you know will never shift under you, and that you can keep on building on top of.
    - smilliken 6y ago
      In practice, building Dockerfiles is unreliable and can produce errors because they inherit all of the deficiencies of aptitude, python packaging, javascript packaging, et al. In practice, building nix dependencies is reliable and reproducible because of the militant isolation of build environments, hash integrity checks on _all_ inputs, explicit dependencies, and the long tail of bug fixes related to non-determinism in unix tooling. This is my personal experience, not abstract.

silviogutierrez 6y ago

Huge nix fan. Question: how do you deploy these with k8s? Do you just build a NixOS docker image "wrapper" around all the other stuff?

rudolph9 6y ago
Haven’t actually deployed to k8s, currently using them to isolate local development but there I know (at least at one point) kubernetes supported other images than just docker images but even if they do t NixOS containers supports generating docker images... I imaging a ci/cd flow where it build the image and installs your app via a local Nix package built from source in your git repo and all that needs to be shared is the git repo and you have everything you need to reproduce the container er running in production.

root_axis 6y ago

How is a configuration.nix any different than a Dockerfile?

rudolph9 6y ago
Dockerfiles are imperative and the order of steps changes the container image that ultimately gets built. Nix packages are declarative and idempotent. Everything is based on a functional package manager and when you configure your container via nix you get the same thing every time and can easily mix and match other packages and dependencies. A contrived example is you have a program that depends on multiple versions of python, because nix does not globally set dependencies rather links them locally you can have both with versions of python without any conflicts Containers built from Dockerfiles are difficult to exactly reproduce too. A very common practice is to update the package manager in which depending on what the server returns will be different from one day to the next where as nix hash addresses and builds from source everything (you can use caches to speed this up) and you get the same thing every time. Note: NixOS isn’t perfect in terms of being purely functional as many package builds use scripts in pearl,bash,etc but from my understanding these are usually source specific reproducibility issues with Building particular packages and generally speaking things works as expected.
- jmchuster 6y ago
  Then have your Dockerfile build from source. Many of the public layers that people build their containers upon do that for that exact reason. If NixOS is only "generally speaking" correct because of the order it runs its scripts, then put it in a Docker container, where the whole point is to perfectly reproduce the order you run your scripts in order to minimize the errors that arise from doing otherwise. Still worried? That's why layers exist, so that every step you run you now have a static binary that you know will never shift under you, and that you can keep on building on top of.
  - smilliken 6y ago
    In practice, building Dockerfiles is unreliable and can produce errors because they inherit all of the deficiencies of aptitude, python packaging, javascript packaging, et al. In practice, building nix dependencies is reliable and reproducible because of the militant isolation of build environments, hash integrity checks on _all_ inputs, explicit dependencies, and the long tail of bug fixes related to non-determinism in unix tooling. This is my personal experience, not abstract.