Le support/la compatibilité de Contabo S3 seront-ils ajoutés ? Ou quelqu’un a-t-il trouvé une solution de contournement pour le faire fonctionner ?
2 « J'aime »
Nous, les mainteneurs de Discourse, ne prenons en charge qu’AWS S3. Les fournisseurs listés ici ont été testés par nous-mêmes ou par la communauté pour voir s’ils implémentent suffisamment l’API S3 pour être compatibles avec Discourse.
Selon l’OP, @tuxed a testé Contabo et l’a trouvé insuffisant. Il appartient à Contabo d’améliorer la conformité de son implémentation avec S3, s’ils jugent que cela correspond à leurs intérêts commerciaux, ce n’est pas quelque chose que nous pouvons faire.
4 « J'aime »
Est-ce toujours buggé ? Pourquoi le CDN de Digitalocean n’est-il pas bon ?
1 « J'aime »
Avez-vous suivi les liens ?
Il semble que le CDN ne connaisse pas les métadonnées. Mais vous pourriez essayer et voir si cela fonctionne ! Faites-nous savoir si c’est le cas. Je me demandais si cela avait été corrigé l’autre jour. D’après la documentation, je ne vais pas l’essayer moi-même de sitôt.
2 « J'aime »
Je cherche un moyen simple d’ajouter le support CDN à mon forum sur DigitalOcean. Si S3 est plus simple, j’opterais pour cette option.
Je ne veux pas prendre de risque avec une configuration qui n’a pas bien fonctionné auparavant.
2 « J'aime »
La solution recommandée est simplement de ne pas utiliser leur CDN. Vous pouvez utiliser des espaces, si vous suivez les instructions ci-dessus et quelque chose comme bunny.net pour le CDN. C’est bon marché et facile.
Aws S3 est ce que cdck utilise, donc il est un peu mieux testé et supporté, mais à moins que vous ne soyez déjà à l’aise avec aws, le bucket d’espaces est une bonne solution. N’utilisez simplement pas le CDN de digital ocean.
2 « J'aime »
Je viens de passer par ça - configuration CDN, pour l’instant je garde les images en local - d’abord avec fastly, puis un autre dont je ne me souviens plus. J’ai opté pour bunny.net. très facile à configurer. Ils ont des guides spécifiques à Discourse. Nous sommes auto-hébergés sur DO avec plus de 100 Go d’images. 65% de taux de cache et ça augmente.
2 « J'aime »
la politique de pierre tombale de configuration s3 ne fonctionne que sur aws.amazon ?
1 « J'aime »
Non. C’est un problème uniquement avec Backblaze.
2 « J'aime »
3 messages ont été déplacées vers un nouveau sujet : Exploration de solutions pour les problèmes de téléchargement de photos de profil utilisateur
Ouf, par où commencer ? J’utilise Cloudflare pour la mise en cache et le DNS, et Backblaze B2 pour le stockage. J’ai réussi à le faire fonctionner, mais seulement partiellement. Lors d’un ./launcher rebuild app, j’ai vu qu’il téléchargeait des ressources, j’étais donc super content que cela semble fonctionner. Après la réussite de la reconstruction, je n’ai pas pu accéder au site. J’obtiens juste des points qui bougent au milieu de la page.
D’après l’article de Backblaze Deliver Public Backblaze B2 Content Through Cloudflare CDN, j’ai configuré un enregistrement CNAME proxy qui pointe vers l’origine de l’URL conviviale f000.backblazeb2.com, appelé gtech-cdn.
CNAME gtech-cdn –\u003e f000.backblazeb2.com
L’article parle également des règles de page ; j’ai essayé de les activer et de les désactiver sans succès.
Voici les éléments de configuration pertinents :
DISCOURSE_HOSTNAME: mmhmm.com
DISCOURSE_CDN_URL: https://mmhmm.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-west-000
DISCOURSE_S3_ENDPOINT: https://s3.us-west-000.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: <secret>
DISCOURSE_S3_SECRET_ACCESS_KEY: <secret>
DISCOURSE_S3_CDN_URL: https://gtech-cdn.mmhmm.com
DISCOURSE_S3_BUCKET: gtech-uploads
DISCOURSE_S3_BACKUP_BUCKET: gtech-uploads/backups
DISCOURSE_BACKUP_LOCATION: s3
Sous la section **hooks:**...
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
L’une des choses qui me trouble est de savoir quoi mettre dans les deux variables DISCOURSE_S3_CDN_URL et DISCOURSE_CDN_URL. Les ai-je correctement configurées en fonction des informations que j’ai fournies ?
En regardant la console des outils de développement du navigateur, je reçois des erreurs 404 sur les scripts .js. L’URL ne semble pas être construite correctement. Ne devrait-elle pas avoir /file/<nom_du_bucket> avant /assets ? Si j’ajoute cela manuellement pour créer une URL correcte, cela fonctionne :
https://gtech-cdn.mmhmm.com/file/gtech-uploads/assets/google-universal-analytics-v4-e154af4adb3c483a3aba7f9a7229b8881cdc5cf369290923d965a2ad30163ae8.br.js
Merci pour toute aide, elle est très appréciée !!!
1 « J'aime »
https://gtech-cdn.mmhmm.com ne se résout pas, c’est donc la première chose à corriger.
Je ne suis pas sûr que vous puissiez utiliser Cloudflare comme CDN de cette manière, mais peut-être que je me trompe.
1 « J'aime »
Désolé, j’aurais dû mentionner que mmhmm.com est un faux domaine. Il répond à un ping.
Pour ce qui est de l’impossibilité d’utiliser Cloudflare comme CDN, je ne suis pas sûr de comprendre. L’article que j’ai lié explique clairement comment l’utiliser comme CDN. Si ce n’est pas le cas, alors encore une fois, quelles valeurs doivent être utilisées pour les deux variables DISCOURSE_S3_CDN_URL et DISCOURSE_CDN_URL ?
Cordialement,
Si vous donnez de fausses URL, vous ne pouvez obtenir que de fausses réponses.
L’URL sert-elle les données attendues ? Pouvez-vous les récupérer à partir de l’URL du forum ?
Je pense que le CDN S3 devrait fonctionner. Il utilise l’URL du forum pour le CDN du forum, mais je ne suis pas sûr.
Un CDN normal est une URL différente de celle du forum et le CDN peut compter sur des données statiques plutôt que de devoir deviner ce qui est dynamique.
1 « J'aime »
Je fais de mon mieux pour ne pas étaler mes informations sur divers forums, alors veuillez excuser mon secret à ce sujet.
Le forum se trouve sur « https://mmhmm.com », qui est un enregistrement DNS Cloudflare qui est proxifié (mis en cache). Avant de configurer Discourse pour utiliser Backblaze, tout fonctionnait correctement.
« https://gtech-cdn.mmhmm.com », comme indiqué précédemment, se résout et répond également à un ping. La cible de l’enregistrement CNAME, f000.backblazeb2.com, se résout également. Cette origine d’URL conviviale B2 est ce que l’article vous demande d’utiliser. Ce n’est pas le problème cependant. Le problème est que Discourse sert des URL pour les fichiers .js en utilisant une URL invalide qui ne fonctionnera jamais car il manque la partie « /file/gtech-cdn » du chemin. Si vous prenez l’une de ces URL .js incomplètes et ajoutez manuellement les informations manquantes, elle chargera le texte du fichier .js sans problème.
Bien sûr, j’essaie toujours de comprendre comment tout cela est censé fonctionner avec ces deux variables. Je suis plus un apprenant visuel et j’aurais vraiment besoin d’un organigramme ou de quelque chose pour m’aider à comprendre ce qui est censé se passer avec les interactions entre Cloudflare CDN, Discourse et Backblaze B2.
Merci de votre aide.
Oh, et j’essaierai de répondre à votre dernière phrase concernant un CDN normal…
L’article de Backblaze vous demande de créer deux règles de page par bucket (dans mon cas, 1 bucket est utilisé), ce qui, si je comprends bien, ressemble à une règle de pare-feu dans la façon dont elle traite.
La règle 1 indique que https://gtech-cdn.mmhmm.com/file/*/* doit utiliser la mise en cache standard (qui est définie ailleurs dans Cloudflare à 1 mois).
La règle 2 redirige tout (302 - redirection temporaire) qui ne correspond pas au modèle de la règle 1.
Donc, tout ne sera pas mis en cache en allant sur mmhmm.com… du moins, c’est ce que je comprends.
EDIT : Cela n’a pas fonctionné.
En me concentrant un peu plus sur ce point, j’ai décidé, pour des raisons évidentes, d’utiliser l’URL S3 comme cible CNAME au lieu de l’URL conviviale suggérée dans l’article de Backblaze. J’attends maintenant que la durée de vie (TTL) de l’enregistrement DNS expire.
Concernant ce hook :
Je ne vois rien concernant S3 dans le dump de rake --tasks. Est-ce toujours pertinent ou est-ce qu’il me manque un plugin ?
Je vois aussi ceci lorsque j’exécute manuellement :
uploads:migrate_to_s3
rake aborted!
FileStore::ToS3MigrationError: Certains uploads n'ont pas pu être migrés vers le nouveau schéma. Vous devez corriger cela manuellement. (FileStore::ToS3MigrationError)
/var/www/discourse/lib/file_store/to_s3_migration.rb:156:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:126:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:106:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:36:in `each_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management.rb:21:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:104:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:100:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3
(See full trace by running task with --trace)
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse#
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse# rake uploads:migrate_to_s3
Please note that migrating to S3 is currently not reversible!
6 messages ont été déplacées vers un nouveau sujet : Cloudflare R2 : Configuration et gestion des erreurs de configuration
On dirait que Cloudflare fonctionne maintenant :
Voir Cloudflare R2: Navigating Setup and Handling Configuration Errors - #13 by pfaffman
2 « J'aime »