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>
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.