Fediversity/infra/README.md

2.4 KiB

Infra

This directory contains the definition of the VMs that host our infrastructure.

Provisioning VMs with an initial configuration

NOTE[Niols]: This is very manual and clunky.

  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.

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

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

  5. (Optional) Add a DNS entry for the machine; for instance fedi117.abundos.eu A 95.215.187.117.

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

tofu apply

Removing an existing VM

See infra/proxmox-remove.sh --help.

TODO

  • does it know the key?
  • can it access the key?
  • place in credentials, maybe like nixops
  • secrets
  • test deployed application
  • ssh keys
  • other infra (incl import)
  • TF for users
  • deploy deployment (#76)
  • handle infra state (#169)
  • handle user state (#169)
  • provision VMs (#116)