Der Magento 2.2.x-Cache wird automatisch deaktiviert

Erstens konnte ich nirgendwo im Web Informationen zu dieser Art von Problem finden.

Wir haben eine Produktionsumgebung mit Git- Integration. Wir ziehen unsere Änderungen nur über Git ( Git Pull ).

Das Problem ist, dass Magento- Caches in einem der Schritte automatisch deaktiviert werden (alle Nullen beim Überprüfen des Cache: Status) . Dies verursacht ein Problem, wenn dies über den Programmierer übersehen wird, was zu einer weiteren Serverüberlastung führt, da ein hoher Datenverkehr ohne Cache auf das Magento übertragen wird.

Vielleicht haben einige von Ihnen dieses Problem schon einmal gesehen? Wir wissen nicht wann oder wie es genau passiert.
Und es erscheint irgendwie zufällig.

Übliche Schritte, die wir machen:

• Wartung ermöglichen
• Git Pull
• Komponisteninstallation (falls erforderlich)
• Modul aktivieren Vendor_ModuleName (falls erforderlich)
• Setup: Upgrade (falls erforderlich)
• statische Sachen löschen
• Bereitstellungsbefehl
• Caches löschen
• Opcache löschen
• Deaktivieren der Wartung

Ich würde mich über wertvolle Vorschläge freuen, die zur Lösung dieses Problems beitragen könnten.

Dies scheint ein bekanntes Problem zu sein :
Dies passiert gelegentlich bei dem Projekt, an dem ich arbeite, aber ich konnte die Schritte zur Reproduktion nicht finden. Ich kann nur sagen, dass dies während eines Bereitstellungsprozesses geschieht.
Ich konnte nur feststellen, dass unter bestimmten Umständen eine Datei .regeneratein den varOrdner geschrieben wird (entweder beim Setup-Upgrade oder bei der Installation / Aktualisierung von Composer). Wenn diese Datei beim Ausführen vorhanden ist, wird setup:di:compileder Cache deaktiviert und nach Abschluss des Kompilierungsprozesses wieder aktiviert.
Aus irgendeinem Grund wird der Cache manchmal nicht wieder aktiviert.
Wir haben den schnellen und schmutzigen Ansatz gewählt und den letzten Schritt des Bereitstellungsprozesses gemacht php bin/magento cache:enable, um sicherzugehen. Im Grunde haben wir den Dreck unter dem Teppich versteckt.

Den Code, der den Cache deaktiviert, finden
Sie hier. Er ist in eine TODO: removeAnweisung eingeschlossen.

Für alle Interessierten denke ich, dass ich etwas Licht in dieses Thema bringen kann. Es scheint ein Problem mit der Parallelität (Race Condition) in \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles zu sein, wenn das Flag var / .regenerate gesetzt ist und mehr als ein Prozess / eine Anforderung versucht, generierte Dateien zu bereinigen .

Es ist wahrscheinlicher, dass Cron aktiviert ist und viele Cron-Gruppen die Konfiguration use_separate_process verwenden. Wenn mehr als ein Prozess versucht, dasselbe zu bereinigen, schlägt FileIterator mit verschiedenen Meldungen fehl, die den folgenden ähneln:FilesystemIterator::__construct(/Users/adrianmartinez/Sites/r2-project-develop-b2b/environments/2-2-develop-b2b/magento/generated/code): failed to open dir: No such file or directory.

Wenn Sie den Anruf $this->write->delete(self::REGENERATE_FLAG);direkt nach der Überprüfung der Flag-Existenz nach oben verschieben, wird das Problem behoben, da sich der erste ankommende Prozess als für die Bereinigung von Dateien verantwortlich markiert.

Ich hinterlasse hier ein Demo-Video zum Replizieren des Problems : https://youtu.be/9-X1cIIY7y8

Und das dafür verwendete Skript:

#!/bin/bash

# \Magento\Framework\Code\GeneratedFiles has a concurrency problem
# Create regenerate flag and launch parallel commands that try to regenerate at the same time
# This is a real case, cron:run launches stand alone processes in parallel

# Created by magento composer installer upon code install or module enable/disable
touch var/.regenerate

# Launch parallel commands
# Error differs each execution, sometimes it even works
bin/magento cron:run --group=ddg_automation --bootstrap=standaloneProcessStarted=1 2>&1 &
bin/magento cron:run --group=index --bootstrap=standaloneProcessStarted=1 2>&1 &

wait
echo "All done"