Druckbare Version
Immerhin habe ich so jetzt das erste Update im Groben fertig. Feinarbeiten werden wohl noch folgen müssen. Z.B. .htaccess und die Integration einiger der neuen Features. Aber hat ja keine Eile. Wenn ich dann zufrieden bin schalte ich einfach die Domain auf das neue Verzeichnis.
Der Vorschlag für die Mitgliedern der Contao Association (bin ich!) einer bevorzugten Abarbeitung der Jobs würde ich begrüßen.
Damit die bevorzugte Behandlung nur für Mitglieder funktioniert, wäre eine Art Lizenzschlüssel oder die E-Mail-Adresse vom Mitglied eine Möglichkeit als Identifikation. Die könnte beim CManager neben der Checkbox zur Cloud als weiteres Feld eingesetzt werden. Der Abgleich mit den Mitgliedern / Lizenzschlüssel wäre dann noch von Terminal42 zu lösen und die Bereitstellung einer eigenen Cloud nur für Mitglieder der Accociation.
Ich glaube, man möchte eher, dass Contao keine zwei Klassen einführt, sondern dass für alle ausreichende Ressourcen vorhanden sind.
Die Ressourcen reichen ja eigentlich völlig aus. Außer bei Sicherheitsupdates hat man ja keine Eile. Solche Wartezeiten gibt es in der Regel nur kurz nach der Ankündigung einer neuen Version, ein paar Tage später dürfte der größte Andrang vorbei sein. Wenn alle gleichzeitig alle ihre Installationen updaten wollen dann reichen die Kapazitäten nie dafür. Wollte man das einrichten, dann sollte man besser gleich ein Rechenzentrum anmieten. Zwei Tage später hätte man dann eine Auslastung < 5 Prozent bis zur nächsten Version. Das macht keinen Sinn. Wenn es wirklich mal brennt und man viele Installationen sehr zügig updaten will oder muss, dann sollte man halt eine lokale Entwicklungsumgebung haben, in der man normalerweise keine Resolver-Cloud braucht. Dauert wahrscheinlich noch ne Weile, bis mein Arbeitsplatzrechner damit in die Nähe seiner Grenzen kommt. Da muss sich sogar Composer ganz schön anstrengen.
In den Cloudsystemen ist ja eine automatische horizontale Skalierung möglich, sofern man das will und, und das ist hier nicht unwichtig, auch bezahlen kann.
Will sagen, es wäre sicherlich möglich, ich selber kenne es nur von MS Azure, zu solchen Spitzenzeiten automatisch weitere Instanzen zu starten und und später wieder zu stoppen.
Wie hier schon öfters angesprochen, will das aber auch finanziert werden. Aber dynamische (minutengenaue Abrechung der Compute Zeiten) lassen sich halt schlecht planen ;)
Autoscaling steht auf meiner (langen) Liste...
freu :DZitat:
Autoscaling steht auf meiner (langen) Liste...
Danke dafür.Zitat:
Zitat von Toflar
Sei auch mal gesagt dass du da einen riesen Job machst. Der Contao Manager ist wirklich sehr geil, ich glaube da beneiden uns die User anderer CMS sehr drum :)
Also vielen Dank für die ganze Mühe und Arbeit die du da rein steckst, damit hast du Contao definitiv einen riesigen Schritt nach vorne gebracht.
Das muss dringend weiter hoch auf der Liste. ;)
Ich warte hier gerade über 20 Minuten bevor es überhaupt erst mal losgeht. Wenn dann irgendwas schief läuft (und das tut es eben leider ab und zu) geht's wieder von vorne los.
Oder ihn in Colt Resover umbenenne. (Der Spaß sei mir erlaubt :D)
Der Revolver :D ist noch gar nicht wirklich ausgelastet. Tagsüber, ja. Da war ich heute mal ausnahmsweise unterwegs und wollte außerplanmäßig noch mal eben ein Update eines alten Eigenprojekts vorbereiten, also einfach nur Contao 4.9 installieren. Da hab ich auch 25 Minuten gebraucht bis das fertig war. Hätte ich jetzt so nicht gedacht, weil so ganz neu ist das 4.9.0 ja nicht mehr. Später kam dann noch 4.9.1 raus und ich habe probiert, gleich das Update zu machen. Da kam dann nur noch Status 503. Klar, da waren natürlich alle am updaten. Aber um ca 18:40 war ich dann wieder sofort und ohne Wartezeit dabei, ganz so wie ich es gewöhnt bin :).
GitHub war quasi down.
War down, oder ist?
HTTP request to hxxps://composer-resolver.cloud/jobs failed with status code 400 ()
ToM
GitHub hat nichts mit der Cloud zu tun. Also wenn du einen 400er von der Cloud bekommst, dann wohl aus guten Gründen (400 heisst ja Client-Fehler, also was von deiner Seite).
GitHub (bzw. jeder Paket-Provider) und packagist.org (bzw. jedes Paket-Repository) können einfach die Geschwindigkeit der Abhängigkeitsauflösung beeinträchtigen.
Ich habe soeben Version 2.3.0 der Composer Resolver Cloud produktiv geschaltet. Ich habe über die letzten 3 Wochen an der Implementierung von Autoscaling gearbeitet. Das bedeutet, dass jetzt nicht mehr ständig 10 Worker laufen, sondern im Prinzip immer nur mindestens einer und je höher die Auslastung, desto mehr Worker und Ressourcen werden hinzugefügt. Konkret bedeutet das, dass ihr generell wohl eher immer bisschen warten müsst, weil eben nicht 10 Worker rumgurken und warten sondern nur einer oder was es dann eben gerade sind. Allerdings bedeutet das auch, dass wir nachts kein Geld verschwenden und theoretisch (so der Plan) dann mehr als 10 Worker gleichzeitig laufen haben können, wenn sie eben erforderlich sind. So können wir dann Spitzen abfangen (z.B. bei Sicherheitsupdates) und hoffentlich trotzdem nicht viel mehr Kosten generieren. Also kurz: Die Chancen kurz zu warten steigen, dafür aber auch die Chancen, dass der Job überhaupt angenommen wird und innert brauchbarem Zeithorizont erledigt werden kann. Im Moment laufen immer noch maximal 10 Worker gleichzeitig. Ich möchte zuerst bisschen die Kosten überwachen und erst dann die Anzahl der maximal gleichzeitig arbeitenden Worker erhöhen. Wir haben auch noch einige Stellschrauben an denen wir arbeiten können. Z.B. immer mindestens zwei Worker am Leben halten etc. Ich muss da bisschen Erfahrung sammeln und ich kann es leider nicht wirklich simulieren. Deswegen seid ihr jetzt alle meine Versuchskaninchen. Ich hoffe, dass das alles so klappt, wie ich es mir vorstelle:oZitat:
Zitat von Toflar
Mal ein kurzes Feedback:
Ich habe gestern und vorgestern in insgesamt wenigen Stunden rund 70 Installationen von 4.7 auf 4.9 aktualisiert. Die Wartezeiten (für das Resolving) waren immer unter zwei Minuten und auch sonst funktioniert der Manager inzwischen einfach reibungslos. Vielen Dank an dieser Stelle für die Energie und Zeit, die in das Teil gesteckt wird. Das ist ganz großes Kino.
Ich sichere die Websites vorher über ein eigenes kleines Backup-Script, das alle Dateien und die Datenbank wegsichert. Das würde ich mir im Manager noch wünschen.
Insgsamt ist der Prozess nur einmal (!) abgebrochen, konnte dann aber einfach noch mal neu gestartet werden. Nur bei Mittwald hat ein einziges Update nicht geklappt: "An error occurred while executing the contao:install-web-dir command". Dafür konnte ich leider keine Lösung finden.
Und bei IONOS (bzw. mit aktuellen Browsern) gibt es das Problem, dass man iFrames der eigenen Subdomain (also ein iFrame von sub.domain.de in einer Contao-Installation auf domain.de) nicht mehr einbetten kann. Stichwort "X-Frame-Options". Auch hierfür konnte ich leider bislang noch keine Lösung finden, da IONOS das Überschreiben der Header via .htaccess wohl nicht (mehr) zulässt.
Die X-Frame-Options konfigurierst du über das Nelmio CORS Bundle dazu gibt es bereits einige Threads.
Tausend Dank! Ich dachte die Subdomain müsste irgendwie dafür Sorge tragen, dass sie eingebunden werden kann, aber es war dann tatsächlich die Anpassung in der parameters.yaml aus deinem Beitrag.