Magento 2-Bereitstellungsprozess

8

Derzeit legen wir composer.lockdas Repository fest und führen es dann composer install --no-devauf dem Produktionsserver aus. Ich denke nicht, dass dies der beste Weg ist, da es einige Minuten dauert, bis der Komponist alle Dateien generiert, und es ist riskant.

Ich frage mich, ob es besser ist, alle Dateien, die für die Ausführung im Produktionsmodus benötigt werden, auf das Repo zu übertragen.

Wie verwalten andere den Bereitstellungsprozess mit Magento 2?

magento2 composer deployment

— Claudiu Creanga
quelle

Warum ist es riskant? Dies muss nur einmal pro Installation / Einrichtung durchgeführt werden, und sobald der Komponist ein Paket heruntergeladen hat, wird es zwischengespeichert.

— user3668514

Vielleicht fehlt mir etwas, aber wenn Sie den Herstellerordner nicht im Repository haben, wie würden Sie neue Module installieren, ohne sie composer installin der Produktion auszuführen? letcodejavascript.com/v3/blog/2014/03/the_npm_debacle

— Claudiu Creanga

Der Punkt ist zu rennen composer install. Haben Sie sich einen Git-Hook angesehen, um den Prozess zu automatisieren?

— user3668514

@ user3668514 Was ist, wenn beim Ausführen der Composer-Installation in der Produktion einige Remote-Pakete nicht verfügbar sind, wie dies bei npm der Fall war?

— Claudiu Creanga

Wie oft passiert das? Magento2 wird jetzt mit einem .gitignore geliefert, der unter anderem den Anbieter explizit ignoriert. Da dies der neue 'Magento-Weg' ist,

— folge

5

Stimmen Sie zu 100% mit claudiu-creanga überein, dass Sie den Anbieter nicht verpflichten und vermeiden, dass die Composer-Installation in der Produktion ausgeführt wird.

Wir haben damit umgegangen, indem wir einen Live-Ordner und einen Release-Candidate-Ordner haben. Im Release-Candidate-Ordner führen wir Git-Pull-Befehle und die Composer-Installation --no-dev aus. Unser Prozess kann folgendermaßen zusammengefasst werden:

Im Release-Candidate-Ordner:
- Suchen Sie nach unerwarteten Änderungen
- Repo aktualisieren
- Composer installieren
Synchronisieren Sie Dateien mit dem Live-Site-Ordner
Im Live-Site-Ordner:
- Stellen Sie statische Dateien bereit
- Aktivieren Sie den Wartungsmodus
- Module aktivieren
- Führen Sie Setup-Skripte aus
- Kompilieren Sie DI
- Cache leeren
- Deaktivieren Sie den Wartungsmodus
- Berechtigungen aktualisieren

Ich habe einen längeren Blog-Artikel geschrieben, in dem die tatsächlichen Befehle und Gründe dafür aufgeführt sind: https://www.c3media.co.uk/blog/c3-news/deploying-magento-2-production-environment/

UPDATE: Wir kopieren jetzt die Live-Datenbank in eine Staging-Datenbank und verwenden diese, um Setup-Skripte auszuführen, statische Dateien bereitzustellen und DI alle offline zu kompilieren. Dies kann dann live bereitgestellt werden, einschließlich pub / static-Dateien und var. Wir nehmen die Site immer noch kurz herunter, wenn Setup-Skripte ausgeführt werden, aber ansonsten bleibt die Site offen. Weitere Informationen finden Sie unter https://www.c3media.co.uk/blog/c3-news/magento-2-deployment-without-downtime/

UPDATE: Ich habe meine Meinung über das Festschreiben des Herstellerordners geändert. Durch das Festschreiben des Ordners können Sie den Verlauf der Änderung dieser Dateien verfolgen, feststellen, ob Sie versehentlich etwas geändert haben, und vor allem vermeiden Sie, Composer ausführen zu müssen zur Bereitstellungszeit. Letzteres ist jetzt von entscheidender Bedeutung, da wir uns auf externe Lieferanten von Repositories verlassen. Was ist, wenn einer von ihnen nicht verfügbar ist? Plötzlich können Sie nicht mehr bereitstellen. Die Nachteile sind ein größeres Repository, das Risiko, Core-Hacks zu begehen, und die Knie-Ruck-Distanz von Entwicklern wie mir :)

— Robert Egginton
quelle

Wir haben auch damit begonnen, app / etc / config.php festzuschreiben. Dies wird vom .gitignore von Magento 2 standardmäßig ignoriert. Durch Festschreiben dieses Aktivierens und Deaktivierens wird dies jedoch während der Entwicklung vorgenommen. Diese Entscheidung wird dann festgeschrieben und kann über CI weitergegeben und getestet werden.

— Robert Egginton

Sie schalten Ihre Website ernsthaft offline? Das ist für uns keine Option. Unsere Firma verdient tatsächlich Geld

— TheBlackBenzKid

Derzeit schalten wir Websites kurzzeitig offline, da wir nicht zu 100% sicher sind, dass Benutzer keine teilweise funktionsfähige Website sehen würden. Mit unserer größeren Erfahrung mit M1 wissen wir mit hoher Sicherheit, welche Änderungen live gehen können, ohne die Site zu entfernen. Noch nicht so bei M2.

— Robert Egginton

Up-Voted. Wie bei @TheBlackBenzKid würde ich jedoch gerne etwas sehen, das Ihre Website nicht offline schaltet, zumal die DI-Kompilierung einige Zeit in Anspruch nimmt. Ich denke, es ist wichtig zu verstehen, was die DI-Kompilierung tatsächlich tut - es wäre großartig, wenn dieser Schritt im Release-Candidate-Ordner ausgeführt werden könnte. Irgendwelche Fortschritte in der Zwischenzeit, seit du diesen @Robert gepostet hast?

— Erfan

1

Interessante Bearbeitung @RobertEgginton - Ich untersuche dies derzeit und habe Ihre Beiträge und Diskussionen verfolgt. Ich teile die Vorbehalte gegen die Verwendung von Composer zur Bereitstellungszeit und die mögliche Nichtverfügbarkeit von Repos von Drittanbietern, obwohl ich davon ausgehe, dass dies bei Repos von Packagisten weniger problematisch ist. Das Festschreiben von ./vendor scheint ebenfalls nicht ideal zu sein, bietet Ihnen jedoch zumindest eine vollständige Version, die unabhängig von Repos von Drittanbietern bereitgestellt werden kann. Haben Sie die Erweiterung Capistrano Magento2 ausprobiert? Dies verwendet Composer-Installation, aber ich mag den Cap-Workflow github.com/davidalger/capistrano-magento2

— BlueC

3

Bisher haben wir auch den Vendor-Ordner festgeschrieben, der natürlich eine ganze Reihe von Dateien zu Ihrem Repo hinzufügt. (Entfernen Sie unbedingt alle .git-Ordner in den Hersteller-Composer-Dateien, da sonst der Ordnerinhalt nicht festgeschrieben wird, z. B. firegento.) Das Verknüpfen des Vendor-Ordners funktioniert jedoch nicht. Das Bearbeiten des Pfads in der Datei vendor_path.php funktioniert ebenfalls nicht und wir hatten bisher keine Zeit, nach einer besseren Lösung zu suchen.

Wir haben keinen Build-Server und führen keinen Composer auf dem Server aus. Wir führen alle Updates lokal aus, testen sie und schreiben sie fest. Dies löst wiederum unser Bereitstellungsskript aus.

Unser Bereitstellungsskript ersetzt die Datei env.php, führt einige benutzerdefinierte Aktionen aus und löst dann auch setup:upgradeund setup:static-content:deployvor dem Umschalten des Live-Links in den neuen Ordner aus.

Der einzige Ordner, den wir mit einem Symlink versehen, ist Pub / Media.

— Tecjam
quelle

danke für die eingabe. Welche anderen Änderungen möchten Sie neben der Änderung der Datei env.php vornehmen?

— Claudiu Creanga

Das hängt alles von Ihrem eigenen Server und Projekt-Setup ab, denke ich. Für die dev & staging-Zweige löschen wir auch die .htaccess-Datei und kopieren unsere eigenen .htaccess & htpassword-Dateien in das Verzeichnis. Wir stellen sicher, dass bin / magento vorsorglich ausführbar ist, bevor wir cli-Befehle darauf ausführen, was wir sicherstellen Wir werden als Eigentümer der Magento-Datei ausgeführt (Bereitstellungsbenutzer ist root) und verknüpfen den Medienordner mit dem Pub-Ordner. Natürlich können Sie auch noch etwas hinzufügen, was Sie bei der Bereitstellung lieber tun als zuvor.

— Tecjam

Das Festschreiben von Dateien in / vendor wird generell davon abgeraten, da dies das Ziel eines Komponentenmanagers verfehlt. Siehe Composer-Dokumentation.

— user3668514

Das ist klar. Wie verwalten Sie dann Ihre Bereitstellung?

— Tecjam

1

Careful @ user3668514 - Ich denke du meinst Composer installieren. Es ist einfach, versehentlich ein Update auszuführen und Komponenten zu ändern, anstatt sie zu installieren.

— Robert Egginton

2

Schließlich haben wir uns für einen Dienst wie deploybot( http://deploybot.com/ ) entschieden. Sie können verwenden, capistranodie kostenlos ist. Deploybot erstellt einen Docker-Container, während die Composer-Installation ausgeführt wird. Wenn der Befehl erfolgreich ist, wird der Code bereitgestellt. Andernfalls wird nichts bereitgestellt, sodass Ihre Produktionsumgebung sicher ist.

Ich halte dies für den besten Ansatz, weil:

1) Den Vendor-Ordner in Ihrem Git-Repo zu haben, wird von den Komponisten aus guten Gründen nicht empfohlen:

The general recommendation is no. The vendor directory (or wherever your dependencies are installed) should be added to .gitignore/svn:ignore/etc.

Weitere Informationen: https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

2) Das Ausführen composer install in productionohne Sicherheitsnetze ist riskant , Pakete können ausfallen (siehe npm), Sie können auf Speicherprobleme stoßen oder auf einen Fehler, der beim Generieren von Dateien durch den Composer auftreten kann, und Sie müssen mit einer kaputten Produktionsumgebung umgehen.

— Claudiu Creanga
quelle

1

Ich beschäftige mich auch damit. Der Ansatz, den ich bisher gewählt habe, ist:

Bootstrapping des Servers:

Richten Sie das Projekt mit composer --create-project ... --no-devin einem srcOrdner ein (obwohl ich immer noch viel Dev Cruft sehe)
App einrichten, statische Dateien kompilieren, Datenbank aktualisieren usw.
Stellen Sie alle richtigen Berechtigungen ein

Das gibt mir einen Lagerbestand, der aus meinem src-Verzeichnis läuft (aber meine Webroot zeigt nicht dorthin)

Dann mein Bereitstellungsprozess:

Erstellen Sie einen neuen Release-Ordner
rsync die src-Dateien in meine Version (ohne die Cruft)
Bereitstellen und Entpacken meiner Anpassungen (eine Handvoll Themendateien und Module)
Installieren Sie Magento-Module von Drittanbietern über Magento Connect
Zeigen Sie mit der Webroot meines Hosts auf meine neue Version (mit einem Symlink).
Laden Sie meinen Webserver ordnungsgemäß neu

Dies ermöglicht es mir, den Magento-Kerncode von meinem eigenen zu trennen, Composer zu verwenden, um ihn auf dem neuesten Stand zu halten. Und ich muss keine 39.102 versenden !!! Dateien bei jeder Bereitstellung oder führen Sie Composer-Befehle zur Bereitstellungszeit aus.

... Ich bin gespannt auf andere Ansätze oder auf bewährte Methoden, und ich würde auch gerne wissen, welche Dateien tatsächlich für die Produktion benötigt werden und welche Entwickler sind, damit ich meine Webroot sauber halten kann.

Sobald ich fertig bin, habe ich ein ansibles Playbook und einige Fabric-Befehle, um die Konfiguration und Bereitstellung zu koordinieren, die ich gerne teile.

Ich hoffe, das hilft

— Farridav
quelle

Ich würde gerne die Spielbücher und Skripte sehen.

— JM Becker