Apache gegen nginx tauschen

Mehr tippen Sie nicht

„Ersetze auf intranet01 den Apache durch nginx, PHP über php-fpm. Alle drei Seiten müssen danach unter denselben Adressen laufen, mit ihren Zertifikaten.“

Wer: Der Admin, an einem ruhigen Nachmittag
Server: intranet01, Apache mit drei Seiten und PHP
Ihr Anteil: Ein Satz, den Plan lesen, eine Freigabe
Stufe: rw- Fragt vor Änderungen, siehe die drei Stufen

Problem

Auf intranet01 läuft seit Jahren ein Apache mit mod_php: Intranet, Wiki und Zeiterfassung, dazu eine Konfiguration, an der viele Hände waren. Jede Verbindung kostet einen Prozess mit PHP im Bauch, der Speicher wird knapp, und niemand weiß mehr genau, welche Regel in welcher .htaccess wofür da ist. Der Wechsel auf nginx mit php-fpm steht seit einem Jahr auf der Liste, weil er einen Nachmittag Lesen kostet und beim Umschalten etwas schiefgehen kann.

Gesucht: nginx und php-fpm statt Apache, dieselben drei Adressen mit denselben Zertifikaten, höchstens Sekunden ohne Antwort, und ein Weg zurück.

Lösung

Ein Satz, und Heinzel Pro liest den Apache aus, schreibt die Serverblöcke, zeigt den Plan und schaltet nach Ihrer Freigabe um. Apache bleibt installiert, nur aus.

Schritt 1: Sie sagen, was danach gelten soll

Der Satz oben nennt das Ziel und die Bedingung: dieselben Adressen, mit Zertifikaten. Sie wählen intranet01 und lassen die Stufe auf „Fragt vor Änderungen“: Lesen läuft allein, der Umbau wartet auf Sie.

Eine neue Session in Heinzel Pro: der eingetippte Satz zum Tausch von Apache gegen nginx, darunter der gewählte Server intranet01 und die Stufe „Fragt vor Änderungen“

Schritt 2: Heinzel Pro liest den Apache aus

Drei lesende Befehle: welche virtuellen Hosts es gibt, welche Module und Zertifikate, und ob eine .htaccess Regeln enthält. Dann steht der Befund: drei Seiten über mod_php, Zertifikate von Let's Encrypt, vier Rewrite-Regeln im Wiki, php-fpm noch nicht installiert.

Die Session: drei lesende Befehle mit ihrer Ausgabe, die virtuellen Hosts, Module und Zertifikate, die .htaccess des Wikis, darunter die Antwort von Heinzel Pro mit dem Befund und dem Vorhaben

Schritt 3: Sie lesen den Plan und geben ihn frei

Vier Schritte, jeder mit Befehl und Einstufung: installieren, Serverblöcke einschalten und prüfen, umschalten, die drei Seiten abrufen. Dazu, was schiefgehen kann, zwei Sekunden ohne Antwort oder eine fehlende Wiki-Regel, und der eine Befehl zurück. Ein Klick gibt alle vier frei; sie laufen in dieser Reihenfolge, jeder erst, wenn der vorige gelang.

Der Plan in der Session: vier Schritte mit Befehl, Server und Einstufung, darunter was schiefgehen kann, wie es zurückgeht, und der Knopf „Plan freigeben“

Schritt 4: Heinzel Pro schaltet um und schreibt auf, wie es zurückgeht

Die Seiten waren zwei Sekunden nicht erreichbar, dann antworten alle drei mit 200 über nginx. Apache ist aus, aber installiert; der Weg zurück steht im Journal von intranet01, zusammen mit dem Hinweis, dass die Regeln des Wikis jetzt im Serverblock stehen und nicht mehr in der .htaccess.

Die Session danach: die vier gelaufenen Befehle mit Dauer und Ausgabe, die drei Seiten mit 200, der Journaleintrag für intranet01 und die Abschlussmeldung von Heinzel Pro