Dieses Tutorial ist VALID.

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

Docker Image upgraden – wie gehen wirs an?

Hin und wieder gibt es nicht nur Updates, sondern Upgrades für unsere Anwendungen oder Umgebungen. PHP ist da so ein Fall. Aktuell ist der Umstieg von v7.3 auf v7.4 fällig…

In diesem Artikel beleuchten wir, wie wir bei einem Upgrade vorgehen und wo wir die Änderungen einpflegen…

To Update or not to Update – that’s the question…

Alle hier verwendeten Images bauen auf einem „debian + apache + php“ Stack auf. Für diesen gibt es von Zeit zu Zeit Updates, gerade für PHP. Die sind teilweise auch gar nicht so ohne. Sprich keine „Feature“, sondern „Security“ Updates! Die wichtigste Anlaufstelle hierfür ist php.net. Dort findet sich rechts oben ein Block mit den jeweils aktuellen PHP Versionsnummern und einem Link auf die „Release Notes“, was sich bei dem jeweiligen Aufstieg geändert hat. Diese Seite hab ich zum Beispiel in meiner Browser Autostart, damit ich täglich sehe, ob hier dringender Updatebedarf besteht.

Wenn sich „nur“ an einer Unterversion etwas ändert (x.x.x => x.x.y) ist das noch das einfachste Update, denn wir brauchen dann im Endeffekt nur das jeweilige Image neu bauen. Docker zieht sich dann automatisch das zugrunde liegende Basis-Image in der aktuellen Fassung und unser Anwendungsimage wird zusammen mit der neuen PHP Version erstellt.

Interessanter ist ein Versionswechsel bei WordPress, Nextcloud oder Matomo. Hier müssen wir das jeweilige Dockerfile bearbeiten und dort die aktuelle Versionsnummer an der korrekten Stelle eintragen. Bei WordPress brauchen wir zusätzlich noch einen Hashwert, der zu der Version gehört, um die Dateiintegrität nach dem Download prüfen zu können.

Haben wir die neue Versionsnummer drin, bauen wir das Image neu. Dabei wird dann die aktuelle Version der Anwendung geladen und ins Image installiert.

Diese Thematik ist im Kapitel „Unseren Docker Stack updaten“ schon behandelt…

Upgrade auf eine neue Version

Richtig interessant wird dann der Umstieg auf einen anderen PHP Zweig. Hier gerade geschehen von v7.3.14 auf v7.4.2. Das Problem dabei ist, dass wir hier erst schauen müssen, ob unsere Anwendungen überhaupt mit der neuen PHP Version umgehen können und ob diverse Änderungen im Dockerfile nötig sind. Manchmal läuft der Umstieg ohne jede Änderung problemlos, manchmal muss man das halbe Dockerfile umbauen. Und Nextcloud 17.0.2 läuft zum Beispiel noch gar nicht mit PHP 7.4.x. Da kommt nur ein dezenter Hinweis, dass die Version dazu nicht kompatibel ist – und Ende.

Mischumgebungen könnten wir ohne Docker auch gleich komplett vergessen. Aber mit Docker können wir WordPress und Matomo auf PHP 7.4 fahren, während Nextcloud noch PHP 7.3 bekommt. Das ist phantastisch. Und gruselig. Aber in erster Linie phantastisch :)

Wie genau gehen wir jetzt vor?

Hier zeige ich das mal beispielhaft beim Umstieg von PHP 7.3 auf 7.4 anhand von WordPress:

Unsere erste Anlaufstelle ist Github. Dort laden wir für die zwei PHP Versionen jeweils das Dockerfile herunter und vergleichen beide Dateien auf Änderungen.

Ich verwende dazu den Notepad++ mit dem „Compare“ Addon. Das sieht dann so aus:

Das Basis-Image ändert sich in Zeile 1 von php:7.3-apache auf php:7.4-apache – aber das war uns ja fast klar :)

Wichtig ist dann die Änderung an der gd Konfiguration in Zeile 26: Hier wird der „png“ Teil völlig entfernt und bei „jpeg“ und „freetype“ die Verzeichnisse gekappt. Der komplette Rest der Datei ist unverändert. Also ein recht einfacher Umstieg.

Ich persönlich mache für jede neue PHP Haupt- und Nebenversion ein neues Verzeichnis für die Docker-Steuerdatei. Sollte der unwahrscheinliche Fall eintreten, dass die neue PHP Version mit der Anwendung doch nicht so super funktioniert, können wir nämlich ganz schnell zurück auf unser vorheriges Image und alles läuft wieder wie gehabt. Auch das ist nur dank Docker möglich und würde uns auf einem „normalen“ System vor unlösbare Probleme stellen. Da müssten wir unser komplettes System per Snapshot sichern und dann global zurück, falls es Probleme gibt. Aber mit Docker geht das zum Glück für jedes Image einzeln und unter einer Minute…

cp -a ~/docker/wordpress-php73-apache ~/docker/wordpress-php74-apache

Dieser Befehl kopiert uns das php73 Verzeichnis 1:1 in ein neues php74 Verzeichnis. Nun laden wir die Entrypoint-Datei nach und passen dann das Dockerfile an:

wget -qNP ~/docker/wordpress-php74-apache https://raw.githubusercontent.com/docker-library/wordpress/master/php7.4/apache/docker-entrypoint.sh

nano ~/docker/wordpress-php74-apache/Dockerfile

Wir ändern dort das Basis Image auf php:7.4-apache und passen die „gd“ Konfiguration entsprechend an, wie wir es beim Vergleichen der Dockerfiles gesehen haben. Anschließend speichern wir die Datei und starten den Bau des neuen Images:

docker build -t wordpress-php74-apache:5.3.2 ~/docker/wordpress-php74-apache
docker tag wordpress-php74-apache:5.3.2 wordpress-php74-apache:latest

Jetzt haben wir zwei WordPress Images, eins mit php-7.3 und das neue mit php-7.4, beide jeweils auch als „latest“ getagged.

Nachdem das Image gebaut wurde, müssen wir die docker-compose.yml Datei von WordPress anpassen, um das neue Image aus der 7.4er Reihe zu laden. Das steht ja noch auf Version 7.3…

nano /var/www/wordpress/docker-compose.yml

##Start
version: '3'
services:

 wordpress:
  image: wordpress-php74-apache:latest
  container_name: wordpress
  restart: always
...

Hier ändern wir in Zeile 8 nur php73 auf php74 und speichern.

Nun lassen wir den Container neu starten und steigen damit auf unser PHP 7.4er Image um:

docker-compose -f /var/www/wordpress/docker-compose.yml up -d

Wir öffnen unser WordPress im Browser und sehen nach, ob unser neues Image auch mit den gewünschten Versionen am Start ist…

PHP v7.4.2 – yay ;)

Läuft alles wie geplant, können wir das 7.3er Image löschen, um Platz auf der Festplatte freizugeben. Dazu zeigen wir die Images mit „docker images“ an und löschen anschließend das 7.3er Image mit seiner ID: „docker rmi <id>“.

Treten aber unerwartete Fehler und Probleme auf, ändern wir in der docker-compose.yml einfach php74 zurück auf php73 und starten den Container neu. Und schon funktioniert wieder alles wie gewohnt…

Fazit

Ein Upgrade ist nicht ganz so einfach wie ein Update, aber mit etwas Vorbereitung kein unlösbares Unterfangen. Das Schönste daran: Dadurch, dass wir parallel ein „neues“ und „altes“ Image haben, können wir bei einem Fehler schnell und einfach zurück auf unseren alten Stand und die Anwendung läuft wieder normal.

Dann gehen wir auf Fehlersuche. Aber entspannt und nicht unter Druck :)

Anzeige *

Kommentar verfassen

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

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top