Magallanes / Mage Probleme

So, durch das Camp angefixt wollte ich mich damit nun endlich mal beschäftigen.

Ich hatte da so einige Probleme, angefangen das es offenbar zwei GitHub Quellen gibt.
Die neuere (magephp/magallanes) schmiss mir Exceptions entgegen, das habe ich aber erst später begriffen, da habe ich schon gewechselt auf die offensichtlich ältere (andres-montanez/magallanes), die wohl auch Leo und terminal42 verwendet.

Nach einigen sehr seltsamen Problemen die immer dann auftraten, wenn ich ein neues Deployment durchführte, kam ich endlich auf die Ursache:
Zend OpCache!
Dieses dumme Teil hat dafür gesorgt, das gar nicht die Backendseite neu geladen wurde, und dadurch die JS und CSS neu generiert wurden, sondern die kam aus dem Cache.

Jetzt muss ich also per mage den OpCache löschen. Das ist wohl offensichtlich ein Problem, denn wenn man den versucht den auf der Kommandozeile zu resetten, dann geht das wohl nicht, das muss wohl per http Aufruf geschehen, so konnte ich das jedenfalls lesen.

Wie nun mach ich das per mage? Ich habe den OpCache erstmal komplett deaktiviert, aber das kann ich nur auf dem Stage Server, nicht auf den Prod Server.

Es wird empfohlen eine Datei wie flush_cache.php anzulegen:

PHP-Code:

---

<?php
opcache_reset();
?>

---

und diese per curl beim Deploy aufzurufen.
Wichtig wohl ist auch das passend zu http / https zu tun, so wie später auch die Seite aufgerufen wird.

Dieses Script soll wohl besser sei, da es nur Dateien aus dem Cache nimmt, die laut filemtime neuerer sind als die im Cache.
bei "high loaded Server" wohl die bessere Variante.

PHP-Code:

---

<?php
if (!function_exists('opcache_get_configuration')) { die('OPCache is not installed/running');}
$data = opcache_get_status();
$expired = array();

if (empty($data['scripts'])) { die('no cached files');}

foreach ($data['scripts'] as $file)
{
  if ( !empty($file['timestamp'])
    && !empty($file['full_path'])
    && (!file_exists($file['full_path']) || (int)$file['timestamp']<filemtime($file['full_path']))
     )
  {
    $expired[]=$file['full_path'];
    @opcache_invalidate($file['full_path'], true); // @ Prevent Warning: Zend OPcache API is restricted by "restrict_api" configuration directive ....
  }
}
echo count($expired),' deleted';

---

Wer hier noch mit liest :D, normalerweise ist das definiert

Code:

---

opcache.revalidate_freq = 2
opcache.validate_timestamps = 1

---

bedeutet, das nach 2 Sekunden bei Aufruf eines Scriptes im Cache geprüft ob, dieses erneuert wurde.
Ein Cache löschen bei Update der Datei erübrigt sich somit.

Problem, wenn ich per "mage" ein Deploy mache, und die app.php hat sich nicht geändert, dann wird logischerweise diese doch wieder aus dem Cache genommen.

Dann wäre es doch eine gute Idee, einfach per "touch app.php" den Zeitstempel zu erneuern.
Oder? Andere Ideen?

Nachtrag: Es wäre ja so schön gewesen, aber nach Aufruf von contao/login sind 427! Dateien im Cache. Und natürlich geht es jetzt wieder schief.
Ist das ne K*cke.

Habe mir mal eine OpCache GUI installiert, die Dateien im Cache werden ja mit absoluten Pfaden im Speicher gehalten.
Dann müsste doch der OpCache mitbekommen, das die Datei, welche auch immer, aus einem neuem Verzeichnis kommt?

Wie soll das funktionieren?

Das ist ein bekanntes Problem von opcache, dass dieser nicht mit einem symlink deployment klarkommt:

http://codinghobo.com/opcache-and-sy...d-deployments/

Ach was bin ich froh, das Uberspace die obcache_... Funktionen nicht gesperrt hat.
So kann ich nun wählen ob ich per "reset" den Cache für alle meine Domains löschen will oder per "invalidate" nur für eine bestimmte Domain.

Dann kann ich ja nun weiter spielen mit Magallanes. :)

Die laufen aber nicht unter der gleichen Instanz. Also ich glaube nicht, dass du so zum Ziel kommst.
Ich nutze https://github.com/Smart-Core/AcceleratorCacheBundle dafür :)

Also bei Uberspace ist das so, dass je Nutzer Account, auf dem ich z.B. 2 Domains laufen lasse, ein eigener PHP Prozess läuft. Den kann ich sogar killen, der wird dann automatisch wieder gestartet.
Über https://github.com/rlerdorf/opcache-status habe ich mir mal auflisten lassen, was da so drinliegt. Und wie erwartet nur Dateien von meinen beiden Domains.
Da ich die über den absoluten Pfad filtern kann, gehe ich nun mit foreach durch den ganzen Cache und setze alle Dateien darin die passend sind auf invalidate.
Das habe ich zwar gestern erst bei mir lokal probiert, auch darin laufen mehrere Domains, aber auf Uberspace sollte das auch gehen.

Der Trick von https://github.com/Smart-Core/AcceleratorCacheBundle ist ja der gleiche, ich rufe auch per http eine Datei auf dem Zielserver auf, der dann die Cache Angelegenheiten ausführt.
Aber schaue ich mir auch mal an. Danke.

Ich bin auch gerade kurz vor dem Durchbruch bei meinem ersten mage-Deploy.

Momentan bricht der Composer mit einem FAIL ab. Laut log besteht ein Fehler:

Code:

---

Generating optimized autoload files > Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication Script Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication handling the post-install-cmd event terminated with an exception [RuntimeException] An error occurred while executing the "contao:install-web-dir" command: In Kernel.php line 765:
Unable to create the logs directory /home/gestalt/home/gestalt/public_html/app/contao/releases/20180529085903/var/logs)
install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...  [] []
[2018-05-29 09:01:05] magephp.DEBUG: Task [Composer] Install (composer/install) finished with FAIL [] []

---

Wenn ich das richtig sehe scheitert es an dem Pfad da "/home/gestalt/" doppelt drin ist.
Weiß aber nicht wo ich das in meiner mage.yml dies beeinflussen kann.