Masterthese

Aus Callooh Wiki
Zur Navigation springen Zur Suche springen

TODO

  • UML Deploy Diagramm
  • Softwarebücher: Deploy, Installation
  • Recherche: Installability
  • Fowler Patterns: Deploy, Command Pattern
  • Anforderungen an Deployer


Fragestellungen

  • Lässt sich aus einem Modell automatisiert Konfiguration erstellen (bzw. wie weit ..)
  • Können Abhängigkeiten so abgebildet werden, dass diese beim Deployment berücksichtet werden
  • Kann festgestellt werden, ob ein Deployment erfolgreich war (bezogen auf Abhängigkeiten)
  • Kann die Atomarität eines Deployments gewährleistet werden
  • Kann ein Rollback automatisiert erfolgen

=> bei den Anforderungen, dort allerdings als Fragestellungen formulieren (... ergeben sich folgende Fragestellungen)

=> bei den Anforderungen im Architekturteil darauf eingehen und Anforderungen ableiten!

Externe Service

Ist eine externe Komponente in der Deploy-Liste nicht angeben und ist diese nicht als deployed gekennzeichnet (im letzten deploy) => Fehler

Ist die externe Komponente angeben, aber ohne version, erfolgt nur check ob deployed, sonst auch version.


Sematik von Deploy externer Komponenten: Check-Script oder Check-URL erfolgreich!

deploy ausgewählter componenten

wenn nicht in Deploy-Liste angegeben, erfolgt nur Check ob Komponente deployt ist (Version ist egal).

Soll auf bestimmte version geprüft werden, dann mit Version, ohne Redeploy angeben.

rollback

neue deployment entität, previous zeigt auf fehlgeschlagenes deployment. is_rollback auf true gesetzt. checks werden ausgesetzt.

Ideen

  • Version: welche Version deployt ist, lässt sich an der pom Datei herauslesen, die im Zuge der maven compile Phase in das META-INF Verzeichnis kopiert wird. Anhand der Version kann auch ermittelt werden, welche Daten-Migrations-Vorgänge ausgeführt werden müssen.
  • Config für Container muss auch Feld für args haben (z.b. bei Glassfish: -domain xy)
  • Config für Timeout bei deploy (dann gilt es als fehlgeschlagen), überschreibbar auf Applikations-Ebene
  • maven plugin: um z.b. via hudson mit mvn d4u:deploy deployen zu können
  • wenn application nicht in repository, sondern nur einzelne komponenten, muss mit versionsangaben der komponenten deployt werden können
  • Javadoc in Masterthese als Anhang!
  • Tests: mit Arquillian könne Tests direkt am Server im EE Umfeld ausgeführt werden. Dafür wird eine Konfigurationsdatei benötigt. Diese kann z.b aus DSL generiert werden.

Einschränkungen

  • Scripts werden lokal (auf host, auf dem d4u läuft) ausgeführt!
=> einbauen dass via ssh oder schtasks etc.
=> eventuell: flag "run-remote" um anzuzeigen dass script remote ausgeführt werden soll
  • Berechtigungskonzept: Eigentümer könne Rechte für JEDE Stage vergeben => soll nicht sein!
  • Berechtigungskonzept2: Stage-Manager soll für diese Stage Rechte vergeben können

TODOs

  • testen von deployment
  • testen von rollback
  • reparieren config-service (i.e. merge), inkl. rechte für stageManager
  • service für suche
  • service für get-status
  • rechte testen: deploy und config (stage-manager, etc. )
  • wrapper um service zu stoppen/starten
  • version-filter bei stage: bei deploy implementieren
  • wenn die ausführung eines jobs weder success noch failed nachsich zieht (weil z.b. abgeschmiert .., runtime-error, blocked, ..) kriegt der deploymentManager das nicht mit: daher periodisch checken welche jobs schon über das timeout hinaus laufen, diese auf failed setzen

Service Attribute (richtiger Begriff? TODO: recherchieren)

  • Abhängigkeiten: weiche, harte (i.e.: Version muss passen oder Komponente muss nur verfügbar sein)
  • Abhängigkeiten: müssen zur Laufzeit vorhanden sein, oder müssen bei Systemstart verfügbar sein
  • Soziale Aspekte: Akzeptanz (ad Tool Verwendung: z.b. EA ist allgemein bekannt, mehr Chancen dass ein modellbasierter Ansatz erfolgreich ist bei dessen Verwendung)


Begriffe

  • Node entspricht z.b unter Tomcat einem Context
  • Für Tomcat vermutlich eher nicht sinnvoll dass ein Job nur einen Server enthält, aber mehrere Nodes
  • Für GF eventuell sinnvoll: Cluster mit einem Artifact, einem Server, auf mehrere Kontexte verteilt
  • Daher ist Node-Name => Context-Name unter Tomcat, Applications-Name unter Glassfish
  • Für Tomcat wird daher das war-file in node-name + extension vom artifact umbenannt
  • Backups bei Tomcat daher für jeden context(=node) extra
  • Node-Name darf daher nicht unique sein, aber kombi node-name<->stage schon
  • für domains bei glassfish: für jede domain eigener server!
  • Server: Service-Name sowie start/stop script ist in RUN_CONTROL gespeichert (Tomcat-Controller macht fallback auf server-name)

windows remote command exection

  • für powershell scripts
invoke-command -computername Server01, Server02 -filepath c:\Scripts\DiskCollect.ps1
Invoke-Command -ComputerName 7-90 -ScriptBlock { start-process "C:\temp\test.bat" }
=> problem: powershell muss verfügbar sein und verwendet werden und richtig konfiguriert sein,

möglicher Fehler: 

CategoryInfo          : Sicherheitsfehler: (:) [Invoke-Command], PSSecurityException
FullyQualifiedErrorId : UnauthorizedAccess,Microsoft.PowerShell.Commands.InvokeCommandCommand

oder, wenn winrm nicht konfiguriert ist: 

+ CategoryInfo          : OpenError: (7-90:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : CannotConnect,PSSessionStateBroken


  • sonst mit schtasks.exe
 schtasks.exe /Create /S 7-90 /SC Einmal /TR c:/temp/test.bat /TN test /ST 10:36
=> Problem: /TN taskname, bleibt auch nach ausführung bestehen. /ST muss angegeben werden
  • oder windows remote management
winrs -r:REMOTECOMPUTERNAME command to run
=> Problem: muss configuriert werden
Abgerufen von „https://wiki.callooh.com/index.php?title=Masterthese&oldid=1233“