feat(monitoring): add uptime-kuma for status page, see #97 #118
Loading…
Reference in a new issue
No description provided.
Delete branch "kiaragrouwstra/infra:feature-service-uptime-kuma"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Adds a config for a status page using uptime-kuma.
Open questions here included:
(and if a new one how to configure their network bits);
services.uptime-kuma), after which the stateless client can be re-built;
publicly access to test.
I think we should add this to public01.
That would be @raito afaik.
(btw we should document the secret management)
Isn't the passwordFile set using agenix in line 82 or does someone have to ssh onto the host and run some uptime-kuma management command? (I'm unfamiliar with uptime-kuma)
Anything with a public facing web interface, which should basically be everything.
You might not be able to access domains such as fodwatch or news at the time because we (try to) shut down the bare metal servers if the services aren't actively in use.
@ -0,0 +5,4 @@
...
}:
let
subdomains = [
It would be preferable to pull the domain information from the
terraform/dnsimple.nix
, so we avoid maintaining the list of domains twice.This should probably be injected via
specialArgs
I assume to make it available.hm. i agree, tho i'm not entirely sure yet what the best approach would here.
if the file were
import
ed (edit: / injected) i'm under the impression it would go thru amkIf
check.maybe the data-y bits could be e.g. factored out into a separate file to reuse from both
uptime-kuma
(if not also fromgandi
which has lotsa overlap withdnsimple
)?feedback welcome. 😶
Let's keep it simple for now, we can do it in a further PR. It's unclear how to extract the data-y bits, maybe Terranix could expose a data-only module we could re-import in the whole expr, unclear to me yet.
@ -0,0 +26,4 @@
# "news"
];
host = "status.forkos.org";
Please add the domain to terraform ^^
@ -0,0 +29,4 @@
host = "status.forkos.org";
port = 3001;
in
{
Please guard the config behind a mkIf with an enable option like
options.bagel.status.enable = mkEnableOption "status page";
. Currently, applying this change would enable this service on every host.@ -0,0 +31,4 @@
in
{
imports = [ "${inputs.stateless-uptime-kuma}/nixos/module.nix" ];
nixpkgs.overlays = [ (import "${inputs.stateless-uptime-kuma}/overlay.nix") ];
We maintain all the input related overlays directly in the flake.nix.
Yeah, all modules and overlays should be applied uniformly to all machines.
@ -0,0 +35,4 @@
services.uptime-kuma.enable = true;
services.nginx = {
The nginx stuff is fine for now, but we should generalize proxying a bit in the future. (having every service add their own firewall rules, and nginx config is redundant and error prone)
@kiaragrouwstra I'm available to help you get this PR to the finishline, if you need my help on anything.
status
to TF (dnsimple, gandi) feebc56f97i pushed updates to address some of the feedback now.
i thought so too.
unfortunately, as it turns out, the credential popped in there is essentially for a client thing to access the actual service so as to populate it declaratively from nix.
as such, it seems that the service itself at present still needs to manually be assigned those seemed credentials imperatively right now.
nitpicks: please adopt https://www.conventionalcommits.org/en/v1.0.0/ for your commit messages (if it's too pesky, please consider do it for the next PR).
I pushed 7de60d03a65df3a73cedf8c9fe8009413dd7ee53 on main to give you the secret, feel free to rebase to get it.
Deployed on https://status.forkos.org/dashboard, seems to work.
@raito Thanks, let me check out the commit convention.
Earlier I wrote the commits (esp. follow-up ones) under the presumption I'd rebase them out, tho now I see Forgejo won't take a push force - perhaps relevant for the rebase to main as well.
If I might ask, is there a way to still fix the commit messages on this PR for me then still?
(Further, now the deployment worked, had you managed to create the account with the desired credentials there as well? I might not know the credential to do that part myself, but at the deployed page I'm currently just seeing the option to log in rather than create account, so if you hadn't I might need to look into that still.)
Yep, I did it. It's first account becomes an admin, so I just provisioned it imperatively. I pinged the author of the stateless module and this should probably be fixed upstream with some INITIAL_ADMIN_USER, INITIAL_ADMIN_PASSWORD convergence option.
I'm surprised, this should work out of the box (?).
For the time being, if it's too much a hassle, we can rebase everything and I can rename the commit. Let me know what you prefer.
660122477f
to65a4e417eb
65a4e417eb
todf7ad30882
@raito apologies, I managed to squash it now. let me know if I should still amend something.
Thank you @kiaragrouwstra !