Webdeployment auf Cluster Seminarvortrag von Lukas Bonzelett

Motivation  Anwendungen werden in das Web ausgelagert permanent verfügbar Problem: Änderungen im laufenden Betrieb  Cluster  bessere Performance  Ausfallsicherheit  Problem: manuelle Verwaltung unmöglich 2

Idee  Repository und Versionierung nutzen  Besonderheiten des Webdeployments nutzen  Automatisierende Skripte nutzen 3

Ziel  Permanente Verfügbarkeit von Webanwendungen mit fortlaufender Entwicklung gewährleisten.  Sicheres Deployment  Einfaches Notfallhandling 4

Agenda  Grundlagen  Deployment-Arten  Cluster-Deployment  Vergleich der Deployments  automatisierte Skripte  Durchlaufstufen eines Deployment-Prozesses  Lösungsvorschlag  Ausblick 5

Definition  „Softwareverteilung (engl. deployment) nennt man Prozesse zur Installation von Software auf Anwender-PCs oder Servern in Betrieben.“ (Wikipedia)  Hot deployment ermöglicht die Installation und das Aktualisieren von Anwendungen im laufenden Betrieb, ohne diesen zu unterbrechen. 6

Repository 7 Darstellung eines Projektes im Entwicklungsprozess innerhalb des Repositorys

Rollout & Rollback  Rollout Verteilung von Software auf die Clients im Web: Nicht an User sondern an Server  Rollback Software wird auf letzten stabilen Stand gebracht Problem: Datenstrukturen könnten sich geändert haben 8

Testing  problemfreien Ablauf gewährleisten  Zeitintensität nicht zu vernachlässigen 9

Deployment-Arten  Webdeployment Gut handelbar (interpretierte Skripte) Anwendung werden nicht gestartet keine Down-Time (hotdeployment)  Javadeployment Applikation-Server Ordnerstruktur wichtig Down-Time 10

Deployment-Arten  C/C++ - Deployment Desktopinstallation (Betriebssystemabhängig) Serveranwendungen (keine einheitlichen Vorgehensweisen beim Deployment) Anwendungen müssen installiert werden Down-Time 11

Webdeployment auf Cluster  Keine Down-Time  Ausnahme: sehr große Datenmengen  Daten als Paket auf alle Server verteilen.  Skripte führen entpacken der Pakete aus.  Synchronität beachten 12

Cluster Deployment  Geeigneten Zeitpunkt finden.  Prüfen ob neue Version auf allen Servern korrekt ankommen sind und funktionieren.  Clusterschwenk Nachteil: langsam und teuer  Zentrales Deployment  Problem: Asynchrone Server  Problem: Löschen von Dateien 13

Schematische vereinfachte Darstellung eines Clusterschwenks 14

Vergleich der Deployments Web-DeploymentJava-DeploymentC/C++-Deployment Down-TimeNeinJa Vorgehensweise (In welchen Schritten die Cluster bestückt werden.) 100% (alle Server gleichzeitig) 50%-50% (erste Hälfte – zweite Hälfte) 50%-50% (erste Hälfte – zweite Hälfte) Ausnahmen (Bei denen Down- Time oder Vorgehen beeinflusst wird.) Große Datenmengen können zu Down- Times führen. (teilweise Hot-Deployment) - Installation (Ausführen der Dateien nötig?) NeinJa 15

Automatisierte Skripte  Prozess durch ein Skript automatisch  Nacheinander ablaufende Befehle  Fehlerquelle Mensch weitestgehend ausgeschlossen  (z.B. ANT bzw. PHING) 16

Darstellung eines vereinfachten Deployments-Prozesses 17 Durchlaufstufen eines Deployment- Prozesses

Lösungsvorschlag  Entwickler entwickelt und testet auf einer Testumgebung.  Nach dem Commit ins Repository, wird ein neuer Tag erstellt. Tag wird auf ein Integrationssystem gespielt. Integrationstest  Tag wird mit Hilfe eines Deployment-Servers und Repository auf ein Staging-System gespielt. Deployment-Server arbeitet mit automatisiert Skripten (z.B. PHING) In den Server werden die Projektdaten (eventuell mit einem Datum versehen) eingespielt. 18

Lösungsvorschlag  Staging-System: Entwickler macht Systemtest und der Abnehmer den Abnahmetest. neue Version mit Versionsnummer  beide Versionen existieren Die neue Version wird mit Hilfe von Checksummen mit dem Repository verglichen. Automatisiert wird auf die neue Version umgeschaltet. Die alte Version wird automatisch vom Server entfernt. 19

Lösungsvorschlag  Tests bestanden: über Deployment Server Rollout Server mit neuen Version bestücken Wenn Checksummentest bestanden ist, synchron auf neue Version umstellen.  Tests nicht bestanden: Zurück zum Beginn(Bugfix)  XML mit Versionsverlauf aktualisieren 20

Schematische Darstellung des Deployments mit Hilfe eines zentralen Repository 21

Lösungsvorschlag  Sonderbehandlung Server offline oder neu Server an Übersichtssystem angeschlossen (jeweilige wird Version abgebildet)  veraltete Versionen sofort erkennbar. In regelmäßigen Abständen Checksummentest: nicht aktuelle Server identifizieren und nachrüsten Server mit veralteten Version gefunden: Diesen mittels rsync auf den neuen Stand bringen. 22

Ausblick  Tool Repository & Versionierung automatisiertes gut kontrollierbares Deployment auf Cluster Schnittstelle zwischen den verschiedenen Abteilungen Entwickler gibt Teile der Verantwortung ab Übersicht über Versionen der Anwendungen 23

Danke für die Aufmerksamkeit! Fragen? 24

Automatisierte Skripte(PHING) 25

Quellen  Wikipedia  Testufen fom.de/index.php/Analyse_der_Anwendungsm%C 3%B6glichkeiten_von_Testautomatisierung fom.de/index.php/Analyse_der_Anwendungsm%C 3%B6glichkeiten_von_Testautomatisierung 26