it-swarm.com.de

Eine schnellere Methode zum Bereitstellen statischer Inhalte in Magento 2? Dev zu leben etc?

Das ist meine Umgebung. Bitte beachten Sie, dass dies auch in den entsprechenden Entwicklungsmodi und Produktionsmodi festgelegt ist.

Dev:
https://ar.dev.loc/
https://en.dev.loc/

Live:
https://ar.site.com/
https://en.site.com/

Ich verwende ein Multi-Store-Setup mit Arabisch und Englisch, und alles funktioniert gut, einschließlich der Erstellung von Modulen und dem Erstellen von Vorlagen.

Wenn ich jedoch Änderungen an weniger Dateien oder JS-Dateien vornehme (trotz der Verwendung von "grunt less" oder "grunt watch"), muss ich die folgenden Befehle in meiner Entwicklungsumgebung ausführen, um sie auf meinem lokalen Computer anzuzeigen.

$ rm -rf var/cache var/page_cache var/view_preprocessed pub/static
$ mkdir pub/static
$ bin/magento setup:static-content:deploy
$ bin/magento setup:static-content:deploy ar_SA
$ grunt exec less // sometimes I leave this do this
$ grunt // I swap between these

Dies dauert jedes Mal sehr lange. Es ist frustrierend, da ich ein schneller Codierer bin und CSS und Less sofort auf der Website sehen und nicht warten muss.

Der schnelle Ansatz unseres Teams besteht darin, Änderungen an pub/static vorzunehmen. Diese werden dann an less und app/design usw. gesendet. Anschließend führen Sie den oben beschriebenen Prozess aus und dann git.

Live Server ist so ziemlich das Gleiche. Git ziehen und dann Wartungsmodus (Wahnsinn auf einer Live-Ecom-Site! Wer baut M2? Dann führen wir die obigen Befehle aus - Ausfallzeit von 45 Minuten).

Sicher muss es einen schnelleren Weg geben, damit unsere Bereitstellung, Entwicklung und unser Team besser funktionieren und Änderungen schneller ohne Ausfallzeiten sehen können!

Sogar die offizielle Dokumentation von Magento 2 besagt, dass Ihre LIVE-Site in den Wartungs- und Ausfallmodus versetzt werden muss, um Inhalte zu veröffentlichen. Dies ist für uns keine Option. Die CTO sind nicht glücklich. Einfach absurd

Verwandte Fragen, bei denen die Leute nach schnelleren, gleichen Themen fragen:

Css-Änderungen werden nur nach dem Bereitstellungsbefehl in magento2 berücksichtigt

Magento 2 statischer Cache

Änderungen an CSS und JavaScript gelten nur nach der Bereitstellung statischer Inhalte

Ich möchte also alle Probleme zusammenfassen und das Problem lösen.

27
TheBlackBenzKid

ja, es kann durch folgende Schritte schneller sein: 

  1. Ändern Sie in Ihrer js/css-Datei im App-Verzeichnis
  2. Löschen Sie nun den Dateiformat pub/static Ordner 

sie können die Datei in pub statisch finden, indem Sie den folgenden Befehl ausführen 

find pub/static -iname yourjsfile.js
  1. entfernen Sie nur die Datei, in der Sie Änderungen aus dem Ordner pub/static vorgenommen haben 
  2. stellen Sie sicher, dass pub/static.htaccess file & pub/static.php file vorhanden ist 
  3. weisen Sie dem Ordner pub Datei Schreibrechte zu
  4. klicken Sie jetzt auf die URL im Browser. Htaccess wird die fehlende JS-Datei direkt bereitstellen

.htaccess in pub/static schickt die fehlenden Dateien an pub/static.php mit dem Parameter resource und pub/static.php erstellt eine StaticResource für die Datei, falls verfügbar, und bereitstellen.

Hinweis: Dies funktioniert nur mit ApacheMod_rewrite

Für Nginx müssen Sie dasselbe über nginx.conf.sample konfigurieren.

13
Emizen Tech

Da ich die Option -j(--jobs) zum Verzweigen eines neuen Prozesses verwende, reduziere ich die static-content:deploy-Zeit von über 10 Minuten auf weniger als eine Minute. Siehe Magento/Deploy/Process/Queue.php

php bin/magento setup:static-content:deploy -j[JOBS_AMOUNT]

Die Option --jobs ermöglicht die parallele Verarbeitung mit der angegebenen Anzahl von Jobs. Der Standardwert ist 4. Um zu bewirken, dass die Task in einem Prozess ausgeführt wird (zum Beispiel, wenn Ihr System Prozessforking nicht unterstützt), verwenden Sie --jobs 1. // siehe: devdocs.magento.com

Diese Option kann nur verwendet werden, wenn pcntl aktiviert ist.


pcntl

Es sind keine externen Bibliotheken erforderlich, um diese Erweiterung zu erstellen.

Die Prozesssteuerungsunterstützung in PHP ist standardmäßig nicht aktiviert. 

Sie müssen die CGI- oder CLI-Version von PHP mit der Konfigurationsoption --enable-pcntl kompilieren, wenn Sie PHP kompilieren, um die Prozesssteuerungsunterstützung zu aktivieren.

Hinweis: Derzeit wird dieses Modul auf Nicht-Unix-Plattformen (Windows) nicht funktionieren.

Hinweis: that pcntl_fork funktioniert not nicht, wenn PHP als Apache-Modul ausgeführt wird. In diesem Fall ist diese Funktion nicht vorhanden!

3
Nolwennig

Allgemeiner Kommentar:

Sie müssen hier nicht "grunzen", während Sie setup: static-content: deploy ausführen. Sie können den statischen Inhalt für en_US (d. H. Ohne Parameter) und ar_SA parallel generieren (mit bash können Sie dies ganz leicht tun).

Wenn Sie (sichere) HTTPS-Ressourcen vermissen (möglicherweise war das der Grund, warum Sie zusätzlich Grunt verwendet haben?), Stellen Sie sicher, dass die Umgebungsvariable "HTTPS" (z. B. HTTPS=ON) für den Prozess festgelegt ist, der statischen Inhalt ( ref ) kompiliert.


Abgesehen davon braucht es ja Zeit. Aufgefallen ist, dass die PHP weniger-Kompilierung einige Zeit in Anspruch nimmt. Eine Idee, die mir in den Sinn kam, als ich von einem anderen Entwickler erfuhr, war, weniger Kompilierung in einem lokalen Cache zu speichern und nur dann neu zu kompilieren, wenn sich eine Datei tatsächlich ändert. Vielleicht kannst du das auch versuchen.

Ich bin noch nicht dafür verantwortlich, einen PoC gemeinsam dafür zu hacken, aber ich denke, es sollte ein guter Test für die Behauptung sein, dass die geringere Kompilierung der Engpass ist.

Ich kann auch dringend vorschlagen, einen Build-Server auszuführen, der automatisch auf git Push kompiliert, um die Belastung zu verringern.

2
hakre

Ich bin nicht mit Magneten vertraut, aber das kann für Sie funktionieren. Wenn ich meine Websites aktualisiere, folge ich diesen Schritten:

Angenommen, die Site befindet sich im Verzeichnis site

$ cp -r site site-update

# update the site in site-update directory

$ mv site site-old && mv site-update site

Auf diese Weise werden meine Websites ohne Ausfallzeiten aktualisiert.

2
napuzba

Ich habe setup:static-content:deploy schon eine Weile nicht mehr berührt. Nachdem ich den langsamen Bereitstellungsprozess in Magento 2 satt geworden war, habe ich mir einen eigenen gemacht, der es mir ermöglicht, Änderungen in einer CSS- oder JS-Datei vorzunehmen und diese fast sofort auf der Website anzuzeigen. Hier ist die Magie:

cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME
find * -type f \( -name "*.css" -o -name "*.js" \) -cmin -10 | xargs -I {} bash -c 'dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web\/|\/[^/]+$)//g"); echo Deploying {} to $dest ...; mkdir -p $dest && cp {} $_'
cd - 1> /dev/null

Lass es uns brechen ...

  1. cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME - Wechseln Sie in das aktive Designverzeichnis (ersetzen Sie $VENDOR und $THEME durch Ihre eigenen Werte).
  2. find * -type f \( -name "*.css" -o -name "*.js" \) -cmin -10 - findet alle CSS- und JS-Dateien, die innerhalb der letzten 10 Minuten innerhalb des Designverzeichnisses geändert wurden (* entfernt den führenden ./ in den Ergebnissen); Sie können die Parameter beliebig an Ihre Bedürfnisse anpassen
  3. xargs -I {} bash -c - Führen Sie für jede geänderte Datei die Befehle in # 4-6 aus (der relative Pfad zur geänderten Datei wird in {} gespeichert)
  4. dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web\/|\/[^/]+$)//g") - Legen Sie den Pfad für das Implementierungsziel fest
    • der * glob sorgt dafür, dass das von Ihnen verwendete Gebietsschema
    • $(...) erzeugt eine Subshell, um nur den Teil des Quellpfads zu extrahieren, den wir an den Zielpfad anhängen müssen (web-Verzeichnisebene ist unter pub nicht vorhanden)
  5. echo Deploying {} to $dest ... - protokollieren Sie die Aktivität in der Konsole, damit Sie wissen, welche Dateien bereitgestellt werden
  6. mkdir -p $dest && cp {} $_ - Zielverzeichnisstruktur erstellen; Wenn und nur wenn die Verzeichnisstruktur erfolgreich erstellt wurde, kopieren Sie die geänderte Datei in ihr Implementierungsziel unter pub ($_ zeigt auf das letzte Argument des vorherigen Befehls, mkdir, das $dest ist)
  7. cd - 1> /dev/null - Wechseln Sie zum vorherigen Verzeichnis, um dort fortzufahren, wo Sie aufgehört haben

Sie können dies alles in einen Alias ​​werfen, um es auf einen Befehl zu reduzieren. Denken Sie jedoch daran, die einfachen Anführungszeichen zu vermeiden:

alias update='cd /path/to/docroot/app/design/frontend/$VENDOR/$THEME; find * -type f \( -name "*.css" -o -name "*.js" \) -cmin -10 | xargs -I {} bash -c '"'"'dest=/path/to/docroot/pub/static/frontend/$VENDOR/$THEME/*/$(echo {} | sed -E "s/(web\/|\/[^/]+$)//g"); echo Deploying {} to $dest ...; mkdir -p $dest && cp {} $_'"'"'; cd - 1> /dev/null'

Wenn Sie Lack verwenden, sollten Sie einen Befehl hinzufügen, um Lack am Ende des Alias ​​neu zu starten (z. B. Sudo service varnish restart). Andernfalls werden statische Assets wahrscheinlich immer noch zwischengespeichert.

Wenn Sie zu ungenau sind, jedes Mal, wenn Sie eine Änderung vornehmen, update einzugeben, können Sie sie in einen cron einfügen oder in eine grunt-Überwachungsaufgabe oder ein gleichwertiges Element integrieren.

2
thdoan

In unserem Unternehmen verwalten wir Magento2-Implementierungen mithilfe von Capistrano . Außerdem gibt es ein spezifisches Set für Magento 2 , das sehr gut funktioniert.

Mit capistrano konfigurieren Sie Ihr Webserver-Stammverzeichnis so, dass es auf einen Symlink verweist, der auf einen "Release" -Ordner verweist. Wenn Sie eine Bereitstellung starten, werden alle Kompilierungen (di, statische Inhalte, ecc) in einem separaten Ordner durchgeführt, sodass Ihre Online-Website nicht betroffen ist und online bleibt. Am Ende des Vorgangs und nur wenn keine Fehler vorliegen, wird der Symlink auf die neue Version umgestellt.

Auf diese Weise beträgt die Ausfallzeit normalerweise null oder wird auf wenige Sekunden reduziert.

Capistrano bietet auch eine grundlegende "Rollback" -Funktion, mit der Sie schnell zu einer alten Version zurückkehren können, wenn etwas schief geht.

2
Mir

Ich habe auch bemerkt, dass, wenn Sie css und js angemeldet haben, es scheinbar verrückt wird, wenn Sie das Setup-Upgrade ausführen. Dann bricht die Version und die css/js werden gelöscht, bis Sie den statischen Inhalt neu erstellen.

Ich habe keine Ahnung, wie sie denken, dass dies für die Menschen in der Produktion funktionieren sollte. Fast alles kann es aus dem Gleichgewicht bringen und Sie müssen neu bauen.

Ich hatte ein bisschen Glück mit 1. Aktivieren Sie die Anmeldung für css/js 2. dann kannst du statischen inhalt bereitstellen, scheint den ur ziemlich intack zu halten 3. Cache leeren (fügt dann den statischen URLs die neue Version12312312 hinzu)

Aber im Ernst, es gibt keine Möglichkeit, mit Implementierungen absolut solide zu sein. 

TheBlackBenzKid sehr kurios, wo du ein Jahr später gelandet bist, hast du Magento abgeladen?

0

Ich bin mit einer Lösung für dieses Problem gekommen.

Sie müssen den Inhalt des von Ihnen gewünschten Shops veröffentlichen 

php bin/magento setup:static-content:deploy [lang(en_US)] -t [vendor]/[theme]

Ich werde mich nicht ändern, weil der Magento-Cache gelöscht wird. Löschen Sie ihn einfach manuell

rm -rf pub/static/_*/*

php bin/magento cache:flush; php bin/magento cache:clean;

Nach dem Aktualisieren Ihrer Seite werden nun die neuen Änderungen übernommen, wenn die Seite neu erstellt wird.

Diese Schritte sind obligatorisch für Änderungen in HTML und statischen Inhalten. Layoutänderungen erfordern eine Cache-Bereinigung, und Änderungen an Controllern sind ein Ärgernis, da Sie di: compile verwenden müssen, um die Produktion zu beenden.

0
Yeison Agudelo