Migrer un serveur de production

, par Julien Falconnet

Ca y est ! L’heure fatidique est arrivée, votre serveur web de production doit migrer vers un nouveau serveur. Quelques nuits blanches en perspective et une bonne dose d’adrénaline dans le sang vous décidez enfin de prendre le taureau par les cornes.

Voici quelques étapes que j’ai du mettre en place.

Cadre

La migration s’effectue entre deux serveurs chez online.net. L’ancien (que l’on appellera Aragorn) part à la décharge, ils m’en ont gracieusement proposé un nouveau (que l’on appellera Elessar) plus puissant sensiblement au même prix. Par contre, c’est un serveur dédié donc à moi le cambouis de la migration.

Au niveau système d’exploitation, on en profite pour passer de Debian 6.0.7 à Debian 7.2

  • Aragorn : GNU/Linux 2.6.32-5-amd64
  • Elessar : GNU/Linux 3.2.0-4-amd64

Etape 1 : installer le nouveau serveur

installer le nouveau serveur(Elessar) ici un Debian 7.2

  • Pour online, l’installation se fait par l’interface l’hébergeur.
  • Ensuite première connexion en ssh root
  • Mise à jour des paquets
    apt-get update
    apt-get upgrade
  • Prendre quelques informations sur la machine (et bien les garder quelque part)
    uname -a
    more /etc/debian_version 
    cat /proc/cpuinfo 
    free
    free -h
    more /etc/debian_version
    /sbin/ifconfig 
    df 
    df -h
    netstat -ltp
  • Sécuriser ssh
    • Installer un accès par clef sur un des utilisateur (Attention ne pas sauter cette étape sinon vous n’aurez plus accès à votre machine)
      ssh-copy-id  utilisateur@000.000.000.000
    • Modifier l’accès ssh pour : changer le port par défaut, empêcher le login root et empêcher le login par mdp.
      vi /etc/ssh/sshd_config 
      >>Port {XXXX}  (ou XXX est un port non standart)
      ...
      >>PermitRootLogin {{no}}	
      ...
      >>PasswordAuthentication {{no}}
    • Relancer le serveur ssh pour que les modifications soient prisent en compte
      /etc/init.d/ssh restart
    • modifier en local dans .ssh/config le numéro du port
    • Tester une connexion par clef.
      PS : pourquoi sécuriser tout de suite ? Parce que si vous vous trompez vous êtes bon pour recommencer l’installation.
  • Vérifier le bon fonctionnement d’exim
    • Reconfigurer pour permettre à vos site d’envoyer des mails
       dpkg-reconfigure exim4-config
    • Pour tester :
      echo "Un message de test" | mail -s "sujet de test" vous@mail.tld
  • Installer les paquets nécessaires :
    • LAMP : jouer sur les dépendances pour installer le nécessaire
      apt-get install mysql-server phpmyadmin
    • NodeJS :
      apt-get install  mongodb build-essential git
      wget http://nodejs.org/dist/v0.10.18/node-v0.10.18.tar.gz
      tar xvf node-v0.10.18.tar.gz 
      pushd node-v0.10.18/
      make
      make install
  • Sécuriser les applications serveurs
    • PhpMyadmin : changer au moins la ligne d’alias
      vi /etc/apache2/conf.d/phpmyadmin.conf 
      >> Alias /unnomquinarienavoiravecphpmysql /usr/share/phpmyadmin
    • Apache : modifier les lignes
      vi /etc/apache2/conf.d/security
      ...
      >> ServerSignature Off
      ...
      >> ServerTokens Prod
      
      vi /etc/php5/apache2/php.ini 
      ...
      >> expose_php = Off

ps : attention il existe des guides bien plus sérieux de sécurisation d’un serveur, je n’indique ici que ce dont j’ai eu besoin.

Étape 2 : en faire le plus possible sans toucher à rien d’important

  • faire un maximum de sauvegardes de l’ancien (Aragorn), un Debian 6.0.7.
    • tar -cvzf backup_etc.tar.gz /etc/
    • tar -cvzf backup_var.tar.gz /var/ (on peut faire mieux)
    • tar -cvzf backup_web.tar.gz /sites/ (pour moi le répertoire où sont stockés mes sites)
  • Préparer les noms de domaine
    • Modifier la zone pour que ww.ndd.tld (avec 2w) redirigent sur le nouveau serveur (Elessar). Faire cela pour tous les sites qui tournent normalement sous www. Si vous avez d’autres sous domaines trouvez une variantes proche (avec un 2 à la fin par exemple).
    • Pour chaque registrar impliqué (gandi, phpnet,etc)
    • Si possible, préparez vos nouveaux "fichiers de zone DNS" pour ne plus avoir qu’à les activer. (ou les www dirigent sur le nouveau serveur, Elessar )
  • Ramener la configuration des sites
    • établir un lien ssh entre les deux.
    • les vhosts récupérer scp -r aragorn.dom.tld:/etc/apache2/sites-available/ /etc/apache2/sites-available/
    • les fichiers des sites scp -r aragorn.dom.tld:/sites/* /sites/
    • corriger les vhost htaccess pour qu’ils supportent les ww.
    • comparer les /etc/apache2/mods-enabled/ pour réactiver tous les modules nécessaires (rewrite, proxy, etc)
    • Remettre en place un système de sauvegarde !!!
  • Faire une première importation temporaire des bases de données pour pouvoir tester que les sites fonctionnent
    • ssh aragorn.dom.tld 'mysqldump -q --skip_trigger -u root -p --database db1 --database db2  --database etc | mysql -u root -p
    • Si vous avez importé la base mysql (important pour les user et leur droits sur les bases), les passwords risquent de ne plus fonctionner si comme moi vous passez d’une version 5.1 à une version 5.5. Vous pouvez utiliser la commande mysql_upgrade -u root -p pour résoudre ce problème.
    • Recopier les crontab de tous les utilisateurs
  • Tester TOUS les sites sur ww. (ou les sous domaines modifiés).

Étape 3 : bascule

Il va falloir ramener les informations les plus fraîches du serveur de production vers le nouveau. Idéalement, couper l’ancien et tout rediriger sur le nouveau, pour limiter le temps ou une partie des gens seront sur l’ancien.

Donc il faut faire dans un temps le plus court possible (si ce temps es trop important, il faut mettre les sites en travaux) ;

  • RE migrer les bases de données
  • RE migrer les fichiers qui bougent (attention aux droits)
  • sur l’ancien serveur utiliser les htaccess pour rediriger tout le trafic du www vers le ww.
  • Changer les dns pour y faire disparaître l’ancien serveur.
  • tester, tester, tester et encore tester

Étape 4 : finaliser

La question du temps de propagation des DNS, c’est à dire le temps que les noms de domaines redirigent sur les bons serveurs est toujours une question épineuse. Il vaut mieux laisser quelques heures, idéalement 24h. Puis :

  • Éteindre l’ancien serveur pour vérifier si tout continue d’être ok.
  • remplacer le ww par www dans les htaccess locaux
  • Rallumer l’ancien serveur et effacer toutes les données possibles.