The Firefly III Data Importer does not allow transaction imports by unattended HTTP requests by default, but this can be enabled with the `CAN_POST_FILES` environment variable. Additionally, an `AUTO_IMPORT_SECRET` environment variable must be set containing a shared "secret" value which must be provided in the querystring of autoimport requests. Since we have the Data Importer protected by Authelia, we need to make some additional changes to the Ingress to allow unattended authentication. Authelia supports passing the username and password of an authorized user in the `Proxy-Authorization` HTTP request header. If this header is valid, it will allow the request through. Unfortunately, many HTTP clients will not set this header unless they are also configured to explicitly connect via a forward proxy. To simplify usage of such clients, we can configure nginx to copy the value of the normal `Authorization` header into `Proxy-Authorization`, thus allowing clients to use simple HTTP Basic authentication, even though the Data Importer doesn't actually support it. |
||
---|---|---|
argocd | ||
authelia | ||
autoscaler | ||
cert-manager | ||
dch-root-ca | ||
dch-webhooks | ||
device-plugins | ||
docker-distribution | ||
dynk8s-provisioner | ||
firefly-iii | ||
home-assistant | ||
hudctrl | ||
ingress | ||
jenkins | ||
kitchen | ||
metrics | ||
ntfy | ||
paperless-ngx | ||
photoframesvc | ||
phpipam | ||
postgresql | ||
prometheus_speedtest | ||
scanservjs | ||
sealed-secrets | ||
setup | ||
sshca | ||
step-ca | ||
storage | ||
README.md |
README.md
Dustin's Kubernetes Cluster
This repository contains resources for deploying and managing my on-premises Kubernetes cluster
Cluster Setup
The cluster primarily consists of libvirt/QEMU+KVM virtual machines. The Control Plane nodes are VMs, as are the x86_64 worker nodes. Eventually, I would like to add Raspberry Pi or Pine64 machines as aarch64 nodes.
All machines run Fedora, using only Fedora builds of the Kubernetes components
(kubeadm
, kubectl
, and kubeadm
).
See Cluster Setup for details.
Jenkins Agents
One of the main use cases for the Kubernetes cluster is to provide dynamic agents for Jenkins. Using the Kubernetes Plugin, Jenkins will automatically launch worker nodes as Kubernetes pods.
See Jenkins Kubernetes Integration for details.
Persistent Storage
Persistent storage for pods is provided by Longhorn. Longhorn runs within the cluster and provisions storage on worker nodes to make available to pods over iSCSI.
See Persistent Storage Using Longorn for details.