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…

 

2 réponses pour “Quitter un hébergement dédié: la galère…”

  1. luc a dit:

    Même problème et même solution avec un modulo: j’ai passé une partie des sites en mutualisé et, pour les sites verbeux, j’ai fait pointer les CNAME de Gandi sur Blogger.com et j’ai été surpris mais le transfert de cette manière de quelques dizaines de pages joomla a été très rapide. Pour les « bricolages », j’ai fait une machine virtuelle virtualbox avec un serveur ubuntu. Très rapide, très simple, tout marche…pour mémoire, même si l’expérience montre que l’on revient rarement sur d’anciens scripts. Reste que j’avais bêtement mon compilateur android sur le RPS et que je galère à le réinstaller sur ubuntu..De la même manière j’ai été obligé de virer les gadget Latex et de traitement d’image qui ne marchent plus sur du mutualisé.
    Il est également important de prendre en compte (ça veut dire grosse perte de temps) que pour un RPS sorti de release 2 où, très probablement, vous n’avez pas mis php à jour, les nouveaux serveurs sont en php 5.4=> fonction split bye bye, mediawiki 14 marche mais pas fckeditor..Bref en 2 jours le condensé de 3 ans d’update ignorés.
    Si je peux me permettre, ne pas oublier les fichiers de certificats de cryptage que j’ai très stupidement effacés (ils doivent être dans un tar mais bon…)
    Le gros avantage de ce malheur est que je peux réinstaller n’importe quoi n’importe où en 30 minutes. L’occasion de faire jouer la concurrence. En tout cas bye bye OVH. Payer trois ans et se faire virer avec un préavis aussi court ne laisse aucun espoir sur la confiance que l’on pourrait leur porter pour un autre produit. Ils seront sans doute réincarnés en FAI chinois.

    • R. Carlier a dit:

      Effectivement, parmi les « bonnes » nouvelles, pas mal de fonctions dépréciées qui trainaient par ci par là, et qui génèrent soit des erreurs, soit des warnings.

      Idem pour les configurations des .htaccess qui n’acceptent plus certains paramètres (dont la définition de variables d’environnements, utilisées dans de très nombreux scripts… groumph).

      Dans le même ordre d’idée, le fait que certaines requêtes SQL de consolidation de données utilisaient des tables en provenance de plusieurs bases, et là, ben forcément, si je passe en mutualisé, je n’ai que quelques bases et pas de possibilité de faire les jointures. Et bien sûr, si plusieurs tables se nomment pareil d’une base à l’autre, les regrouper signifie les renommer et les préfixer – et donc encore un peu de temps à passer à adapter les scripts derrières…

      Pour le reste de vos remarques, je n’ai pas ce genre de cas de figure, ayant une configuration à priori plus simple.

Laisser une réponse