Point Dev – CloudFlare, c’est quoi, et comment l’utiliser ?

Nouvel article sur CloudFlare, dont j’ignorais l’utilité il y a encore un mois. Merci e-t172 pour la recommandation et l’explication, à l’origine de ce choix.

Donc, d’abord, c’est quoi CloudFlare ?

Cette entreprise propose de se greffer entre le client et le serveur web, comme l’indique ce schéma :

Image reprise chez CloudFlare

Leur service agit comme un proxy : depuis qu’on l’utilise, le contenu servi sur nofrag.com (pas le html, mais les images ou les feuilles CSS) est distribué par CloudFlare.

L’objectif est triple :

  • réduire le temps de latence (CloudFlare propose un réseau distribué qui va servir le contenu de différents serveurs en fonction de votre localisation),
  • réduire la bande passante traitée par le serveur web (on n’envoie plus que le HTML, à peu près),
  • limiter l’impact des attaques des hackerz sur notre système.

Last but not least : leur service est gratuit pour des besoins basiques.

Et comment l’utiliser avec WordPress ?

C’est tellement simple.

  1. S’inscrire à Cloudflare.
  2. Cette étape varie d’un nom de domaine à l’autre, mais il faut modifier les entrées DNS chez  votre fournisseur pour que votre nom de domaine utilise le DNS de CloudFlare.
  3. Installer cette extension sur votre WordPress.

Concernant la configuration de cette dernière, elle est simple :

Il faut d’abord récupérer la clé d’API globale de CloudFlare, disponible dans votre profil :

Cette clé est à recopier, accompagnée de votre adresse e-mail,  sur la première page de configuration de l’extension, visible dans Réglages / CloudFlare :

Vous aurez ensuite un écran avec :

  • un bouton « Apply » qui va configurer WordPress avec CloudFlare.
  • un bouton « Purge Cache » pour vider le cache CloudFlare (pour une raison ou une autre)
  • un bouton pour activer le mode « Je suis attaqué » qui permet demander à CloudFlare d’instaurer un time-out de 5 secondes avant d’accéder à chaque page de votre site, pour limiter l’impact d’une attaque de type DDOS.

Dans les réglages avancées, on trouve de quoi activer un mode « Développement » pour chuinter le cache CloudFlare le temps que vous peaufinez un thème ou un changement sur une CSS, un réglage pour activer le mode « Toujours en ligne » qui servira le cache CloudFlare même si le site est HS, et c’est à peu près tout.

Enfin, la rubrique Analytics permet d’avoir un aperçu de la quantité de données « économisée » de par l’utilisation de leur cache.

Pour avoir un ordre d’idées, sur un mois, nous avons fait passer 363 Gb / 436 Gb par CloudFlare, le reste étant traité par notre serveur.

Notez la présence de plans payants (mais chers), qui permettent d’aller beaucoup plus loin, mais je pense que leur utilité fait que cette offre est réservée à de très gros sites.

 

 

Point Dev – Comment configurer le cache sur WordPress ?

Dans ce Point Dev, voyons comment configurer correctement le cache sur WordPress.

Pourquoi un cache ? Décharger le serveur web et la base de données (et donc payer moins cher Amazon), éviter que le nombre de visiteurs ait un impact sur les performances du site. Tout cela n’a de réel intérêt qu’à partir du moment où le site a un nombre important de visites quotidiennes.

Alors c’est parti. On installe WP Super cache, activation, et rendez-vous dans réglages / WP Super Cache.

Dans Avancé, voici nos réglages :

  • Mise en cache : coché
  • Cache Delivery Method : simple
  • Dans divers sont cochés :
    • Ne pas mettre en cache les pages pour les utilisateurs connus
    • Don’t cache with GET parameters
    • Compresse les pages afin qu’elles soient servies plus rapidement aux utilisateurs
    • Reconstruction du cache
  • Dans avancé sont cochés :
    • Mobile device support
    • Clear all cache files when a post or page is published or updated.
    • Rafraîchir uniquement la page courante lorsqu’un commentaire est effectué.
  • Dans cache location : saisir le répertoire sur le serveur où le cache sera stocké. Attention à ne pas oublier le / de début.
  • Dans cache Location :
    • Cache timeout est fixé à 600s. Cela signifie qu’un visiteur non connecté verra une page ayant un âge de maximum 15 minutes.
    • Scheduler : on l’a fixé également à 600s.

En ce qui concerne les autres onglets, on n’a rien activé. Attention au  choix  d’activer le préchargement (dans l’onglet du même nom) qui est potentiellement très gourmand en CPU.

Avec ces réglages, vous bénéficierez d’un premier niveau de cache permettant de limiter les impacts en performance ou financiers d’un nombre de visites important.

 

La genèse de Nofrag V2 – Présentation de l’Architecture Applicative

Dans l’article précédent, nous avons vu l’architecture technique sur le cloud Amazon. Maintenant, intéressons-nous à l’architecture applicative.

Dans l’article précédent, nous avons vu l’architecture technique sur le cloud Amazon. Maintenant, intéressons-nous à l’architecture applicative.

Continuer la lecture de « La genèse de Nofrag V2 – Présentation de l’Architecture Applicative »

Point Dev – Comment unifier WordPress et PhpBB ?

Elle est bien moche mon image, hein ?

Dans ce premier Point Dev nous allons voir comment permettre à un forum PhpBB de se connecter à WordPress. Ces deux produits ne sont absolument pas prévus pour communiquer ensemble à l’origine.

Pour cela, on utilise l’extension WordPress BridgeDD, qui est la seule à proposer ce service. Les autres extensions existantes généralement la l’unification des utilisateurs, mais pas la création d’un topic depuis WordPress ni l’affichage de commentaires issus du topic du forum (fonctionnalité appelée Cross-Posting).

Continuer la lecture de « Point Dev – Comment unifier WordPress et PhpBB ? »

La genèse de Nofrag V2 – Introduction et Architecture Technique

Il y a quelques semaines, DrLoser  m’a suggéré de rédiger un papier sur le développement de la V2 de Nofrag, qui s’est étalé de début septembre 2017 avec un gros chantier sur le forum, suivi par le nouveau site de news, jusqu’à l’ouverture des nouveaux blogs courant janvier 2018.

L’idée est de rédiger une série d’articles présentant l’architecture technique et applicative, ainsi que des tutoriaux détaillant chaque composant.

A la fin de cette série d’articles, vous aurez à votre disposition un socle logiciel permettant de faire de la publication d’articles sur un site de news, l’hébergement d’un forum, de blogs pour les besoins d’une communauté.

On va commencer par une description de l’infrastructure, résumée par ce schéma.

Nous avons créé une machine virtuelle fonctionnant sur Ubuntu et dont l’image est positionnée dans une AMI. Cette AMI est un cliché de la machine à un instant T, qui a besoin d’être associée à une instance EC2 pour prendre vie. L’EC2, c’est le terme choisi par Amazon pour parler d’une machine virtuelle. La configuration de l’EC2 est de type t2.medium : 2CPU et 4Go de RAM. Cette EC2 est positionnée dans une Auto Scaling Group, qui est un composant permettant de paramétrer le nombre d’instance EC2 simultanées et du même coup protège notre infrastructure des plantages : si une EC2 plante, l’Auto Scaling Group se charge de redémarrer une instance avec son contenu d’origine dans l’AMI et une configuration lui permettant de récupérer le contenu qui a évolué depuis la création de l’AMI.

Car oui, si nous nous arrêtions là, à chaque redémarrage d’une instance, tout le contenu de la machine qui aura évolué entre temps est perdu. Il est donc nécessaire de gérer le stockage du contenu qui évolue et qu’on doit conserver.

Ainsi, pour le contenu des différents sites (Nofrag, Forums, Wiki, Blogs) , nous utilisons le produit S3 de Amazon, qui permet le stockage de données sur le cloud. Nous synchronisons régulièrement le contenu des sites sur S3, et lors d’un redémarrage de l’EC2, ce contenu est redescendu sur l’instance afin d’avoir les fichiers les plus récents.

L’adresse IP de nofrag.com est affiliée à l’Auto Scaling Group pour avoir accès en permanence à l’instance EC2 en cours depuis l’IP associée au nom de domaine.

Concernant la base de données, RDS (managée sous AWS), et sous MariaDB, elle n’est pas hébergée sur l’EC2 mais sur une machine dédiée, elle n’est pas dans l’Auto Scaling Group car elle se gère toute seule, notamment en terme de maintenance. Ce choix s’est fait pour des raisons de performances et de sécurité. Il s’agit d’une  t2.small : 1CPU et 2Go de RAM. De par l’utilisation de plusieurs caches, son taux d’utilisation est relativement faible.

Tout ce petit monde est défini dans une Availability Zone, qui permet de choisir le datacenter sur lequel sera stocké nos composants. On trouve également la notion de region, qui est la zone géographique où l’on héberge nos composants. Ces deux parties ne sont pas neutres car elles ont de l’influence sur la manière dont sont traitées les données légalement, et sur le montant de la facture. En effet, il est important de définir des zones et datacenters communs.

Rassurez-vous, nos données sont en Europe.

Bilan

Me concernant, j’ai trouvé hyper enrichissant l’utilisation du cloud Amazon, d’un point de vue personnel mais aussi professionnel. C’est très performant, quoique pas toujours clair.

Nous n’utilisons qu’une infime partie des fonctionnalités proposées, comme vous pouvez le voir dans cette petite liste. Si un jour on veut se lancer dans les learning machine, on a ce qu’il faut !

Voilà pour l’infrastructure technique, prochain article sur l’architecture applicative.