Accueil > Recettes Techniques > Linux > Migrer un serveur de production
Migrer un serveur de production
jeudi 31 octobre 2013, par
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.
- 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)
- 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
- Reconfigurer pour permettre à vos site d’envoyer des mails
- 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
- LAMP : jouer sur les dépendances pour installer le nécessaire
- 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
- PhpMyadmin : changer au moins la ligne d’alias
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.