Voici en partage ma fiche de procédure en cas de crash de mon serveur WordPress et que je viens d’utiliser pour le remettre en service.
Le contexte :
Je loue un serveur WordPress “clef en main” chez un hébergeur. Comme tout serveur WordPress, j’ai un compte administrateur qui me permet de le paramétrer et de choisir des extensions. Parmi les extensions que j’ai choisies, celle qui gère la sauvegarde de mon site s’appelle UpdraftPlus. Elle est paramétrée pour faire une sauvegarde complète (base de données WordPress, extensions, thèmes, etc.) régulièrement. Je transfère manuellement les fichiers de sauvegarde par ftp chez moi pour disposer de sauvegardes externalisées et respecter la règle 3-2-1.
L’incident :
J’ai mis en place une surveillance du fonctionnement de mon blog avec l’excellent “UptimeRobot” dont le service gratuit de monitoring me convient parfaitement. En cas de problème grave, les lecteurs me préviennent aussi (cf Pwned).
J’ai reçu la semaine dernière une alerte d’indisponibilité de mon blog, et après vérification, j’ai pu constater que l’hébergeur affichait une magnifique “Erreur 504”. J’ai donc ouvert un ticket d’assistance, et appliqué le plan de reprise d’activité (PRA) du blog que je décris ci-après.
Procédure :
- Rester calme
- Configurer un serveur Yunohost hébergé chez moi (sur un Raspberry Pi)
- Configurer le nom de domaine zythom.fr sur ce serveur via l’interface Yunohost
- Rediriger les ports TCP 80 et 443 de ma box vers ce serveur Yunohost
- Modifier l’adresse IP du blog zythom.fr dans le DNS (je suis chez Gandi)
- Mettre en place le certificat SSL Letsencrypt via la procédure proposée par Yunohost
- Rester calme
- Installer l’application Yunohost WordPress
- Installer l’extension WordPress UpdraftPlus
- Transférer sur le serveur les fichiers de la dernière sauvegarde disponible
- Restaurer l’ensemble de la sauvegarde (base de données, extensions, thèmes, etc.)
- Option: mettre le blog derrière Cloudflare (compte gratuit) pour la mise en cache
Retour d’expérience :
La procédure s’est bien déroulée, avec un temps d’interruption assez court (compte tenu de l’audience modeste de ce blog) et essentiellement lié au temps de propagation DNS. Améliorations à faire :
– la sécurité du site repose en partie sur des fichiers .htaccess que je n’avais pas étudiés pour le serveur Yunohost.
– mettre en place une page de maintenance pour masquer toutes les pages temporaires (page par défaut du serveur web avant installation de WordPress, site WordPress par défaut avant restauration…)
Pendant trois jours, j’ai surveillé un peu tout cela, et j’ai publié hier un billet pour tester la charge, et tout s’est bien passé, sauf l’envoi des emails me prévenant des commentaires.
Le mot de la fin :
J’ai installé hier soir une nouvelle machine virtuelle Debian sur mon NAS Synology. J’y ai installé un WordPress classique sur lequel j’ai pu de nouveau basculer le blog. Je peux remettre en place une sécurité que je gère un peu mieux, même si je le rappelle, ce blog se fera pirater car je ne maîtrise pas tout.
Je découvre Cloudflare et c’est un peu déroutant.
Un technicien du support de mon hébergeur m’a contacté 3 jours après l’ouverture du ticket (et après la mise en place du PRA et donc la migration du site ailleurs) pour me dire qu’il ne voyait pas le problème car mon site répondait correctement… Je pense que je vais clore mon abonnement chez eux.
Kudos à tous les développeurs de Yunohost.
Avec tous les tests et les essais qu’il me reste à faire, ça va bagotter un peu ici.
L’hébergeur ? Des noms ! Des noms !
Il s’agit d’un hébergeur qui comme beaucoup sous staffe son support et rémunère mal ses techniciens supports. Je ne lancerai donc pas la pierre à ceux qui triment, surtout que l’offre que j’utilise est particulièrement économique.
Question : pourquoi ne pas chercher à faire tourner les données via un container wordpress plutôt que de refaire une install avec un serveur web dédié à chaque fois ?
J’avoue être en train d’aimer de plus en plus la containerisation, avec un traefik en frontend qui s’occupe de la partie reverse proxy, ça fonctionne très très bien.
C’est uniquement une question de compétences. Je connais (un peu) l’administration d’un serveur GNU/Linux, mais je ne suis pas à l’aise avec un container, surtout si celui-ci a été construit par quelqu’un d’autre. La sécurité me semble plus simple à gérer, et surtout, je sais sauvegarder facilement une VM de mon NAS.
La containerisation c’est bien pour l’immutabilité, dans le cas d’archi distribué avec un orchestrateur.
Mais installer un container wordpress en solo sur une vm, a quoi bon ?
Mais oui, mettre un reverse-proxy (nginx ou haproxy) devant quoique-ce soit est une bonne pratique.
Déja nginx permet de mettre du cache (sans rentrer dans la complexité, ni la performance d’un varnish) et avec un peu de compétence et de temps permettra d’augmenter la sécurité.
Docker est un paquet supporté sur mon NAS Synology, mais je ne suis pas trop tenté, surtout pour des raisons de compétences, donc aussi de sécurité.
Je vais approfondir le côté reverse proxy, merci pour le conseil. Auriez-vous un tutoriel bien fait à me conseiller ?
Désolé pour le délai de réponse, j’étais en déplacement 🙂
Pour la sécurité, les containers sont a priori réputés pour rajouter une couche de sécurité. Si l’appli est compromise, le container n’a pas accès au reste de la machine simplement, contrairement à un wordpress qui tournerait en natif sur un Linux. Pour l’aspect sécurité / confiance “surtout si celui-ci a été construit par quelqu’un d’autre” : c’est le cas de votre serveur web (nginx / httpd) ou de wordpress, vous ne les avez pas codés vous-même (enfin… je ne pense pas).
Donc que wordpress vous fournisse un zip ou une image docker, la confiance est la même pour l’applicatif : à moins de contrôler le code, vous ne pourrez pas vous assurer que wordpress est sécurisé.
Pour les tutos de reverse proxy, en container je recommanderai traefik (et leur doc) ou SWAG (par linuxserver.io). Hors container, je viserai celui-ci :
https://openclassrooms.com/fr/courses/1733551-gerez-votre-serveur-linux-et-ses-services/5236081-mettez-en-place-un-reverse-proxy-avec-nginx#:~:text=Un%20reverse%2Dproxy%20est%20une,compos%C3%A9e%20de%20blocs%20de%20directives.
Pour ce qui est de l’aspect “pourquoi un container sur une machine seule” : ça permet de faire tourner plusieurs applis sur la même machine alors qu’elles peuvent avoir des pré-requis complètement différents (nginx / httpd, php7.x/php8.x, nodeJS version x ou y, etc…), sans avoir à se prendre la tête.
Manque à la fin de la procédure : Savourer le travail réalisé, yes it’s works !
Jusqu’à maintenant 😉
Hello, pourquoi avoir installé spécifiquement une VM Debian et ne pas avoir utilisé Synology Web Station qui fonctionne parfaitement pour faire tourner un site web hébergé ?
Parce que mon NAS Synology est déjà bien occupé à faire tourner beaucoup de services très personnels et que je voulais isoler cette VM exposée sur Internet. De plus, l’OS du Synology, bien que basé sur GNU/Linux, est modifié au fil des mises à jour, ce qui rend complexe les opérations de sécurisation. C’est aussi pour cela que je n’ai pas utilisé le paquet Synology WordPress. Enfin, je maîtrise mieux l’administration en profondeur de Debian que celle du NAS Synology (masquée par l’interface DSM).