Anleitung zur Administration der Webanwendungen der AG

Voraussetzungen

Damit man die Webanwendungen der AG aktualisieren kann, benötigt man zunächst einmal Zugriff auf den Webserver giscours. Der Zugriff kann über den lokalen Nutzer www-rails per ssh erfolgen. Dazu muss der ssh-Schlüssel der betreffenden Person auf giscours unter .ssh/authorized_keys eingetragen werden.

Zur Einrichtigung neuer Webanwendungen benötigt man hingegen root-Rechte auf giscours. In diesem Fall wendet man sich am besten an den Techniker der AG.

Die meisten der Webanwendungen basieren auf Ruby on Rails. Um die Abhängigkeiten der Webanwendungen zu aktualisieren, sollte man sich daher verschiedene Ruby-Versionen lokal installieren. Zur Verwaltung der verschiedenen Versionen ist es am einfachsten sich den Ruby Version Manager zu installieren (siehe http://rvm.io/).

gpg2 --keyserver hkp://pool.sks-keyservers.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
\curl -sSL https://get.rvm.io | bash -s stable

Mit rvm get stable kann man sich die aktuelle stable-Version des Ruby Version Managers installieren.

Mittels rvm install <Ruby-Version> kann man einen speziellen Ruby-Interpreter installieren und mittels rvm list kann man sich die installierten Ruby-Versionen auflisten lassen. Falls sich der Ruby-Interpreter nicht lokal im Homeverzeichnis installieren lässt, gibt es einen Workaround: Man loggt sich auf dem Fileserver der AG, medoc ein und installiert den entsprechenden Interpreter dort.

Zur Aktualisierung der Ruby gems benötigt man weiterhin das Gem bundler, um dieses nicht separat für jede Webanwendung installieren zu müssen, kann man es mittels folgendem Befehl global für eine bestimmte Ruby-Version installieren:

rvm <Ruby-Version>@global do gem install bundler

Für die verschiedenen Versionen der Ruby-Interpreter sind unter rvm Aliase eingerichtet. Diese Aliase haben den Vorteil, dass man bei kleineren Ruby Updates (Revision) nicht die Apache-Konfiguration der einzelnen Webanwendungen per Hand anpassen muss. In der Konfiguration wird einfach der Alias angegeben und über rvm wird dieser Alias dann entsprechend aufgelöst.

Gibt es beispielsweise ein Ruby-Update (z.B. von 2.2.3 auf 2.2.4), so installiert man lokal und auf dem Webserver einfach den neuen Ruby-Interpreter und passt den Verweis für den Alias ruby 2.2 mittels rvm alias delete bzw. rvm alias create entsprechend an. Die aktuelle Aliasliste kann man sich mittels rvm alias list anzeigen lassen.

Aktualisierung einer Webanwendung

Sofern man die obigen Voraussetzungen geschaffen hat, kann man zur Aktualisierung einer Webanwendung wie folgt vorgehen.

Zunächst checkt man sich lokal das entsprechende git-Repository aus:

git checkout ssh://git@git.ps.informatik.uni-kiel.de:55055/apps/<Anwendung>.git

Dann wechselt man in das entsprechende Verzeichnis und wählt mittels rvm current einen geeigneten Ruby-Interpreter für die Anwendung aus. Hierbei wird wieder der Alias-Name, der in der Konfiguration der Anwendung angegeben wurde, verwendet, um lokal den entsprechenden Ruby-Interpreter auszuwählen.

Als nächstes prüft man mittels bundle check, ob alle Abhängigkeiten installiert sind. Ist dies nicht der Fall, so kann man mittels bundle install diese Abhängigkeiten lokal installieren.

Schließlich passt man im Gemfile die Abhängigkeiten geeignet an (z.B. für Rails) und führt dann das Kommando bundle update (bzw. speziell für die Aktualisierung von Rails bundle update rails aus). Falls alles klappt, wird für die Constraints (Versionen der verschiedenen Gems) im Gemfile eine Lösung berechnet: Gemfile.lock.

Falls die Anwendung über Tests verfügt (Unterordner /spec oder /test), so führt man nun diese aus:

rake spec bzw. rake test

Falls alle Tests erfolgreich sind, aktualsiert man den Branch des Repositories mit dem aktualisierten Gemfile.lock (commit + push) entsprechend. Falls es production und staging Branches gibt, muss der Commit entsprechend auch in diese Branches gemergt werden.

Schließlich kann man die Webanwendung mittels cap deploy (ggf. cap production deploy bzw. cap staging deploy) aktualisieren und neu starten.

Weitere Informationen
  • Bauen und Installieren der Webanwendungen + Ausführung der Testfälle mit Jenkins
  • Voraussetzung: Zugriff auf jenkins-Nutzer (auf siran)
  • Airbrake: Abfangen von Exceptions + Erstellen von Fehlermeldungen im Errbit
  • Airbrake-Konfiguration findet sich im Ordner /initializer bzw. bei Anwendungen mit production- und staging-Environment im Ordner /environment
  • Webpiraten aufgrund eines Bugs (28417) im Jenkins nicht sichtbar
  • Redmine: Automatisches Schließen von Tickets bei commit: git-mirror
  • Die Versionsnummer des zu verwendenden Ruby-Interpreters ist in jedem Repository in der Datei .ruby-version hinterlegt. Diese sollte mit der Versionsnummer, die in der Apache-Konfiguration bzw. im zugehörigen Deploy-Skript eingetragen ist, übereinstimmen.
  • Anpassen der Apache-Konfiguration unter: etc/apache2/include/default.inc. Danach Neustarten des Apache mittels sudo service apache2 restart
/srv/dokuwiki/adminwiki/data/pages/admin/info/webanwendungen/administration_der_webanwendungen.txt · Zuletzt geändert: 2022-02-17 09:25 von hbs
CC Attribution-Noncommercial-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0