Configuration Management
Die folgende Seite ist eine Dokumentation der Diskussion auf dem Geekend 2022. Für Dokumentation zu unserem bundlewrap-repo gucke dir bitte die README im cm-Repo an.
Aktuelle Situation
- ansible repo von 2013 oder 2014?
- fühlt sich ungepflegt an
- langsam
- questionable procedures
- bei jedem ansible lauf ein mal alles von voctomix löschen und neu deployen machts langsam und unhandlich
- anpassungen im laufenden betrieb unmöglich
- änderungen beim apply unsichtbar in ganz viel rauschen
- voc2mix wurde drangeflanscht
- kann bisher im saal nur debian 10
- viel ist am ansible vorbei konfiguriert
- firewalls
- web.c3voc.de incident auf der
- rz dinge sind an allen cm vorbei konfiguriert (teilweise in ansbile, teilweise nicht)
- das Problem war nicht ansible, sondern verschiedene leute machten verschiedene quickfixes ohne dinge nachzuziehen
Links
-
- beispiel bundle für eine node anwendung: https://git.franzi.business/kunsi/bundlewrap/src/branch/main/bundles/hedgedoc
Vorschlag
- von sophie, hexchen und kunsi
- alles abbrennen und mit einem frischen, überblickbaren repo ersetzen.
- saal und rz trennen?
- bundlewrap statt ansible?
- es gibt ein proof of concept im cm repo in einem eigenen branch
- für einen sinnvollen umstieg muss es einen harten cut geben, saalzeug kann in einer woche laufen
Ergebnisse
- Wir fangen mit dem Saal an
- hier ist bundlewrap gut geeignet, da relativ oft neu neugebaut und niedrige einstiegshürde
- In den Main branch mergen/migrieren
- Was in bunblewrap gesichert funktioniert, direkt aus ansible löschen
- rz setup
- es braucht ein paar leute die das CM pflegen, bzw nach dem event die diffs nachziehen
- hier können wir mit einer basisrolle anfangen
- für die vm könnte man mit nixos anfangen
- für sourcecodes / checkouts kann man die git version festpinnen
- web / mngt
- ist alles irgendwie zusammengewachsen, hier kann man nach diensten trennen
- für quick applications (etwas nodejs/python) braucht man einen ansatz. das muss sehr gut dokumentiert werden
- fahrplankonverter, datenmerger, …
- es ist egal was da läuft, aber es muss mit beispielen dokumentiert werden
- für jeden service muss im wiki stehen was
Todos
- bundlewrap für saal fertigstellen und ausrollen, test auf der MCH (kunsi)
- hexchen sucht sich nach der MCH mit anderen leuten diensten ansehen und ein paar nixos vorschläge machen
- danach: review des vorschlagen