
My experience of using NixOps as an Ansible user - Keats
https://blog.wearewizards.io/my-experience-of-using-nixops-as-an-ansible-user
======
falcolas
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?

~~~
timtadh
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.

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

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

~~~
justincormack
Yes its a pity they had to reinvent this.

------
davexunit
This was a good read. I'm currently designing the deployment tool for GNU Guix
(a package manager and distro based on Nix) so I find stories like this very
valuable. The author didn't seem crazy about the NixOps state file, which is
something I'm trying to think hard about for Guix. They claim that the state
file isn't easily shareable across machines. Couldn't they just version
control it and clone the repo on every workstation that does deploys or are
there complications?

~~~
cwp
It's an SQLite database, so you wouldn't be able to merge changes made in
different clones.

~~~
davexunit
Ah, I see. Thanks. My initial prototype will use a flat text file (a
serialized s-exp) instead.

~~~
teh
Another issue is full paths to the nix config file encoded in the state file
itself. The state file should not point to the config files used IMO.

~~~
davexunit
Totally agreed. The user should pass the config file to the program each time.

------
brohoolio
One of the things I don't understand about the newer automation tools like
ansible is lack of ability to go back in time.

I used Radmind and for all it's old school complexity and faults you could
roll back production changes really easily. That was hugely powerful.

~~~
mercurial
How do you "go back in time" after upgrading a package in a sensible manner?

~~~
cwp
This is what makes Nix special. The "functional package manager" paradigm
means you don't overwrite the old version when installing the new version.

~~~
mercurial
To clarify, the question is about Radmind, not Nix.

