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