Le 09/11 dernier (2017), les serveurs d'OVH ont connu une grosse panne qui a mis dans le noir plus de 3 millions de sites français, dont plusieurs assez en vue (BFM Business, Interflora, Nexity, etc.) L'hébergeur OVH est tout de même le 5ème acteur mondial de l'hébergement web... mais là, pas de bol, ils ont eu en quelques heures une cascade de problèmes (coupure EDF !!) et le redémarrage des services, malgré une annonce de rétablissement à 99% dans la journée, n'a pas été aussi rapide pour tout le monde. Autant mes services “mutualisés” hébergés chez eux ont vite redémarré, autant mon VPS (serveur virtuel personnel) est resté à l'arrêt et inaccessible 4 jours complets !!! Quelques enseignements à en tirer...

La première chose à dire est qu'OVH n'a pas eu de bol et je ne les blâme pas : on peut tous se prendre une tuile... Et leurs équipes ont fait un boulot énorme, travaillant jour et nuit pendant les 48 heures suivantes... Mais autant 99% des usagers ont pu être vite remis en route, autant quelques 1% dont je fais partie, sont restés en rade pendant plusieurs jours (4 jours complets sans aucun accès au VPS au moment où j'écris ces lignes) ! Ceci est l'occasion de quelques réflexions...

Avoir en local ce qu'il y a sur son serveur

Je fais des sites web depuis plus de 10 ans... et l'expérience m'a déjà montré tout l'intérêt d'avoir des solutions robustes et si possibles d'abord développées en local et ensuite mises en ligne. Et heureusement pour moi dans le cas présent !! Si mes services hébergés sur mon serveur VPS n'étaient pas disponibles en local également, impossible d'y avoir accès !!

Là, une fois passé le délai “raisonnable” d'attente de la remise en route du service chez OVH (2-3 j quand même... car une ré-installation complète c'est long aussi 2 ou 3Go à uploader... ) et n'ayant toujours pas accès au VPS après 4 jours (!!!), j'ai pu tout simplement réinstaller l'ensemble de mes sites et services (8 en tout) sur un autre VPS chez un autre hébergeur français chez qui j'ai déjà un VPS dont je suis content (scaleway en l'occurence). Heureusement que je n'utilise que des ressources “simples” et tournant toutes en local, sinon, cela aurait tout bonnement été impossible sans les backups du VPS OVH...

A noter qu'au passage, à prix égal, le nouveau serveur est un dual core (contre 1 coeur sur le VPS précédent) et l'espace disque passe à 50Go.

Dans le pire scénario, on pourrait imaginer une perte totale des data du VPS... çà m'est arrivé une fois avec un hébergeur sur un cloud... donc, c'est possible !!! Et dans ce cas, si on n'a pas en local, c'est mort !

Remettre en cause la “centralisation” des services

Je suis personnellement assez critique vis à vis des services centralisés (Google Docs, Facebook, Dropbox, ...) car je considère que cela constitue une régression conceptuelle vis à vis de la notion de réseau : si un acteur “central” tombe, de nombreux utilisateurs sont impactés. Je préfère les services décentralisés tels que BitTorrent ou encore Diaspora pour ne citer qu'eux.

Le cas d'OVH est un peu particulier en ce sens qu'il ne constitue pas un service centralisé unique en tant que tel... mais avec le temps, cet acteur a mine de rien de fait “centralisé” l'hébergement des sites et cela pose donc problème si un tel acteur a un souci majeur comme cela vient de se produire. Si la raison du problème était une destruction physique des serveurs (attentat ou autre accident industriel)... on ose à peine imaginer le fiasco résultant... et pas pendant 1 matinée du coup !

Donc, partant de ce constat, et sans aucune animosité envers OVH qui a selon moi traité au mieux la crise, je considère que la question se pose de la centralisation des services... En clair, ne pas mettre tous ses oeufs dans le même panier. J'ai déjà une politique de ce type (ma boutique en ligne est chez un fournisseur de service différent de l'hébergeur, j'ai un mutualisé qui n'est pas chez OVH, etc. )... et malgré tout, je me retrouve dépendant de l'acteur OVH car il a une position centrale... J'ai des VPS chez d'autres hébergeurs pour d'autres usages... et du coup, j'ai réinstallé mes services sur un VPS de cet hébergeur et simplement repointé le nom de domaine vers ce nouvel hébergement.

On voit au passage aussi tout l'intérêt de pouvoir facilement installer un serveur indépendamment d'une ip.. ce que propose ledit hébergeur d'ailleurs.

Remise en cause du “tout en ligne”

La tendance est au “cloud”, au web “dans les nuages”... et pas mal de gens ont des services domotiques qui sont connectés et certains semblent-ils ont été “bloqués” pour la gestion de leurs installations à domicile ! C'est un comble... mais celà montre tout l'intérêt de penser “local” lorsque l'on pense service domotique et autres, l'accès distant ne devant pas être obligatoire mais doit rester second ou “accessoire” pour ainsi dire... Si on ne peut plus régler son chauffage ou ouvrir ses volets parce que çà passe par un serveur qui est à plusieurs centaines de kilomètres de chez soi, c'est complètement débile... !!

Les data dans les nuages (le cloud), why not... mais garder les pieds sur terre (en local) !

Il faut un contrôle localisé des dispositifs, qui peut le cas échéant envoyer des data en distant, mais le distant ne doit pas être bloquant si il est down... On a les raspberry Pi ou équivalent qu'il faut pour çà de nos jours.

Un bon article sur çà ici

Maîtriser techniquement ses outils webs

Pour éliminer toute dépendance à des tiers (et donc pour ne pas avoir de frais de remise en route, etc.) pour se dépanner, il est impératif de maîtriser sa chaîne technique pour pouvoir réagir et s'adapter rapidement. En clair, il faut pratiquer régulièrement les procédures d'installation d'un VPS “from scratch”, de sa sécurisation, des services qu'on utilise, etc... pour pouvoir le faire le jour où cela est nécessaire sans être trop “perdu”.

Il est intéressant d'avoir également une “unité” des outils avec lesquels on travaille : être sous Debian en local par exemple donne l'habitude de travailler avec... et retrouver la même distribution lorsque l'on est sur le serveur distant fait que l'on n'est à peu près à l'aise ! Il serait illusoire de tenter d'installer un VPS sur un système que l'on ne connaît pas bien...

On potentialise au passage ses savoirs-faire à “tous les étages” pour ainsi dire. Travailler sur un Raspberry Pi régulièrement en mode SSH + accès distant X2Go par exemple est un bon exercice pour çà !

Là encore, on retrouve la notion de robustesse et de sécurité ce qui passe par une bonne connaissance et habitude des outils utilisés !

Suivi de la remise en route des services du site sur le nouveau VPS :

• Site principal www.mon-fablab.fr : fait 12/11/17
• Site machine OMM Prusa i3 : fait 12/11/17
• Site machine OMM PRO : fait 12/11/17
• Site machine OMM PLUS : fait 12/11/17
• Site du cloud des documentations : fait 12/11/17
• Blog du site principal : fait 12/11/17
• Blog des réalisations : fait 12/11/17
• Site du wiki : fait 12/11/17

Conclusion

Mon site principal a été 4 jours complet “offline” en raison d'un évènement technique majeur ayant touché OVH et j'ai pu me réinstaller sur une autre instance de VPS ailleurs car j'ai tout en local : ouf !

Au passage, recadrage de certains choix techniques et confirmation des choix déjà faits pour l'essentiel.

#general #web

A la recherche d'un outil aussi souple que possible et simple d'utilisation pour mes sites webs, j'ai récemment découvert un CMS opensource sans base de données : il s'appelle GRAV et c'est vraiment grave ce truc !

Bon aller, je fais mon KORBEN aujourd'hui : je vous parle d'une petite trouvaille qui me plaît bien pour faire en 2 temps 3 mouvements un site “ouaibe” sans DB (sans base de données), tout en donnant un résultat “moderne” visuellement.

C'est quoi ton problème ?

En clair, pour faire un site web, on 3 grosses options possibles :

• soit utiliser une classique solution serveur web Apache + PHP + Base de données : typiquement un Wordpress ou un Joomla. Le hic de cette solution, c'est qu'il faut quasi-obligatoirement travailler en ligne, et faut faire des mises à jour régulièrement, c'est difficile à bouger déplacer. C'est un peu le semi-remorque du site web.

• soit utiliser un site web statique : que des fichiers textes qui auront été générés préalablement à l'aide d'un générateur de site statique. Un simple serveur web suffit. On peut citer Pelican en Python par exemple, ou encore Hugo que j'utilise parfois. Le site obtenu est léger, rapide, réputé écolo... et c'est loin d'être “has been”. Par contre, pour toute modif, faut le regénérer et le remettre en ligne. C'est un peu la voiture du site web. Facile à utiliser, pas trop d'entretien, facile à déplacer.

• soit utiliser un entre-2 : là on a un serveur web + un langage côté serveur (PHP) sans base de donnée et des fichiers textes. On peut citer par exemple pmwiki que j'utilise depuis longtemps et qui fonctionne comme çà. L'intérêt de cette solution est de pouvoir facilement tourner aussi bien localement que en ligne par simple transfert. Les pages webs sont générées à la volée à partir des fichiers textes. C'est un peu le véhicule utilitaire du site web : on peut transporter pas mal de trucs, tout en restant mobile.

La solution GRAV dont je vous parle se situe dans cette dernière catégorie : le site n'utilise que des fichiers textes + images, etc et du PHP côté serveur.

GRAV, pourquoi c'est bien ???

• D'abord, çà fonctionne de suite : on télécharge, on active un serveur PHP local et zou, on accède à son site de test.

• Il y a pleins de ressources disponibles :

  • des skeleton : autrement dit des sites “orientés” complets prêt à l'emploi : blog boutique, documentation (nickel çà !), onepage, etc.
  • des templates : autrement dit de nombreux aspects visuels du site possible
  • et des plugins : tout ce qu'on s'attend à avoir.

• Un système de “ligne de commande” très pratique aussi bien pour mettre à jour que pour installer / désinstaller des plugins. Un peu comme le shell d'un système Linux

• Des fichiers texte de type Markdown capable d'intégrer aussi la coloration syntaxique, des images, des vidéos, etc.

• Et çà peut même être couplé à des pages Github pour les sources !

Une fois le site fait et testé en local, un envoi par FTP (ou mieux par Rsync si on a un VPS..) sur le serveur, et c'est OK !

C'est où ?

Tout est là : https://getgrav.org/

Tu fais quoi avec ?

Ben moi, du coup, j'ai commencé à mettre des GRAV à droite et à gauche en fonction de mes besoins et vous pouvez voir ce que çà donne sur ce blog et aussi ici : Blog des réalisations

En pratique, ce qui est trop compliqué ou trop long à faire... n'est pas fait ! Donc en clair, si pour faire un post faut se connecter, passer 4 plombes à uploader des images, etc... çà le fait pas. A l'inverse, si d'une simple idée, on peut faire un post en quelques minutes sur son poste, même non connecté, dans un simple éditeur, alors on le fera volontiers.

Mieux, si on peut utiliser toutes sortes de fichiers par simple copier/coller de répertoires, en travaillant localement sur son poste comme on le ferait pour n'importe quelle autre tâche, alors là, l'outil est adopté en moins de 2... Mieux, il donne envie de bosser avec. C'est ce que je ressens avec GRAV.

#web