Salut, j’ai travaillé avec d’autres personnes pour terminer une migration ad hoc de notre ancien vbulletin3 vers discourse. Il est maintenant temps de commencer à penser à d’autres aspects de la migration, dont le fait que nous avons un compte cloudflare qui dessert notre forum.
Nous aimerions le conserver si possible car notre forum a des tonnes de lurkers (et environ 1000 utilisateurs actifs).
Le seul fil que j’ai trouvé ici qui contient des informations date de 2015, je demande donc s’il existe une documentation “officielle” que j’aurais manquée et qui spécifie comment configurer correctement cloudflare avec discourse.
En second lieu, j’aimerais savoir s’il existe un processus à suivre pour :
que discourse mette à jour les statistiques après la migration
que l’index de recherche de discourse soit “rafraîchi” après la migration
Héberge comment ? Le plus simple est d’utiliser le mode DNS. Si vous voulez passer un peu plus de temps pour très peu de bénéfices, il y a des sujets à ce sujet. La plupart du temps, vous désactivez les optimisations qui cassent Discourse. Si ce que vous voulez, c’est décharger votre serveur, alors un vrai CDN comme bunny.net est la solution.
Je pense que les statistiques et la recherche devraient simplement fonctionner.
Il pourrait être un peu myope d’impliquer que Cloudflare n’est pas un « vrai CDN » ? Parce que ça l’est (et plus encore). Peut-être vouliez-vous dire un CDN « traditionnel » ?
La mise en place d’un CDN traditionnel coûtera beaucoup plus de temps et vous apportera à peu près le même bénéfice.
Et Cloudflare peut être moins cher, car la version gratuite est probablement suffisante pour beaucoup de monde. Il semble qu’il y ait toujours un sujet actif où quelqu’un a cassé son site avec Cloudflare, et le moyen le plus simple de le faire fonctionner semble être de désactiver toute optimisation afin qu’il ne puisse qu’augmenter la latence.
Si vous pouviez créer un sujet décrivant comment configurer Cloudflare de manière à ce qu’il offre les mêmes avantages qu’un CDN traditionnel, ce serait très utile en effet. Peut-être suffit-il de désactiver le rocket loader, mais il semble que la façon exacte de le configurer pourrait être une cible mouvante (car ils changent et améliorent leur produit).
Je suis désolé, je ne veux pas lancer de discussion sur le CDN le meilleur, etc.
Je n’ai pas encore obtenu plus d’informations moi-même, mais d’après ce que je comprends, le forum utilise actuellement un plan payant (donc pas l’option gratuite, je suppose), mais même ainsi, ce n’est pas le problème.
Question simple → Que dois-je faire pour configurer Cloudflare afin qu’il ne dérange pas Discourse ?
Après cela, je serai plus qu’heureux de comprendre si c’est même quelque chose de vraiment nécessaire ou non (c’est-à-dire les avantages, etc.)
Aussi, si quelqu’un peut me donner un lien ou quelque chose concernant les deux autres questions mineures, ce serait génial
Je vais utiliser la semaine prochaine pour effectuer des tests dans un environnement de staging, donc rien n’est gravé dans le marbre !
Si vous êtes hébergé par discourse.org, ou par quelqu’un d’autre, d’ailleurs. Vous devriez vérifier auprès d’eux avant de faire quoi que ce soit avec cloudflare. Généralement, vous créez simplement un CNAME DNS qui pointe vers leurs serveurs. Discourse.org a déjà des CDN en place, vous n’avez donc pas à vous inquiéter.
Merci @pfaffman, c’est auto-hébergé. Comme je l’ai dit, il est utilisé pour le forum vbulletin actuel qui sera simplement mis hors ligne et remplacé par discourse qui répondra à partir du même nom de domaine.
Cela dépend du rôle que vous souhaitez que Cloudflare joue (le cas échéant).
Si vous souhaitez simplement utiliser Cloudflare comme DNS, assurez-vous que le nuage orange est désactivé pour l’enregistrement « a » du forum.
Si vous souhaitez réellement envoyer le trafic Discourse sur le réseau de Cloudflare et que vous acceptez la latence supplémentaire qu’il ajoute, créez au minimum une règle de page pour « Désactiver les performances » pour l’ensemble du domaine du forum. Aucune des optimisations de performance de Cloudflare n’est recommandée et elles sont connues pour casser des sites.
Notez qu’il existe un modèle Cloudflare qui doit être ajouté à votre app.yml, il transmettra le CF-Connecting-IP comme adresse IP client, de sorte que vous ne verrez pas tout le monde provenir d’un nœud de leur réseau.
Si vous n’utilisez pas de stockage basé sur des objets et que vous exécutez avec le nuage orange activé, vous pouvez créer une règle de mise en cache pour votre chemin d’accès aux actifs.
Cloudflare était (eh bien, l’est toujours pour l’instant) utilisé pour ne pas surcharger le serveur web réel avec des requêtes.
Je me demandais surtout, avec la nature des mises à jour en temps réel de Discourse (je suppose que c’est du websocket ? je n’ai pas vérifié) comment cela pourrait poser problème avec quelque chose comme la mise en cache de Cloudflare et tout ça. C’est pourquoi je me demandais s’il y avait des documents ou si quelqu’un avait des conseils
Je ne sais rien et c’est pourquoi je suis si perdu de temps en temps, mais il semble que vous recherchiez la nature de PHP, mais vous obtenez la nature d’une application JavaScript où tout, sauf l’obtention de données réelles, se déroule sur l’appareil de l’utilisateur.
C’est la raison (et mes compétences limitées) pour laquelle mes tentatives de mettre Varnish devant Discourse ont échoué si lamentablement.
Bien sûr, vous pouvez servir des actifs depuis un CDN, mais c’est tout.
Right, Cloudflare n’est pas en mesure de faire quoi que ce soit pour réduire la charge du serveur d’application. En tant qu’application javascript d’une seule page, Discourse n’en tire vraiment aucun avantage.
La situation empire, car placer Discourse derrière Cloudflare ajoute des sauts réseau pour chaque requête entre l’application dans le navigateur et le serveur, ce qui augmente légèrement les temps de réponse.
Gardez-vous les téléchargements sur le serveur, ou utilisez-vous S3/une alternative de type S3 ?
Je n’en sais pas assez sur la conception de Discourse, mais je pense que la présence de Redis gère déjà une partie de la mise en cache des requêtes courantes. Cela explique le fait que « Cloudflare n’est pas vraiment nécessaire ».
Donc, est-ce que je comprends bien qu’il y a peu ou pas d’avantage à avoir Cloudflare devant une installation Discourse, et au contraire, cela ralentirait la réponse (sauts réseau) ?
La seule raison pour Cloudflare pour l’installation vbulletin3 était que la quantité de requêtes submergerait le serveur et (je suppose ici) pourrait être due au mauvais travail dans la conception du code de vbulletin3 pour être honnête, car la VM qui l’héberge a 4 cœurs, 8 Go de RAM rien que pour l’application elle-même et une autre VM de spécifications égales pour la base de données.
Il n’y a aucun moyen qu’une application web moderne ait besoin d’autant de puissance aujourd’hui.
En parlant de cela, existe-t-il une référence que je puisse consulter pour évaluer la quantité de matériel dont j’aurais besoin pour une installation Discourse qui compte en moyenne environ 1 000 utilisateurs actifs et environ 5 à 6 000 lurkers ?
Ce n’est pas tout à fait vrai. Surtout lors du premier chargement, Cloudflare peut accélérer le chargement des ressources statiques Javascript. Et c’est exactement l’une des choses que Google examine pour décider si votre site est suffisamment performant pour éviter une pénalité de référencement. Les avantages sont plus importants lorsque vous avez un forum marketing qui attire des utilisateurs des moteurs de recherche, et les inconvénients sont plus importants lorsque vous avez un forum avec un groupe d’utilisateurs actifs et récurrents.
Non, car cela dépend vraiment de savoir si ces utilisateurs sont très actifs ou s’ils visitent une fois par jour. J’ai vu un groupe de moins de 50 personnes échangeant de grandes photos et utilisant Discourse comme une boîte de chat toute la journée mettre à genoux du matériel très performant, tandis que j’ai aussi vu un forum avec 10 000 personnes qui venaient poster quelque chose une fois par semaine et plus de 30 millions (!) de spectateurs fonctionner sur un VPS médiocre.
Merci pour votre perspicacité et vos informations @RGJ, je suppose que je vais juste surveiller et nous verrons comment les choses se passent. J’espère que cela ne nécessitera pas une augmentation massive des exigences par rapport au logiciel précédent
