I'm oversaw completely, that I have to change the SSH-port for all nodes
in the cluster otherwise I cannot provide a meaningful load-balancer for
the git-ssh port in it.
Additionally this allowed me to fix some config errors which I simply
oversaw.
The previous setting of tags still let ansible gather facts for the
roles in question, even though they're not executed. This fix prevent
this from happening.
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.
It looks somehow random that the SSH-port was simply defined in the
configuration of the k3s-setup. It looks somehow "configurable" although
it isn't. Therefore I moved this setting to the correct place in the
terraform-setup.
An important side-note is that this change doesn't make it possible to
_change_ the ssh-port, though. Once decided for an port and I have to
stick to it until I tear down the cluster!
The navigation through a bunch of config files, all with just a few
lines in it is cumbersome. This change moves all the configuration into
a centralized `config.ini` that way it's easier for me to get a quick
overview of the setup. The `config.ini` acts as another inventory and is
therefore references as such by the ansible.cfg. The `inventory.ini`
(which is generated by terraform in the provisioning-step) is not
affected by this change.
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.
The only reason I even change the port is to make sure a git-client can
reach the my upcoming git-servers on the standard ssh-port. Though to
achive this I only have to make sure that the port is reacheable on the
internet, after that the port is routed through the kubernetes network.
This means that my agents can keep using the standard-port, which makes
everything easier for me :)
I want to use port 22 for my git-server, therefore I have to make this
port free for use of kubernetes. This change allows this, so when I want
to connect to the host-machines I'll use port 1022.
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.
This change makes all the settings configurable. The only part which
still lacks some flexibility is the location, though I really don't need
to run a k8s-cluster over multiple datacenters and regions! - At least
right now ;-)
