|
| 1 | +# Deploying via SSH |
| 2 | + |
| 3 | +By running either from packages or through systemd services |
| 4 | +microvm.nix tries to support a wholesome Nix workflow: develop and |
| 5 | +test on your local laptop, then deploy to staging and later to |
| 6 | +production. |
| 7 | + |
| 8 | +Let's explore alternative ways before detailing our elaboration: |
| 9 | + |
| 10 | +- You could build |
| 11 | + `.#nixosConfiguration.my-microvm.config.microvm.declaredRunner` |
| 12 | + locally, then `nix copy` it to the target host for |
| 13 | + installation. This comes at the expense of your laptop's battery |
| 14 | + time and it can also become quite network-heavy. |
| 15 | +- You may transfer each change to the remote host to build entirely |
| 16 | + remote. There you're going to have a repository state that is going |
| 17 | + to confuse fellow operators. Also, your local `--override-input` |
| 18 | + parameters will become meaningless on the remote filesystem. |
| 19 | + |
| 20 | +## microvm.deploy.rebuild |
| 21 | + |
| 22 | +The *easy* interface that is named after `nixos-rebuild` combines the |
| 23 | +two scripts that are described below: |
| 24 | + |
| 25 | +- First, we evaluate locally and build remotely with |
| 26 | + `microvm.deploy.installOnHost` |
| 27 | +- Depending on whether the host's `/nix/store` is mounted and SSH is |
| 28 | + running in the MicroVM: |
| 29 | + - We either run `microvm.deploy.sshSwitch` as described below |
| 30 | + - Alternatively, we restart the MicroVM's systemd service on the |
| 31 | + host |
| 32 | + |
| 33 | +Because it needs to know about both the host and the MicroVM, these |
| 34 | +ssh addresses must come before the actual `switch` argument: |
| 35 | + |
| 36 | +``` |
| 37 | +nix run .#nixosConfigurations.my-microvm.config.microvm.deploy.rebuild [email protected] [email protected] switch |
| 38 | +``` |
| 39 | + |
| 40 | +## microvm.deploy.installOnHost |
| 41 | + |
| 42 | +This script will evaluate only the system's derivations locally. It |
| 43 | +then transfers these and their dependencies to the remote system so |
| 44 | +the actual build can be performed there. |
| 45 | + |
| 46 | +Just like [the microvm command](microvm-command.md), it then installs |
| 47 | +the MicroVM under `/var/lib/microvms/$NAME` so that the systemd |
| 48 | +services of the `host` module can pick it up. |
| 49 | + |
| 50 | +It is irrelevant whether you create a new MicrVOM or update an |
| 51 | +existing one. |
| 52 | + |
| 53 | +## microvm.deploy.sshSwitch |
| 54 | + |
| 55 | +Once the host has an updated MicroVM in its `/nix/store` (see above) |
| 56 | +the new system must be activated. For a proper state, this script does |
| 57 | +a bit more in the MicroVM than just `switch-to-configuration`: |
| 58 | + |
| 59 | +- First, the `config.networking.hostName` is compared to the running |
| 60 | + system for safety reasons. |
| 61 | +- The Nix database registration will be imported which is important if |
| 62 | + you build packages into a `microvm.writableStoreOverlay`. |
| 63 | +- The new system is installed into `/nix/var/nix/profiles/system` |
| 64 | + which is optional but expected by some Nix tooling. |
| 65 | +- Finally, run `switch-to-configuration` with the provided parameter |
| 66 | + (eg. `switch`). |
0 commit comments