Archive for the ‘Infrastruktur Innatura’ Category

MvnIndex

Friday, January 17th, 2020

Der MvnIndex ist äusserst praktisch, wenn man ein neues Projekt mit Maven aufsetzt.
Neben einer “Artifact”-Websuche gibts auch ein Eclipse Plugin für die Suche nach GroupId, ArtifactId und Version.

Active Directory Virtualisierung mit Penrose

Sunday, December 8th, 2019

Bei einem Projekt hatte ich die Problemstellung, dass Useraccounts aus zwei Active Directories in ein (javabasiertes) Shop-Produkt importiert werden sollen. Dieses Shop-Produkt wird zwar mit einer LDAP-Anbindung ausgeliefert, allerdings kann es nur Useraccounts aus genau einem Active Directory oder LDAP importieren.

Die Lösung: Ein LDAP-Proxy, der die beiden Active Directories zu einem virtuellen LDAP zusammenführt, und gleichzeitig LDAP-Binds erlaubt, um Single Sign On mit den Windows Credentials zu ermöglichen. Das (ebenfalls javabasierte) Open Source Produkt Penrose erfüllt genau diese Aufgabe.

Beispiel:
Active Directory 1 speichert die Kundenaccounts und besitzt folgenden Wurzelknoten:
dc=customer,dc=company,dc=com

Active Directory 2 speichert die Mitarbeiteraccounts und besitzt folgenden Wurzelknoten:
dc=employees,dc=company,dc=com

Im Penrose werden diese beiden Active Directory as LDAP Proxy Partitions importiert und die beiden Wurzelknoten in das Root DSE attribut eingetragen. Penrose simuliert keinen Active Directory, sondern lediglich einen “puren” LDAP. (Active Directory hat ein paar Spezialitäten, beispielsweise einen Bind mit der user@domain Notation). Dennoch werden Active Directory-spezifische Attribute wie memberOf übernommen. Man bekommt also einen LDAP mit Active Directory Schema.

Eine (wichtige) Kleinigkeit: Der Session Timeout in Penrose kann über die /conf/server.xml angepasst werden:

<session>
   <parameter>
      <param-name>maxIdleTime</param-name>
      <param-value>10080</param-value><!– time out von 7 tagen –>
   </parameter>
</session>

Script your Server!

Sunday, August 18th, 2019

In fast jedem Softwareprojekt wird die Applikation auf mehrere Server mit unterschiedlichen Konfigurationseinstellungen installiert und betrieben. Neben der Konfiguration für die Produktivumgebung müssen auch die Konfigurationen für Staging- und Entwicklungsserver verwaltet werden. Beispielsweise benötigt die Staging-Instanz andere Datenbankeinstellungen als die Produktivinstanz.

Somit kommen bei einem Projekt schnell mal 6 Konfigurationsversionen zusammen:

  • dienstleister-devlocal (lokale Entwicklungsinstanz)
  • dienstleister-dev (zentrale Entwicklungsinstanz)
  • dienstleister-sta (Staging System beim Dienstleister)
  • kunde-sta (Staging System beim Kunden)
  • kunde-productive1 (Produktiv-System – Cluster 1)
  • kunde-productive2 (Produktiv-System – Cluster 2)

Jede Konfigurationsversion setzt sich aus einer Vielzahl von Dateien zusammen, die sich noch in unterschiedlichen Pfaden befinden. Wenn zudem noch ein Produkt einsetzt wird, (z.B. Day Communiqué oder Hybris) kommt man leider ab und an in die Verlegenheit Dateien des Produktes (z.B. JavaScripts) zu überschreiben. Weiteres Beispiel ist die Installation von DLLs (z.B. bei Verwendung des SAP JCO Connectors).

Das Problem ist: Manuelles Pflege auf allen Servern ist langsam, fehleranfällig und nicht zuletzt unglaublich langweilig. Die Lösung ist recht simpel: Automatisieren, Automatisieren, Automatisieren, Automatisieren… Dabei trennt man das Projekt strickt von den eigentlichen Konfigurationsdateien. Diese Trennung spiegelt sich auch im Subversion wieder.

Beispiel Projekt im Subversion:
/project<br /> /project/core/branches<br /> /project/core/tags<br /> /project/core/trunk<br />

Beispiel Konfiguration im Subversion:
/project_configuration<br /> /project_configuration/branches<br /> /project_configuration/tags<br /> /project_configuration/trunk<br /> /project_configuration/trunk/scripts<br /> /project_configuration/trunk/instance/dienstleister-devlocal<br /> /project_configuration/trunk/instance/dienstleister-dev<br /> /project_configuration/trunk/instance/dienstleister-sta<br /> /project_configuration/trunk/instance/kunde-sta<br /> /project_configuration/trunk/instance/kunde-live1<br /> /project_configuration/trunk/instance/kunde-live2<br />
Auf jedem Server wird /project/core und /project_configuration ausgecheckt. Aber wie kommen Konfiguration und Projekt zusammen ? Dies geschieht über ANT-Skripte, die aus einem ausgecheckten Projekt eine lauffähige, serverabhängige Installation generieren. Dabei werden die Dateien aus dem jeweiligen Konfigurationsverzeichnis (z.B. dienstleister-devlocal) in das Projektverzeichnis kopiert und ggf. vorhandene Dateien überschrieben.

Somit kann in wenigen Minuten eine komplette Instanz installiert werden. Weiter vereinfacht wird das Ganze, wenn .bat Dateien (oder Shellscripte) diese ANT-Skripte aufrufen.

Beispiel Skriptaufruf:
checkout-project-configuration.bat (Checkt das Konfigurationsprojekt aus dem Subversion)
checkout-project.bat (Checkt das Projekt aus dem Subversion aus)
configure-dienstleister-devlocal.bat (Konfiguriert das Projekt mit “dienstleister-devlocal” Konfiguration)

Fazit:
Durch das Automatisieren sämtlicher Konfigurations- und Installationsdateien werden Flüchtigkeitsfehler vermieden und das Aufsetzen von Serverinstallationen erheblich beschleunigt. Das Programmieren solcher Konfigurationsskripte kostet zwar zu Beginn des Projekts etwas Zeit, diese Investition wird aber doppelt und dreifach wieder amortisiert.