Aktualisierung von Drupal 9 auf Drupal 10 – Teil 2, das Upgrade der Produktivseite

Dies ist der zweite und abschließende Teil der Artikelserie über das Upgrade von Drupal 9 auf Drupal 10.

In Teil 1 ging es um die Vorbereitungen in der lokalen Entwicklungsumgebung. Am Ende dieser Phase stand eine lokale Drupal-Instanz, die bereits auf Drupal 10 aktualisiert wurde.

Nun geht es darum, auch die Produktivseite auf Version 10 zu heben.

Zur Erinnerung: In dieser Artikelserie möchte ich meine Sicht über das Upgrade auf Version 10 anhand der Seite epicenter.academy schildern, die ich seit 2022 technisch betreuen darf. Die beiden Artikel sind keinesfalls als Ersatz für die offizielle Anleitung zu sehen, sondern schildern lediglich einen zusätzlichen Blickwinkel auf das Vorhaben mit hoffentlich nützlichen Details.

Die zwei Phasen der Aktualisierung des Live-Betriebs

Das Upgrade im Echtbetrieb gliedert sich in zwei Unterphasen.

Die erste Unterphase ist das Upgrade einer gespiegelten Produktivinstanz, die zweite Unterphase die Aktualisierung der Live-Seite.

Warum eine gespiegelte Seite?

Zunächst stellt sich die Frage, warum nicht gleich zum Upgrade der Live-Seite übergegangen wird. Nun, die offizielle Anleitung auf drupal.org ist zwar schon sehr ausführlich, behandelt aber nicht den Aspekt der Trennung zwischen Entwicklungsinstanz und Live-Betrieb.

Diese Trennung ist selbstverständlich sehr ratsam, denn wer möchte schon, dass technische Probleme, die nun mal bei Weiterentwicklungen und Updates vorkommen können, die Verfügbarkeit der Website für Besucher schmälert.

Das bisher Gesagte erklärt freilich noch nicht, warum ich zunächst eine gespiegelte Instanz auf Version 10 aktualisierte. Der Grund liegt im bereits vorher erwähnten Umstand, dass die offizielle Anleitung kein Wort darüber verliert, wie man die Änderungen der Vorbereitungsphase auf eine etwaige Produktiv-Instanz überträgt.

Für mich war es also wichtig, in einer möglichst dem Echtbetrieb gleichenden Umgebung die notwendigen Schritte zu explorieren.

Sicherungen geben Sicherheit

Den Start solcher Arbeiten bildet selbstverständlich die ordnungsgemäße Sicherung der Produktivseite.

Dazu wird zunächst am Server der Root-Folder der Website mit einem einfachen cp -a kopiert. Weiters wird mit dem mysqldump Tool eine Sicherung der Datenbank erstellt. Ein kleiner Tipp: Verwenden Sie die --single-transaction Option um einen konsistenten Datenstand in Ihrer Sicherung zu erhalten.

Lokale Sicherungen sind nicht genug, denn es kann im weiteren Verlauf immer wieder zu Fehlern auf der Kommandozeile kommen. Deswegen ist es wichtig, die Sicherung der Dateien und der Datenbank nochmals woanders (z.B. auf dem lokalen Entwicklungsrechner) zu speichern. Für das Backup des Root-Folders empfiehlt sich vor dem Download das Verpacken in einem tar-Archiv, da die unzähligen kleinen Dateien in diesem Verzeichnis einen großen zeitlichen Overhead beim Herunterladen erzeugen würden.

Spiegeln der Produktivseite

Um eine dem Echtbetrieb möglichst nahe Umgebung zu schaffen, spiegelte ich die Live-Seite wie folgt.

Ich kreierte eine weitere Kopie des Root-Folders mit dem cp -a Befehl. Dann erstellte ich im Admin-Panel des Hosting-Anbieters eine zweite Datenbank. In dieser spielte ich das zuvor erstellte Datenbank-Backup mithilfe des mysql Kommandozeilenprogramms wieder ein. Bevor dies geschehen konnte, musste ich lediglich den Namen der Datenbank in der Sicherungsdatei zweimal anpassen. Nun war die Datenbank gespiegelt.

Da sie aber einen anderen Namen hatte, und über andere Zugangsdaten verfügte, musste dies der kopierten Drupal-Instanz noch beigebracht werden. Auch dieser Schritt ist äußert trivial, indem man die entsprechenden Konfigurationswerte in web/sites/default/settings.php anpasst.

Zu guter Letzt sollte die gespiegelte Seite auch noch erreichbar sein. Dazu erstellte ich einfach eine Subdomain in der DNS-Verwaltung und ließ diese Subdomain im Webhosting-Panel auf den neu erstellten Root-Folder zeigen.

Ein kurzer Aufruf der neuen Subdomain gab die notwendige Gewissheit, dass die gespiegelte Seite läuft.

Upgrade der gespiegelten Drupal-Instanz

Jetzt ging es daran, die gespiegelte Instanz zu aktualisieren.

Dafür versuchte ich das zunächst Augenscheinliche: Ich lud den für das Upgrade extra erzeugten git-Branch mit git pull und git checkout in den Root-Folder der gespiegelten Instanz und rief anschließend composer install auf.

Dies zeigte jedoch recht rasch auf, dass es so einfach nicht geht. Drupal erklärte mir via Kommandozeile, dass das Upgrade nicht möglich sei, da die Seite nicht mehr unterstützte Core Module verwendet. Namentlich verhinderten die Module Color und RDF, deren Deinstallation in Teil 1 geschildert wurde, den erfolgreichen Upgrade-Prozess.

Das interne Update-Prozedere von Drupal 10 enthält offensichtlich eine Überprüfung, ob die zu aktualisierende Instanz keine "deprecated" Module und Themes mehr verwendet. In unserem Fall biss sich somit die Katze ein wenig in den Schwanz.

Upgrade in zwei Akten

Augenscheinlich mussten die nicht mehr unterstützten Module zunächst "deinstalliert" werden.

Zur Erinnerung: Deinstallieren bedeutet in diesem Kontext eigentlich nur ein Deaktivieren. Denn der Code der deaktivierten Module bleibt weiterhin im Verzeichnisbaum bestehen und wird durch das "Deinstallieren" nicht gelöscht.

Jedenfalls macht sich die Erfassung der Update-Schritte in einzelne Git-Commits an dieser Stelle bezahlt. Ich musste einzig den Hash des Commits, der die beiden Module "deinstalliert", mit git log suchen und mit git checkout auschecken.

Dann wiederholte ich das Prozedere mit composer install und diesmal war der Aufruf von Erfolg gekrönt. Selbstverständlich führte ich auch einen Import der Konfigurationsänderungen durch und applizierte nun neu hinzugekommene Datenbankupdates mit drush updatedb. So weit, so gut.

Anschließend machte ich mich abermals an das Offensichtliche. Ich lud den Commit, der Drupal auf Version 10 hebt, wiederum mit git checkout und führte im Anschluss composer install aus. Auch dieser Aufruf ging ohne Fehler und Warnungen vonstatten. Das neuerliche Importieren von Konfigurationsänderungen und das Einspielen der restlichen Datenbankupdates schlossen den Prozess ab.

Zu guter Letzt überzeugte ich mich vom Ergebnis und testete die gespiegelte Seite im Front-end sowie im Adminbereich. Zu meiner Freude präsentierte sich die Website für Besucher unverändert und ausprobierte Funktionen wie das Bearbeiten von Unterseiten funktionierte wie gewohnt.

Damit wusste ich, dass dieser zweiteilige Upgrade-Prozess höchstwahrscheinlich auch für die Produktivinstanz klappen würde.

Upgrade der Live-Seite

Mit einem sichereren Gefühl und daher relativ entspannt, machte ich mich daran, auch die Live-Instanz auf Version 10 zu heben.

Kurz und gut wandte ich den zweiteiligen Upgrade-Prozess, der sich beim Aktualisieren der gespiegelten Instanz herauskristallisierte, ebenso auf die Live-Instanz an.

Nach ein paar Minuten im Wartungsmodus war auch das Update des Echtbetriebs geschafft.

Das Entfernen der gespiegelten Website war der Abschluss eines aus meiner Sicht sehr gelungenen Aktualisierungsprozesses von Drupal 9 auf Drupal 10.

Fazit

Gute Planung und Vorbereitung ist die halbe Miete. Selbst wenn das Upgrade auf eine neue Hauptversion nach wie vor nicht vergleichbar ist mit dem Ein-Klick-Update von WordPress, so ist mit bedachter Arbeitsweise mittlerweile das Aktualisieren von Drupal ohne Bauchschmerzen und mit moderatem Zeitaufwand möglich.

Selbstverständlich muss man Entwickler- und teilweise auch Admin-Kenntnisse mitbringen. Aber eine professionelle Wartung ist beim Betrieb einer Drupal-Seite ohnehin anzuraten und Drupals Zielgruppe ist eben eine andere als die von WordPress.