tvl-depot/ops/terraform/deploy-nixos/README.md
Florian Klink 774194652b feat(ops/terraform): add trigger to deploy-nixos, remove target_name
This allows passing in custom triggers to trigger a (re)deploy.

For example, a caller can put an AWS instance ID into the triggers to
cause a redeploy whenever the instance ID has changed.

The `target_name` terraform variable was doing something similar, but
`triggers` is more generic, allowing multiple triggers, without having
to stringify them.

We also don't need to trigger on the attrpath - it can be changed, and
as long as it still evaluates to the same
`data.external.nixos_system.result.drv` (which is checked on every
plan), no redeploy needs to be made.

Change-Id: I94ce787a50830b87b6f53c08e042e4abe4036bdd
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8191
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: flokli <flokli@flokli.de>
2023-03-03 14:53:43 +00:00

1.4 KiB

deploy-nixos

This is a Terraform module to deploy a NixOS system closure to a remote machine.

The system closure must be accessible by Nix-importing the repository root and building a specific attribute (e.g. nix-build -A ops.machines.machine-name).

The target machine must be accessible normally over SSH, and an SSH key must be used for access.

Notably this module separates the evaluation of the system closure from building and deploying it, and uses the closure's derivation hash to determine whether a deploy is necessary.

Usage example:

module "deploy_somehost" {
  source              = "git::https://code.tvl.fyi/depot.git:/ops/terraform/deploy-nixos.git"
  attrpath            = "ops.nixos.somehost"
  target_host         = "somehost.tvl.su"
  target_user         = "someone"
  target_user_ssh_key = tls_private_key.somehost.private_key_pem
}

Future work

Several things can be improved about this module, for example:

  • The repository root (relative to which the attribute path is evaluated) could be made configurable.

  • The remote system closure could be discovered to restore remote system state after manual deploys on the target (i.e. "stomping" of changes).

More ideas and contributions are, of course, welcome.

Acknowledgements

Development of this module was sponsored by Resoptima.