On Sun, Sep 17, 2017 at 2:34 PM, Hartmut Goebel <[email protected]> wrote: > Hi, > > in Ludo's presentation at GHM he presented "GuixOps" on a slide. What is > the status of this approach? I'm very interested in trying it out and > contributing.
I made a wip-deploy branch years ago that allowed you to describe a cluster of machines and then launch them all simultaneously with qemu. It was an interesting prototype but nothing has been done since. I have since become a full-time DevOps person and have some opinions about how 'guix deploy' ought to work. The most important thing is that there needs to be a generic interface for creating/updating/destroying machines that can be implemented for bare metal machines on some LAN, VMs at some VPS provider, VMs at AWS, VMs on OpenStack, etc. I think it's also important to support both in-place updates and "immutable deploys". A bare metal machine would need an in-place update, but an Amazon EC2 instance in an auto-scaling group could be replaced entirely. As a long term thing, I think that we need to leave a door open for supporting the all-inclusive infrastructure creation tools like OpenStack's HEAT templates and Amazon's CloudFormation. I use CloudFormation extensively at my day job and a tool that just managed EC2 instances for me wouldn't cut it. In summary I think that we need to think carefully about what a convenient interface is for someone managing a few personal servers and implement that without making it impossible to scale up to more "enterprise" use-cases later. > I contributed to DebOps when it was "young". So my point of view is > influenced by how DebOps works. DebOps is a collection of interoperating > role/recipes for Ansible. Debops has become quite complex and I would > like to migrate to GuixSD for new systems. Yeah, anything based on the status quo configuration management tools is bound to be overly complex. With Guix we can do soooo much better, we just need some free time, a plan, and a few good hackers. :) > Q1: I did not follow the development closely, but I seem to recall that > there is some guix sub-command for configuring a remote system. But > grepping the manual for "remote", I did not find it, neither one of the > commands did attract me. How is it called? I haven't tried it but I think Ludo said that it was going to be a flag to 'guix system'. Has that code been merged? Not being able to easily connect to a remote daemon is what blocked me when I first tried writing 'guix deploy'. > Q2: DebOps has some tooling to securely store credentials, certificates, > etc. It uses a gpg-encrypted container which is mounted using FUSE. When > I unlock this container, the appropriate data is transferred to the > target system. How can this be handled with GuixSD? AFAIU with GuixSD > all data in the system-configuration is world-readable in the store. So > how can I automatically transfer e.g. passwords and private keys the the > target system? I don't think that is the best approach, or at least it should not be an approach that GuixSD users *have to* use. I use Chef at work, and the equivalent technology there is called "encrypted data bags" (terrible name, I know). They are a pain and thus we do not manage secrets with it. You're right, everything in the store is world-readable, therefore you should never store secrets there. The most important thing to know is that secrets are stateful, which contrasts with many things in Guix that are stateless. Secrets can't be configured at build-time, it has to be done at runtime. So how do we get secrets onto machines? I think this is a job for GuixSD system services. Let's take for example a web application that connects to a MariaDB database. When the web application service starts, it will fetch the database password from the secret store and initialize the application with it by whatever means is supported (command line flag, environment variable, etc.). The secrets store could be a local GPG-encrypted file (getting the decryption key onto the machine is non-trivial, of course) or an external service. To give you an idea of the possibilities available when it comes to secrets management, I'll give a more complex example. All of my experience with this is with Amazon web services, so if you don't know AWS stuff you can skip this part but I'll describe it anyway for people that might be interested: EC2 instances are assigned an IAM role that allows them to decrypt a set of secrets that have been encrypted using a KMS key. The encrypted secrets happen to be stored in a DynamoDB table. A command line tool for fetching the secrets is installed on the instances and is integrated into the application startup processes that need secrets. When we want to rotate a key, we replace the DynamoDB record with a new one and restart the relevant services. Whether the secrets are stored in an encrypted file on each machine or in some external database, the basic process is the same: applications will receive their secrets when they are started, not when the system is configured. > Q3: One of DepOps' main features for me is easy use and the automatic > refresh of Let's Encrypt certificates. Basically I just say: "Create > certificates for hostnames A, B, C" and everything happens > automatically: Configuration of nginx, creating the CSR, requesting the > certificate, renewal, etc. What is the status for something like this > for GuixSD? We have an nginx service, so you can write a configuration that points to certs generated by Let's Encrypt. The cron service could be configured to periodically run the Let's Encrypt tool that refreshes the certificates periodically. The pieces are all there, you just need to put them together. This is what I plan to do when I finally get around to switching my VPS from Debian to GuixSD. Since this is all just Scheme code, we could write abstractions that make this common use-case "just work" for people so they don't have to worry about the details. One step at a time. :) Hope this helps, - Dave
