Exactly, ansible is basically imperative, where write the steps declaratively.
Whereas nixos is more like a compiler that compiles to a working linux install.
If I added the software myprogram and a config file at /etc/myprogram.conf, that’s pretty easy in both. But if I needed to to then remove those it gets different .
With nixos it’s at easy as removing the two lines that add the program and the config file; after the next “compile”, the file is gone and myprogram is no longer available in the PATH.
With ansible you need to change the relevant step to use apt remove instead of apt install and to change the config file step in a step that removes the file.
Don’t get me wrong, ansible is still better than writing a lot of bash scripts, especially if you don’t have people with a lot of shell experience.
But tools like nixos and guix are on a whole other level.
With ansible you need to change the relevant step to use apt remove instead of apt install and to change the config file step in a step that removes the file.
Wait until you have 2 services that use the same resource. Now you need:
When both are enabled the resource is set up.
When either one is enabled the resource is still set up.
When neither is configured the resource is removed.
Doing this with Ansible is a nightmare. And 99% of the time you don’t even realize that you have this problem until your configs don’t work for some reason.
Yeah, ansible is just full of these scenarios. Even in the best of times it demands an awful amount of verbosity.
Half the time I see people land with no more idempotency than they had before, which is supposed to be one of the big draws. A lot of the things they are frontending are inherently idempotent, and a lot of other times the modules themselves fail to be safe to run multiple times for the admins input. I’ve been shocked how fragile some modules have been given its regard in the industry.
Exactly, ansible is basically imperative, where write the steps declaratively.
Whereas nixos is more like a compiler that compiles to a working linux install.
If I added the software
myprogramand a config file at/etc/myprogram.conf, that’s pretty easy in both. But if I needed to to then remove those it gets different .With nixos it’s at easy as removing the two lines that add the program and the config file; after the next “compile”, the file is gone and
myprogramis no longer available in the PATH.With ansible you need to change the relevant step to use
apt removeinstead ofapt installand to change the config file step in a step that removes the file.Don’t get me wrong, ansible is still better than writing a lot of bash scripts, especially if you don’t have people with a lot of shell experience.
But tools like nixos and guix are on a whole other level.
Wait until you have 2 services that use the same resource. Now you need:
Doing this with Ansible is a nightmare. And 99% of the time you don’t even realize that you have this problem until your configs don’t work for some reason.
Yeah, ansible is just full of these scenarios. Even in the best of times it demands an awful amount of verbosity.
Half the time I see people land with no more idempotency than they had before, which is supposed to be one of the big draws. A lot of the things they are frontending are inherently idempotent, and a lot of other times the modules themselves fail to be safe to run multiple times for the admins input. I’ve been shocked how fragile some modules have been given its regard in the industry.