forked from Fediversity/Fediversity
98 lines
3 KiB
Markdown
98 lines
3 KiB
Markdown
# Infra
|
|
|
|
This directory contains the definition of [the VMs](machines.md) that host our
|
|
infrastructure.
|
|
|
|
## Provisioning VMs with an initial configuration
|
|
|
|
NOTE[Niols]: This is very manual and clunky. Two things will happen. In the near
|
|
future, I will improve the provisioning script to make this a bit less clunky.
|
|
In the far future, NixOps4 will be able to communicate with Proxmox directly and
|
|
everything will become much cleaner.
|
|
|
|
1. Choose names for your VMs. It is recommended to choose `fediXXX`, with `XXX`
|
|
above 100. For instance, `fedi117`.
|
|
|
|
2. Add a basic configuration for the machine. These typically go in
|
|
`infra/machines/<name>/default.nix`. You can look at other `fediXXX` VMs to
|
|
find inspiration. You probably do not need a `nixos.module` option at this
|
|
point.
|
|
|
|
2. Add a file for each of those VM's public keys, eg.
|
|
```
|
|
touch keys/systems/fedi117.pub
|
|
```
|
|
Those files need to exist during provisioning, but their content matters only
|
|
when updating the machines' configuration.
|
|
|
|
FIXME: Remove this step by making the provisioning script not fail with the
|
|
public key does not exist yet.
|
|
|
|
3. Run the provisioning script:
|
|
```
|
|
sh infra/proxmox-provision.sh fedi117
|
|
```
|
|
The script can take several ids at the same time. It requires some
|
|
authentication options and provides several more. See `--help`.
|
|
|
|
4. (Optional) Add a DNS entry for the machine; for instance `fedi117.abundos.eu
|
|
A 95.215.187.117`.
|
|
|
|
5. Grab the public host keys for the machines in question, and add it to the
|
|
repository. For instance:
|
|
```
|
|
ssh fedi117.abundos.eu 'sudo cat /etc/ssh/ssh_host_ed25519_key.pub' > keys/systems/fedi117.pub
|
|
```
|
|
|
|
FIXME: Make the provisioning script do that for us.
|
|
|
|
7. Regenerate the list of machines:
|
|
```
|
|
sh infra/machines.md.sh
|
|
```
|
|
Commit it with the machine's configuration, public key, etc.
|
|
|
|
8. At this point, the machine contains a very basic configuration that contains
|
|
just enough for it to boot and be reachable. Go on to the next section to
|
|
update the machine and put an actual configuration.
|
|
|
|
FIXME: Figure out why the full configuration isn't on the machine at this
|
|
point and fix it.
|
|
|
|
## Updating existing VM configurations
|
|
|
|
Their configuration can be updated via NixOps4. Run
|
|
|
|
```sh
|
|
nixops4 deployments list
|
|
```
|
|
|
|
to see the available deployments.
|
|
This should be done from the root of the repository,
|
|
otherwise NixOps4 will fail with something like:
|
|
|
|
```
|
|
nixops4 error: evaluation: error:
|
|
… while calling the 'getFlake' builtin
|
|
|
|
error: path '/nix/store/05nn7krhvi8wkcyl6bsysznlv60g5rrf-source/flake.nix' does not exist, evaluation: error:
|
|
… while calling the 'getFlake' builtin
|
|
|
|
error: path '/nix/store/05nn7krhvi8wkcyl6bsysznlv60g5rrf-source/flake.nix' does not exist
|
|
```
|
|
|
|
Then, given a deployment (eg. `fedi200`), run
|
|
|
|
```sh
|
|
nixops4 apply <deployment>
|
|
```
|
|
|
|
Alternatively, to run the `default` deployment, which contains all the VMs, run
|
|
|
|
```sh
|
|
nixops4 apply
|
|
```
|
|
|
|
## Removing an existing VM
|
|
|
|
See `infra/proxmox-remove.sh --help`.
|