Hallo Stefan,
zunächst einmal danke für den notwendigen Ansatz.
Einzelne Punkte/Kommentare stehen schon unten, weitere werden sicher in der jetzt entstehenden Diskussion noch folgen.
Ich gehe allerdings davon aus, dass dies eine schrittweise Lösung ist, denn viele Bereiche der config sind von uns zunächst noch zu „erforschen“
und das muss mit einer Prio gemacht werden, die die anderen Themen nicht vernachlässigt.
Mit freundlichen Grüßen
Haiko Gerdes
- Geschäftsführer -
___________________________________________________________________________
TraSo GmbH
Georg-Schumann-Str. 294
D-04159 / Leipzig
Tel.: +49 341 90 98 7 418 // Fax: +49 341 90 98 749
Mobil: +49 172 610 2849
Internet: http://traso.de E-Mail: h.gerdes@traso.de
___________________________________________________________________________
Geschäftsführer: Haiko Gerdes
Handelsregister: Amtsgericht Leipzig, HRB 21850
Von: Stefan Rank Kunitz [mailto:s.rank-kunitz@traso.de]
Gesendet: Dienstag, 9. September 2014 09:57
An: Haiko Gerdes
Cc: entwicklung@lists.traso.de; Tilo Werner
Betreff: Konzept: xResConfig - die ewige Baustelle
Hallo Haiko,
In Folge einer entsprechenden (berechtigten) Kritik von Tilo habe ich mir über einige Punkte zum Thema xRes-Config Gedanken gemacht und biete hiermit ein Konzept für Lösungen zu relativ vielen Problemen um die xRes-Konfiguration an. Zentral geht es darum, "die" XML-Datei zur Konfiguration des xRes zu vereinheitlichen, über eine GUI bedienbar zu machen, zu dokumentieren und reproduzierbar/deploy-bar zu gestalten. Ich gehe dabei von gegenwärtigen Problemen aus und biete eine zentrale Lösung an.
Grundidee:
Die xRes-Config liegt gegenwärtig als XML-Datei auf den jeweiligen Kundensystemen und wird NUR dort per Eingabefenster im xAdmin gepflegt.
In Zukunft biete ein Portal "xRes-Konfigurator" die Möglichkeit, alle xRes-Konfigurationen aller xRes-Installationen (also aller Kunden auf allen Kundensystemen) über eine grafische Oberfläche zu bedienen, zentral zu verwalten und auf Kundensysteme auszurollen.
[HGE:] Absolut richtig, zusätzlich gibt es meines Wissens noch Konfigurationen, die im Code liegen und in diese Komponente hochgezogen werden könnten/sollten.
Problem 1: Bedienung des XML über den xAdmin
Die aktuelle der XML-Konfiguration ist sehr umständlich: Der Anwender muss XML beherrschen, eine Plausibilitätsprüfung der Eingaben ist (bis auf XML-Validierung) nicht möglich. Zusätzliche Metadaten wie eine Hilfe / Dokumentation der Knoten (Was tut diese Einstellung? Welche Werte sind erlaubt?) und ein Rechtemanagement (Wer darf welche Einstellung sehen / verändern?) sind nicht möglich. Unter anderem ist dadurch eine Trennung der von Kunden bearbeitbaren Config zu einer "TraSo-Config" (z.B. Aktivieren/Deaktivieren ganzer Module) nicht möglich.
Lösungsansatz: Ein zentrales in PHP geschriebenes Webportal verwaltet in Zukunft alle xRes-Configs aller Kundensysteme. Die Bearbeitung der Konfiguration ist bequem generisch per Web-Oberfläche möglich (Eingabefelder, Ja/Nein-Radiobuttons, aktiv/inaktiv-Checkboxen, ...). Ein Rechtemanagement regelt für jeden XML-Knoten die Sichtbarkeit und Änderbarkeit => über entsprechende Rechte sind TraSo-MitarbeiterInnen in der Lage, mehr Einstellungen im Kundensystem zu sehen und zu bearbeiten als der Kunde selbst.
Die Web-Oberfläche ist dokumentiert und erklärt jede Einstellung in wenigen Worten.
Die Oberfläche zur Bearbeitung der Config im xRes wird entfernt und der neue Konfigurator per iFrame eingebunden. Das beschriebene Rechtemanagement stellt sicher, dass jeder Kunde nur SEINE Konfiguration sieht und nur eine Untermenge dessen ändern kann.
[HGE:] OK
Problem 2: DIE xResConfig / unterschiedliche Kunden-Stände der Config
Die Konfigurations-Dateien der verschiedenen xRes-Installationen sind "gewachsen" und auf völlig unterschiedlichem Stand. Mangels "Gesamtdokumentation" (bisher: Teil-Dokus im Confluence-Wiki) ist nur mit sehr viel Aufwand reproduzierbar, welche Einstellung bei welchem Kunden gesetzt sind bzw. fehlen => die Größe der Konfiguration (bei JT 3799 Zeilen) schließt eine "Übersicht" über bestehende bzw. mögliche Einstellungen aus, DIE xResConfig (im Sinne einer default-Version) existiert nicht.
Das Ausrollen eines neuen Kunden / eines bestehenden Kunden auf einer neuen Maschine bedeutet (nach bereits erfolgter Automatisierung des Deployments und der Chef-Installation der Maschinen) nun im Wesentlichen die manuelle Anfertigung einer Konfigurations-Datei (3799 Zeilen!!!). Ein Hardware-Defekt auf einem Server, der kein Backup besitzt, bedeutet automatisch den Verlust der xResConfig und damit die manuelle Neuerstellung der Konfiguration.
Lösungsansatz: Das oben beschriebene Portal verwaltet die xRes-Konfigurationen in Zukunft selbstständig. Initial wird es einen Import geben, der ALLE xResConf ALLER Kundensysteme importiert und über eine Vergleichsansicht die schnelle Erarbeitung DER Standard-xResConf erlaubt. Nach erstem "Ausmisten" (z.B. Entfernen nicht mehr genutzter Einstellungen bei LMX) und Dokumentieren der Einstellungen gibt es DIE EINE xRes-Config mit der Zusatzinformation, welche Einstellung auf welchem Kundensystem gesetzt sind.
Das Portal wird aus diesem Datenbestand heraus in der Lage sein, die kundenspezifischen Konfigurationsdateien zu erzeugen (DB2XML) und dem Kundenserver zur Verfügung zu stellen. Damit können Änderungen wie auch Neuinstallationen sehr einfach umgesetzt werden. Der Verlust der xResConf im Livesystem (z.B. HDD-Defekt) kann durch neues Einspielen der im xRes-Konfigurator hinterlegten Config ausgeglichen werden.
[HGE:] OK
[HGE:] Wird nicht ganz so einfach, da es durchaus verschiedene Varianten einer Lösung gibt.
Beispiel der Flugexport, der mal so und mal so konfiguriert ist, inhaltlich aber das gleiche bedeutet.
Es muss also die Bedeutung der configs zusammengeführt werden und nicht nur deren Syntax, was eine Automatisierung vermutlich ausschließt.
Problem 3: Sicherheit
Der gegenwärtige Broadcast-Mechanismus erfordert, dass auf allen Kundensystemen ein Apache-Server mit PHP installiert ist. Dieser muss die (sicherheitskritische!!!) Haupt-Config per Webrequest entgegen nehmen und ins Verzeichnissystem legen => sicherheitstechnisch ist dies der worst case.
Lösungsansatz: Das beschriebene Portal "xRes-Konfigurator" erzeugt die Konfig-Datei in Zukunft per Knopfdruck aus dem per GUI erstellten Einstellungen heraus. Die erzeugte Datei wird automatisiert auf alle betroffenen Kundensysteme geschoben (z.B. per ssh mit dem Deployment-User) und/oder dem Deployment zur Verfügung gestellt (über ein automatisch mitgeführtes GIT-Repository). Die bestehende Config-Bearbeitung und der Broadcast-Mechanismus werden durch den xRes-Konfigurator im xAdmin ersetzt.
[HGE:] OK
Hier muss gleich auch berücksichtigt werden, dass wir in Zukunft häufiger parallele Server zur Lastverteilung (service01 und service02) haben werden
und auch solche, die unterschiedliche Kapazitäten haben und deswegen unterschiedliche Konfigurationen brauchen (cache01 und cache02)
Umsetzung:
Die Kern-Komponenten der Applikation "xRes-Konfigurator" sind diese:
Da diese Software nicht zwingend einen Bezug zu xRes hat, kann sie auch von einem externen Entwickler erstellt werden. Ich empfehle, dafür Varianten wie einen Praktikanten oder Lehrling in Betracht zu ziehen.
[HGE:] Das finde ich einen guten Ansatz. Die Frage ist nun noch, wo kommt der Praktikant oder Lehrling her?
Und dann könnte dieser Ansatz noch um die beiden folgenden im nächsten Schritt erweitert werden:
- Integration der Cron-Jobs in eine DB-Lösung
- Verwaltung der Importprozesse und Importressourcen über einen Scheduler, dessen Konfiguration ebenfalls hier landen könnte.
Ich freue mich sehr auf allseitige Rückmeldungen!!!
VG SRK
--
Mit freundlichen Grüßen
Stefan Rank-Kunitz
- Senior Developer -
________________________________________________________
TraSo GmbH
Georg-Schumann-Str. 294
D-04159 Leipzig
Tel.: +49 341 909 87 45