Quitter un hébergement dédié: la galère…

Cet article aurait pu s’appeler comment perdre quelques jours à cause d’OVH, mais on va plutôt adopter la positive attitude et en tirer les enseignements qui s’imposent.

Changer d’hébergement est un exercice toujours utile à connaître (si possible avant d’être confronté au problème).

C’est hier, en rentrant d’un weekend prolongé que je découvre un mail qui fait plaisir en provenance d’OVH mon hébergeur fétiche (jusqu’à présent):

OVH a proposé le produit RPS de Janvier 2008 à Juin 2011. L’infrastructure de ce produit devient obsolète, amenant à terme de potentiels risques. OVH proposant désormais des offres plus adaptées à ce type de besoin, nous avons pris la décision de stopper le service.

Le service RPS sera donc définitivement stoppé le 24 juin 2013 à 11h00.

L’infrastructure sera rendue indisponible à cette date, et toutes les données que vous n’aurez pas récupérées seront perdues.

En terme pratique, cela signifie que j’ai à peine plus d’un mois pour déménager un paquet de sites, et non des moindre, puisque ce sont ceux qui me servent à titre personnel plusieurs fois par jour (pour gérer mes cours, ma compta, mes mails…) et tout un tas de bazar expérimental dont une bonne partie risque de ne pas fonctionner sur un autre hébergement, et divers projets réels. En gros 40 domaines, soit 50 projets environ sont concernés.

Passé le moment de surprise (et d’énervement), il est temps de se lancer.

Premières décisions

Mutualisé ou dédié ?

Le service RPS était intéressant pour moi, pour expérimenter un certain nombre de choses, dont la gestion d’un serveur.

Suite à ce mail, c’est l’occasion de faire le bilan. Après quelques années force est de constater que cela m’a fait perdre beaucoup de temps à configurer des trucs, n’ayant pas réellement les connaissances nécessaires (ni l’envie ni le temps de les approfondir). En terme d’avantages? Ma foi… A part avoir la place d’accumuler du bazar…

La première décision s’est faite assez vite ce matin: si OVH me chasse de mon hébergement dédié, ben ma fois, je ne renouvelle pas vers un autre hébergement dédié, mais vers un mutualisé (ou plusieurs). D’autant que migrer vers un Kimsufi (ou autre) pour que dans 2 ans ils me disent qu’ils arrêtent le Kimsufi… Samsufi!

J’avais il y a quelques temps opté pour un site = un hébergement. Avantage en terme d’organisation (encore qu’à l’époque, chaque projet était chez un hébergeur différent), mais inconvénient en terme de coût.

Mon RPS a donc été l’occasion de tester un hébergement = un nombre illimité de sites. Avantage en terme de coût, inconvénient en terme de configuration et réglages divers (oui, hébergeur, c’est un métier).

Les offres ont évolué, je vais donc migrer vers x hébergements = x sites, en optant pour des multi domaines, regroupés par thématiques. Largement suffisant en ce qui me concerne.

A l’arrivée, si on exclu le temps passé à la migration proprement dite, j’économiserais presque 10€ht par mois (oui, bon, c’est pas énorme, mais quand même).

Process de migration

Il faut donc commencer par le commencement!

• faire le ménage sur ce qui sert et ce qui ne sert pas, ou plus. Pas la peine de transférer des trucs expérimentaux vieux de quelques années…
• mettre au point une procédure de migration (c’est le but de cet article) avec un site peu important, pour appliquer la méthode avec les autres

Faisons donc le tour en détail de cette procédure.

Qu’implique un changement d’hébergeur ?

Sur le papier et pour un site dynamique, la méthode est assez simple: il suffit de:

• transférer les fichiers par FTP sur le serveur cible
• réinstaller les bases de données
• modifier un script de configuration (avec les identifiants aux dites bases),
• rediriger les noms de domaines (ce qui peut prendre un peu de temps)
• et pour finir faire le ménage sur le serveur source.

En théorie…

En pratique, c’est un peu plus complexe, surtout dans la partie c’est mon bazar personnel, puisque par définition, un bazar est peu organisé. Il y a donc beaucoup de choses mal faites, et donc pleins de choses à vérifier. L’avantage étant que si ça ne marche pas quelques heures, c’est pas grave non plus, je suis l’unique utilisateur de la plupart de ces choses.

Transférer les fichiers

Bon, ça, ça pourrait être la partie la plus simple. On sait transférer un fichier d’un serveur à l’autre.

Non? Pourtant, c’est facile: vous vous connectez en FTP sur l’ancien site, vous rapatriez en local, vous vous connectez sur le nouveau et vous uploadez…

Sauf que… Si vous avez presque 6 ans de bazar (en fait plus, pas mal de choses proviennent d’un autre hébergeur encore), le nombre de fichier risque de vous refroidir. D’autant qu’il faut surtout gérer les permissions sur ces fichiers (certains dossiers acceptant l’upload de fichier, ils sont assortis de réglage en écriture…).

Bon point, l’ancien hébergement comme le nouveau acceptent les connections SSH (c’est à dire que l’on peut s’y connecter en mode console, et donc utiliser des outils d’administration en ligne de commande).

Après quelques expériences tournant autour de ftp, ncp, rsync, et autres, j’ai opté pour la démarche suivante, à mon sens optimisée en terme de temps de transfert.

• Se connecter en SSH sur le serveur source
• Se déplacer dans le dossier concerné (en fait, le dossier parent)

  cd /var/html/sitesource.fr

• Créer une archive TAR, avec les bonnes options

  tar -cvzf sitesource.tar.gz ./www/
      c == création d'archive
      v == verbose (affichage de ce qu'il se passe)
      z == gzip (compression)
      f == nom du fichier

• Se connecter avec ncftp vers le serveur cible, dans le bon dossier, et balancer le fichier tar

  ncftp -u USERCIBLE -p PASSWORDCIBLE ftp.cible.net
  cd sitesource.fr/
  put -R -f sitesource.tar.gz

• Se connecter en SSH sur le serveur cible, dans le bon dossier
• Extraire l’archive

  tar -pxvzf sitesource.tar.gz ./www/
      x == extraction

Cette méthode, somme toute un peu pénible (mais c’est assez rapide) possède comme gros avantage le délai de transfert (un seul fichier à copier en FTP).

Base de données

Le changement de base de données ne pose pas de problème majeur.

• utiliser phpMyAdmin pour faire un export depuis le serveur source
• utiliser phpMyAdmin pour faire un import depuis le serveur cible

Voilà… Bien sûr, si vous passez d’un serveur perso (avec un nombre illimité de base de données) à un serveur mutualisé (avec 3 base), vous courrez le risque de ne pas pouvoir tout mettre. L’occasion de faire le ménage dans tous les trucs qui servent à rien…

Bien sûr, si votre base est un peu lourde, car utilisée depuis quasi 12 ans pour l’une d’entre elle (elle a déjà connu 3 hébergeurs), il faut pouvoir uploader des fichiers lourd dans phpMYAdmin.

A défaut, ajoutons ceci dans le .htaccess de phpMyAdmin

php_value upload_max_filesize "4100000"

(au moins le temps des opérations, en faisant varier la valeur…)

Et le reste

Ben, c’est là où le bazar évoqué prend tout son sens. Un site bien fait possèderait un fichier de configuration, point central de toutes les connections.

Oui, mais je suis dans une zone expérimental, peuplée de myriades de fichiers ayant tous (!) des configurations perso…

Les points à vérifier sont:

• connexion à la base de données
• dossiers nommés en interne dans des scripts (pour inclusion de fichier, uploads, etc.)
• utilisation d’extensions php particulière (je crois pas)
• utilisation de scripts ou commandes systèmes (je crois pas)
• paramétrage des crontab (ovh propose des webcron qui feront l’affaire)
• régler au cas par cas les bugs résiduels (dû à des versions de php différentes, par exemples…)

C’est sans doute tout…

Et après ?

Découvrir les (mauvaise) surprise au fur et à mesure.

Bon, a tout hasard, avant la fermeture du service, une bonne grosse sauvegarde intégrale des dossiers et des bases de données ne nuira pas.

J’en suis à une journée de perdue, forte chance que ce soit la première d’une série de plusieurs… L’avantage est que les temps de création des zip, transfert et autres pourront être mis à profit pour des opérations plus intéressantes et plus urgentes qui étaient prévues pour ce mois ci (on exclu cet article, dont le rôle est de me servir de mémo pour éviter de perdre du temps pour les autres jours).

Bien sûr, la première journée est plus longue, puisque tout doit être mis au point. Les suivantes devraient être plus efficaces…