-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Liste, und Danke Stefan für den RFC. Meine Anmerkungen sind im Text.
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.
Hintergrund hierfür war u.a. eine fahrlässige Lernen-Durch-Schmerzen-Aktion meinerseits ;-)
_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./*
Ack. Mir fällt da spontan die xRes-Benutzersteuerung ein, welche im DB-Schema xres_$cust_hotels residiert und die kundenspezifischen Einstellungen der Cache-Produktion, die sich irgendwo dort in einem DB-Schema befinden. @spestner Wo genau?
_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.
Wobei man hier auch generell überlegen kann, ob ein Kunde überhaupt Module ab/an-schalten können sollte. Diese Frage ist aber direkt mit der Komplexität der bisherigen Lösung verbunden, womit das Erlauben des An-/Abschalten für die Gruppe xRes-Admin (s.u.) so lala ok ist.
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.
Das heißt, dass es dafür einen redundant und zuverlässig erreichbaren Dienst an einem zentrale (Netzwerk-) Ort geben muss! @admin
*/[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.
Wir werden dafür in der Übergangszeit eine xResConf.xml (z.B. die auf allen service01) sichern, bis wir hier bei einer Lösung auf logischer/höherer Ebene sind. @admin
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.
Yeah!
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.
Das muss aber zwangsweise in eine computerlesbare Logik umsetzt werden. Vertriebs-/Marketinggedanken mit/auf Basis von EDV müssen sich gerade dort wieder spiegeln können. Wenn nicht, dann sind es voneinander losgelöste Ansätze, welche dann immer wieder Problem induzieren, die u.a. wir (xRes) technisch nicht abbilden können.
_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.
Dazu kommt das Apache natürlich Ressourcen verbraucht, die bei maximaler Effizienz des Systems lieber freigeben werden wollen.
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.
Denkbar wäre hier auch ein Synchronisationsprozess dem man auch über den xRes-Job-Ticker (TM) bewerkstelligen kann. D.h. betriebssystemseitig gibt es einen Prozess (Cron) der den xRes-Job-Ticker (TM) anstösst. Dieser wiederum schaut in eine Liste und stößt xRes-interne Jobs an, die zu der Zeit aufgrund der Listings abzuarbeiten sind. Unter diesen kann sich dann auch ein xRes-Config-Job befinden, der die lokale Config auf dem jeweiligen xRes-Server im Bereich eines Kundensystems anpasst. Hierbei gäbe es eine minimale Latenz von einer Minute bis Änderungen ankommen.
*/[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)/*
Full Ack. Das heißt (diese speziellen) Knoten der XML-Struktur müssen frei erweiterbar sein und dieses muss der Parser auch zu lassen (s.u schemaloser Ansatz).
_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),
Gruppe TraSo -> Gruppe xRes-Admin.
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
Oder einen geeigneten Ansatz um schemalos xml/json/bson abbilden zu können. Das eleminiert Schemaanpassungen bei Änderungen in der Datenquelle (z.B. XML aus dem xRes-Config-Generator (TM)) (s.u. Job -> Queue -> Arbiter -> Worker)
* 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?/*
Das schwarze Brett der Uni-Leipzig. http://www.dsble.de/
*/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/*
Das ist der xRes-Job-Ticker (TM) (s.o.)
- */Verwaltung der Importprozesse und Importressourcen über einen Scheduler, dessen Konfiguration ebenfalls hier landen könnte./*
Das ist der xRes-Resource-Manager (TM). Dieser umfasst folgende Bereiche: a) Eine Aufgabe (Job) ohne große Logik. Diese sagt nur für wen (Kunde) und was (Cacheupdate, Import etc.pp) gemacht werden soll. b) Einer Übertragungsschicht (Queue), die den Job aufnimmt und an einen c) Vermittler (Arbiter) weiterleitet, welcher weiß wieviel RAM,CPU,HDD dem Kunden mit entsprechenden SLAs zusteht und sie entsprechend dem d) Arbeiter (Worker) übergibt, der die Aufgabe dann einfach abarbeiten kann (ohne Logik). Aufgabe -> Übertragung -> Vermittler -> Arbeiter -> fertsch Alle Elemente dieser Kette funktionieren nach dem Prinzip gibt es eins dann gibt es n.
Ich freue mich sehr auf allseitige Rückmeldungen!!!
Ich auch :D Grüße, Tilo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUD06aAAoJEFfjOJdKpi1EMCYP/02Gf/C577gYK6Tcw78hNpvl y4js73gCdpeqF2vGDR8qkz27mJKfHQk19tExvWXrZht7mly4ImB1alNu8QuXSzHk an5WMQThgEFjmc1Ol6ur9IlUKHwnu+a3QWFztRCE1vSk6O/DwolYRErpN3jXvYc5 I6xVv11PNxfzN4SA7S/y3iO39Fp2o0OjxIBoyQH5L5p45XIXTgQevY4IBpix6mgv +eWtgmR2uABNEotQ05hwq0mpooPxBi6QDb9rkVoXLyVqoJeBrSxQ+8tGogkLad8Y qNaZK6RQDIoKm1+jsneHIULoGTNrxMHev/FHQ0ATgJ8T60A5Rjtj/weyPKThYyp6 AAOUpjcgz9E1QJtFGGChxxsVq34wtOHsmW8IjjoRADlrhBI+pjRUhB3ppHBcp/Sz oBPuiWqIXi1tF+RdgMH6HhBa3i07SATUc+fVvC+OTELANaHOL21HmCxclVm1657K gHzzrV6iw6+FnB782RJEs6awdY2FiR1wmgnBZc/7i64sgXNUkr7ooTQuil9Ysfvl 8h5H0kN2exiTOPWujoZUONED76jAsMBHGTwWtsX8dYcriMIa4IBVGRnq6gsQ9/9T aoWcw1OfUNukbRDzAe3HFUJ63PP2o9uTI0IyKZaWWaKLaNsTF8IiWoGd7eFH2HBY RXKqKRSSlePtD9e4xaFo =4Xwy -----END PGP SIGNATURE-----