Live data from Hacker News

NixOps – Declarative cloud provisioning and deployment with NixOS

nixos.org

11–20 of 67 posts

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#11
post #7
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?

When I last tried it about 6 months ago it seemed to be a complete mess. I failed to get any recent ruby gems installed. There were dozens of different articles describing how to work with package repositories, and all of them seemed to be outdated by varying degrees. I also got the feeling that nix had more of a focus on desktop systems, for whatever reason.

I use it as a system level configuration tool, and then use Docker for the application level. This is not how the NixOS sees itself ideally, but in my experience their ideology does not map well to the reality of application deployment.

So what I do is have all system level tools installed using NixOS: the OS, logging, systemd, Docker, sshd and so on. Then I have my applications built as Docker containers and provision them as systemd units also configured by NixOS files.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#12

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…

NixOS is the system configuration layer and closer to puppet in solo mode. With a single (or multiple) nix file(s) it's possible to configure a machine and it's services entirely.

NixOps is the cloud configuration layer, it provisions cloud resources and uploads NixOS configuration to the machines. It's closer to terraform in that regard. It also has a state file (currently sqlite3) and uses a push model to propagate configuration changes.

What's missing right now is a third option where an agent is installed on the machines for a more dynamic configuration of the cluster as a whole. This role will probably be filled by Kubernetes or Nomad.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#13
post #4
post #2

Seems neat, better than Terraform, although limited to just nix and a few providers. Hopefully that will grow. I've been working on a provisioning tool myself. Provisioning is hard, and supporting multiple APIs can be really difficult.

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.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#14
post #5

Is there good explanation anywhere of the syntax of those files? I tried getting into nix multiple times and was always put off by the lack of understandability of this.

Nix is a bit like JSON + functions.

An object (called attrset in nix):

    { a = 3; b = 4; }
A list:

    [ 1 2 3 4 ];
A string:

     "hello"
A multi-line string:

    ''
      multine
      string
    ''
This defines a lambda with two arguments:

    a: b: a + b;
It's possible to pattern-match arguments. This accepts an attrset with keys a and b, and maps them to local variables:

    { a, b }: a + b;
There are some variations around that like `{ a ? 3 }:` `{ a }@attrs:` and `{ a, ... }`

One special type is the path, which has it's own literal that starts with `./`

To load a file, the `import` keyword is being used. In most cases the whole file is a big lambda function, which gets returned by the import.

Once you know that you can start reading nixpkgs and learn about the building blocks to constructs packages.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#15
post #2

Seems neat, better than Terraform, although limited to just nix and a few providers. Hopefully that will grow. I've been working on a provisioning tool myself. Provisioning is hard, and supporting multiple APIs can be really difficult.

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!

So put on a Nix overlay on your Linux/Unix flavor of choice like people have done with pkgsrc in and outside the NetBSD community?

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#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 to develop Haskell projects with Nix, including managing non-Haskell dependencies (zlib, SDL, ncurses, and so on):

https://github.com/Gabriel439/haskell-nix/

I only started using NixOS about a month ago, and it's fantastic. The best part is that binary caches are available for almost everything, so the hitherto-painful step where one compiles Haskell dependencies locally has been completely eliminated. The best way I can describe how I work now is "Python virtualenvs, but for everything at once and just so much better".

PS. Gabriel Gonzalez is, in general, someone who makes great documenation. Check out the tutorial for his stream-processing library Pipes: the ASCII art alone is awesome :)

https://hackage.haskell.org/package/pipes-4.3.4/docs/Pipes-T...

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#17

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…

> Other than integration with the rest of the Nix/NixOS ecosystem

Nix/NixOS is the big deal actually. NixOps is just icing on the cake. A NixOS installation is configured by building/copying over a system profile, and then activating it.

With just NixOS, you edit a configuration file on the server, then run a command that will build a system profile from that configuration and activate it.

With NixOps, you have configuration files on your workstation, and run commands to build the system profiles, copy it to the servers, and activate them. Of course you can do all of this without NixOps. It just makes certain things easier.

Puppet and others can do all of this, too. However state transition tend to be the weakest link (e.g. tell Puppet to provision a brand new server vs one that has run some other stuff, how sure are you that the resulting systems are the same?). Nix/NixOS takes care of that (most of the time anyway -- there are still things like data migrations that applications have to take care of).

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#20
post #15

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!

So put on a Nix overlay on your Linux/Unix flavor of choice like people have done with pkgsrc in and outside the NetBSD community?

No. Vultr supports custom ISO's. And I uploaded the nixos image to my account
Post reply on HN