Hey folks,
I'm writing this in an attempt to "think out loud" about a deployment
automation tool for GuixSD.
Guix needs a NixOps[0] equivalent. NixOps is the Nix project's
deployment automation tool. I read the source code[1] a bit, and here's
what I've learned about it:
* The central data type is a "deployment", which is a Nix expression
consisting of one or more named OS configs
* The OS configs contain extra data that specifies the target platform:
VirtualBox, EC2, NixOS container, etc. Each platform implements the
generic MachineDefinition and MachineState interfaces.
* The 'nixops' command is stateful. It stores necessary state about
deployed systems in a special directory ($HOME/.nixops by default),
such as the IP addresses of the deployed systems. Because of this,
each deployment needs a unique identifier.
* Deployments may be parameterized by values known only at deploy time.
This covers cases such as a web application server needing to know the
IP address of the database server.
* There are useful subcommands to check the status of each system or ssh
into one of them.
Here's a rough outline of how I'm thinking of implementing similar
features in Guix:
* Introduce new data types:
* <platform>: The generic interface type for implementing deployment
targets. Its fields hold procedures for various actions like
'provision', 'destroy', 'boot', or 'reboot'. I haven't determined
the precise list of actions needed, but it will become apparent as
platforms are added.
* <machine>: Describes a single system in the deployment. Contains a
name string, an <operating-system>, and a <platform>.
* <deployment>: Contains a name string and a list of <machine> and
procedures. Procedures in the list should accept an argument
containing the deployment results of the non-parameterized machines
and return a <machine>.
* Use a simple s-exp deployment state format. Store the state in
$HOME/.config/guix by default.
* Implement a 'guix ops' subcommand roughly the same actions as NixOps:
create, deploy, start, stop, destroy, list, info, check, ssh, etc.
* The bulk of the work will be creating <platform> objects that actually
provision various types of resources. For prototyping, a
'local-vm-platform' would be enough to test that the whole system
works.
Anyone want to join in on this brainstorming party? Your thoughts are
appreciated!
[0] http://nixos.org/nixops/
[1] https://github.com/NixOS/nixops
--
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate
