Kunden-Websites aktualisieren #

Diese Seite ist für Systemadministratoren und Support-Verantwortliche bei einem Hoster, die viele Exponential-Installationen auf aktuellen Releases halten. Sie beantwortet: wie Sie herausfinden, welches Release jede Website betreibt, wie Sie Upgrades über Kunden hinweg planen, welche Schritte ein Upgrade innerhalb der Linie 6.0 umfasst, wie Sie das Ergebnis prüfen und wie Sie sich erholen, wenn ein Schritt scheitert.

Das Verfahren ist Kapitel 11, Upgrade des Installationsbuchs und die Anleitung Upgrade; diese Seite ordnet es für einen Hoster. Kunden, die von älteren Hauptversionen oder anderen Produkten kommen, stehen auf Kunden migrieren.

Inhalt #

1. Regeln vor allem anderen
2. Bestand erfassen
3. Das Upgrade pro Kunde planen
4. Das Upgrade innerhalb der Linie 6.0
5. Das Ergebnis prüfen
6. Wenn etwas schiefgeht
7. Checkliste

Regeln vor allem anderen #

• Führen Sie nie einen Installer über einer bestehenden Website aus. Der Setup-Assistent, der Kickstarter und exp:install legen eine neue Datenbank an. Ein Upgrade ersetzt den Code und aktualisiert die bestehende Datenbank an Ort und Stelle. exp:install verweigert den Lauf, wo eine Installation existiert; fügen Sie auf einer Live-Website nicht --force hinzu, um daran vorbeizukommen (11.1).
• Zuerst sichern, jedes Mal. Der Datenbankschritt ist der, der sich nicht durch Zurücklegen von Dateien rückgängig machen lässt.
• Als Benutzer der Website ausführen. Dateien, die root in var/ anlegt, beschädigen die Website später.
• Ein veröffentlichtes Release lässt sich nicht ändern. Der Weg zu einer Korrektur ist die nächste Version. Planen Sie, nach vorn zu gehen, nicht ein Release an Ort und Stelle zu flicken.

Bestand erfassen #

Halten Sie für jede Installation das Release, die PHP-Version, die Datenbank-Engine und den Webserver oder die Engine fest:

• In der Administration: Setup > Systeminformationen nennt die Version, PHP und den Server, der geantwortet hat.

• Auf der Kommandozeile: ./console exp:systeminfo --json.

• In der Datenbank die Zeile mit der Version (ihr Name behält absichtlich die historische Schreibweise):

  mysql -u USER -p DATABASE -e "SELECT name, value FROM ezsite_data WHERE name LIKE 'ezpublish-%';"

  Nutzen Sie den entsprechenden Client für PostgreSQL oder SQLite.

Welcher Teil der Anleitung gilt, ergibt sich aus der Version (Welchen Teil lese ich?):

Das Upgrade pro Kunde planen #

Tipp Gruppieren Sie Kunden nach ihrem aktuellen Release und danach, wie stark sie angepasst sind. Nicht angepasste Websites auf demselben Release können einem getesteten Runbook folgen; angepasste erhalten jeweils eine Staging-Kopie.

Das Upgrade innerhalb der Linie 6.0 #

Aus 11.6 Von jedem 6.0.x bis heute und Teil C:

1. Wartung an und ein frisches Backup:

   php bin/php/maintenance.php on --message="Upgrade in progress" --until=30m

2. Bringen Sie den neuen Code an seinen Platz: ein Checkout des neuen Tags oder composer update von se7enxweb/exponential in der composer.json des Projekts. Halten Sie settings/override/, settings/siteaccess/, Ihre Erweiterungen und Designs aus jedem Befehl heraus, der Dateien ersetzt. Dann:

   php bin/php/ezpgenerateautoloads.php -e
   php bin/php/ezcache.php --clear-all --allow-root-user

3. Spielen Sie das Datenbank-Update der Linie ein, einmal, vollständig, in Reihenfolge: update/database/<engine>/6.0/dbupdate-6.0.0-6.0.15.sql. Dateien gibt es für MySQL (auch für MariaDB genutzt), PostgreSQL und SQLite; die Dateien für Oracle kommen mit der Erweiterung ezoracle, und MongoDB braucht keine SQL-Datei (11.3 Je Engine).

   mysql -u USER -p DATABASE < update/database/mysql/6.0/dbupdate-6.0.0-6.0.15.sql

4. Führen Sie die Datenskripte der Linie einmal aus (einmal pro var-Verzeichnis, auf jedem Webserver eines Clusters):

   php update/common/scripts/6.0/createaudittables.php
   php update/common/scripts/6.0/movetrashrecords.php --remove-file

5. Eindeutige Anmeldenamen. Listen Sie Konten auf, die sich einen Anmeldenamen teilen, und fügen Sie den eindeutigen Index hinzu, wenn es keine gibt:

   ./console exp:user-login-check --allow-root-user
   ./console exp:user-login-check --fix-index --allow-root-user

6. Lesen Sie die Checkliste jedes Zeitraums, den Sie durchlaufen (Changelogs und Hinweise zu Verhaltensänderungen, aufgeführt in C3). Die Änderungen, auf die man am häufigsten trifft: Konten ohne Zeile in ezuser_setting können sich nicht anmelden; Overrides folgen Priority; Sicherheitsheader, Cookie-Merkmale und eine strengere Prüfung von Uploads sind standardmäßig an.

7. Prüfen Sie eigene Erweiterungen: ./console exp:checkclasses --allow-root-user meldet Klassen, die PHP nicht laden will.

8. Ausrollen: Laden Sie das PHP-FPM neu, das die Website ausliefert, oder führen Sie auf Velocity ./console exp:velocity deploy aus (Änderungen ausrollen). Leeren Sie nach dem Neuladen den Content-Cache und den Antwort-Cache von Velocity.

9. Wartung aus nach den Prüfungen unten.

Das Ergebnis prüfen #

php bin/php/ezcache.php --clear-all --allow-root-user     # ends without an error
./console exp:checkdbfiles --allow-root-user               # no file marked missing for your line

Dann im Browser: Die Startseite lädt; melden Sie sich in der Administration an; Setup > Systeminformationen zeigt die neue Version; veröffentlichen Sie ein Testobjekt und sehen Sie es auf der Website. Setup > Upgrade-Prüfung und Überprüfe Dateikonsistenz listen Dateien des Codes auf, die vom Release abweichen; absichtlich geänderte Dateien werden dort erwartet (Die Upgrade-Prüfung).

Wenn etwas schiefgeht #

Quelle: Wenn etwas schiefgeht.

Checkliste #

• To do: Bestand: Release, PHP, Datenbank-Engine und Server pro Website festgehalten.
• To do: Angepasste Websites auf einer aus einem Backup wiederhergestellten Staging-Kopie getestet.
• To do: Backup direkt vor dem Fenster erstellt; Dauer einer Wiederherstellung bekannt.
• To do: Code, Autoloads, Caches, Datenbankdatei, Datenskripte und Prüfung der Anmeldenamen in Reihenfolge erledigt.
• To do: Die Checklisten jedes durchlaufenen Zeitraums wurden gelesen.
• To do: PHP-FPM neu geladen oder Velocity ausgerollt; Content- und Antwort-Caches danach geleert.
• To do: exp:checkdbfiles, die Upgrade-Prüfung und eine Testveröffentlichung bestehen; der Kunde ist informiert.

Verwandte Seiten #

• PHP-Upgrade (Runbook)
• Von älteren Exponential-Versionen
• Automatische Updates mit ezupdate
• Wartungsmodus, Änderungen ausrollen
• Kapitel 11: Upgrade
• Migrationen auf gehosteten Sites, Migrationen
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.