Changer ses permaliens sans tout exploser

Sujet récurrent depuis la refonte en 2017, la structure des liens des articles (permalien, permalink…) de Nofrag étaient basée sur le magnifique schéma suivant : /YYYY/MM/JJ/<id>

Sauf que ça n’a rien de SEO friendly, en 2020 on attend plutôt le titre de la news que ce schéma qui n’a quasiment aucune valeur informative. En plus, on donne directement une indication de la date de l’article : le lecteur peut estimer qu’une information ancienne n’est plus vraie et qu’elle ne mérite pas d’être lue. Ce n’est pas mon avis hein.

Changer les permaliens c’est simple, mais il faut gérer les liens existants. On parle d’environ 56000 liens vers des news pour le patrimoine de Nofrag. Si on ne prend pas le temps de réfléchir à cette question, on perd gros en référencement : des 404 à tour de bras ça fait mal auprès de Google.

On a installé le plugin Redirection, qui permet de faire…. Des redirections. Pour tester ses redirections avant de les enregistrer sous nginx c’est plutôt pratique.

La première idée a été d’aller pomper sur la base de données les URL existantes de chaque news, de sorte d’avoir un résultat de ce type par news :

"^/2005/04/02/16896/*","https://nofrag.com/preview-de-pariah/"

Et après d’importer ça dans redirection via l’outil d’import.

Ça marchait au début, mais le site a explosé cette nuit juste après avoir fait l’import  : 56000 lignes à faire gérer par le plugin, c’était trop lourd. J’ai ensuite pensé faire faire ce travail par nginx, mais pareil, 56000 rewrite rules, il n’aime pas DU TOUT.

Ce matin, j’ai eu l’idée au réveil d’utiliser les Regex. Couplée à l’utilisation de l’url https://nofrag.com/?p=ID, qui redirige vers la page d’un article à partir uniquement de son ID, c’était tout simple. Encore fallait il connaître l’existence de cette url, merci StackOverFlow.

L’expression régulière suivante nous a permis de récupérer l’identifiant de la news :

^/[0-9]{4}/[0-9]{2}/[0-9]{2}/([0-9]*)

On redirige ensuite vers la page suivante :

https://nofrag.com/?p=$1

L’idée étant qu’on récupère la partie en rouge (grâce à l’utilisation des parenthèses), et qu’on la recolle dans l’url de destination avec la mention $1.

Pour aller plus loin, on va définir une règle toute bête sous nginx sur la conf de notre site :

rewrite ^/[0-9]{4}/[0-9]{2}/[0-9]{2}/([0-9]*) https://nofrag.com/p=$1 permanent;

Ce qui nous permettra de nous débarrasser du plugin WP et gagner un peu de mémoire.

2020, quelques évos techniques chez Nofrag

Mise en contexte : 08h du matin, un samedi, on reçoit pour la n-ième fois un mail comme quoi le nombre de crédits EC2 de la machine est en baisse et s’approche inexorablement du moment où elle passe en mode dégradé (performances de merde).

Sauf qu’on est déjà sur une machine de type EC2 Large, qui répond à nos besoins 90% du temps.

Schéma de notre infra avant les modifications :

Les sites sont hébergés sur une machine (T2 Large) qui pointe vers la base de données.

Donc l’objectif de cet article, c’est de passer à cette infra.

aws NF

Petite description rapide. 

On passe à plusieurs EC2 de type T2 small (donc à l’unité moins chères que la T2 Large), dont le nombre varie en fonction du trafic, via l’utilisation d’un ASG (Auto Scaling Group). Les données communes aux EC2, à savoir les images du site et des blogs, sont à partager entre elles et stockées sur un espace EFS (Elastic File System), illimité en espace disque.

Pour répartir le trafic sur ces différentes instances EC2, on configure un load balancer, appelé chez AWS Elastic-Load Balancing (ELB).

Bascule des médias sur EFS

Pour cela, on crée un EFS sur AWS. Ca se fait en 3 minutes.

Ensuite, on se connecte à ce partage EFS sur la machine EC2 en cours :

mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,fsc [URL_EFS]:/ /mnt/efs

Puis sur chaque site, on copie les uploads vers un sous répertoire de /mnt/efs, et on remplace le répertoire uploads par un lien symbolique du même nom pointant vers /mn/efs/<sous-répertoire dédié au site>.

On modifie le fichier /etc/fstab pour se connecter au partage EFS dès le démarrage de la machine.

Et c’est tout ! Au passage, on réduit l’espace occupé par l’EC2 de 50 Go à moins de 10 Go. On recrée une image AMI, qui servira de point de référence pour nos petites EC2 auto-managées.

Création de l’Auto Scaling Group

Pour cela, on crée une « configuration de lancement » basée sur l’AMI nouvellement créée. On se contentera d’une typologie de type T2 Small. On pense à cocher la case « Supprimer à la résiliation » dans la partie Stockage, pour supprimer les volumes à chaque destruction d’EC2.

Ensuite, création de l’auto scaling group, avec pour configuration de lancement celle que l’on vient de créer à l’instant. Pour l’instant on la dimensionne à 1 avec une limite à 6, et on définit une stratégie de dimensionnement, qui va nous servir par la suite avec le load-balancer. On est parti sur un taux d’occupation CPU à 30%, ce qui permet de garder une quantité de crédits EC2 stables (ils commencent à descendre à partir de 20%).

Et ? C’est tout. L’auto scaling group se crée et lance une première EC2.

Création du load-balancer

Le load-balancer gère le trafic entre n EC2. Ces EC2 doivent être positionnées dans un ou plusieurs groupes cibles, qui sont ensuite contactés par le load-balancer pour prendre des appels HTTP/HTTPS.

Donc on commence par créer deux groupes cibles, un pour le http et un pour le https. On retourne ensuite dans l’auto scaling group nouvellement créé pour positionner le nom des deux groupes cibles dans la zone idoine de l’auto scaling group, afin que les EC2 soient déclarées immédiatement dans le groupe cible de l’ELB à leur création. Au passage, on active le « type de vérification de l’état » sur ELB : cela permet de se fier à la réponse du serveur nginx comme critère de bonne santé d’une EC2. Si nginx ne répond plus : on tue l’EC2.

Pour ce qui est de la création de l’ELB, c’est simple, on choisit un ELB de type « applicatif » qui va gérer le trafic http et https. Il faut savoir au passage que Amazon propose des certificats HTTPS gratuitement dès lors qu’on utilise un ELB. Donc on en profite, et on choisira de s’en remettre à AWS certificate manager pour la gestion du certificat HTTPS au niveau du load-balancer. On envoie tout le trafic http vers le groupe cible http, idem pour le https. Et c’est tout.

Lors de la création de l’ELB, AWS crée un nom de domaine de type .elb.amazonaws.com. Pour rediriger le trafic entrant vers l’ELB, il suffit d’ajouter une entrée de type CNAME dans le DNS qui va pointer vers ce domaine aws. Au passage on retire toutes les entrées A pour ne plus avoir d’accès IP directe pour le site nofrag.com. Pour notre part, on a fait ces modifications sur CloudFlare.

Et c’est tout.

Bilan

On gagne en robustesse. L’infrastructure s’adapte dynamiquement à la demande. Le graphe ci-dessous montre l’adaptation de l’auto-scaling group à l’occupation CPU sur 3 jours.

Nous avons fait un test de charge, qui s’avère plutôt correct. Pour les plus curieux, ça se passe ici.

Reste à voir l’impact en terme de coût, on verra ça dans quelques semaines.

Afficher un Live Twitch sur WordPress

 

Pour résumer : ne touchez pas aux extensions WordPress qui proposent d’afficher un live Twitch. En tout cas à ce jour (fin août 2018), aucun n’est fiable : nombreux sont ceux qui ne fonctionnent tout simplement pas, et le seul qui fonctionne occasionne une surcharge du serveur en faisant des appels continus auprès de l’API twitch pour connaître l’état des streams.

Reste donc la solution maison !

L’intégration à WP passe par du html et du javascript. Si vous voulez intégrer le stream à une barre de widget, vous aurez besoin d’un widget de html basique. Sinon ça peut-être imaginé sur un article ou une page.

Ensuite, le code à intégrer.

Pour quelque chose de très basique qui se contente d’afficher le stream quelque soit son état (connecté ou non), on peut se contenter de ça :

<div id="twitch-embed"></div>
<script src="https://embed.twitch.tv/embed/v1.js"></script> <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.0/jquery.min.js" </script> <script> new Twitch.Embed("twitch-embed", { width: 250, height: 140, channel: "nofrag_official", layout: "video" }); </script>

Avec ça, vous affichez le stream de Nofrag, sans la zone de chat, dans une zone de 250 par 140. Ça conviendra parfaitement si vous n’avez aucun soucis avec le fait d’afficher le stream même s’il est déconnecté.

Chez Nofrag on a voulu aller un peu plus loin en affichant autre chose que le stream lorsqu’il n’est pas connecté.

Pour cela vous avez besoin d’un jeton d’accès à l’API twitch, que vous pourrez créer à partir de https://dev.twitch.tv/ puis en créant une « App ». Vous aurez alors un identifiant client, qui servira par la suite.
Le code à insérer :

<script src="https://embed.twitch.tv/embed/v1.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.0/jquery.min.js"></script>
<div id="twitch-embed"></div>
<script>
$.getJSON('https://api.twitch.tv/kraken/streams/nofrag_official?client_id=<IDENTIFIANT_CLIENT>', function(channel) {
if (channel["stream"] == null) {
/* le channel est déconnecté, je définis ce que je vais
 afficher dans le div "twitch-embed". Ici, on appelle
 une iframe avec un petit widget qui indique l'état du stream Nofrag,
 mais on pourrait afficher une image, tout simplement.*/
$('#twitch-embed').html('<iframe src="https://svinkle.github.io/twitch-tv-widget/?username=nofrag_official" width="100%" height="64" frameborder="0" allowtransparency="true"> </iframe>');
} else {
// le channel est connecté, j'affiche le stream de Nofrag
new Twitch.Embed("twitch-embed", {
width: 250,
height: 140,
channel: "nofrag_official",
layout: "video"
});
}
});
</script>

Cette solution permet de ne pas faire reposer l’appel à Twitch sur le serveur mais sur le navigateur de l’utilisateur. On pourrait aller plus loin en interrogeant régulièrement l’API twitch par javascript sans avoir à rafraîchir la page, mais en ce qui nous concerne, nous n’en avons pas ressenti le besoin.

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.

 

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 ? »