Nicolas “Niols” Jeannerod
ee5c2b90b7
Closes Fediversity/Fediversity#276 This PR adds a CLI deployment test. It builds on top of Fediversity/Fediversity#323. This test features a deployer node and four target nodes. The deployer node runs `nixops4 apply` on a deployment built with our actual code in `deployment/default.nix`, which pushes onto the four target machines combinations of Garage/Mastodon/Peertube/Pixelfed depending on a JSON payload. We check that the expected services are indeed deployed on the machines. Getting there involved reworking the existing basic test to extract common patterns, and adding support for ACME certificates negotiation inside the NixOS test. What works: - deployer successfully runs `nixops4 apply` with various payloads - target machines indeed get the right services pushed onto them and removed - services on target machines successfully negotiate ACME certificates What does not work: the services themselves depend a lot on DNS and that is not taken care of at all, so they are probably very broken. Still, this is a good milestone. Test it yourself by running `nix build .#checks.x86_64-linux.deployment-basic -vL` and `nix build .#checks.x86_64-linux.deployment-cli -vL`. On the very beefy machine that I am using, the basic test runs in ~4 minutes and the CLI test in ~17 minutes. We know from Fediversity/Fediversity#323 that the basic test runs in ~12 minutes on the CI runner, so maybe about an hour for the CLI test? Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io> Reviewed-on: Fediversity/Fediversity#329 Reviewed-by: kiara Grouwstra <kiara@procolix.eu> Reviewed-by: Valentin Gagarin <valentin.gagarin@tweag.io> Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com> Co-committed-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com> |
||
|---|---|---|
| .. | ||
| fediversity | ||
| tests | ||
| vm | ||
| default.nix | ||
| HACKING.md | ||
| README.md | ||
Services
This directory contains the definition of a NixOS module allowing to easily set up the Fediverse services that our project cares about. Those services are already packaged in nixpkgs, which arguably already provides this. Here is therefore the important distinction:
-
The goal of nixpkgs is to be generic, bring all the building blocks and let you do whatever it is you want with them. You get to choose all the options, if to use a reverse proxy, which one, if to use an S3 backend, which one, which database, etc.
-
This module aims at being straightforward to use by being opinionated. It only supports the use case of the Fediversity project and strives to hide as much of the nitty-gritty details as possible.
For those that know it, we could say that the current module is an analogous of simple-nixos-mailserver for Fediverse services.
Content of this directory
-
[fediversity][./fediversity] contains the definition of the services. Look in particular at its
default.nixthat contains the definition of the options. -
[vm][./vm] contains options specific to making the service run in local QEMU VMs. These modules will for instance override the defaults to disable SSL, and they will add virtualisation options to forward ports, for instance.
-
[tests][./tests] contain full NixOS tests of the services.