Il peut arriver certains cas où vous avez tout intérêt à définir des variables spécifiques à votre environnement de développement ou de production tout en gardant exactement le même code pour votre application (dans le cas de l’utilisation de git par exemple, ou simplement si vous travaillez en local avant la mise en production). Plus concrètement, vous pouvez vouloir changer les informations de connexion à votre base de donnée en fonction de votre environnement sans que ça impact votre code.

La solution la plus commune reste alors à déterminer dans votre code dans quel environnement vous vous trouvez :

if($_SERVER['HTTP_HOST'] == 'localhost') {
    // Environnement de développement
} else {
    // Environnement de production
}

Mais très honnêtement, cela peut apporter son lot de complications. A savoir, devoir modifier et redéployer son application à chaque changement pour le moindre environnement par exemple, ou ça devient vite ingérable si vous en utilisez plusieurs.

Une solution bien plus simple existe alors. Pour cela, il suffit de déclarer vos variables directement à l’intérieur même de votre environnement et simplement de les récupérer de manière transparente dans votre application. Pour cela, il suffit d’utiliser en PHP la fonction getenv($var) pour récupérer la variable $var que vous aurez déclaré dans votre votre vhost apache ou votre htaccess à l’aide de la commande SetEnv $var value

Exemple

Pour illustrer cette méthode, nous allons imaginer une application déployée sur 2 environnements différents. La première plateforme est celle de développement répondant à l’URL http://dev.application.com et devra se connecter sur le serveur de base de donnée de développement 123.456.789.0. La seconde plateforme est celle de production répondant à l’URL http://www.application.com et devra se connecter sur le serveur de base de donnée de production 123.456.789.1.

Vhost Apache :

# Développement
<VirtualHost *:80>
    ServerAdmin admin@application.com
    ServerName dev.application.com
    DocumentRoot /var/www/application/dev/

    SetEnv DBHOST 123.456.789.0
    SetEnv DBUSER application_dev
    SetEnv DBPASS application123
    SetEnv DBNAME application_dev

    <Directory /var/www/application/dev/>
        Options -Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
     </Directory>
</VirtualHost>

# Production
<VirtualHost *:80>
    ServerAdmin admin@application.com
    ServerName www.application.com
    DocumentRoot /var/www/application/www/

    SetEnv DBHOST 123.456.789.1
    SetEnv DBUSER application_www
    SetEnv DBPASS application123
    SetEnv DBNAME application_www

    <Directory /var/www/application/www/>
        Options -Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
     </Directory>
</VirtualHost>

Application PHP

$db = new PDO('mysql:host='. getenv('DBHOST').';dbname='.getenv('DBNAME'),
               getenv('DBUSER'),
               getenv('DBPASS'));

Et voila votre application communique maintenant avec votre environnement et est prête à être déployée où vous le voulez.

Récemment (très récemment en fait … hier), j’ai subi quelques soucis avec un serveur mit hors-ligne par mon hébergeur sans me prévenir (ouh le méchant OVH). Le soucis le plus important, c’est que je m’en suis rendu compte un peu tard, à savoir, le lendemain (dur dur l’arrivée au bureau ce matin. Je n’ai même pas eu le temps de mettre en place mon intraveineuse de café). Il existe bien entendu beaucoup de systèmes automatique de monitoring sur le web mais quoi de mieux que de réinventer la roue et surtout, de savoir comment celle-ci fonctionne.

Le principe de notre système va donc être de regarder régulièrement, à l’aide d’une tâche CRON, si le serveur de votre site répond correctement et si celui-ci est bien le bon serveur (une guerre existe au sujet de la prononciation du mot « CRON », un camps prône la tâche « crone » et l’autre, la tâche « cron » . Je préfère pour ma part « cron », ça me permet d’insulter tout le monde de « tâche » automatique sans passer pour un … bref).

I/ Créer la base de donnée

La base de donnée n’a rien de compliqué en soit, il suffit de hiérarchiser toutes les données dont nous avons besoins, à savoir :

  • Le titre du site
  • Le nom de domaine du site
  • L’IP du serveur hébergent le site
  • L’indicateur d’état DNS
  • L’indicateur d’état HTTP
  • La date du dernier changement d’état

Soit en SQL :

CREATE TABLE IF NOT EXISTS `monitoring` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`title` varchar(64) NOT NULL,
`domain` varchar(64) NOT NULL,
`ip` varchar(64) NOT NULL,
`dns` tinyint(1) NOT NULL,
`http` tinyint(1) NOT NULL,
`update` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=58 ;

II/ Créer le script

Pour la création de ce script, je vais assumer le fait que vous soyez correctement connecté à votre base de donnée et que vous utilisez la bibliothèque PDO.

Récupéreration des données

Commençons ainsi par créer notre requête de récupération des données :

$sites = $pdo->query('SELECT * FROM monitoring');
foreach($sites->fetchAll() as $site):
    // Traitement du monitoring HTTP

    // Traitement du monitoring DNS
endforeach;

Tester l’accès HTTP

Ensuite, on va tester si l’accès au site est bien possible. Pour cela, il vous suffit de tenter d’ouvrir une connexion PHP entre votre script et votre serveur avec la fonction fopen pointant sur l’IP. Si la connexion s’effectue, la fonction va vous retourner le code brut de votre script, si votre serveur est indisponible, alors votre fonction retournera false.

$sites = $pdo->query('SELECT * FROM monitoring');
foreach($sites->fetchAll() as $site):
    // Traitement du monitoring HTTP
    $ping = (bool) @fopen('http://'.$site['ip'].'/', "r");

    // Traitement du monitoring DNS
endforeach;

En ajoutant un (bool) avant la fonction, on s’assure que celle-ci ne nous renvoit pas le code source du site, mais simplement la valeur true. de la même manière, en ajoutant un @ avant le nom de la fonction, je demande à PHP de ne pas renvoyer d’erreur mais simplement un false si quelque chose ne se passe pas bien (comme le fait que votre serveur ne réponde pas).

Tester le paramétrage DNS

Nous allons maintenant tester le paramétrage des DNS. Cette étape est assez important en fonction de votre configuration. En effet, nous allons vérifier que le serveur correspondant au nom de domaine est bien le bon. En effet, il existe de nombreux cas ou votre nom de domaine pourrait pointer vers un serveur, certe, fonctionnel, mais ne vous appartenant pas pour autant. (Cela m’arrive malheureusement régulièrement avec des clients qui pensent bien faire en modifiant eux-même leur nom de domaine et qui en fait, plombe totalement leur site internet sans même vous prévenir … Pour après vous en blâmer).

Pour cela, il existe une fonction toute faite ! gethostbyname qui prend comme paramètre le nom de domaine recherché et vous renvoi l’IP vers lequel celui-ci redirige. Il suffit alors de vérifier si l’IP répondu correspond bien à notre IP.

$sites = $pdo->query('SELECT * FROM monitoring');
foreach($sites->fetchAll() as $site):
    // Traitement du monitoring HTTP
    $http = (bool) @fopen('http://'.$site['ip'].'/', "r");

    // Traitement du monitoring DNS
    $dns = gethostbyname($site['domain']) == $site['ip'];
endforeach;

Vérification du monitoring

Il reste tout de même une dernière étape avant d’alerter quiconque en cas de problème. Car effectivement, si dès que vous détectez un soucis dans votre monitoring vous envoyez en e-mail, alors dites-vous que tant que votre problème n’est pas réglé, vous allez harcelé par votre propre serveur. Pour cela, il ne faut donc pas oublier de vérifier que l’état actuel des DNS ou du HTTP est différent du précédant état de votre site.

$sites = $pdo->query('SELECT * FROM monitoring');
foreach($sites->fetchAll() as $site):
    // Traitement du monitoring HTTP
    $http = (bool) @fopen('http://'.$site['ip'].'/', "r");

    // Traitement du monitoring DNS
    $dns = gethostbyname($site['domain']) == $site['ip'];

    if($dns != $site['dns'] || $http != $site['http']):
        // On met à jour le site dans la base de donnée
        $pdo->query('UPDATE monitoring SET http = '.$site['http'].', dns = '.$site['dns'].', time = '.time().' WHERE id = '.$site['id']);

        // On n'alerte qu'à cette condition
    endif;
endforeach;

Alerte

Pour les alertes, je vous laissez gérer comme vous le souhaitez. Vous pouvez vous envoyer un mail, un SMS, une notification push … Tout ce qui compte, c’est que vous ayez toutes les informations nécessaire pour traiter le problème le plus rapidement possible. Ainsi, avec ce script, vous saurez :

  • Depuis combien de temps l’alerte est en place (ou depuis combien de temps le site est en ligne)
  • Qu’est-ce qui empêche vos utilisateurs d’accéder à votre site :
    • Votre serveur ne répond plus ?
    • Vos DNS sont mal configurés ?

III/ Paramétrer la tâche CRON

Il vous manque maintenant le plus important, la mise en production de votre script. Ici, nous allons demander à votre serveur (ce sera un debian 6.0 pour ma part) de lancer votre tâche CRON toutes les 3 minutes. Vous pouvez faire varier cette intervale mais plus elle augmente, moins vous serez réactif, plus elle diminue, plus vos serveurs vont travailler.

Nous supposerons que le chemin d’accès à mon script de monitoring soit à l’adresse suivante : /var/www/monitoring/cron.php et que vous avez les droits d’administration de votre serveur (un petit sudo et hop !)

Nous allons éditer le cron général de votre serveur. Pour se faire, connectez vous à votre terminal puis tapez la commande suivante :

$ crontab -e

Votre fichier CRON va s’ouvrir avec votre éditeur de texte préféré. Il vous suffira alors d’ajouter la ligne suivante :

*/3 * * * * php -f /var/www/monitoring/cron.php

Et voila, votre service de monitoring est en place. C’est plutôt cool, et surtout indispensable de savoir, avant votre client, quand ça va chauffer pour vos oreilles.

Lors de vos gros projets, il se peut que vous ayez à garantir la sécurité de votre site et donc avoir une copie exacte de tous vos fichiers et de vos données en permanence. Dans ce cas là, deux possibilités s’offrent à vous :

  • Le plan d’activité de reprise (PRA) : Vous utilisez un serveur maître qui gère le traffic des visiteurs et qui copie toutes ses données et tous ses fichiers sur un serveur esclave qui sera alors prêt à prendre la relève en cas de panne du serveur maître.
  • Le cluster : Vous utilisez deux ou plusieurs serveurs qui vont se répartir le traffic des visiteurs et s’assurer que toutes les données soient les mêmes partout.

Comment choisir votre architecture ? C’est plutôt simple. le PRA a l’avantage d’être peu coûteux par rapport au cluster qui nécessite un matériel spécifique (Load-Balancer, 70€/mois chez OVH contre 1€/mois pour l’IP Fail-over nécessaire au PRA) mais qui, lui, se révèle indispensable pour un projet à fort traffic (puisque les charges des serveurs sont répartis, vos visiteurs auront alors accès à un site plus fluide).

Pour ma part, pour le moment, je n’ai eu à m’occuper que de PRA, alors je voulais vous partager mon expérience. Nous avons déjà vu plusieurs étapes dans des tutoriaux précédents, je ne ferais donc que les citer.

Sommaires :

  • Etape 1 – Installation des serveurs web
  • Etape 2 – Configuration de l’IP Fail-Over
  • Etape 3 – Configuration du nom de domaine
  • Etape 4 – Réplication de la base de données
  • Etape 5 – Réplication des fichiers
Pour effectuer un PRA de base, nous aurons besoins :
  • Un nom de domaine avec ses accès DNS
  • Un IP Fail-Over (disponible chez OVH pour sa gamme de serveurs dédiés professionnels pour 1€HT/mois)
  • Deux serveurs web (pas forcément de la même capacité, il faut simplement qu’ils soient tous les deux accessibles par l’IP Fail-Over)
Pour l’installation d’un PRA, outre la propagation des DNS, comptez environs une heure de travail.

Etape 1 – Installation des serveurs web

Nous allons donc installer nos deux serveurs web, que nous appellerons S1 (pour le serveur maître) et S2 (pour le serveur esclave). Pour cela, pour vos deux serveurs, suivez ce tutoriel : [Tuto] Installer un serveur web sous Debian. Nous reviendrons sur les configurations d’apache plus tard. Pour ceux qui sont chez OVH, celui-ci vous permet de choisir un datacenter en particulier. Je vous conseille grandement de prendre vos deux serveurs dans des DC différents, histoire d’éviter que votre PRA soit mit à mal lors d’un incident physique sur le site.

Etape 2 – Configuration de l’IP Fail-Over

L’IP Fail-Over est un outil très pratique dans l’administration réseau. Celle-ci n’est en fait qu’une IP publique que vous pouvez faire rediriger votre l’IP privée de votre serveur (qui doit se trouver sur le même réseau). L’avantage, c’est qu’en un clic, et de manière presque instantanée, vous pouvez changer son IP de redirection. Fini donc les attentes longues des propagations DNS. Vous configurez votre nom de domaine pour que celui-ci pointe vers votre IP publique (ce qui peut prendre entre 30 minutes et 72 heures) une seule fois. A chaque changement de serveur, vous pourrez faire la modification d’IP rapidement, ce qui évite d’avoir des sites hors ligne de manière hasardeuse pendant quelques temps.

Commandez-donc votre IP fail-over que vous allez faire rediriger vers l’IP de votre serveur S1. Malheureusement, pour le moment, si vous tentez de vous connecter à cette IP, le serveur ne répondra pas. En effet, il va nous falloir configurer S1 et S2 pour accepter le traffic provenant de cette IP qui n’est pas la leur.

Pour cela, faites la manipulation suivante sur vos deux serveurs. Allez modifier le fichier « /etc/network/interfaces » et rajoutez les lignes suivantes à la fin du fichier :

post-up /sbin/ifconfig eth0:X 1.2.3.4 netmask 255.255.255.255 broadcast 1.2.3.4
post-down /sbin/ifconfig eth0:X down

Pensez à bien changer l’IP « 1.2.3.4 » (2 fois) par votre IP Fail-Over (IP publique). Puis lancez la commande :

/etc/init.d/network restart

Une fois que vous avez fait cette manipulation sur le S1, celui-ci devrait être accessible depuis son IP Publique. Mais n’oubliez pas de faire la même chose sur votre S2, sinon vous risquez d’avoir quelques soucis lors de votre premier basculement (et hop, un site hors ligne …).

Etape 3 – Configuration du nom de domaine

Cette étape là est relativement simple et à vrai dire, vous n’êtes pas forcément obligé de faire comme moi. Je vous conseille juste de prendre quelques précautions afin de pouvoir développer au mieux votre projet et de pouvoir cibler rapidement le moindre bug.

Nous allons donc configurer notre nom de domaine pour que celui-ci redirige vers l’IP publique de notre projet mais également des accès directs aux S1 et S2.

@ A [IP Publique]
www A [IP Publique]
s1 A [IP Privée S1]
s2 A [IP Privée S2]

Ainsi, quand vous venez de créer les redirections suivantes :

www.votredomaine.com ==> IP Publique
votredomaine.com ==> IP Publique
s1.votredomaine.com ==> IP privée S1
s2.votredomaine.com ==> IP privée S2

Ce qui vous permettra de configurer votre IP publique mais aussi d’avoir un accès direct au serveur de votre choix (pour la gestion de la BDD par exemple).

Mais il faut maintenant configurer correctement apache de vos deux serveurs. Ainsi sur S1, modifier votre fichier vhost :

ServerName votredomaine.com
ServerAlias www.votredomaine.com s1.votredomaine.com

Et sur votre s2 :

ServerName votredomaine.com
ServerAlias www.votredomaine.com s2.votredomaine.com

Votre nom de domaine, une fois la propagation DNS effectuée, sera convenablement configuré pour votre PRA.

Etape 4 : Réplication de la base de données

Là, je vous invite simplement à relire l’article suivant : [Tuto] Réplication base de données avec PHPMyAdmin.

Etape 5 : Réplication des fichiers

« Et maintenant, le coeur de la maison, la cuisine » Ou du moins la plus importante, la réplication des fichiers de s1 vers s2. Pour cela, nous allons utiliser Unison, qui va assurer la synchronisation de deux répertoires toutes les X minutes à l’aide d’un cron.

La première des choses à faire est de créer un tunnel SSH entre S1 et S2 et encore une fois, je vous renvoi vers ce tutoriel : [Tuto] Créer un tunnel SSH entre deux serveurs Debian.

Nous allons ensuite installer unison sur les deux machines :

apt-get install unison

Unison s’occupe donc de synchroniser les deux répertoires. Il va aller vérifier que tous les fichiers sont présents et sont les mêmes. S’ils ont été modifiés, vous pouvez configurer Unison de deux manières différentes:

  • Newer : C’est le dernier fichier qui a été créé qui est considéré comme le bon fichier.
  • Force : Vous déterminez quel serveur est considéré comme référent.
Dans notre cas, nous allons toujours utiliser la méthode « Force » pour deux raisons :
  1. Nous ne ferons nos développements que sur S1 et nous laisserons le soins à Unison de mettre à jour S2. Ca évite toute erreur.
  2. Unison ne sait pas supprimer les fichiers en mode Newer. En effet, si vous supprimez le fichier sur s1, il va le remplacer par celui présent sur s2 en le considérant comme plus récent (ce qui est logique) ce qui va donc vous causer des soucis.
Le but est donc de forcer la mise à jour du répertoire /var/www de S1 sur S2 toutes les X minutes. Pour cela, nous allons créer le fichier de configuration sur S1 pour Unison : Créez le répertoire /root/.unison/ et le fichier /root/.unison/default.prf :

# On force les modifications en cas de conflit
auto=true
batch=true

# Si tout le répertoire sur s1 est vide, on empêche la mise à jour de s2 (question de sécurité)
confirmbigdeletes=true

# On accepte de se contenter de la vérification du nom du fichier et de sa taille pour la comparaison des fichiers au lieu d’aller vérifier tout son contenu (c’est nettement plus rapide).
fastcheck=true

# On garde le même propriétaire des fichiers
group=true
owner=true

# On force la mise à jour de S2 depuis S1 en cas de conflit entre deux fichiers
prefer = /var/www

# On demande à Unison de ne rien ressortir de ses actions (puisqu’on va l’effectuer avec un cron, c’est inutile)
silent=true

# On demande à ce que l’heure de modification des fichiers soit aussi synchronisée (pour avoir réellement les mêmes données sur les deux serveurs
times=true

Nous allons pouvoir tester notre configuration et voir si tout marche bien manuellement. Pour cela, créez un fichier vide sur S1 mais pas sur S2 dans votre répertoire /var/www/ puis testez la commande suivante

 root@s1:~# unison /var/www ssh://[IP Privée S2]//var/www

C’est la première fois que vous lancez unison donc il se peut qu’il soit un peu bavard mais cela n’a pas d’importance. Si vous allez sur S2, vous devriez voir apparaître votre fichier. Pour aller un peu plus loin dans les vérifications, modifier le contenu de votre fichier sur S1 et relancez la commande. Normalement, Unison ne dit plus rien et le contenu du fichier a bien été modifié sur S2. Refaite le test en modifiant le fichier sur S2, relancez la commande et vérifiez que le fichier sur S1 n’a pas été modifié et que celui sur S2 a bien été écrasé par celui du S1. Et enfin supprimez le fichier sur S1 puis relancez la commande pour vérifier qu’il disparaît bien sur S2.

Nous pouvons maintenant automatiser cette commande à l’aide d’un cron. Pour cela, toujours sur S1, tapez la commande suivante pour ouvrir la console de gestion de vos tâches cron :

root@s1:~# crontab -e

Et ajoutez la ligne suivante :

*/1 * * * * unison /var/www ssh://[IP Privée S2]//var/www &> /dev/null

ici, la synchronisation s’exécute toutes les minutes (la ligne commence par */1). Une mise à jour aussi fréquente n’est pas nécessaire. Cela dépend totalement de votre type de projet. Si votre projet modifie des fichiers (en y stockant des données par exemple) alors oui, une synchronisation régulière est primordiale. Mais celle-ci étant lourde, si vos fichiers ne sont pas modifiés, n’hésitez pas à choisir des intervalle de synchronisation plus longs pour éviter de fatiguer votre serveur pour rien. Testez votre cron en modifiant un de vos fichiers sur S1 dans /var/www/ et vérifiez que celui-ci est répercuté sur S2 après l’intervalle de temps de votre cron.

Maintenant, si les tests sont concluants, alors bravo, vous venez de monter votre propre PRA.

Conclusion

Développez votre projet sur S1, toujours, ne touchez jamais à S2 sauf pour vérifier de temps en temps que tout fonctionne parfaitement (notamment du côté de la base de donnée). Dès que votre S1 a un problème et que vous êtes obligé de le mettre hors ligne, basculez votre IP Publique vers l’IP privée de votre S2 pour que celui-ci prenne la relève. Vous venez d’assurer à votre projet la sauvegarde intégrale de ses données en temps réelle et ça, ce n’est pas négligeable pour des sites importants.

Certaines de vos configurations réseaux vont impliquer la connexion d’un de vos serveurs en SSH à un autre de vos serveurs afin de pouvoir, par exemple, faire un sauvegarder ou encore synchroniser des fichiers ou des données. Afin d’automatiser cette connexion, nous pouvons apprendre à ces deux serveurs à se reconnaître entre eux et ainsi à ne pas demander de mot de passe ni de login. Nous allons pour cela, mettre en place un tunnel SSH à l’aide d’une paire de clef publique / clef privée sur chacun des serveurs.

Nous aurons besoins pour cela de deux serveurs linux tournant sous Debian 6.0. Nous appellerons le premier serveur S1 et le second S2.

Etape 1 : Création de la paire de clef publique / privée

La clef publique est une chaîne de caractère unique à chaque serveur. Cette clef est toujours associée à une clef privée qui permet au serveur de vérifier la validité de celle publique. Ainsi, si vous partagez la clef publique, le serveur pourra alors vérifier son authenticité et donc permettre la connexion sans mot de passe. Pour se faire, connectez vous sur votre serveur S1 et créez le couple de clefs :

$ root@server1:~# ssh-keygen -t dsa -b 1024

Votre console va vous demander où enregistrer la pair de clef et une « passphrase », laissez la vide et appuyer simplement sur entrer à chaque fois, jusqu’à ce que le « fingerprint » apparaisse. Vos fichiers « /root/.ssh/id_rsa » (clef privée) et « /root/.ssh/id_rsa.pub » (clef publique) ont été créées ! Réeffectuer la même opération sur votre S2.

Etape 2 : Transfert de la clef publique

Maintenant, nous allons partager notre clef publique et ainsi apprendre à notre serveur à accepter les connexions sans mot de passe de notre autre serveur. Pour cela, rien de plus simple, une petite ligne de commande :

$ root@server1:~# ssh-copy-id -i ~/.ssh/id_dsa.pub root@server2

Il vous demandera le mot de passe root de votre serveur 2 pour la dernière fois ! Faites de même dans le sens inverse pour accepter les connections de S2 sur S1.

Etape 3 : Tests

On va maintenant pourvoir tester. Connectez-vous en root sur S1 puis, depuis S1, connectez vous en root sur S2 :

$ root@server1:~# ssh root@server2

S’il ne vous demande pas de mot de passe, c’est que tout marche ! Effectuez le même test dans l’autre sens pour vérifier que la manipulation est bien symétrique. Vous venez de créer un tunnel SSH entre vos deux serveurs et ainsi de vous affranchir de vos mots de passes.

 

Pour certains de vos projets, vous aurez sûrement la nécessité de créer un système de sauvegarde de données complet. Ici, nous allons apprendre à copier en temps direct une base de données d’un serveur S1 (maître) sur un serveur S2 (esclave), ce qui nous permettra d’avoir deux bases de données totalement synchronisées. En cas de crash du premier serveur, on peut alors basculer sur la base de l’autre serveur et ainsi, ne perdre aucune donnée.

Pour ce faire, nous allons utiliser un serveur sous Debian 6.0 avec PHPMyAdmin. (Pour installer ce serveur web, je vous invite à aller lire ce tutoriel)

Etape 1 : Création de la base de données à dupliquer

Créez une base de donnée sur S1 et S2 depuis PHPMyAdmin. La mienne s’appellera, de manière tout à fait objective, « tiloweb ».

Etape 2 : Configuration du serveur maître

Dans l’accueil de PHPMyAdmin du serveur S1, allez dans l’onglet « Réplication ».

Puis cliquez sur le lien « configurer » de la partie « Réplication maître ».

Cliquez sur « Configurer le serveur maître »

Un formulaire apparaît, choisissez la ou les bases de données à répliquer sur votre S2. En l’occurrence, la table « tiloweb ». On vous demande alors de modifier un fichier pour y rajouter quelques paramètres de configuration.

Configuration de la réplication

Le fichier en question, si vous avez suivi la procédure d’installation standard de MySQL, se trouve à l’adresse suivante dans votre serveur : /etc/mysql/my.cnf. Contrairement à ce que vous dit PHPMyAdmin, ne copiez pas ces lignes à la fin de votre fichier de configuration mais quelque part entre « [mysqld] » et « [mysqldump] » (normalement, juste après la ligne 86). Trouvez également la ligne « bind-address » et commentez-la (ce qui vous permettra d’autoriser les connexions depuis d’autres IP). Vérifiez également que les droits de ce fichiers sont bien en 755 (et non pas en 777). Cliquez alors sur « Exécuter ». PHPMySQL va redémarrer automatiquement le serveur MySQL et normalement.

Tuto Réplication - Screen 5

Confirmation de la configuration de votre S1 comme maître.

Cliquez ensuite sur « Ajouter un utilisateur pour la réplication vers l’esclave ? ». Et remplissez le formulaire comme suit :

Créez un nouvel utilisateur avec les droits de réplication maître

Vous pouvez bien évidement choisir un nom d’utilisateur différent, mais par soucis d’organisation, j’utilise l’utilisateur « sync ». Dans la ligne « Serveur »,  « % » signifie « Tout serveur » mais vous pouvez décider de n’autoriser qu’un IP spécifique.

Votre serveur maître est maintenant prêt à être répliqué.

Etape 3 : Configuration du serveur esclave

Sur votre serveur S2, rendez-vous dans l’onglet « Réplication » puis cliquez sur « configurer le serveur esclave ? ». Commencez alors par modifier le même fichier my.cnf en rajouter cette fois ci simplement la ligne « server-id » et en vous assurant que le numéro est unique. Remplissez alors le formulaire avec les identifiants correspondant à l’utilisateur créé en étape 2 :

Remplissez les informations de l’utilisateur créé à l’étape 2

Validez, et voila votre serveur esclave configuré.

Cliquez ensuite sur « synchroniser les bases de données avec le serveur maître ». Ce qui va permettre de s’assurer, avant de démarrer le processus, que les données soient les mêmes sur les deux serveurs. Une fois que c’est fait, il ne vous reste plus qu’à cliquer sur « Démarrer » complètement. Et voila, votre base de données est répliquée.

Etape 4 : Test

Un petit test s’impose tout de même pour vérifier que la réplication s’effectue correctement. Allez sur l’interface PHPMyAdmin de votre S1, sélectionnez dans votre base répliquée une table et insérez une ligne. Normalement, la ligne est automatiquement insérée également sur le serveur S2. Essayez !

 

La réplication d’une base de donnée n’est qu’une étape parmi tant d’autre pour la création d’un hébergement sécurisé, comme un PRA (Plan de Reprise d’Activité, qui vous permet une sauvegarde sûr de toutes vos données) ou un Cluster (qui vous permet de répartir les charges d’un site à forte fréquentation sur plusieurs serveurs). Vous voulez aller plus loin ? Je vous conseille l’excellent article d’Antoine Augusti « La réplication de bases de données » qui vous apprendra à gérer plus de deux serveurs à la fois.

Nous avons vu ensemble, il y a quelques semaines de cela, comment créer un environnement de développement PHP local sous Mac OS X. Malheureusement, l’arrivée de la mise à jour 10.8 de Mac OS (Mountain Lion) a quelque peu tout chamboulé et quelques actions sont nécessaires pour rétablir votre environnement.

Tout d’abords, sachez que les droits sur les fichiers ont été rétablis, que les fichiers sont de retour à l’origine donc que nous avons perdu toutes les anciennes configurations d’apache. Réeffectuez simplement l’étape 1 du tutoriel.

L’interface des paramètres de partage de Mac OS X a changé également et ne permet plus de redémarrer apache comme dans la version précédente. Il faut maintenant ouvrir le terminal (qui se trouve dans « /Applications/Utilitaires/terminal.app ») et utiliser cette ligne de commande :

sudo apachectl restart

A partir de là, normalement, tout est revenu à la normal. Alors profitez bien !

La mise à jour de Mac OS X 10.8 Mountain Lion a changé la configuration d’apache. Pour plus d’informations, lisez l’article MAJ Max OS X Mountain Lion : Impact de votre serveur de développement local.

Il existe plusieurs solutions de développement en local sous windows pour bien préparer vos projet (EasyPHP ou encore WampServer) mais les solutions sous Mac OS X sont assez limitées (Mamp est très limité dans sa version gratuite et Xamp est instable et très hasardeux). Pourtant, c’est très facile de développer son environnement manuellement sous MaxOS X sachant qu’apache est déjà installé et intégré au système d’exploitation. Nous allons ainsi voir comment configurer apache pour qu’il puisse faire tourner un site en local sur un nom de domaine de développement personnalisé et comment faire tourner MySQL et se passer de PHPMyAdmin.

I/ Configurer Apache 2

Apache a le mérite d’être déjà installé sur Mac OS X. Il suffit alors de le lancer, de le configurer et d’apprendre à le manier. Tout cela est extrêmement simple !

Commencez par ouvrir les préférences systèmes de votre machine, pour rappel, vous pouvez y accéder depuis la pomme en haut à gauche de votre ordinateur. Sélectionnez l’icone « partage » puis activer l’option « Partage Web » (il se peut que le démarrage soit un peu récalcitrant, c’est comme une vieille Renault, n’hésitez pas à insister un peu en décochant puis recochant la checkbox). Ensuite … En fait non, c’est tout. Votre apache est maintenant allumé et prêt à fonctionner. Il faut tout de même le configurer maintenant.

Si vous n’avez pas activé la gestion des fichiers cachés, le dossier apache sera invisible et il vous faudra y accéder depuis « Menu Finder / Aller / Aller directement à » rendez-vous donc ici : « /etc/apache2 » et vous voici dans l’arborescence de la configuration d’apache 2. Celle-ci est légèrement modifié par rapport à l’officielle qui tourne sous Linux, mais on y retrouve les principaux composant dont vous aurez besoins :

  • httpd.conf qui vous permettre de gérer les extensions et activer les virtual hosts.
  • extra/httpd-vhosts.conf qui vous permettra de gérer vos différents sites locaux.

Commençons avec le fichier httpd.conf. Il se peut que celui-ci soit bloqué au niveau des accès en écriture. Pour remédier à ce problème, clic droit sur le fichier, lire les informations et tout en bas, sélectionnez votre utilisateur pour lui donner les droits de lecture et d’écriture. Vers le début du fichier, vous pouvez apercevoir un certain nombre de ligne commençant par « LoadModule ». Il suffit de commenter cette ligne pour désactiver un module apache. Ainsi, si vous souhaitez utiliser de l’URL Rewriting, je vous conseil de dé-commenter la ligne « LoadModule rewrite_module libexec/apache2/mod_rewrite.so ». De même, assurez-vous que le module php5_module soit activé. Vers la fin du fichier, vous trouverez la ligne suivante : « Include /private/etc/apache2/extra/httpd-vhosts.conf » si celle-ci est commentée, activez-la en retirant le # ce qui vous permettra alors de gérer vous même les répertoires de vos sites locaux.

Ouvrez le fichier extra/httpd-vhosts.conf et créez votre propre virtual host. Petit exemple :

<VirtualHost *:80>
    ServerAdmin thibaulthenry@tilotiti.com
    DocumentRoot "/Users/thibaulthenry/Sites/EdenPHP/www/"
    ServerName edenphp.dev
    ServerAlias www.edenphp.dev
    ErrorLog "/Users/thibaulthenry/Sites/EdenPHP/www/log/apache-error_log"
    CustomLog "/Users/thibaulthenry/Sites/EdenPHP/www/log/apache-access_log" common

    <Directory "/Users/thibaulthenry/Sites/EdenPHP/www/">
        AllowOverride All
        Options MultiViews FollowSymlinks
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

Ici, j’ai donc créé le site EdenPHP qui répondra au nom de domaine edenphp.dev (ainsi qu’à son alias www.edenphp.dev). J’y autorise la lecture web depuis mon ordinateur ainsi que l’interprétation de la réécriture d’URL. Je précise que la racine du site web se trouve à cette adresse « /Users/thibaulthenry/Sites/EdenPHP/www/ » et je donne mon adresse e-mail en cas de problème, ce qui ne sert ici strictement à rien !

Votre apache est maintenant correctement configuré, il est lancé mais il vous manque deux choses : Premièrement, il faut relancer apache pour que les modifications soient prises en compte et il faudrait faire rediriger le nom de domaine vers votre ordinateur.

L’équivalent de « /etc/init.d/apache2 restart » sous mac, c’est « je décoche la case partage web de mes préférence de partage, puis je la recoche ». Jusque là, rien de bien complexe. Soyez insistant mais en cas de soucis, les logs sont présents dans le répertoire d’apache pour vous indiquer l’erreur que vous avez comise.

Vous devez ensuite rediriger manuellement le nom de domaine choisi (ici edenphp.dev) vers votre mac. Pour se faire, il vous suffit d’aller dans /etc/ et d’éditer le fichier hosts (comme pour le fichier httpd.conf, si vous n’avez pas les autorisations nécessaires pour modifier le fichier, allez régler ce problème dans « lire les informations » du menu contextuel). Rajoutez simplement la ligne suivante à la fin de votre fichier :

127.0.0.1 edenphp.dev www.edenphp.dev

Enregistrez et tada ! Vous aurez accès à votre site local depuis votre site préféré. Il se peut cependant que vous ayez à utiliser du mysql en localhost, pour ça, mysql a tout prévu !

II/ Installation de MySQL

Quand je dis que c’est simple, c’est simple. Allez télécharger MySQL Workbench pour mac directement sur le site officiel. Installez l’application et lancez là (depuis votre répertoire d’application, pas depuis le volume temporairement monté). L’application est plutôt bien faite, tout à droite, dans la partie « Server Administration » sélectionnez « New Server Instance ». Sachez que votre login sera root et le mot de passe sera vide (vous êtes en local, on s’en fiche un peu). Puis dans la partie « SQL Development », sélectionnez « New Connection » et vous voici avec un serveur MySQL monté en local et un formidable outil, bien plus efficace que PHPMyAdmin. Vous pouvez maintenant connecter votre application PHP à MySQL en utilisant le serveur localhost avec l’utilisateur root et sans mot de passe.

 

Vous voilà donc avec un super environnement « MAMP » (Mac, Apache, Mysql, PHP) qui vous permettra de développer votre propre projet en local directement sans avoir à dépendre de programmes tierces qui ne correspondent pas forcément à vos besoins.

Si vous avez le moindre problème, n’hésitez pas à me poser des questions en commentaire. J’y répondrais quoi qu’il arrive.

Les tutoriels d’installation d’un serveur web pullulent sur le net. Mais Linux étant ce qu’il est, la plupart des packages (programme que vous installez sur votre serveur) sont rapidement obsolètes. Ainsi, dès que vous souhaitez suivre un tuto, vous tombez vite sur des erreurs ou carrément sur des configurations totalement différentes et donc inutilisables.

Je ne suis, pour ma part, absolument pas administrateur serveur/réseau. Ce n’est pas ma spécialité et je ne peux même pas dire que j’aime ça. Mais il n’empêche, qu’en quelques mois, j’ai dû installer plus d’une vingtaines de serveurs et donc c’est tout naturellement que je voulais vous partager ma méthode.

Ainsi, nous allons voir ensemble comment installer et configurer un serveur web sous Linux Debian assez basique mais amplement suffisant pour la création d’un site internet.

Sommaire :

  • Chapitre 1 : Les bases
  • Chapitre 2 : Apache
  • Chapitre 3 : PHP
  • Chapitre 4 : Base de donnée
  • Chapitre 5 : Serveur mail

Chapitre 1 : Les bases

Lorsque vous achetez (ou louez) un serveur web chez un hébergeur, celui-ci vous installe une distribution dessus. Par exemple chez Online, il vous laisse le choix entre plusieurs systèmes d’exploitation (si vous êtes en mode « serveur ») : Debian, Ubuntu, Centos, Windows, ESXI, Mageia, Proxmox et Fedora. Pour ce tutoriel, nous avons choisi le système d’exploitation Debian en version 64 bits.

Une fois votre serveur installé, il faut maintenant vous connecter dessus, nous allons utiliser pour ça, un protocole appelé SSH. C’est un protocole sécurisé qui permet de prendre le contrôle total de votre machine en ligne de commande. Sachez qu’il faut attendre entre 3 et 15 minutes après le premier allumage d’un serveur pour que le SSH fonctionne. Ainsi, si vous n’arrivez pas à vous connecter, retenter d’ici quelques minutes.

Pour se connecter en SSH sur votre serveur, vous avez plusieurs possibilités :

– Pour Windows : Installez Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)

– Pour Mac : Utilisez directement votre terminal (/Applications/Utilitaires/Terminal)

– Pour Linux : Votre console fera amplement l’affaire …

Pour notre tutoriel, j’utilise le terminal de Mac OS X.  Son utilisation est exactement la même que la console de linux. Par contre, l’utilisation de putty est légèrement différente au niveau de la connexion au serveur. Celui-ci vous demande l’IP de votre serveur, le nom d’utilisateur et le mot de passe directement dans une fenêtre avant votre connexion et ce dernier vous connecte automatiquement au serveur. Ainsi, pour ceux qui utilisent putty, ne prenez pas en compte cette étape. Pour les autres, voici la ligne de commande a effectuer :

ssh  root@123.123.123.123

« root » est le super utilisateur par défaut de votre machine, celui-ci a les pleins pouvoir sur tous les fichier. Remplacez bien évidement 123.123.123.123 par l’IP de votre machine. La première fois que vous vous connecterez à votre serveur, votre ordinateur va vous demander si vous lui faites confiance. Ce choix vous appartiens entièrement, mais s’il est négatif, vous ne pourrez pas vous y connecter. C’est bête …

Ensuite, votre serveur vous demandera votre mot de passe. Attention ! Vous aurez beau le taper, celui-ci ne s’affichera pas, c’est tout à fait normal, simple question de sécurité. Valider simplement avec la touche « Entrer », vous êtes donc maintenant connecté à votre serveur.

Premier réflexe ! Mettre à jour votre machine. Commencez par rechercher des mises à jours :

apt-get update

Puis installez-les :

apt-get upgrade

Cette seconde opération est un peu plus longue (5 minutes chez moi) et peux vous poser quelques questions assez simples à répondre (il me demande par exemple le type de clavier que je veux utiliser, ce qui est totalement inutile, mais rien que pour me la péter, je sélectionne le MacBook Pro), si vous ne savez pas quoi répondre, la valeur par défaut est toujours idéale.

Votre serveur est à jour, nous sommes prêt à faire joujoux avec.

Chapitre 2 : Apache

Apache est le programme qui permettra à votre serveur d’interpréter vos fichiers et de les associer à une URL. Pour l’installer, exécutez la ligne de commande suivante :

apt-get install apache2

Félicitation, votre serveur est maintenant officiellement un serveur « web ». Tapez l’IP de votre machine dans votre navigateur, et vous verrez un beau « It works ! » apparaître. Ce fichier se trouve dans le répertoire « /var/www/ » par défaut. Cependant, certains d’entre vous n’ont pas forcément envie que leur site soit accessible directement depuis son IP. Apache nous permet donc de filtrer les entrées en fonction du nom de domaine appelé et de les rediriger vers des répertoires différents grâce aux fichier vhost. Nous allons donc maintenant configurer votre premier site (à tout hasard test.com).

Nous allons commencer par créer le répertoire qui accueillera le site en question. Allez dans le répertoire d’apache par défaut :

 cd /var/www/

Puis créez votre répertoire au nom de votre site :

mkdir test.com

Le répertoire /var/www/test.com/ est maintenant créé et va pouvoir accueillir votre site internet. Créons donc sa première page index.html qui va nous permettre de tester si apache est bien configuré :

nano /var/www/test.com/index.html

Remplissez le avec un code HTML, juste de quoi attester de la présence du fichier :

<center><b>Vous êtes maintenant sur le site test.com</b></center>

Pour enregistrer les fichier, appuyez sur CTRL + X puis validez. Nous allons maintenant créer le vhost qui correspondra au nom de domaine test.com

cd /etc/apache2/sites-available
nano test.conf

Et voici votre premier vhost :

<VirtualHost *:80>
        ServerAdmin contact@test.com
        ServerName test.com
        ServerAlias www.test.com
        DocumentRoot /var/www/test.com
        <Directory /var/www/test.com>
                Options -Indexes FollowSymLinks
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
</VirtualHost>

Je m’explique :

ServerAdmin : L’adresse e-mail à renvoyer à vos utilisateur si une erreur survient

ServerName : Le nom de domaine sur lequel doit répondre le serveur

ServerAlias : Les alias du nom de domaine, comme le www ou d’autres sous-domaines

DocumentRoot : La racine de votre répertoire pointant vers le site

Toute la partie Directory représente les droits des fichiers du serveur (je ne développerais pas plus ici, sachez juste que les valeurs de notre vhost sont optimales pour un site web).

Enregistrez le fichier. Il faut maintenant l’activer, et pour ça, rien de plus simple :

a2ensite test

Maintenant, apprenez par coeur la ligne de commande suivante, elle vous permettra de prendre en compte les modifications effectuées à Apache et de redémarrer ce dernier :

service apache2 restart

Votre serveur est maintenant configuré pour recevoir le trafic venant du domaine test.com et redirigé vers le dossier /var/www/test.com/.

Par contre, vous l’aurez remarqué, le vrai domaine test.com ne pointe pas forcément sur votre serveur (si c’est le cas, vous avez énormément de chance !), nous allons, pour tester notre configuration, obliger votre ordinateur à rediriger test.com vers votre serveur.

Sur mac, ouvrez Finder, dans le menu, choisissez « Aller » puis « Allez au dossier » et tapez le répertoire suivant :

/private/etc/

Trouvez le fichier « host » (sans extension). Clic droit, « lire les informations ». Dans la partie « Partage et permissions » sélectionnez votre utilisateur et définissez lui le droit « Lecture et écriture » puis ouvrez le fichier avec votre éditeur de texte. Pour les autres systèmes d’exploitation, la manipulation est très similaire. Une petite recherche Google vous permettra d’arriver à vos fins. Une fois sur le fichier, rajouter à la fin de celui ci la ligne suivante :

123.123.123.123 test.com www.test.com

Notez que nous n’utilisons pas d’espace mais des tabulations ! Enregistrez. Vous venez d’apprendre à votre ordinateur à rediriger test.com et www.test.com vers l’IP 123.123.123.123 (modifiez cet IP par celui de votre serveur). Vous pouvez maintenant vous rendre à l’adresse http://www.test.com et vous allez voir votre fichier index.html.

Vous avez la possibilité, pour des questions de sécurité, de supprimer la redirection par défaut sur le répertoire /var/www en désactivant le vhost default :

a2dissite default

N’oubliez pas de redémarrer apache :

service apache2 restart

Si vous avez l’intention d’utiliser de l’URL rewriting, n’oubliez pas d’activer le mode, pour cela, rien de plus simple :

a2enmod rewrite

Votre apache est maintenant configuré correctement. Vous êtes presque prêt à installer votre site internet. Il manque encore un petit détail : votre serveur ne sait que lire vos fichiers, pas les interpréter. Nous devons donc installer PHP.

Chapitre 3 : PHP

Cette installation est très rapide et ne demande aucune configuration !

apt-get install php5

On peut également rajouter tout de suite quelques librairies bien utiles

apt-get install php-pear php5-gd php5-curl

On va maintenant vérifier que PHP fonctionne bien, pour cela, il suffit d’installer un fichier à la racine de votre site test.com avec à l’intérieur un phpinfo() :

nano /var/www/test.com/phpinfo.php

Et entrez le code suivant dans votre page :

<?php
phpinfo();
?>

Enregistrez et rendez-vous sur l’url de la page : http://www.test.com/phpinfo.php. Voici un récapitulatif de toutes les informations PHP de votre serveur. PHP est donc bien installé.

Chapitre 4 : Base de donnée

J’ai fait depuis longtemps le choix d’une base de donnée décentralisée, histoire de gagner du temps. Mais si vous souhaitez installer une base de donnée sur votre serveur, alors il vous faut installer MySQL, apprendre à votre serveur à faire communiquer votre base de donnée et PHP et enfin, vous donner la possibilité d’administrer cette base de donnée.

Pour commencer, il faut installer mysql :

apt-get install mysql-server

On va vous demander le mot de passe administrateur de votre base de donnée, notez le bien. Ensuite, apprenons à PHP à communiquer avec la base de donnée :

apt-get install php5-mysql

Et enfin, installons PHPMyAdmin qui nous permettra d’administrer cette base de donnée.

apt-get install phpmyadmin

Il va d’abords vous demander de faire un choix entre lighthttpd et apache2. Choisissez apache2 (attention, le fait qu’il soit surligné par défaut ne le sélectionne pas pour autant. Il vous faut appuyer sur la barre d’espace pour voir une étoile apparaître devant « apache2 »). Ensuite, il va vous demander l’autorisation de modifier votre base de donnée, répondez oui puis donnez lui le mot de passe de celle-ci. Il vous demandera ensuite de choisir un mot de passe pour vous connecter à PHPMyAdmin. Voila, PHPMyAdmin est installé avec succès. Vous devriez pouvoir vous connectez depuis l’URL http://www.test.com/phpmyadmin/. Si ce n’est pas le cas il faut déterminer par quel moyen y accéder. La solution la plus courante reste à paramétrer votre vhost pour que celui-ci fasse pointer le répertoire /phpmyadmin/ de votre site vers phpmyadmin :

nano /etc/apache2/sites-available/test

Et rajoutez juste après </Directory> les lignes suivantes :

Alias /phpmyadmin "/usr/share/phpmyadmin/"
<Directory /usr/share/phpmyadmin/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Order allow,deny
        allow from all
</Directory>

Puis redémarrez votre serveur apache :

service apache2 restart

Concrètement, je vous conseille de ne pas utiliser cette URL qui est utilisée par défaut. En effet, des milliers de robots scrutes tous les serveurs afins de déterminer qui a installé phpmyadmin et d’y exploiter d’éventuelles failles. Donc choisissez votre propre URI discrète.

Chapitre 5 : Serveur mail

Vous avez sûrement envie de pouvoir envoyer des mails depuis votre site internet. Pour cela, il faut apprendre à votre serveur à le faire en installant postfix :

apt-get install postfix

Il va vous demander comment le configurer, choisissez la configuration « Site Internet » puis un domaine depuis lequel envoyer vos mails. Dans l’idéal, renseignez un domaine existant, pointant réellement sur votre machine, mais pour ces tests, nous nous contenterons d’utiliser test.com. La seule répercussion (à ce que je sache) est que tout mail envoyé depuis test.com aura de grande chance de se trouver dans les SPAM.

Voila, la fonction mail() de PHP fonctionnera maintenant à merveille.

 

Voila votre serveur web prêt à être en production ! Dès que j’aurais le temps, je vous ferais sécuriser un peu tout ça.

 

UPDATE 06/10/2015 : Suite à la remarque de d’Alexis, ce tutoriel a été mit à jour pour la version 8 de Debian ! Quelques modifications sont importantes : vous devez impérativement renommer vos VHOST pour y ajouter l’extension « .conf ».