Ich scheine keine Wiki-Bearbeitungsberechtigung zu haben, aber ich konnte erfolgreich einen anderen Anbieter nutzen.
OVHcloud
Dienstname: Object Storage
Regionen entsprechen Rechenzentren, die durch einen dreibuchstabigen Code identifiziert werden. Wenn Sie nicht wissen, wo Sie Ihren Bucket erstellt haben, überprüfen Sie dies im Tab „Object Storage“ in Ihrem Kundenportal.
Ursprünglich sowohl in meiner Testversion, aber ich bin mit nur Backups in die Produktion gegangen, da die Produktionsmaschine sowieso viel Speicherplatz hat.
Es ist sehr kompatibel mit S3, aber es gibt einige fehlende Funktionen, wie Lebenszyklusregeln zum Löschen alter Dateien oder zum Verschieben in Kaltlagerung, an denen aktiv von OVH gearbeitet wird. Es funktioniert jedoch gut, um Dateien bereitzustellen.
Für Backups habe ich einfach die Option von Discourse genutzt, alte Backups automatisch zu löschen.
[Zitat=“pfaffman, Beitrag:439, Thema:148916”]
Hast du den Links gefolgt?
Es sieht so aus, als ob das CDN keine Metadaten kennt. Aber du könntest es versuchen und sehen, ob es funktioniert! Lass uns wissen, wenn du es machst. Ich habe mich gefragt, ob es erst neulich behoben wurde. Nach der Dokumentation zu urteilen, werde ich es selbst in nächster Zeit wohl nicht ausprobieren.
[/Zitat]
Das ist eine wirklich enttäuschende und völlig unhilfreiche Antwort. Was genau ist das Problem? Einen Link zu einem Support-Dokument, das sich ändert, zu posten, bedeutet, dass niemand wirklich sagen kann, was genau die “furchtbare Zerbrochenheit” in diesem Thread hier ist.
Du erwähnst „Metadaten“ und dass das CDN „dazu nichts weiß“. Welche Metadaten? Es wäre hilfreich zu wissen, was nicht funktioniert.
Ich wollte nur diesen Beitrag von mir mit Anleitungen zur Verwendung von iDrive E2 ergänzen.
Es scheint, dass iDrive kürzlich eine Funktion aktiviert hat, die dazu führt, dass Zugriffsschlüssel, die nur einem Bucket zugewiesen sind, fehlschlagen, es sei denn, eine Bucket-Authentifizierungsprüfung wird umgangen.
Sie können dies bei der Verwendung von rclone mit no_check_bucket = true in der Datei rclone.conf umgehen, aber ich bin mir nicht sicher, ob eine solche ENV-Einstellung für den Discourse-Build existiert.
Daher müssen Sie mit iDrive E2 derzeit einen Schlüssel verwenden, der Zugriff zum Schreiben auf alle Ihre Buckets hat, anstatt nur auf einen.
Woher sollte jemand anderes das genaue Problem für einen Anbieter kennen, den er nicht nutzt?
Wie auch immer, es sieht so aus, als wären wir mit Cloudflare R2 fast fertig. Laut:
Als ich alle Informationen in der Weboberfläche eingegeben habe, wurden neue Uploads korrekt in den S3-Speicher hochgeladen und Backups werden korrekt zu S3 gesendet. Aktuelle Uploads wurden offensichtlich nicht verschoben.
Dann ging ich zu app.yml und gab diese Informationen ein:
Nach einem Rebuild war meine Seite aufgrund vieler fehlender Dateien kaputt, also habe ich versucht, sie auf den Server zu übertragen und erhielt für jede Datei diesen Fehler:
root@talk-app:/var/www/discourse# rake uploads:migrate_to_s3
Bitte beachten Sie, dass die Migration zu S3 derzeit nicht rückgängig gemacht werden kann!
[CTRL+c] zum Abbrechen, [ENTER] zum Fortfahren
Migriere Uploads zu S3 für 'default'...
Dateien werden zu S3 hochgeladen...
- Lokale Dateien auflisten
=> 31 Dateien
- S3-Dateien auflisten
. => 4 Dateien
- Dateien mit S3 synchronisieren
#<Thread:0x00007ff89dcbcb20 /var/www/discourse/lib/file_store/to_s3_migration.rb:212 run> beendet mit Ausnahme (report_on_exception ist true):
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call': You can only specify one non-default checksum at a time. (Aws::S3::Errors::InvalidRequest)
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/dualstack.rb:21:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/accelerate.rb:43:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/checksum_algorithm.rb:169:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:16:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/invocation_id.rb:16:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/plugins/request_callback.rb:89:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/seahorse/client/plugins/response_target.rb:24:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `block in call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/telemetry/no_op.rb:29:in `in_span'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/telemetry.rb:53:in `span_wrapper'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.226.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `call'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/client.rb:17315:in `put_object'
from /var/www/discourse/lib/file_store/to_s3_migration.rb:215:in `block (2 levels) in migrate_to_s3'
Ich würde mich über Ratschläge freuen, um dies auf die eine oder andere Weise abzuschließen.
Die fehlenden Dateien sind wahrscheinlich Assets, daher benötigen Sie die Rake-Aufgabe, die diese nach S3 hochlädt (s3:upload_assets – sie befindet sich ganz oben).
Aber Ihre Fehler sind wahrscheinlich darauf zurückzuführen, dass die neue AWS S3-Bibliothek eine Reihe von Diensten unterbrochen hat. Sie müssen also die AWS-Gem herunterstufen oder einen anderen Dienst verwenden.
Ich glaube, es gibt ein Thema darüber, wie man das macht. Ich habe es auf einer oder zwei Websites gemacht, bin mir aber nicht sicher, wie oder wo es dokumentiert wurde.
Ich muss das ausführen, obwohl das Teil der Änderungen ist, die ich in die app.yml-Datei eingefügt habe? Ich dachte, das wäre dazu da, die Dateien automatisch während eines Rebuilds hochzuladen.
Das solltest du nicht, aber das sind die Dinge, die deine Seite “kaputt” machen würden (oder bedeutet “kaputt” für dich “Bilder fehlen”?) Das Hochladen von Bildern mit migrate_to_s3 betrifft nur Bilder.
Ich kann nicht genau erklären, wie die Assets bereits hochgeladen wurden (was war auf der Seite kaputt? Wie wurden diese hochgeladen, wenn dein S3-Setup kaputt ist?)
[quote=„pfaffman, Beitrag:485, Thema:148916”]
Kannst du irgendwelche Bilder auf deiner Seite hochladen?
[/quote]
Ich kann im Moment nichts auf der Seite machen.
Schau sie dir gerne an. https://eu.technospider.com
Da alles in meinem Bucket vorhanden zu sein scheint, gibt es wahrscheinlich eine Umgebungsvariable, die aktualisiert werden muss, damit alles richtig funktioniert.
Wenn wir das knacken, können wir sagen, dass R2 bereit für die Hauptsendezeit ist.
Wo soll sich „extra-locales“ befinden? Ich sehe es weder unter „public“ noch unter „assets“, selbst innerhalb des Containers. Wo soll ich suchen?
Entschuldigen Sie die dummen Fragen, aber das ist für mich völliges Neuland.
Ist WAS mein CDN oder mein Bucket?
Mit den führenden Bindestrichen und all den einfachen und doppelten Anführungszeichen? Ich habe keine davon in meiner app.yml-Datei. Sollte ich diese hinzufügen und neu kompilieren, um zu testen?
Das ist genau so, wie meine Datei aussieht, jeweils 2 Leerzeichen eingerückt:
## This set of lines allows R2 S3 hosted files to be uploaded and downloaded..
DISCOURSE_CDN_URL: https://eufiles.technospider.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_ENDPOINT: https://randomnumber.r2.cloudflarestorage.com
DISCOURSE_S3_CDN_URL: https://eufiles.technospider.com
DISCOURSE_S3_BACKUP_BUCKET: exotics-unlimited-backups
DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_S3_BUCKET: exotics-unlimited
DISCOURSE_S3_REGION: auto
DISCOURSE_S3_ACCESS_KEY_ID: randomnumbers
DISCOURSE_S3_SECRET_ACCESS_KEY: randomnumbers
DISCOURSE_S3_INSTALL_CORS_RULE: false
Es funktionierte, als ich die Einstellungen über die Weboberfläche eingegeben hatte. Als ich dann alles in die app.yml-Datei eingegeben habe, bekam ich das, was Sie auf der Website gesehen haben.
Hier ist, was ich sehe, wenn ich auf eines Ihrer Assets zugreife:
Dieses Objekt existiert nicht oder ist unter dieser URL nicht öffentlich zugänglich. Überprüfen Sie die URL des gesuchten Objekts oder kontaktieren Sie den Eigentümer, um den öffentlichen Zugriff zu ermöglichen.
Sie können sehen, ob https://eufiles.technospider.com/extra-locales/ca382c69f8e6b85162b2ba58f2ce100bfe741966/en/mf.js?__ws=eu.technospider.com funktioniert, wenn Sie den Hostnamen zu Ihrem Cloudflare-Endpunkt ändern.
Können Sie diese Datei in Ihrem Bucket finden? Können Sie darauf zugreifen?
Ich weiß es nicht, aber das ist eine URL, die ich aus den Entwicklertools in meinem Browser kopiert habe.
Finden Sie also zuerst diese Datei in Ihrem Bucket und prüfen Sie, ob sie überhaupt vorhanden ist, und dann können Sie herausfinden, warum das CDN sie nicht finden kann.
Nein. Ich benutze ein anderes Werkzeug für die Konfiguration, aber das sind die ENV-Einstellungen, von denen ich ziemlich sicher bin, dass sie bei mir einmal funktioniert haben.
Diese XML-Datei scheint keine Stilinformationen zu haben. Der Dokumentenbaum wird unten angezeigt.
<Error>
<Code>InvalidArgument</Code>
<Message>Authorization</Message>
</Error>
Finden Sie ein Asset, auf das Sie mit der Bucket-URL zugreifen können, und ermitteln Sie dann, wie Sie über das CDN auf dasselbe Asset zugreifen können.
Ein Bucket ist das „Hauptverzeichnis“, das Sie erstellt haben und in dem sich alle Dateien befinden. Ein CDN sind viele Server auf der ganzen Welt, und diese erhalten eine Kopie dieses Buckets. Ihr Bucket wird über die URL identifiziert, die Sie bei der Erstellung dieser Verbindung angegeben haben, z. B. cdn.example.com.
Es scheint, dass mit R2 das CDN automatisch erstellt wird, wenn Sie dem Bucket eine benutzerdefinierte Domain geben. Das war etwas verwirrend, da ich nichts mit CDN tun musste.
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<Error>
<Code>InvalidArgument</Code>
<Message>Authorization</Message>
</Error>
Gibt mir:
Da der Fehler von Autorisierung spricht, habe ich mich damit beschäftigt und bin auf diese Erkenntnis gestoßen:
Hinweis
Standardmäßig werden nur bestimmte Dateitypen zwischengespeichert. Um alle Dateien in Ihrem Bucket zu cachen, müssen Sie eine “Cache Everything”-Regel einrichten.
Weitere Informationen zum Standard-Cache-Verhalten und wie Sie es anpassen können, finden Sie unter Standard-Cache-Verhalten
Von dieser Seite:
Ich habe eine “Cache Everything”-Regel erstellt, aber keine Änderung.
