Comment by falcolas | Hacker News Reader

Comment by falcolas | Hacker News Reader

Parent Full thread

Rolling back with Ansible (Puppet/Chef/Salt) is best done by provisioning a new server. Yum/Apt do not support "rolling back" packages in any reasonably sane manner.

I would love to get to the point where I could do immutable deploys in real life. We're getting closer by using Docker, but we're encountering a number of hard problems, one of which is simply finding ways to keep all of the images up-to-date with all of the recent packages.

That said, convincing a company to use Nix (which is still relatively immature, in the grand scheme of things) is going to be an uphill battle. When you can stand up a fresh VM using Ansible in a few minutes, the value of being able to roll a server back easily is hard to justify.

It's also hard to justify when you have to wait for a third party to decide to update their core packages. It took nix two days to build new packages for heartbleed, Ubuntu and CentOS were updated that day. How much longer could you be waiting on a fix which wasn't so broadly publicized?

With Nix it seems like the technology is there. It works. It has a superior model compared with other systems. However, it lacks a corporate sponsor or large community to make it "professional-grade". Canonical and RedHat make their money from people depending on their packages being continuously up to date. Debian has an enormous community ensuring that stable is stable and secure for the duration of its life. Nix doesn't have either, so it is up to the users it does have to be reactive.

That said, I think the benefits of Nix are real. The existing configuration management systems do not have the ability to fully understand the system. Nix does, because everything about the system is contained in the configuration file. As a consequence, you can up and down grade servers without fear of breaking everything. You can check to see exactly what changes between different versions. There is much more control and more assurance that the nodes are in the proper state.

One part of your comment which I do not understand is:

> When you can stand up a fresh VM using Ansible in a few minutes, the value of being able to roll a server back easily is hard to justify.

Isn't this also true for Nix? You just launch the image and push your desired configuration? If you mean time to write a new ansible playbook/role then in my experience, although I am fairly productive with ansible, I would not put it at "a few minutes" from nothing to a new service. Maybe you are talking about the learning curve? Nix definitely seems steeper so a clear win for ansible on that front.

> With Nix it seems like the technology is there. It works. It has a superior model compared with other systems. However, it lacks a corporate sponsor or large community to make it "professional-grade". Canonical and RedHat make their money from people depending on their packages being continuously up to date.

Check out bosh: http://bosh.cloudfoundry.org/ . It has a somewhat similar philosophy with respect to immutable instances and systems at large, and has strong corporate backing.

Both Canonical and RedHat seem to be doing their own things in this space, Snappy and Atomic.

I haven't looked at Atomic yet, but the design of Nix is so much better than Snappy.

Yes its a pity they had to reinvent this.

I've been using Nix at a startup for about a year now. For us, the value is easy and exact replication of an application's execution environment. Setting up a development environment for a new hire is just a matter of cloning the repository and running nix-build. (Though for some apps, there's also a third step: run a script to set up the database.) Once an app works in the dev environment, it just works in staging or production.

That's not to say that we never have configuration issues, but mostly they come from weirdness in 3-party packages. For example, recent versions of `node-pg` (postgresql bindings for node) have an implicit dependency: if you want to use the native library instead of the pure-Javascript implementation, you must also install `pg-native` alongside pg. That's just in the README, though, there's no peerDependency declared in pg's package.json file, so npm2nix can't generate the appropriate nix expressions.

Using nix definitely gives you the sense of swimming upstream, because the rest of the world doesn't understand this stuff and doesn't care. But for us, it's been worth it.

Glad to hear that you've managed to get Nix adopted at your workplace. Gives me hope for the future.

Nix (which is still relatively immature, in the grand scheme of things)

Nix predates all the other technologies you listed, with the possible exception of Chef, which I can't pinpoint a concrete date or even year of origin.

why are you simply not adjusting the versions of the package in chef and allowing yum to manage the dependencies ? A staging environment and proper continuous deployment processes tends to eliminate problems.

Reply on news.ycombinator.com