Checkliste Serverumzug

Vorbereitung

Mit der Vorbereitung könnt ihr beliebig lange vorher anfangen, aber 2 Wochen Zeit solltet ihr euch mindestens geben. Euer Setup wird nicht auf Anhieb perfekt sein. Mal fehlen hier ein paar Rechte, dann benötigt man doch noch ein weiteres PHP-Modul. Vieles fällt erst bei ausgiebigen Tests auf.

Schritt 1: Webserver testen

Optimaler Weise habt ihr ein Skript für den Deploy auf eure Server. Dann müsst ihr das nur auf den neuen Server umstellen und die Software ausrollen. Andernfalls folgt eurer normalen Patch-Routine – nur eben in der neuen Umgebung.

Fangt mit euren UnitTests an. Dazu beim composer install das --no-dev weglassen, sonst habt ihr kein phpunit verfügbar. Je nach Code Coverage habt ihr jetzt schon mal alle PHP-Module im Einsatz gehabt. Laufen die Tests durch fehlt euch also keines mehr.

Schritt 2: Konfiguration Webserver

Ihr habt im Rahmen der UnitTests möglicherweise schon eine Konfiguration benötigt, müsst dies aber für den Web-Betrieb auf jeden Fall noch einrichten. In Symfony wäre das z. B. die parameters.yml.

Einzutragen wäre u. a. die neue Datenbankverbindung und Zugang zu den anderen Diensten, die ihr noch laufen lasst.

Schritt 3: Erste Tests im Browser

Ihr könnt für die ersten Tests eine (Sub-)Domain einrichten lassen (DNS-Eintrag) oder über eure /etc/hosts (Windows: C:\Windows\System32\drivers\etc\hosts) den DNS für euren Browser definieren und sofort die „korrekte“ Domain verwenden.

Letzteres ist unbedingt zu bevorzugen. Mindestens für die letzten Tests kurz vorm Umzug. Damit kommt ihr so nah wie möglich an „echte“ Bedingungen. Insbesondere SSL-Zertifikate sind dann auch korrekt.

Ihr werdet wahrscheinlich noch nicht viel sehen, aber grundsätzliche Probleme am Webserver fallen jetzt auf.

Schritt 4: Datenbank aufsetzen

Ihr müsst User und Datenbank anlegen (lassen). Danach geht es dran den ersten Dump einzuspielen. Fangt erst mal nur mit dem Schema an. Wer ein Framework verwendet, kann natürlich dessen Funktionen einsetzen. Beispiel in Symfony:

Andernfalls vom alten Server einen Dump ziehen:

Jetzt mit scp die schema.sql auf den neuen Server verfrachten und per

einspielen. Jetzt sollte sich was im Browser tun. Ihr könnt ab hier zunächst mit Testdaten arbeiten. Schon mal die Registrierung testen, Bilder hochladen, …

Vollständiger Datenbank Dump

Früher oder später müsst ihr einen vollständigen Dump eurer Daten ziehen. Hier kann folgendes hilfreich sein:

Ihr könnt nach datenbank_name alle Tabellen auflisten, die ihr extrahieren wollt. Hier kann es hilfreich sein gezielt Tabellen auszulassen (z. B. Logs), denn die Zeitspanne zw. Start des Dumps und Ende des Einspielvorgangs ist eure Downtime. Also stoppt hier mit, damit ihr später euren Kunden ankündigen könnt wie lange die Seite nicht erreichbar sein wird.

Insbesondere, wenn ihr nicht alle Tabellen beim Datendump mitnehmt, solltet ihr vorher einmal das Schema einspielen.

Achtet unbedingt darauf, dass ihr eure Datendumps vom Slave zieht! Während des gesamten Vorgangs sind alle Tabellen gesperrt (table-lock) und damit eure Seite de-facto down, wenn ihr den Master verwendet.

Schritt 5: Weitere Services

Eure Seite sollte soweit schon einiges anzeigen. Zeit für die restlichen Services, die ihr laufen habt. Caches und Dienste für Textsuchen (Apache Solr, Elasticsearch, …) sollten sich aus euren Daten generieren lassen. Eine gute Gelegenheit die alten Skripte auf den neuesten Stand zu bringen.

Schritt 6: Shared Files, Benutzer-Inhalte

Zum Schluss müsst ihr noch die von allen Servern gemeinsam genutzten Dateien umziehen. Loggt euch auf dem neuen Server ein und synchronisiert mit

Wie lange das dauert hat keine Auswirkungen auf eure Downtime. 99 % der Dateien habt ihr soeben transferiert. Während der Umstellung haltet ihr mit dem selben Befehl die beiden Server synchron.

Weiter geht’s am Tag X