Live data from Hacker News

NixOps – Declarative cloud provisioning and deployment with NixOS

nixos.org

51–60 of 67 posts

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#51
post #48
post #46

Earlier quoted context omitted.

I found Guix a lot more organised. Most package code is very simple, and the toolchain is also quite elegant. Hopefully the latter will be addressed by the new nix interface.

Is GuixSD really usable in production? Its focus on using a Linux-libre kernel instead of mainline is worrisome regarding real-world hardware support.

Switching to mainline is almost trivial, just override plain linux-libre kernel and redefine the source.

GuixSD is getting production-ready IMHO. See for example Guix getting adopted by some HPCs:

https://guix-hpc.bordeaux.inria.fr/

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#52
post #45
post #40

Earlier quoted context omitted.

I love Nix concepts and all it's subprojects (NixOS, NixOps, Hydra, Disnix). However, i've found NixPkgs to be a bit messy. It's too big, targets too many platforms and it's too disorganised. But to be completely fair, I think it's getting a lot of good refactorings lately.

Yeah it's basically just growing pains. For large enterprise use, Nix is going to need to mature to a point where it's possible for enterprises to host a Nixpkgs cache locally, using a binary repository manager like Artifactory or Nexus, both for sheer cost (to save on bandwidth of thousands of servers downloading updates from the Internet) as well as risk reduction (in case the public binary caches are unavailable a…

Setting up your own binary cache is straightforward: https://nixos.org/nix/manual/#sec-sharing-packages

Is using Artifactory or Nexus a requirement? Why?

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#53
post #50

Can anyone comment on whether or not Nix is 100% reproducible? To the best of my limited understanding, it is not.

Nix doesn't guarantee bit-for-bit reproducibility: That is, two different builds of a Nix package may not produce bit-identical output. (They probably will, because of all the sandboxing, but nothing prevents an arbitrary package from generating random numbers at build time.)

Certainly Nix makes it a lot easier to get reproducibility in practice, though.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#54
post #45
post #40

Earlier quoted context omitted.

I love Nix concepts and all it's subprojects (NixOS, NixOps, Hydra, Disnix). However, i've found NixPkgs to be a bit messy. It's too big, targets too many platforms and it's too disorganised. But to be completely fair, I think it's getting a lot of good refactorings lately.

Yeah it's basically just growing pains. For large enterprise use, Nix is going to need to mature to a point where it's possible for enterprises to host a Nixpkgs cache locally, using a binary repository manager like Artifactory or Nexus, both for sheer cost (to save on bandwidth of thousands of servers downloading updates from the Internet) as well as risk reduction (in case the public binary caches are unavailable a…

You can install nix-serve on any machine to share its binary cache (including patched applications). Then add all of the enabled machines to every machine's nix.binaryCaches in order of preference. If they don't have what you need, it will fall back to the upstream server. You'll want to make sure they are upgraded in an appropriate order to minimize the need to leave your network for updates. It's true this isn't well documented, but I figured it out in about a day and was surprised at how simple it turned out to be.

You can even go further and set up your own build server to service all the architectures you need to support.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#55
post #50

Can anyone comment on whether or not Nix is 100% reproducible? To the best of my limited understanding, it is not.

It is not. In this talk [1] Eelco Dolstra touches upon that a bit also.

[1] https://www.youtube.com/watch?v=QvH5qU1qBXY&feature=youtu.be

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#56
NixOS makes a great OS for personal/workstation use, too.

With NixOS, my system is always 100% clean, and never broken.

I can install packages in my home directory without root.

Best of all, whenever I want to write any code, I can use nix-shell to make the toolchain and dependencies temporarily available to a self-contained shell. No more cluttering my system with libfoobar-dev for a quick build, and forgetting why.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#57
post #35

Earlier quoted context omitted.

The `none` provider works for any servers that has an ssh connection. I use it myself to maintain my server on vultr.com . It has been pretty neat!

FYI, there's a WIP PR for Vultr backend support in NixOps. https://github.com/NixOS/nixops/pull/634 I cherry-picked this into my local NixOps repo and have been using it for several weeks to deploy to Vultr servers with no issues, except one -- the author has hard-wired an assumption that you're using Btrfs for your root filesystem. I didn't want that so I simply replaced that hard-wired assumption with ext4 in my pe…

I'm the author of that PR. I apologize for the forced usage of btrfs. This was one of my first delves into the nix language, and I literally copied the digital ocean backend and changed the API calls (and the d.o had a hardcoded filesystem and I wanted btrfs and didn't know how at the time to move that into the configuration level). After the 17.09 release of NixOS is completed, I'll put some focus back in that PR and hopefully get it merged upstream.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#58
post #35

Earlier quoted context omitted.

FYI, there's a WIP PR for Vultr backend support in NixOps. https://github.com/NixOS/nixops/pull/634 I cherry-picked this into my local NixOps repo and have been using it for several weeks to deploy to Vultr servers with no issues, except one -- the author has hard-wired an assumption that you're using Btrfs for your root filesystem. I didn't want that so I simply replaced that hard-wired assumption with ext4 in my pe…

I'm the author of that PR. I apologize for the forced usage of btrfs. This was one of my first delves into the nix language, and I literally copied the digital ocean backend and changed the API calls (and the d.o had a hardcoded filesystem and I wanted btrfs and didn't know how at the time to move that into the configuration level). After the 17.09 release of NixOS is completed, I'll put some focus back in that PR an…

No need to apologize. It works great for my needs and it was easy enough just to hack your hack :)

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#59
post #45
post #40

Earlier quoted context omitted.

I love Nix concepts and all it's subprojects (NixOS, NixOps, Hydra, Disnix). However, i've found NixPkgs to be a bit messy. It's too big, targets too many platforms and it's too disorganised. But to be completely fair, I think it's getting a lot of good refactorings lately.

Yeah it's basically just growing pains. For large enterprise use, Nix is going to need to mature to a point where it's possible for enterprises to host a Nixpkgs cache locally, using a binary repository manager like Artifactory or Nexus, both for sheer cost (to save on bandwidth of thousands of servers downloading updates from the Internet) as well as risk reduction (in case the public binary caches are unavailable a…

That is already very easy:

https://github.com/nh2/nix-binary-cache-proxy

Allows you to set up (using NixOps!) a caching proxy for the nixos binary cache in your local network.

It can also serve your own custom packages if you sign it with your own package signing key and tell your machines to trust it.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#60
post #52
post #45

Earlier quoted context omitted.

Yeah it's basically just growing pains. For large enterprise use, Nix is going to need to mature to a point where it's possible for enterprises to host a Nixpkgs cache locally, using a binary repository manager like Artifactory or Nexus, both for sheer cost (to save on bandwidth of thousands of servers downloading updates from the Internet) as well as risk reduction (in case the public binary caches are unavailable a…

Setting up your own binary cache is straightforward: https://nixos.org/nix/manual/#sec-sharing-packages Is using Artifactory or Nexus a requirement? Why?

Mainly concerns like access control, and auditing for internal projects. If we're going to package for Nix, we need to host those packages internally somewhere, and access to that host needs to be audited/monitored. Access should be limited to developers and forbidden to non-engineering staff, etc.
Post reply on HN