Je n’ai pas la permission de modifier le wiki, mais j’ai réussi à utiliser un autre fournisseur.
OVHcloud
Nom du service : Stockage d’objets
Les régions correspondent à des centres de données identifiés par un code à trois lettres. Si vous ne savez pas où vous avez créé votre bucket, vérifiez dans l’onglet stockage d’objets de votre portail client.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: [code du centre de données]
DISCOURSE_S3_ENDPOINT: https://s3.[code du centre de données].io.cloud.ovh.net/
DISCOURSE_S3_ACCESS_KEY_ID: [clé]
DISCOURSE_S3_SECRET_ACCESS_KEY: [clé]
DISCOURSE_S3_BUCKET: [nom du bucket]
DISCOURSE_S3_BACKUP_BUCKET: [nom du bucket]
DISCOURSE_BACKUP_LOCATION: s3
Initialement, dans ma version de test, mais je suis passé en production avec uniquement des sauvegardes puisque la machine de production dispose de beaucoup d’espace de toute façon.
C’est très compatible avec S3, mais il manque certaines fonctionnalités comme les règles de cycle de vie pour supprimer les anciens fichiers ou les déplacer vers un stockage froid, ce qui est en cours de développement par OVH. Cela fonctionne cependant parfaitement pour servir des fichiers.
Donc, pour les sauvegardes, j’ai simplement utilisé l’option de Discourse pour supprimer automatiquement les anciennes sauvegardes.
C’est une réponse vraiment décevante et complètement inutile. Quel est exactement le problème ? Lier vers un document de support qui change signifie que personne ne peut réellement dire quelle est cette « terrible défaillance » mentionnée dans ce fil de discussion ici.
Vous mentionnez les « métadonnées » et que le CDN « n’en est pas conscient ». Quelles métadonnées ? Il serait utile de savoir ce qui ne fonctionne pas.
Je voulais juste ajouter à ce post des instructions sur la façon d’utiliser E2 d’iDrive.
Il semble qu’une fonctionnalité que iDrive a récemment activée fasse échouer les clés d’accès qui ne sont attribuées qu’à un seul bucket, à moins qu’une vérification d’authentification du bucket ne soit contournée.
Vous pouvez contourner cela lors de l’utilisation de rclone avec no_check_bucket = true dans le fichier rclone.conf, mais je ne suis pas sûr qu’un tel paramètre ENV existe pour la construction de Discourse.
Par conséquent, avec iDrive E2, vous devez actuellement utiliser une clé qui a accès en écriture à tous vos buckets, plutôt qu’à un seul.
Comment quelqu’un d’autre pourrait-il connaître le problème exact pour un fournisseur qu’il n’utilise pas ?
Quoi qu’il en soit, il semble que nous soyons presque arrivés avec Cloudflare R2. Selon :
Lorsque j’ai entré toutes les informations dans l’interface utilisateur Web, les nouveaux téléchargements ont été correctement envoyés vers le stockage S3, et les sauvegardes sont également envoyées correctement vers S3. Les téléchargements actuels n’ont évidemment pas été déplacés.
J’ai ensuite accédé au fichier app.yml et entré ces informations :
## Cet ensemble de lignes permet aux fichiers hébergés sur R2 S3 d'être téléchargés et téléversés.
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
## Le conteneur Docker est sans état ; toutes les données sont stockées dans /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
## Les plugins vont ici
## voir https://meta.discourse.org/t/19157 pour plus de détails
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
# - git clone https://github.com/discourse/discourse-subscriptions.git
- git clone https://github.com/discourse/discourse-follow.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/communiteq/discourse-private-topics.git
# - git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/tknospdr/discourse-auto-remove-group.git
- git clone https://github.com/discourse/discourse-topic-voting.git
- git clone https://github.com/discourse/discourse-livestream.git
# - git clone https://github.com/discourse/discourse-calendar.git
- git clone https://github.com/jannolii/discourse-topic-trade-buttons.git
## - git clone https://github.com/tknospdr/force-tag-group-order.git
## Hooks pour S3
after_assets_precompile:
- exec:
cd: $home
cmd:
- sudo -E -u discourse bundle exec rake s3:upload_assets
- sudo -E -u discourse bundle exec rake s3:expire_missing_assets
Après une reconstruction, mon site était cassé en raison d’un grand nombre de fichiers manquants, j’ai donc essayé de les importer sur le serveur et j’ai obtenu cette erreur pour chaque fichier :
root@talk-app:/var/www/discourse# rake uploads:migrate_to_s3
Veuillez noter que la migration vers S3 n'est actuellement pas réversible !
[CTRL+c] pour annuler, [ENTRÉE] pour continuer
Migration des téléchargements vers S3 pour 'default'...
Téléchargement des fichiers vers S3...
- Listage des fichiers locaux
=> 31 fichiers
- Listage des fichiers S3
. => 4 fichiers
- Synchronisation des fichiers vers S3
#<Thread:0x00007ff89dcbcb20 /var/www/discourse/lib/file_store/to_s3_migration.rb:212 run> terminé avec une exception (report_on_exception est vrai) :
/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-core-3.226.0/lib/seahorse/client/request.rb:72:in `send_request'
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'
J’apprécierais beaucoup des conseils pour terminer cela d’une manière ou d’une autre.
Les fichiers manquants sont probablement des ressources, vous avez donc besoin de la tâche rake qui les envoie vers s3 (s3:upload_assets – elle est près du début)
Mais vos erreurs sont probablement dues à la nouvelle bibliothèque aws s3 qui casse un tas de services. Vous devrez donc vous arranger pour rétrograder le gem aws ou utiliser un autre service.
Je pense qu’il peut y avoir un sujet sur la façon de faire cela. Je l’ai fait sur un site ou deux, mais je ne suis pas sûr comment ou où cela a été documenté.
Je dois l’exécuter même si cela fait partie des modifications que j’ai apportées au fichier app.yml ? Je pensais que c’était là pour envoyer automatiquement les fichiers lors d’une reconstruction.
Vous ne devriez pas, mais ce sont les choses qui rendraient votre site « cassé » (ou est-ce que « cassé » signifie « images manquantes » pour vous ?) Le téléchargement d’images avec migrate_to_s3 n’affecte que les images.
Je ne peux pas vraiment expliquer comment les actifs ont déjà été téléchargés (qu’est-ce qui était cassé sur le site ? Comment ont-ils été téléchargés si votre configuration S3 est cassée ?)
Pouvez-vous télécharger des images sur votre site ?
Je ne peux rien faire sur le site pour le moment.
N’hésitez pas à y jeter un œil. https://eu.technospider.com
Comme tout semble être dans mon bucket, il y a probablement une variable d’environnement qui doit être mise à jour pour que tout fonctionne correctement.
Si nous pouvons résoudre cela, nous pourrons dire que R2 est prêt pour l’heure de pointe.
Où est censé se trouver “extra-locales” ? Je ne le vois ni sous ‘public’ ni sous ‘assets’, même à l’intérieur du conteneur. Où devrais-je chercher ?
Désolé pour les questions stupides, mais c’est une toute nouvelle aventure pour moi.
Est-ce QUE mon CDN ou mon bucket ?
Avec les tirets en tête, et tous les guillemets simples et doubles ? Je n’ai rien de tout cela dans mon fichier app.yml. Devrais-je les ajouter et reconstruire pour tester ?
C’est exactement à quoi ressemble mon fichier, indenté de 2 espaces chacun :
## Cet ensemble de lignes permet de télécharger et de télécharger des fichiers hébergés sur R2 S3.
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
Cela a fonctionné lorsque j’avais les paramètres entrés via l’interface web, puis lorsque j’ai tout mis dans le fichier app.yml, j’ai obtenu ce que vous avez vu lorsque vous êtes allé sur le site.
Voici ce que je vois lorsque j’accède à l’un de vos actifs :
Cet objet n'existe pas ou n'est pas accessible publiquement à cette URL. Vérifiez l'URL de l'objet que vous recherchez ou contactez le propriétaire pour activer l'accès public.
Vous pouvez voir si https://eufiles.technospider.com/extra-locales/ca382c69f8e6b85162b2ba58f2ce100bfe741966/en/mf.js?__ws=eu.technospider.com fonctionne si vous remplacez le nom d’hôte par votre point de terminaison Cloudflare.
Pouvez-vous trouver ce fichier dans votre bucket ? Pouvez-vous y accéder ?
Je ne sais pas, mais c’est une URL que j’ai copiée à partir des outils de développement de mon navigateur.
Alors, trouvez d’abord ce fichier dans votre bucket et voyez s’il y est, puis vous pourrez essayer de comprendre pourquoi le CDN ne le trouve pas.
Non. J’utilise un outil différent pour la configuration, mais ce sont les paramètres ENV qui, je suis sûr, ont fonctionné pour moi à un moment donné.
Ce fichier XML ne semble avoir aucune information de style associée. L'arborescence du document est affichée ci-dessous.
<Error>
<Code>InvalidArgument</Code>
<Message>Authorization</Message>
</Error>
Un bucket est ce « répertoire principal » que vous avez créé et où se trouvent tous les fichiers. Le CDN est constitué de nombreux serveurs dans le monde entier qui copient ce bucket. Votre bucket est identifié par l’URL que vous avez fournie lors de la création de cette connexion, par exemple cdn.example.com.
Il semble qu’avec R2, le CDN soit automatiquement créé si vous donnez un domaine personnalisé au bucket. C’était un peu déroutant car je n’ai pas eu à faire quoi que ce soit avec le CDN.
Ce fichier XML ne semble avoir aucune information de style associée. L'arborescence du document est affichée ci-dessous.
<Error>
<Code>InvalidArgument</Code>
<Message>Authorization</Message>
</Error>
Me donne :
Comme l’erreur parle d’autorisation, j’ai examiné cela un peu et j’ai trouvé cette pépite :
Remarque
Par défaut, seuls certains types de fichiers sont mis en cache. Pour mettre en cache tous les fichiers de votre bucket, vous devez définir une règle de page “Cache tout”.
Pour plus d’informations sur le comportement de cache par défaut et comment le personnaliser, consultez Comportement de cache par défaut
De cette page :
J’ai créé une règle “Cache tout”, mais aucun changement.
