Thanks. When I wrote 'GuixOps', I meant tools that could replace Ansible. I am aware of 'guix deploy'. Is Guix currently providing other tools that could help?
" - would it be possible to generate a guile script (for GuixOps) from Ansible? - would it be possible to change the Ansible to talk to the Guix (or GuixOps) system? " I meant the ability to generate a script for the Guix system configuration and / or guix deploy from existing Ansible configurations. Do you think that creating an intermediate program that converts Ansible configuration to Guix will be problematic? A few words of explanation. I would like to transfer my current infrastructure (configurations in Ansible) to Guix and I was wondering about the possibilities. Thanks for all the answers. Regards, Robert. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, December 19, 2019 10:13 PM, Thompson, David <dthomps...@worcester.edu> wrote: > 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
