J’ai donc configuré un bucket Amazon S3 pour stocker les assets de mon forum, je l’ai lié à un domaine personnalisé et j’ai configuré CloudFlare CDN pour mettre en cache le contenu.
Tout fonctionne correctement. Si j’ajoute une image dans le dossier principal du bucket, je peux la récupérer via mon URL personnalisée, c’est-à-dire que http://forum-storage.com/test.jpg renvoie l’image, avec les en-têtes CloudFlare.
Trois questions simples…
#1
Maintenant, je dois indiquer à Discourse d’utiliser cette nouvelle URL comme bucket S3. Que dois-je saisir dans ces 3 champs ?
J’ai actuellement des images dans les messages de mon forum qui sont stockées dans un autre bucket S3, et j’ai aussi des images stockées localement. (Mes URLs d’images sont très dispersées.)
Une fois que j’aurai apporté les modifications appropriées (ci-dessus), cela signifie que tous les NOUVEAUX médias ajoutés à mon forum iront dans le nouveau bucket, mais les images existantes ne seront pas déplacées et continueront d’être accessibles là où elles se trouvent actuellement, n’est-ce pas ?
#3
Maintenant que cela fonctionne pour toutes les images à partir de maintenant, comment puis-je demander à Discourse de DÉPLACER toutes les anciennes images qui ne sont pas dans ce nouveau bucket vers ce nouveau bucket (et de reconstruire les messages si nécessaire) ?
L’objectif est de tout regrouper dans un seul bucket, ce nouveau bucket derrière le CDN.
Créez un nouveau bucket dont le nom ne contient pas de point. Vous rencontrerez des souffrances sans fin si vous continuez, en raison du fonctionnement des certificats SSL génériques.
Hmm, c’est sympa, mais vous souhaitez placer un CDN, par exemple CloudFront, devant le bucket, qui recevra le nom de domaine personnalisé (CNAME). Ce n’est donc pas une fonctionnalité utile pour le moment.
L’absence de CDN vous exposera à la même facture de transfert exorbitante.
Exactement. Je pense que nous sommes sur la même longueur d’onde ? Pour être plus clair, tel que je le comprends, il existe trois façons de connecter Discourse et S3 :
Faire en sorte que Discourse utilise directement le cloud S3. Avantage : très facile à configurer. Inconvénient : devient rapidement coûteux.
Faire en sorte que Discourse utilise le cloud S3 via un nom de domaine personnalisé (comme forum-storage.com) afin que je puisse utiliser un CDN. Avantages : très facile à configurer avec S3 si le nom du bucket correspond exactement au nom de domaine personnalisé (c’est-à-dire forum-storage.com.s3-amazon-aws.com). Inconvénients : le certificat SSL pose problème.
Faire en sorte que Discourse utilise le cloud S3 via un nom de domaine personnalisé (là encore, pour utiliser un CDN), mais configurer le bucket S3 de sorte qu’il n’y ait pas de point supplémentaire dans le nom (c’est-à-dire forum-storage-com.s3-amazon-aws.com). Avantages : le certificat SSL fonctionne. Inconvénients : pas aussi facile à configurer avec Amazon S3.
Donc… j’utilisais la méthode #1 jusqu’à ce que je reçoive la facture puis j’ai appris que la #2 était une option, je l’ai configurée, j’ai lancé ce sujet, et j’ai immédiatement appris que la #2 n’était pas vraiment une option.
Maintenant, je travaille sur la #3. Je pense que je dois utiliser le service DNS “Route 53” d’Amazon, ou quelque chose du genre. Je m’embrouille encore un peu. Toutes mes recherches sur Google renvoient des informations sur la façon de faire la #2, mais personne ne semble avoir écrit d’instructions claires pour la #3.
Veuillez me corriger si je me trompe ou si je mal compris quelque chose…
J’ai ajouté un enregistrement CNAME pointant vers l’URL <long id>.cloudfront.net de la distribution Cloudfront CDN dans notre configuration DNS pour bokeh.org (qui est hébergée sur Cloudflare dans notre cas, mais cela ne devrait pas avoir d’importance).
À titre de référence, notre bucket S3 ne contient aucun point dans son nom, mais je ne me souviens d’aucun problème spécifique lors de la configuration du CDN pour cette raison (ni lors de la création du bucket, qui nécessite simplement un nom unique).
C’est, sans aucun doute, la chose la plus frustrante qui soit. Je ne parviens absolument pas à comprendre comment faire fonctionner ensemble un bucket Amazon S3 (sans point dans le nom du bucket !), mon domaine personnalisé et CloudFlare. Si je pouvais mettre un point dans le nom du bucket, ce serait simple. Mais pour l’instant, tout est trop confus. Ughhhhhh, quelqu’un peut-il m’aider ou me montrer un moyen simple de configurer CloudFlare avec un bucket S3 qui n’a pas le même nom que le domaine ?
J’ai essayé les informations StackPath ci-dessus — je pense avoir fait quelque chose de similaire dans CloudFlare, mais je ne suis pas certain. Ça n’a pas marché. J’ai lu les informations de CloudFlare sur l’ajout du CDN à un bucket Amazon, mais bien sûr, ils veulent que le nom du bucket corresponde au nom de domaine, ce qui, m’a-t-on dit, est une Très Mauvaise Idée et je ne peux pas le faire.
Ça semble vraiment se résumer à ceci :
Si le nom du bucket correspond au nom de domaine (avec un point), Amazon S3 s’occupe de tout pour moi, c’est magnifique, sauf que cela pose des problèmes avec SSL, donc je ne devrais pas le faire.
Si le nom du bucket ne correspond PAS au nom de domaine, tout devient massivement plus compliqué et je n’arrive pas à résoudre le problème.
Quelqu’un peut-il m’aider ou me conseiller ? En attendant, je reçois des factures de plus de 100 chaque mois pour mon stockage S3. C'est vraiment pénible. Puis-je payer quelqu'un 200 maintenant pour régler tout ça ? Blargh.
L’avez-vous déjà lu ? J’ai aussi eu du mal à configurer S3 et Cloudflare, mais j’ai fini par trouver la solution. Vous pouvez toujours utiliser Cloudflare pour ses avantages en matière de sécurité, mais je suis presque certain que vous aurez également besoin d’un service CDN séparé. Cloudflare ne fonctionne pas comme un CDN classique, son mode de fonctionnement est différent. Vous devriez passer à un service S3 moins cher, Amazon est coûteux.
L’utilisation de Cloudflare pour mettre en cache un bucket S3 implique de manipuler l’en-tête d’origine dans les requêtes. Cette fonctionnalité est disponible dans le plan entreprise de Cloudflare, il est donc plus simple d’utiliser un autre CDN.
Est-ce que le point dans le nom du bucket est vraiment pertinent s’il va mettre en cache les images via un CDN de toute façon ? La seule chose qui compte, c’est d’avoir un bon certificat qui couvre les images servies par Cloudflare.
Je pense qu’il doit se concentrer sur les serveurs Cloudflare, le DNS et le certificat pour couvrir ces éléments. Je ne pense pas que l’utilisateur ou le navigateur saura jamais que la source de ces images est un bucket S3. Cloudflare va bien mettre en cache et faire office de proxy pour l’image elle-même, non ?
Discourse générera des URL directes vers les buckets et les utilisera pour les opérations internes, telles que « l’envoi d’un fichier ». Cela reste important.
@riking Tout ce que Discourse semble exiger, c’est un nom de bucket, n’est-ce pas ? Le téléchargement et la gestion peuvent être effectués via des URL AWS avec leurs certificats, si HTTPS est même requis. Jusqu’à présent, y a-t-il une raison de parler de certificats de sécurité ?
Ensuite, l’OP peut examiner séparément ce qu’il doit faire pour permettre à son CDN ou à sa solution de mise en cache de récupérer les images depuis S3. Sécurisé ou non, cela n’a pas d’importance sauf si l’OP ou le CDN ont des exigences spécifiques, non ? Discourse se soucie-t-il de sa configuration entre S3 et le CDN ?
Enfin, l’OP doit s’assurer que les images sont servies par le CDN avec un certificat valide. Cela a-t-il un rapport avec Discourse autre que le fait que l’OP fournisse l’URL de base où résideront finalement les images ? Une fois que son CDN ou son cache a récupéré les images depuis S3, alors AWS, les buckets, et tout le reste sortent complètement de l’équation.
Je comprends qu’il y ait des problèmes liés à un point dans les noms de buckets S3 si vous avez l’intention de servir vos images depuis là, mais l’OP ne le fait PAS. Il ne s’agit donc que de l’OP choisissant n’importe quel nom de bucket que Discourse acceptera, tant qu’il n’interfère pas avec sa configuration avec le CDN.
Même s’il est possible d’éviter les URL de type « bucket-in-domain », cela n’est pas réellement évité en raison de la façon dont le SDK AWS S3 est utilisé et des difficultés de configuration.
Encore une fois, ces opérations contournent le CDN ; la seule façon de les corriger est de modifier le code source de Discourse. Elles peuvent être corrigées, mais ne le sont pas actuellement. De nombreux problèmes ne se produisent également pas sur le chemin critique et n’apparaissent que plus tard. Par conséquent, tant que cela ne changera pas, n’utilisez pas de noms de bucket contenant des points.
Résumons donc cela de manière ultra-simple… La question de l’OP était de savoir quoi remplir dans trois paramètres à configurer :
(1) NOM DU BUCKET — on dit donc que les points ne sont pas… recommandés ? interdits ? Je soupçonne que cela ne devrait pas poser de problème à l’OP. (Il doit juste trouver séparément un moyen pour que son CDN mette en cache et diffuse les images.) Donc, on est tous d’accord sur ce point, n’est-ce pas ?
(2) POINT DE TERMINAISON S3 — laisser vide, rien n’est nécessaire s’il utilise AWS, sinon il peut le remplir pour un autre fournisseur ?
(3) URL CDN S3 — s’agit-il simplement de l’URL de base que Discourse préfixera au chemin de l’image ? Si oui, c’est simple et direct, et l’OP peut configurer son CDN et fournir cette URL de base ici.
Je ne vois pas en quoi les certificats SSL génériques entrent en jeu ici. On a dit à l’OP qu’un point dans la configuration de Discourse est mauvais car il cassera son certificat. Mais s’il utilise un CDN ou un cache, le nom du bucket pourrait très bien être sans rapport avec le certificat, n’est-ce pas ? S’il va casser Discourse d’une autre manière, c’est utile de le savoir.
Je ne suis pas sûr de bien suivre tout cela de si près, mais pour prendre un peu de recul, peut-être que cet ensemble simple d’exigences aide :
Les objectifs :
Ne pas stocker mes images Discourse sur mon serveur Discourse
Avoir un bucket S3 pour stocker les images (doit être S3 car c’est ce que Discourse prend en charge)
Éviter des frais S3 coûteux
Un CDN n’est pas obligatoire, mais c’est un bonus agréable car il peut aider à réduire (ou être le seul moyen d’éliminer) les frais S3 coûteux et offre également une meilleure disponibilité mondiale, une sauvegarde au cas où le serveur principal serait hors ligne, etc., etc.
Veuillez me corriger si l’une de ces affirmations est erronée
Limites/exigences :
Le stockage d’images externe doit prendre en charge le protocole S3 (car c’est ainsi que Discourse fonctionne), mais, strictement parlant, n’a pas besoin d’être Amazon S3.
Discourse exige que le nom du bucket S3 ne contienne pas de points.
La source des images (S3 ou CDN) doit servir du contenu en https://, car un navigateur signalera une erreur si la page est en https mais que les images ne le sont pas.
Veuillez me corriger si l’une de ces affirmations est erronée
Solutions :
Auparavant, je servais directement depuis Amazon S3. Cela fonctionnait très bien, sauf que les frais d’Amazon pour DataTransfer-Out-Bytes étaient extrêmement élevés. Cela a entraîné des factures mensuelles élevées de la part d’Amazon ! J’ai donc tout ramené sur le serveur principal. Deux solutions possibles : placer un CDN devant le bucket Amazon S3 afin que le CDN gère tout le transfert de données, et/ou changer de fournisseur S3.
J’ai essayé de mettre le CDN CloudFlare au-dessus du bucket Amazon S3, mais j’ai rapidement rencontré de nombreux problèmes que je n’ai pas pu résoudre.
Une autre option ?
Je viens de regarder cette offre de stockage compatible S3 de Digital Ocean. CDN intégré (je ne sais pas exactement ce que cela signifie, mais cela semble prometteur), tarifs avantageux. Cela fonctionnerait-il avec Discourse ?
Pour référence, j’ai servi environ 300 Go depuis S3 au cours des 30 derniers jours. Une partie de cela correspond à des sauvegardes de site, une grande partie à des images statiques. Il est TRÈS difficile pour moi de déterminer comment mesurer ces éléments chez Amazon… leur interface de rapport de facturation — comme tout le reste chez Amazon AWS — est vraiment confuse à administrer.
Je pense que la solution la plus simple consiste à utiliser AWS et KeyCDN, en suivant les recommandations de Utiliser le stockage objet pour les téléversements (S3 et clones). Si vos utilisateurs ne se trouvent pas en Amérique du Sud, KeyCDN est assez abordable et facile à configurer.
Une solution potentiellement moins coûteuse pourrait être Comment configurer BackBlaze S3 avec BunnyCDN. J’ai été satisfait de BackBlaze lors de mes premiers tests pour les sauvegardes, mais je ne l’ai pas encore essayé pour les téléversements.
Nous avons été terriblement distraits par un point dans un nom de bac et les certificats de navigateur, mais je pense que toute cette discussion est complètement hors de propos. N’importe quel CDN permettra une configuration HTTPS, donc il n’y a AUCUN PROBLÈME avec le problème du « certificat générique » et la présence ou non d’un point dans le nom du bac EN CE QUI CONCERNE LE CERTIFICAT DE NAVIGATEUR DE L’UTILISATEUR FINAL. Car encore une fois, n’importe quel CDN permettra certainement cela.
Donc, l’OP peut simplement…
(1) choisir une solution de stockage compatible S3 et CDN, puis configurer le point de terminaison et le nom du bac dans les paramètres de Discourse.
(2) Configurer le CDN pour récupérer les images depuis S3. Sécurisé ou non sécurisé. Je ne pense pas que cela importe à l’OP tant que le CDN sert les images à l’utilisateur via HTTPS.
Quelqu’un peut-il me corriger si j’oublie quelque chose ici ? Je pense que le problème du certificat de navigateur de l’utilisateur final combiné au point dans le nom du bac n’est un souci QUE si vous servez les images DIRECTEMENT depuis le bac. Cela est sans rapport avec le service via un CDN.
P.S. Ce sujet, que @pfaffman a aimablement lié ci-dessus, indique que le produit S3 de Digital Ocean (« Spaces ») possède un CDN « extrêmement défaillant ». Configure an S3 compatible object storage provider for uploads Et je vois que pour d’autres fournisseurs S3, il faut ajuster divers paramètres. Ce qui me dit ceci : - Les paramètres varient d’un fournisseur à l’autre, même s’ils prétendent tous suivre le protocole « S3 ».
ARRÊTEZ IMMÉDIATEMENT 
Merci pour l’info, 
puis j’ai appris que la 
N’ajoutez PAS de point (période) dans le nom de votre bucket