After I removed the automatic IP addition to the firewalls for SSH and
Kubernetes I ran into a problem only a few days later. My ISP changed
my IPs and I was to stupid to realize that immediately. So, this change
reintroduces the automatic addition of my current IPs to the whitelists
for Kubernetes and SSH. Though, I adjusted the algorithm, so it will not
change every day or so, but instead really only when my ISP changes my
IPs.
I renamed the project from "hetzner-infra" to "base-infra", since that
better fits the purpose of this repository. So, this change migrates the
state name accordingly, to avoid confusion.
I liked the idea to have these IPs dynamically detected at runtime,
though some research showed that my current provider only renews these
every 180 days, nowadays. So, no need for such a hyper-dynamic solution.
Instead I use a variable now, which brings some other benefits, like
adding arbitrary IPs as well. This might become handy in cases of CI/CD.
The terraform-state can be stored in backblaze b2 with some
configurations. This changes does exactly this. Note, that this requires
the special env-variables `AWS_SECRET_ACCESS_KEY` and
`AWS_ACCESS_KEY_ID` which are normally part of the AWS-setup. To be able
to use AWS and this setup in parallel I use dotenv to maintain the
variables in the special file `.envrc`.
Reference: https://andrzejgor.ski/posts/backblaze_b2_tf_state
Reference: https://www.reddit.com/r/selfhosted/comments/1iv1qir
Reference: https://direnv.net/
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.
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.