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: * Aufsetzen eines PHP-Frameworks wie Symfony oder Zend * Benutzer-Autentifizierung mit RechteSystem (unbegrenzt User, eine Gruppe je Kunde + Gruppe TraSo), GUI für Bearbeitung des Rechte-Systems durch Admin => ggf. fertige Lösung als Plugin verwenden? Anpassung der Authentifizierung zur iFrame-Integration in den xAdmin OHNE erneutes Login * Datenbank-Entwurf zur Abbildung der rekursiv verknüpften Datenstruktur: Datensatz, Wert, Attribute und Verknüpfung zum Eltern-Datensatz * Import XML2DB, GUI zum Vergleich der Konfigurationen verschiedener Kunden (Diff-Tool) * Export DB2XML, Upload der XML-Datei z.B. per ssh * GUI zum Anlegen / Bearbeiten der Einstellungen * Aufsetzen der Software auf einer TraSo-zentralen VM, Durchführung XML-Importe und Erarbeitung default-xresConf 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 E-Mail: s.rank-kunitz@traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850