DevOps Things To-Do

What is this page intended for?

On this page, ideas, issues, and anything else that catches the attention of the DevOps team are logged.

This page serves as a topic or task provider for the DevOps team.

Ansible and Terraform do the same thing. However, Terraform is optimized for infrastructure, and Ansible is optimized for configuration.

No.	Thing	Benefit	Goal
001	Terraform It should be considered whether we should establish a Terraform structure in a repository similar to what we did with Hetzner in the past.	1. The Kubernetes cluster is automatically monitored on the Goedelnode. This eliminates the need to manually execute installation scripts each time. 2. Changes can be easily deployed through a configuration file. 3. GitLab Terraform CI/CD implementation is planned.	Automated Monitoring of the Node Infrastructure
002	Terraform or Ansible Both tools are responsible for the automated maintenance of the state of the Goedelnode and the k3s cluster This enables direct configuration of the cluster.	Automation of the cluster configuration through GitLab Terraform CI/CD or GitLab Ansible CI/CD. This eliminates the need to access the cluster directly to make changes. For example, one could create new users and groups in Rancher, with roles, so that this no longer needs to be done manually.	Automated setup/configuration of the k3s cluster
003	Rancher Fleet System / GitOps We are currently using it in a makeshift manner. It should be properly implemented.	Current errors are being addressed, especially those that almost always require manual intervention.	Runs with fewer errors. Almost no manual intervention is required anymore.
004	Centralized Databases To prevent errors when deploying services, databases should be removed from the services and provided centrally. There are two options for this: 1. Connect to the already existing databases in the Goedel network (another server). 2. Host the databases internally on our node.	Fewer errors when updating or completely renewing individual services, and fewer databases to manage, as each service no longer brings its own database.	Centralized Databases
005	Helm Charts and Naming Convention Consider a convention for all Helm charts (Infrastructure, Core-Services, Player-Services, Skeletons) on how variables in the values.yaml and in the YAML files of the Helm charts should be named.	Improved readability and comparability of Helm charts. Less confusion when creating new Helm charts for new services (simple copy and paste).	A standard that everyone understands and follows.
006	Documentation Maintenance Add everything related to DevOps that is missing, especially the parts needed by the players for their pipelines of containers and Helm charts.	Players can more easily understand and utilize our infrastructure.	Adjust documentation.
007	Helm and Container Registry For Helm charts, there is already a repository where they are stored. The same should be created for container images, possibly both in a new repository. This repository will be public, allowing players to keep their code in a private repository.	1. Players can use our new registry repository to store container images and Helm charts there. 2. For test games, local players can be pulled, which do not come from a potentially private repository.	Easier access to the container images alongside the Helm charts.
008	Standardize Helm charts Currently, some services use a ConfigMap, others only the env section, and yet others retrieve values individually in the env section. Some charts fetch a list of values.	Determine how this should be handled and then adjust accordingly. This complements point 005 on the list quite well.	Standardized Helm charts for the simplified addition of new services.
009	Helm and Container Registry Script Modify/Add the script to ensure that container images are also stored in the new container registry. This should be tested for repositories outside MSD as well. Refer to point 007 on this list.	Refer to the benefit outlined in point 007. Additionally, guests of MSD can more easily access our clusters.	Refer to point 007 on this list. This also applies to guests of MSD.

Miscellaneous (for someday)

No.	Thing	Benefit	Goal	Accepted ✔ Denied ✘
001	Harvester With Harvester, you can create multiple virtual clusters on our node and manage them with Rancher.	One could set up a cluster for Dev/Test, one for production, and another for Gitlab Runner, instead of having everything on the management cluster.	Multiple clusters.

Last modified February 4, 2025: fix go & npm dependencies (8ff1fa0)