Upgrade und Migration von Redmine – Licht und Schatten eines Projektmanagement-Tools

Redmine ist ein wunderbares Projektmanagement-Tool. Ich setze es seit mehreren Jahren ein, sowohl privat als auch zeitweise im Unternehmensumfeld. Neben Projektverwaltung, Issue-Tracking-System, Diskussionsforum, Zugriff auf Versionsverwaltungssysteme bietet es auch pro Projekt ein Wiki, was bei meinem Einsatz letztlich eines der meist verwendeten Features darstellt. Daneben lässt es sich bereits im Auslieferungszustand vielfältig konfigurieren, es sind eigene Workflows möglich, das Berechtigungssystem erlaubt Mandantenfähigkeit und nicht zuletzt ist Redmine mit einer Vielzahl von Plugins erweiterbar, falls doch einmal die Standard-Funktionen nicht ausreichen sollten. Und dazu Open Source und frei verfügbar. Insofern – alles wunderbar, oder?Leider nicht. Um es noch einmal zu wiederholen – Redmine ist ein wunderbares Tool. Sobald es denn einmal läuft. Dann läuft es rund – und die Installation möchte am besten gar nicht mehr angefasst werden. 

Dabei ist die Installation an sich gar nicht besonders schwierig – nur dank Ruby on Rails ein wenig umständlicher als mal eben ein PHP-Skript in seinen Webspace zu kopieren. Das Schlimmste dabei sind jedoch die einfach nur schlechten Anleitungen, sowohl zur Installation als auch zum Upgrade. Fast wirkt es, als möchten die Entwickler gar nicht, dass man Redmine einsetzt und sogar irgendwie lieb gewinnt, denn dieser Ansammlung von kruden Hinweisen zu folgen, macht einfach keinen Spaß. Insofern ist es auch kein Wunder, dass es inzwischen einige Anbieter gibt, die gehostete Lösungen vermarkten oder fertig nutzbare Appliances bereit stellen. Leider sind die Preise bzw. deren Leistungen nicht wirklich adäquat zur privaten Nutzung, im Unternehmensumfeld würde ich hingegen jederzeit darauf zurück greifen. Googlen mit „Redmine Hosting“ hilft – da ich an dieser Stelle keine Anbieter empfehlen bzw. keine Werbung machen möchte. 

Die Ausgangslage

Die alte Redmine-Installation bestand aus einer etwas angestaubten Version 2.4.x und befand sich auf einer ebenso älteren VM. Als Distribution wurde Ubuntu 14.04 LTS eingesetzt – zwar noch supported, aber alles andere als frisch. Ursprünglich lag sogar eine noch ältere Ubuntu-Fassung darunter, die auf 14.04 LTS hoch gezogen wurde. Bereits damals war der Aufwand nicht zu verachten, da alle Bundles neu installiert bzw. mit den richtigen Libraries gebaut werden mussten. 

Redmine lief mit einer MySQL-/MariaDB-Datenbank, die ebenfalls auf der VM installiert war. Das Ziel war, alles autark auf einem System ohne weitere Abhängigkeiten zu haben. Auch lief auf dieser VM ausschließlich Redmine, ebenfalls war die MariaDB-Instanz nur für Redmine vorgesehen, es wurden keine anderen Datenbanken darauf gespeichert. 

Redmine hatte ein etwas moderneres Theme bekommen, Plugins waren hingegen keine installiert. Bei einigen Wiki-Seiten wurden Dateien hinzugefügt, insofern mussten neben der Datenbank die Upload-Verzeichnisse migriert werden. 

Der Migrationspfad

Der von mir zunächst geplante Migrationspfad sah wie folgt aus:

  1. Einrichtung einer neuen VM mit neuer Ubuntu-Distribution und ein wenig mehr Plattenplatz
  2. Auf der neuen VM Redmine einrichten (inkl. MariaDB)
  3. Backup vom alten System erstellen (Files und Datenbank)
  4. Altes System upgraden
  5. Daten vom alten System, was nun die neueste Redmine-Version besitzen sollte, auf das neue System kopieren
  6. hoffen…

Das war immerhin ein Plan. Der erste und zweite Punkt dürfte sich selbst erklären. Das bestehende System sollte nicht kompromittiert werden, zudem wäre es einfach, es bei Problemen weiterhin zu nutzen. Das Thema Backup darf natürlich nicht unterschätzt werden – die „Assets“ steckten ja gerade in Datenbank und den hochgeladenen Dateien, insofern steht ein Backup hier an erster Stelle. 

Aber warum das alte System erst upgraden, dann die Daten auf das neue kopieren? Dieser Vorgehensweise ist eher klassisch. Meist lässt sich ein System leichter, d.h. mit weniger Problemen auf eine aktuelle Version bringen, wenn die (hoffentlich vorhandenen) Upgrade-Prozeduren verwendet werden. Nehmen wir z.B. eine Linux-Distribution, etwa Ubuntu. Der Aufwand, eine alte Distribution per „do-release-upgrade“ von einem Release auf das nächste zu heben, ist in den meisten Fällen geringer, als ein neues System aufzusetzen und dann mühsam, d.h. manuell alle Services des alten Systems umzuziehen. 

Aber um es vorweg zu nehmen, dieser Migrationspfad war nicht in Stein gemeißelt, denn dabei kam ein zarter Lichtschein von Rails hervor – die Rails Migrations. Später dazu mehr. 

Die Alternativen

Eine Alternative zu Redmine bzw. ein Tool, was sich letztlich daraus entwickelte, wäre OpenProject gewesen. Ich habe es kurz angesehen, dank Docker war die Installation zu Testzwecken eine Sache von nur wenigen Minuten. Bei OpenProject hätten die Daten aus Redmine übernommen werden können, für mein Szenario ein entscheidender Punkt. 

Leider hat es mir nicht wirklich gefallen. Die UI sieht zwar moderner aus als die standardmäßige UI von Redmine, aber so richtig nutzerfreundlich erschien sie mir nicht, vor allem dann, wenn man nicht immer viel Platz auf dem Bildschirm hat. Ich verwende Redmine sowohl mit 27″-Display (und dann nicht im Vollbild), als auch mit 13″ auf dem Notebook, da fehlte mir einfach die Übersicht. Noch dazu ließ sich das Design nicht ändern. Darüber hinaus wurde in der freien Community-Version nahezu auf jeder Seite die Werbung für die Enterprise-Version angezeigt. Ich habe Verständnis für kommerzielle Unternehmen, aber die Verknüpfung zwischen „OpenProject Foundation e.V.“ und „OpenProject GmbH“ erscheint mir dann doch ein wenig zu eng. 

Redmine selbst hätte ich durchaus gerne als Docker-Container installiert. Das hätte das Upgrade auf zukünftige Versionen voraussichtlich sehr erleichtert. Letztlich habe ich mich doch dagegen entschieden. Einerseits ist die Beschreibung des anscheinend offiziellen Docker-Images im Bereich von „geht so“. Darüber hinaus hatte ich diesbezüglich noch keine Erfahrung mit der Migration der Daten, und der Speicherort von lokalen Daten ist ja nach wie vor ein durchaus kritischer Punkt. Ein wesentlich umfassenderes Image war leider noch nicht auf dem neuesten Stand von Redmine, aber evtl. werde ich es mir in der nächsten Zeit noch einmal genauer ansehen. 

Somit kam diesmal ausnahmsweise kein Docker zum Einsatz. 

Einfach mal los laufen

Der erste Schritt sollte die Installation von Redmine & Co. auf der neuen VM sein – also einfach mal drauf los. Bei Ubuntu habe ich die momentan aktuelle Version 17.04 genutzt, wohlbekannt, dass es keine LTS-Variante ist, aber in dem Fall heißt es eben zeitnah zu updaten. 

Zunächst MariaDB:

MariaDB macht es einem mit der Wahl der Repositories bzw. Installation sehr einfach. Ich habe den halb-manuellen Weg genommen, da ich es vorziehe, externe Repositories nicht in der zentralen sources.list-Datei zu speichern. 

Datei /etc/apt/sources.list.d/mariadb.list editieren:

Und wie üblich update und die eigentliche Installation des MariaDB-Servers:

Während des Installationsschrittes muss ein neues Root-Passwort für MariaDB gewählt werden. 

Weitere Abhängigkeiten

Damit liegt MariaDB bereits lauffähig vor. Immerhin war somit die erste Abhängigkeit von Redmine erfüllt. Die anderen – nun, eine gute Frage. Redmine nennt z.B. ImageMagick oder diverse Binaries von Versionskontrollsystemen. Oder Ruby-Versionen. Spannend, aber an der Stelle nicht besonders hilfreich. 

Zunächst einmal habe ich es mit ImageMagick versucht:

Das lief zwar soweit durch, aber reicht das? Darüber lässt sich die Installationsanleitung nicht aus. (Spoiler: Es reicht nicht.)

Schritt für Schritt – oder auch nicht

Anschließend soll – laut Schritt 1 – der Quellcode von Redmine herunter geladen werden. Ich habe mich für das neueste Release entschieden -getreu der Empfehlung der Entwickler. 

Somit befand sich die Datei redmine-3.4.0.tar.gz nun bei mir im Home. Jedoch war an dieser Stelle nichts davon zu lesen, wo man die Redmine-Installation möglicherweise platzieren sollte. Das Kuriose dabei – die Anleitung bezieht sich auf den Download, danach folgt die Einrichtung der Datenbank, und im nächsten Schritt sollen die Datenbank-Konfigurations-Parameter eingerichtet werden. Diese befinden sich natürlich in einer Datei, die sich im vormals herunter geladenen Quellcode befindet. Schritt-für-Schritt-Anleitung? Mitnichten!

Daher habe ich die Installation analog zur bisherigen vollzogen. D.h. Redmine soll in /vol/www/redmine liegen, die Git-Repositories in /vol/repositories. Warum nicht in /var/www o.ä.? Einfach aus praktischen Gründen, ein Backup von /vol/ reicht, um alle relevanten Dateien zu erwischen.

Aber zunächst zur Datenbank, man logge sich als User root mit dem zuvor gewählten Passwort ein:

Danach hieß es somit, erst einige Verzeichnisse anzulegen und den Quellcode dort hinein zu platzieren. Im Folgenden weiche ich auch teilweise vom Vorgehen, was in der Installationsanleitung genannt wird, ab. Beispielsweise wird darin kein User für Redmine angelegt, was ich aber durchaus bevorzuge.

Nun die Datenbank-Config – Datei umkopieren und die eigenen Daten eintragen:

Datei in den Editor und im Bereich „production“ ändern:

Dasselbe mit der E-Mail-Config:

Die bei mir verwendeten Werte lauten:

Dabei ist „mailout.geschke.net“ ein nur intern erreichbarer Mailausgangs-Server, der die Weiterleitung übernimmt. Somit der einfachste Weg, weitere Konfigurationsbeispiele finden sich in der Datei. 

Danach bin ich vom oben beschriebenen Migrationspfad abgewichen. Was wäre denn, wenn von vornherein die bestehenden Daten genutzt werden könnten? Immerhin beschreibt die Anleitung zur Upgrade auch den Weg von einer Redmine Version 2.4.x zur momentan aktuellen Fassung. Natürlich unter Zuhilfenahme eines Backups, und genau dann wäre es auch irrelevant, ob das Backup auf einer neuen Installation auf einem neuen Server eingespielt wird, oder nur auf einer neuen Installation auf demselben Server. Vor allem würde ich die Lauffähigkeit der bestehenden Installation somit überhaupt nicht gefährden und könnte diese bei Problemen einfach weiter verwenden. 

Gedacht, getan, zunächst also einen Dump der alten Datenbank gezogen (per mysqldump), danach die hochgeladenen Files gepackt und kopiert. Das Ergebnis wurde dann auf den neuen Server kopiert.

Datenbank-Dump: redmine_20170702.dump

Files: redminefiles-20170702.tar.gz

Die Files wurden entsprechend am gewünschten Ort entpackt:

Dann noch ein paar Verzeichnisse anlegen und Rechte setzen:

Ein Blick auf die standardmässig bei Ubuntu installierte Ruby-Version besagte, dass die Version 2.3.3 installiert werden würde. Das sollte reichen, insofern – wenn die Distribution schon aktuell genug ist, warum dann nicht einfach nutzen? Somit:

Bundler musste mit genommen werden, subjektiv gefühlt wurden damit auch so gut wie alle Entwicklungs-Tools gleich mit installiert. 

Nun konnten die notwendigen Ruby-Gems installiert werden. An dieser Stelle kürze ich jedoch etwas ab, denn es benötigte ca. drei Versuche, bis es letztlich erfolgreich war. Erstens wollte ich als User „redmine“ installieren, was aber nur funktioniert, wenn man einen Pfad wie „vendor/bundle“ angibt. Ok. Dann fehlte noch libmysqlclient-dev, somit installiert. Und nicht zuletzt gab es dann Probleme mit „rmagick„, das sollte doch dank „ImageMagick“ eingerichtet sein? Nein, da musste noch „libmagickwand-dev“ hinzu gefügt werden:

Nun aber wirklich los – als User „redmine“:

Nach einiger Zeit tauchte tatsächlich die Erfolgsmeldung auf:

Danach laut Anleitung den secret token generieren:

Nun noch die Datenbank importieren:

Nun war also die alte Redmine 2.4.x Datenbank in einer neuen Redmine-Installation vorhanden. Genau dasselbe wie beim Upgrade!

Insofern hieß es hoffen, dass die Rails Active Record Migrations ordentlich geschrieben worden waren und dass die Datenbank-Auffrischung somit erfolgreich durchlaufen werden kann. 

Nach kurzer Zeit folgte die Bestätigung – keinerlei Fehlermeldung bei der Migration, das sah insofern gut aus!

Ad-hoc-Test

Für einen ersten Test reichte daher die Nutzung des integrierten Webservers:

Perfekt! Das Einloggen war möglich, alle Daten waren vorhanden, einzig das Design ließ zu wünschen übrig, was am noch nicht vorhandenen Theme lag. 

Das Ergebnis

Redmine läuft und musste nun nur noch richtig gestartet bzw. eingebunden werden. Dazu dient Thin in Kombination mit Nginx, evtl. später diesbezüglich mehr. 

Falls keine alten Daten vorhanden gewesen wären, hätte zum Aufsetzen der Datenbank und Befüllen mit Default-Werten ebenfalls eine Migration genügt:

Das macht das Installieren somit wiederum einfach – und erst recht das Upgrade auf neue Versionen. Über die Anleitung habe ich mich ja bereits ausgelassen, beispielsweise sind diese Schritte einfach nicht chronologisch sinnvoll erklärt. Beispiel? Irgendwo mittendrin wird auf mögliche Probleme mit Ubuntu beim Migrationsschritt eingegangen. Ubuntu wurde aber weder zuvor noch danach irgendwo erwähnt. Darüber hinaus wird als Lösung die Installation einer doch eher alten Library benannt. Auf welche Ubuntu-Version bezieht sich der Einschub? Oder – weitere Abhängigkeiten, etwa das Puma-Gem. Sinnvoll oder nicht? Weitere Hinweise zu Puma? Nein. Ohne weitere Quellen bzw. Hinweisen der vorherigen Installations-Mitschrift wäre ich nicht besonders gut weiter gekommen. 

Aber immerhin – Redmine läuft, alle Daten sind vorhanden. Ein wunderbares System, was mir noch lange Zeit gute Dienste leisten wird, wenngleich das Upgraden keinen Spaß macht. 

 

Ähnliche Beiträge

Tags:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.