Live data from Hacker News

NixOps – Declarative cloud provisioning and deployment with NixOS

nixos.org

41–50 of 67 posts

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#41

Other than integration with the rest of the Nix/NixOS ecosystem, how is NixOps different from Puppet? Reading briefly through the examples, it seems very oriented towards provisioning machine instances rather than provisioning behavior across networks or multi-machine services, which is something that Puppet really excels at. What features does this offer in addition to ones that Puppet provides? That said, I've been…

To say what my sibling comments say, more briefly:

With the nix system you can fully declaratively state your entire fleet of machines, from your highest level application configs all the way down to kernel patches.

When you run nixops, your machines become exactly as specified.

That this works reliably is a novelty: most other configuration management tools work like "action runners" that try in a best-effort fashion to achieve the desired state, but that doesn't always work (for example in Ansible, declaring a package as installed installs it, but NOT declaring a package will not uninstall it).

It is made possible because the nix system is designed from the bottom up to be declarative. That makes it different from Puppet.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#42
post #27

Earlier quoted context omitted.

We use NixOS in production in our product, for our cloud services, and for some development environments. We build everything with nix from sbt projects, go projects, haskell projects, purescript projects, docker images, and npm projects. It's an incredible tool. NixOps is also a good tool but there are a lot of issues with it we haven't had time to contribute fixes for. We also wanted it to be lighter weight and to…

Are you able to share your tool?

We will definitely be publishing it. Time is very short and the backlog of projects to publish is growing though so it might take time to polish and write a blogpost and tutorial.

I work for Awake Security so keep an eye out on the company's GitHub org as we've been publicly releasing a lot of projects even though they aren't completely polished or announced yet. I'll see if I can do this for our deploy tool soon.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#43
post #41

Other than integration with the rest of the Nix/NixOS ecosystem, how is NixOps different from Puppet? Reading briefly through the examples, it seems very oriented towards provisioning machine instances rather than provisioning behavior across networks or multi-machine services, which is something that Puppet really excels at. What features does this offer in addition to ones that Puppet provides? That said, I've been…

To say what my sibling comments say, more briefly: With the nix system you can fully declaratively state your entire fleet of machines, from your highest level application configs all the way down to kernel patches. When you run nixops, your machines become exactly as specified. That this works reliably is a novelty: most other configuration management tools work like "action runners" that try in a best-effort fashio…

> most other configuration management tools work like "action runners" that try in a best-effort fashion to achieve the desired state, but that doesn't always work (for example in Ansible, declaring a package as installed installs it, but NOT declaring a package will not uninstall it).

Most other configuration management tools have no choice. I got my own [1] to the point where it cannot only provision files/users/groups, but also clean them up correctly most of the time. However, since it is not the final authority (the package manager is... or rather, root is), there will always be situations where the entity that needs to be provisioned will be found to be in an entirely unanticipated state.

You have basically two ways to solve this conundrum:

1. just throw everything away and start from a clean slate when the configuration changes (aka containers)

2. do configuration management in the package manager and encourage/force root to keep his filthy hands off the system partition (aka NixOS et al)

[1] https://github.com/holocm/holo

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#44
post #42

Earlier quoted context omitted.

Are you able to share your tool?

We will definitely be publishing it. Time is very short and the backlog of projects to publish is growing though so it might take time to polish and write a blogpost and tutorial. I work for Awake Security so keep an eye out on the company's GitHub org as we've been publicly releasing a lot of projects even though they aren't completely polished or announced yet. I'll see if I can do this for our deploy tool soon.

Nice, I'd love to see it released.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#45
post #40
post #16

In view of some replies downthread: yes, application-level management is entirely possible with Nix(OS). Currently, this works best for Haskell, for which there is a sizeable amount (relatively speaking) of Nix tooling available. This is largely because a lot of Nix(OS) users also use Haskell, perhaps because lend themselves to very similar modes of "declarative" thinking. This is a thorough, excellent guide on how t…

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 at critical moments). If this is doable today, it's not really documented.

I'm sure the project will get there... eventually.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#46
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…

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.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#47
post #41

Earlier quoted context omitted.

To say what my sibling comments say, more briefly: With the nix system you can fully declaratively state your entire fleet of machines, from your highest level application configs all the way down to kernel patches. When you run nixops, your machines become exactly as specified. That this works reliably is a novelty: most other configuration management tools work like "action runners" that try in a best-effort fashio…

> most other configuration management tools work like "action runners" that try in a best-effort fashion to achieve the desired state, but that doesn't always work (for example in Ansible, declaring a package as installed installs it, but NOT declaring a package will not uninstall it). Most other configuration management tools have no choice. I got my own [1] to the point where it cannot only provision files/users/gr…

BOSH uses both tactics. It deals in whole VMs, but parks deployed software in a known location that's the same for all stemcells.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#48
post #46
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…

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.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#49
post #4

Earlier quoted context omitted.

I don't really see Nix as a limitation. It has a good claim to being a universal system configuration tool. Or how do you mean it's limited?

Can I use it to deploy either client or server applications on windows? All configuration and deployment tools I've looked at seem like they assume the only deployment target is linux servers running web applications. I don't care about the web. I need a deployment tool that works for local research on my clients' analysts' desktops, not just devops on remote somewhere.

BOSH works with Windows machines.

Most of the pain is building stemcells (the target disk image). Microsoft haven't quite made their peace with the idea.

Post reply on HN