This change is surprisingly tricky and needed some temporary
workarounds. First, there is no "official" snappass helm chart but I
found one, which does the job and looked good enough. The other problem
is the missing "official" image of snappass. The helm-chart used a
customized image which I didn't want to use, therefore I had to rebuild
a brand new image quickly. This new image is unfortunately not bound to
any repository or pipeline yet, which means that this change needs some
trust for the moment until I've set up the needed repo and CI
structures.
Reference: https://github.com/lmacka/helm-snappass/tree/main
Reference: https://github.com/pinterest/snappass
For stupidity reasons I had split up the "Supported Platforms" and the
"Required Software" without realising that these are actually entangled.
This change fixes that.
This change actually alters the readme significantly. The overall goal
was to adjust it to an easier to read document, since the previous
version had generally outgrown its initial layout. This alone should
raise a flag since it could indicate a too long document. But, I want to
make sure to understand each detail even after some time off.
This new approach is targeting this desire, and improves the overall
structure to read the document from top to bottom, as I like it.
This change is huge, therefore I only sum up the most important changes:
* Improve spelling
* Reduce ambiguity
* Use OpenTofu instead of Terraform
* Document missing tags for Ansible
* Provide example-configuration
* Fix confusion between dotenv and direnv, I use direnv!
* Add section about required software
* Many spelling mistakes
I plan to move over more base tasks to this repository, like maintaining
the keys for Backblaze. Therefore I adjusted the readme accordingly.
Furthermore I fixed the spelling on sever places.
The playbook itself is written to be idempotent, so it doesn't hurt to
run all tasks many times. But, it doesn't need to run all tasks all the
time, therefore you can limit the executional-scope with the documented
tags to only affect certain tasks. This improves the performance a lot!
Since I don't have multiple terraform steps anymore it simply doesn't
make sense to me anymore to split all tasks into separate folders.
Instead I try to be as clear as possible in the README to make it easy
to follow the structure in the future without too much headache.
It simply doesn't make sense to split the installation of the
kubernetes-cluster from the provisioning of foundational services.
Therefore I drop the idea to organise these services in another
terraform-setup and instead ensure their presence with ansible, as it's
already responsible for setting up the cluster and keep it up-to.date.
With this change we no longer use user-data scripts on the provided
machines. That makes it way easier for me to handle all the
configuration, since I only have to run ansible. Furthermore this the
burdon to think what may went wrong, since ansible is easier to debug
than some arbitrary scripts which run at provisioning-time on the
machines.
With this change I should also think about restructuring the code a bit
as well. Since it's actually easier to provide the initial
software-stack for the cluster via ansible than via terraform, at least
as far as I can tell right now.
This change contains a new module which will be applied after the
kubernetes-cluster has been created. It will install the cert-manager in
it and add let's encrypt as a ClusterIssuer to the cluster. That setup
allows me to simply issue certificates for all services in the cluster.
This changes makes it easier to differentiate and understand the
different parts of the kubernetes setup. On one hand we have the bare
infrastructure (servers, network, etc), on the other hand we have the
software (k3s in this case).
In the future we'll have a few more parts, like the minimal
configuration of the kubernetes cluster, e.g. with a cert-manager. This
is easier to manage with helm or terraform than with ansible. Therefore
it makes even more sense to split the responsibilities into dedicated
directories.
