1
0
Fork 0
Commit Graph

11 Commits (380af211ec52783432ea7cb9194e7f82f96d8891)

Author SHA1 Message Date
Dustin 3439ce1f13 grafana: Deploy Grafana
Now that Victoria Metrics is hosted in Kubernetes, it only makes sense
to host Grafana there as well.  I chose to use a single-instance
deployment for simplicity; I don't really need high availability for
Grafana.  Its configuration does not change enough to worry about the
downtime associated with restarting it.  Migrating the existing data
from SQLite to PostgreSQL, while possible, is just not worth the hassle.
2024-01-27 22:01:08 -06:00
Dustin 4e15a9d71d invoice-ninja: Deploy Invoice Ninja
Invoice Ninja is a small business management tool.  Tabitha wants to
use it for HLC.

I am a bit concerned about the code quality of this application, and
definitely alarmed at the data it send upstream, so I have tried to be
extra careful with it.  All privileges are revoked, including access to
the Internet.
2024-01-27 21:11:26 -06:00
Dustin 9a76a548ec argocd/app: jenkins: Enable auto sync
We're going to try out automatically synchronizing the Jenkins resources
when changes are pushed to Git.
2024-01-22 18:50:41 -06:00
Dustin 8f088fb6ae v-m: Deploy (clustered) Victoria Metrics
Since *mtrcs0.pyrocufflink.blue* (the Metrics Pi) seems to be dying,
I decided to move monitoring and alerting into Kubernetes.

I was originally planning to have a single, dedicated virtual machine
for Victoria Metrics and Grafana, similar to how the Metrics Pi was set
up, but running Fedora CoreOS instead of a custom Buildroot-based OS.
While I was working on the Ignition configuration for the VM, it
occurred to me that monitoring would be interrupted frequently, since
FCOS updates weekly and all updates require a reboot.  I would rather
not have that many gaps in the data.  Ultimately I decided that
deploying a cluster with Kubernetes would probably be more robust and
reliable, as updates can be performed without any downtime at all.

I chose not to use the Victoria Metrics Operator, but rather handle
the resource definitions myself.  Victoria Metrics components are not
particularly difficult to deploy, so the overhead of running the
operator and using its custom resources would not be worth the minor
convenience it provides.
2024-01-01 17:48:10 -06:00
Dustin fe2a84a222 sshca: Deploy SSH CA service
[sshca] is a simple web service I wrote to automatically create signed
SSH certificates for hosts' public keys.  It authenticates hosts by
their machine UUID, which it can find using the libvirt API.

[sshca]: https://git.pyrocufflink.net/dustin/sshca
2023-11-10 14:22:31 -06:00
Dustin 5d0d002efd argocd/apps: kitchen: Initial commit 2023-10-14 22:13:09 -05:00
Dustin 3b05ab5b75 argocd/apps: Add PostgreSQL
The *postgresql* application monitors the PostgreSQL operator and its
assocaited resources.
2023-10-14 21:30:49 -05:00
Dustin ccec71213a photoframesvc: Initial commit
The photo frame service has actually been deployed for a while, I just
forgot to commit it.
2023-10-14 11:25:50 -05:00
Dustin 5611ba5f8c argocd/apps: Add authelia 2023-10-14 11:17:16 -05:00
Dustin 629d1bb93a argocd: Configure SSO for CLI
The `argocd` command needs to have its own OIDC client configuration,
since it works like a "public" client.  To log in, run

```sh
argocd login argocd.pyrocufflink.blue --sso
```
2023-10-14 11:13:06 -05:00
Dustin fdbf1d3432 argocd: Deploy Argo CD
[Argo CD] is a Kubernetes-native GitOps/continuous deployment manager.
It monitors the state of Kubnernetes resources, such as Pods,
Deployments, ConfigMaps, Secrets, and Custom Resources, and synchronizes
them with their canonical definitions from a Git repository.

*Argo CD* consists of various components, including a Repository
Service, an Application Controller, a Notification Controller, and an
API server/Web UI.  It also has some optional components, such as a
bundled Dex server for authentication/authorization, and an
ApplicationSet controller, which we will not be using.

[Argo CD]: https://argo-cd.readthedocs.io/
2023-10-14 10:17:04 -05:00