Hello Robert, On Mon, Dec 16, 2019 at 6:57 AM rchar01 <rcha...@protonmail.com> wrote: > > Probably many admins / DevOps are heavily using Ansible. I also use this > solution to configure systems and services (on Debian and CentOS). > I would like to transfer infrastructure to the Guix System and some questions > arose: > > - is there any way to combine Ansible and GuixOps?
In short, no. I'm assuming that "GuixOps" means 'guix deploy', which is its own special tool that would take the place of Ansible if you choose to use it. > - is there any way to continue using Ansible to configure Guix (some in guile > script and some in ansible)? In the past I've used Chef (very similar to Ansible) to install Guix on Ubuntu machines. You could do the same with Ansible. If you wish to deploy systems running Guix System proper, I think that's possible, too, but you'd have to do some work on your own. You would have to build yourself a base image of a barebones Guix system and run your Ansible scripts from that base. I imagine that Ansible would be little more than a thin layer for running 'guix system reconfigure system.scm' on a remote machine at that point. > - would it be possible to generate a guile script (for GuixOps) from Ansible? Sorry, I don't quite understand this. Maybe? > - would it be possible to change the Ansible to talk to the Guix (or GuixOps) > system? Need more clarity here as well. Seems like a duplicate of your second question?? > Rewriting to Guile (Guix config files): > * Against: > ** time consuming > ** may require new skills > ** only for Guix, Ansible can configure other GNU / Linux systems If you're already using Ansible for everything, then yes it would be a hard sell to switch to something Guix specific, but Guix tools offer features that no mainstream tools could ever hope to offer. As I said earlier, though, you could make a Guix + Ansible mix work if you want. > * What might the benefits be? One of the big benefits is getting to use the Guix tooling and libraries for system deployment in addition to packaging and system configuration which many people already use. For people who are used to Guix, it's relatively easy to use 'guix deploy' whereas it would be very difficult to use something else. Another reason is that Ansible is, frankly, not a very good tool from our point of view. Ansible's model is "start from a base image and mutate it into the system you want." If you're into reproducibility, this isn't great. How was the base image created? Will running the same Ansible scripts a day from now produce the exact same image, bit for bit? Almost certainly not. Ansible is already mostly redundant with 'guix system' because that tool takes care of all the configuration management chores. What is *not* covered by 'guix system' is remote system management, thus 'guix deploy' was created. It takes things further by helping you deploy the same system configurations you use with 'guix system' to many remote systems. 'guix deploy' is still very new and doesn't have a lot of features, but it's built on the right foundation to avoid the big issues with mainstream devops tools. Hope this helps, - Dave
