Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NixOps – Declarative cloud provisioning and deployment with NixOS

nixos.org

Post reply on HN
Print view View original

61–67 of 67 posts

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#61

Post by elcritch »

tinco wrote: post #38
matt4077 wrote: post #37

Earlier quoted context omitted.

That sounds reasonable, but it kinda makes me question NixOS' value proposition. It seems that any one of the current distributions works well as a generic base for containers. There are probably lots of systems running standard Linux packages with more complex configurations (i.e. Mailservers, maybe databases, proxies etc) where I could imagine it being useful? Or maybe their desktop work makes more sense than I tho…

I don't think any operating system at this moment does well as a base for containers. At least not from the box, and as soon as you have to customise the OS you need tooling like Puppet/Chef/Salt to make your customizations reproducible. And that's the exact value proposition of NixOS, it's not only reproducible, the OS will be a complete reflection of your Nix specifications from the ground up. I feel NixOS definite…

I thought the same as well, but recently I've been having a decent go at it with RancherOS. Everything boots from two docker processes, either at the system or user level. Almost anything in the system can be pretty easily configured via cloud-init.yml file. If you want an Ubuntu console layer(or Alpine) just specify it in the yml.

It's great to see NixOS and similar tools gaining ground. But personally I find that docker's configurations simpler to grok than NixOS's syntax. Plus it's interesting the granular level of control over system security and system access gaiened via docker (really mostly Linux secomp controls and process namespaces). It's kind of like having capabilities built into the OS on top of specification driven system configuration.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#62

Post by mbrock »

elcritch wrote: post #61
tinco wrote: post #38

Earlier quoted context omitted.

I don't think any operating system at this moment does well as a base for containers. At least not from the box, and as soon as you have to customise the OS you need tooling like Puppet/Chef/Salt to make your customizations reproducible. And that's the exact value proposition of NixOS, it's not only reproducible, the OS will be a complete reflection of your Nix specifications from the ground up. I feel NixOS definite…

I thought the same as well, but recently I've been having a decent go at it with RancherOS. Everything boots from two docker processes, either at the system or user level. Almost anything in the system can be pretty easily configured via cloud-init.yml file. If you want an Ubuntu console layer(or Alpine) just specify it in the yml. It's great to see NixOS and similar tools gaining ground. But personally I find that d…

Just some notes you might be interested in:

NixOS is capable of creating a Docker image given a Nix specification, by turning the Nix store into an archive. These images are quite minimal since they contain exactly the dependencies needed for your app.

NixOS also has its own container system, so your server configuration can simply specify a subconfiguration that will be spawned as a container. The containers reuse the Nix store from the host system, which means you get a fine-grained caching system.

I haven't used those things much so I don't really know how production-ready they are.

I sometimes use Docker (with Dockerfiles or DockerHub images) on NixOS as a way to run systems that I don't want to package with Nix. I've made a little Nix module for declaring Docker services as systemd services.

That's part of why I don't feel like Nix is a limitation. I have actually used NixOps to deploy NixOS configurations that include Docker services, so my feeling of Nix is that it kind of supervenes on everything else...

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#63

Post by wmertens »

zimbatm wrote: post #12
zbentley wrote: post #10

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…

Note that with nixops, you can pass variables to the whole deployment configuration, and as such, your deployment is "dynamic" if you reconfigure it often enough :)

Here's a deployment of mesos where you can specify how many slaves and masters you want: https://github.com/wmertens/nixops-mesos

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#64

Post by wmertens »

jacques_chester wrote: post #31
pierrebeaucamp wrote: post #8

I would love if someone could compare NixOps with BOSH.

I haven't done much Nix, but I do peek over the fence now and then because I (and others) wonder about applying it to buildpacks and/or OCI layer construction. I do a lot more BOSH, since I work at Pivotal. So these remarks are probably wrong. However, from my ignorant viewpoint: The deep agreement is that machine-level statefulness is evil. Trying to repair it in-situ is pointless when you can simply reset to known-…

* NixOps lets you define the complete layout of your deployment (in Nix, obviously): how many VMs, what they should be running, where they should be running.

* NixOps works on whole machine + transformation of machine level: NixOps builds all system configurations of the whole network, then makes sure the required target hosts are available, then copies the builds to the hosts, and then atomically switches all hosts to the new configuration at once. NixOS is stateless, and a new config only means that the new service configurations are applied.

Rollback is a matter of switching all VMs back to their previous configurations, takes less than a minute in all.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#65

Post by Nullabillity »

jacques_chester wrote: post #31
pierrebeaucamp wrote: post #8

I would love if someone could compare NixOps with BOSH.

I haven't done much Nix, but I do peek over the fence now and then because I (and others) wonder about applying it to buildpacks and/or OCI layer construction. I do a lot more BOSH, since I work at Pivotal. So these remarks are probably wrong. However, from my ignorant viewpoint: The deep agreement is that machine-level statefulness is evil. Trying to repair it in-situ is pointless when you can simply reset to known-…

NixOS/NixOps will manage the whole machine, but it will replace individual services instead of rebuilding the whole VM.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#66

Post by catern »

solatic wrote: post #60
catern wrote: post #52

Earlier quoted context omitted.

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.

Nix package definitions sit in a Git (or other VCS) repo, which you can access-control through your usual means.

The binary artifacts are behind an HTTP server, which you can access control through whatever normal access control mechanisms, or leave uncontrolled and rely on the fact that it's not possible to retrieve artifacts from the server without having access to all the build inputs so you can hash them.

Re: NixOps – Declarative cloud provisioning and deployment with NixOS

#67

Post by jacques_chester »

wmertens wrote: post #64
jacques_chester wrote: post #31

Earlier quoted context omitted.

I haven't done much Nix, but I do peek over the fence now and then because I (and others) wonder about applying it to buildpacks and/or OCI layer construction. I do a lot more BOSH, since I work at Pivotal. So these remarks are probably wrong. However, from my ignorant viewpoint: The deep agreement is that machine-level statefulness is evil. Trying to repair it in-situ is pointless when you can simply reset to known-…

* NixOps lets you define the complete layout of your deployment (in Nix, obviously): how many VMs, what they should be running, where they should be running. * NixOps works on whole machine + transformation of machine level: NixOps builds all system configurations of the whole network, then makes sure the required target hosts are available, then copies the builds to the hosts, and then atomically switches all hosts…

Thankyou for the additional detail. I'd say that the two arrived at similar outcomes, which isn't surprising given NixOps's roots.
Post reply on HN