wie Composer-Client bei <100MB RAM und kein exec(), shell_exec()?

[zonky2]

gibt es einen Weg, (zukünftig) den Composer-Client zu verwenden, wenn weniger als 100MB RAM zur Verfügung stehen.

Für kleinere Seiten ist der RAM völlig ausreichend - wenn aber das ER irgendwann ganz weg ist und nur noch der Composer zur Verfügung steht, wird es "eng".

z.B. bei einem Provider mit 96MB kommt schon eine Fehlermeldung beim Installieren des Composer-Client (frische Contao-Installation) => "zu wenig RAM".

Nach Reload scheint aber alles o.k. zu sein und "kleinere" Erweiterungen können installiert werden. Bei Paketen wie MetaModels ist eine Instalation über den Composer nicht möglich. Am Download der 2MB wird es nicht liegen sondern ggf. an der Prüfung der Anhängigkeiten(??).

M.E. sollte es hierfür eine Lösung geben oder es braucht eine definitive Aussage, ab welcher RAM-Größe Contao (inkl. Composer) verwendet werden kann - sollte dann auch in die Contao-Check-Routine bzw. in die Composer-Installation(s-prüfung).

Bei kleineren Seiten müsste ich dann irgendwann (wieder) auf Wordpress o.ä. zurück greifen... :-(

[fritzmg]

• Remote Installation lokal spiegeln (inkl. Datenbank)
• lokal das Update durchführen
• lokale Installation zurück auf den Remote Server kopieren (inkl. Datenbank)

"Muss" man im Prinzip auch bei allen Symfony Apps so machen. WordPress setzt doch auch schon tlw. auf das package management via composer, oder nicht?

[zonky2]

soweit ich "gehört" habe, soll die (neue) Paketverwaltung das besser handeln können...

[BugBuster1701]

Glaub ich nicht, denn die composer.phar ist der Teil der so viel RAM braucht, nicht die Backend Verwaltung / Tenside in Zukunft)
Siehe Forum

[zonky2]

@BugBuster1701 Dank für die Info

@fritzmg nach "Elegant" hört sich das nicht an - ich habe mir mal die Pakete meiner Kunden angesehen: da sind die wenigsten mit mehr als 128MB unterwegs. Und auch ein Upgrade innerhalb der "Hostingpakete" bringt selten mehr RAM.

Für Contao gibt es auch kein brauchbares "Snapshot-System" (mehr) - die Backups der DB sind doch nur die halbe Miete. Ohne Sicherung der Systemdateien kann ich mit dem Rückspielen einer DB meist nicht viel anfangen. Mit syncCto geht das "Backupen" noch am brauchbarsten... wenn auch mit Einschränkungen.

Der Entwicklung sehe ich - wie einige andere auch - immer noch mit gemischten Gefühlen entgegen (auch wenn die technischen Vorteile verständlich sind)

[bytehead]

Composer braucht nur für das update, bzw. für require viel RAM, weil da Abhängigkeiten aufgelöst werden müssen.

Ich pflege diverse Contao 3.x, 4.x und diverse Symfony-Installationen auf Shared Hostings, und da läuft ein composer update zumindest für die Symfony-Installationen gar nicht (RAM-Verbrauch: bis zu 1.6GB).

Deshalb lasse ich Composer immer lokal auf meiner Maschine laufen und Composer generiert ja beim erfolgreichen update eine composer.lock-Datei. Diese Datei beinhaltet alle aufgeschlüsselten Abhängigkeiten und ist sozusagen der Snapshop einer Installation, mit welchem ich eben diese einfach überall "vervielfältigen" kann.

Somit pushe ich diese composer.lock-Datei nach dem lokalen update auf den Server und da lass ich per Deployment-Tool nur noch einen composer install rennen – dieser ist sehr schnell und braucht eigentlich kein RAM.

Bedingung: SSH - kenne keine vernünftige Deploymentlösung, welche ohne SSH funktioniert.

Man könnte sich das composer.lock-File auch sonst wie hochladen, dazu bräuchte es einen install-Button und nicht nur update für den Contao-Composer-Client .

[fritzmg]

Für Contao gibt es auch kein brauchbares "Snapshot-System" (mehr) - die Backups der DB sind doch nur die halbe Miete. Ohne Sicherung der Systemdateien kann ich mit dem Rückspielen einer DB meist nicht viel anfangen. Mit syncCto geht das "Backupen" noch am brauchbarsten... wenn auch mit Einschränkungen.

Das war aber schon immer so. Durch die Paketverwaltung ist es aber so, dass du weniger sichern musst, als bisher, weil du auf einfache Weise alle Extensions, die du verwendest, wieder installieren kannst, ohne deren Dateien in /system/modules (und im Falle von der Paketverwaltung auch /composer/vendor) auch nochmal sichern zu müssen.

Ohne Paketverwaltung musst du folgendes sichern:

• /files
• /system/config/localconfig.php
• /system/config/initconfig.php
• /system/config/dcaconfig.php
• /system/config/langconfig.php
• etwaige eigene TinyMCE configs
• alle non-Core Module in /system/modules
• alle Dateien von Extensions, die nicht in /system/modules installiert wurden
• die Datenbank

Mit Paketverwaltung musst du folgendes sichern:

• /files
• /system/config/localconfig.php
• /system/config/initconfig.php
• /system/config/dcaconfig.php
• /system/config/langconfig.php
• etwaige eigene TinyMCE configs
• /composer/composer.json
• /composer/composer.lock
• die Datenbank

[bytehead]

@fritzmg wenn du ganz sicher gehen willst, umbedingt die composer.lock auch auf die Liste nehmen. Nur dieses File lässt dich exakt die gleichen Versionen der Pakete installieren (ausser du hast alle Versionen in deiner composer.json gepinnt).

[fritzmg]

Ja, stimmt natürlich. Aber falls die composer.json alleine bzw. ein composer update ein Problem macht, könnte man ja die problematische Extension immer noch pinnen. Müsste man früher oder später ja sowieso machen.

[zonky2]

@fritzmg ... na ja... wenn bei einem Update alles glatt läuft und man ggf. hinterher noch in der Lage ist, ein "roll-back" zu machen.

bei einem "Snapshot" sollte das Paket auch mit einer Contao-unabhängigen Installationsdatei reaktivieren lassen.

[fritzmg]

@fritzmg ... na ja... wenn bei einem Update alles glatt läuft und man ggf. hinterher noch in der Lage ist, ein "roll-back" zu machen.

Was genau meinst du damit?

bei einem "Snapshot" sollte das Paket auch mit einer Contao-unabhängigen Installationsdatei reaktivieren lassen.

Was genau meinst du damit? ;)

[zonky2]

Roll-back: "Alles" auf Stand "vorher" - es soll ja schon vorgekommen sein, dass man sich mit einem Update einen kleinen Bug einfängt ;-)

Snapshot: z.B. alles notwendige in eine "Zip" - diese kann man mit einer "spiel-mich-ein.php" wieder einspielen - ähnlich wie bei Contao2go

[fritzmg]

Beides hat aber nichts mit der Paketverwaltung zu tun, oder was genau meinst du hier diesbezüglich?

[zonky2]

nein - war "off topic"

[bytehead]

@xantippe bezüglich rollback - guck dir mal Magallanes an :)

[zonky2]

da beißt sich die Katze in den Schwanz:

• da wo SSH == genügend RAM
• nicht genügend RAM kein SSH

;-)

[bytehead]

Nö nicht zwingend, ich habe auch zu wenig RAM für ein composer update auf den Shared-Hosting-Kisten.
Aber ja, SSH muss halt sein. Kann man aber heute auch irgendwie erwarten. Gibts sogar schon für "wenig" Geld.

[zonky2]

Mit 512MB RAM gab es nun

[Fri Dec 25 14:09:32 2015] [warn] [client 123.123.123.123] mod_fcgid: read data timeout in 60 seconds, referer: http://www.domain.de/contao/main.php?do=composer

und Error 500.... mit "F5" lief es dann doch irgendwie weiter... hoffe Composer hat sich dabei nicht "verschluckt"...

[discordier]

60 Sekunden sind auch recht wenig wenn man komplexe Updates faehrt. Der detached mode ist das Einzige was wirklich sauber funktioniert. Die Beiden anderen sind Krycken.