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.

Google a lancé, il y a quelques semaines maintenant, les communautés sur son réseau social. Soit l’équivalent des « groupes » sur Facebook, mais en beaucoup plus soigné, soyons honnête. Personnellement, c’est LA fonctionnalité qui m’a fait revenir sur Google+ et qui semble le faire revivre. A vrai dire, ça m’apporte un vrai plus. Effectivement, pour le moment, j’utilisais Twitter pour suivre les différentes communautés et nouveautés autour des différents langages, framework que j’utilisais. Mais Twitter a rapidement ses limites dans ce domaine puisque les informations étaient noyées parmi les postes perso du millier (ou presque) de twittos que je follow. Google+ a donc apporté une véritable solution à ce besoin ! Les posts sont classés en fonction des communautés (donc de la technologie ciblée) et même classés par groupes pour arriver directement là où l’on souhaite chercher la bonne information.

Je fais déjà parti de plusieurs communautés française comme Titanium appcelerator, PHP, etc … Mais il y en a une qui manquait beaucoup à son sens, une communauté française sur jQuery. Voila qui est donc réglé, la communauté jQuery France vient d’être créée sur Google+ et permettra le partage d’infos, de ressources, de plugins et d’entraide en français.

N’hésitez pas à y participer ! J’essayerais, pour ma part, d’y être actif, d’y poster un peu tout ce que je trouve en français et de répondre aux questions que certains peuvent se poser.

jquery_logo

La question est récurrente, jusqu’à quelle version d’Internet Explorer devons-nous rendre compatibles nos sites internet ? Voici mes propres éléments de réponse.

Premièrement, je regarde les statistiques des navigateurs : Au mois d’octobre 2012, selon le W3C, IE représente 16% du traffic web (Microsoft a prit très cher cette année). Donc, de manière globale, il est bien entendu hors de question d’abandonner totalement IE.

Allons un peu plus loin concernant le choix des versions à prendre en compte. Il faut maintenant définir la cible de vos utilisateurs. Quelques petites exemples tiré de certains de mes sites :

Geeks :

  • 9 : 57,31%
  • 8 : 40,38%
  • 10 : 1,15%
  • 6.0 : 0,77%
  • 7.0 : 0,36%

Explication : Les geeks aiment et savent être à la pointe.

Plus de 60 ans :

  • 7 : 54,64%
  • 8 : 39,18%
  • 6 : 6,19%

Explication : La mise à jour, ils la font quand le petit fils vient à la maison …

Pros :

  • 9 : 48,94%
  • 8 : 38,3%
  • 7 : 8,51%
  • 6 : 4,26%

Explication : De manière générale, les petites entreprises sont à jour, les grosses, par contre, sont catastrophiques ! Les DSI mettent en place des parcs systèmes figés qui ne sont alors pas mit à jour. (Je travail avec le service internet d’une filiale d’une banque française. Ils sont tous sous IE7, impossible d’évoluer) d’autres ont monté des systèmes (CRM ou autres) qui fonctionnent avec les propriété systèmes d’IE6 (genre orange …)

 

Ainsi, si votre site est B2B (donc à destination des professionnels) ne négligez pas les anciennes versions d’IE, même si Microsoft a déprécié IE6 depuis un bout de temps et que Google lui, vient de déprécier IE8. Par contre, pour les autres cibles, vu les chiffres, il devient aberrant de travailler sur des versions 8LTE (donc plus anciennes que la version 9) pour prendre en compte des navigateurs qui représentent moins que la population des mals-voyant et autres nécessiteux des technologies d’accessibilité.

De manière plus général, au quotidien,  j’ai abandonné IE6, et je maintiens seulement les fonctionnalités sous IE7 et 8 et la compatibilité totale (fonctionnalités + design) sur les navigateurs IE9+.

Et vous ?

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.

C’est re-parti pour les recherches !

Si tu es jeune, si tu es geek, si tu es doué en développement web et surtout en PHP, si tu es sociable, si tu as envi d’intégrer une équipe dynamique dans une boîte sympathique (mais avec beaucoup de caractère), si tu aimes la bière et si tu n’as pas peur d’un directeur technique tyrannique, alors peut-être que tu es fait pour nous !

Poste : Développeur Web Junior
Contrat : CDI
Rémunération : Selon profil (ouai, c’est très chiant de dire ça, mais tente ta chance tout de même, sait-on jamais)
Languages : PHP/HTML(5)/CSS(3)/JS et un petit plus pour Smarty, Titanium Mobile, jQuery et EdenPHP.
Entreprise : Digital Dealer – Création de sites internet pour la distribution automobile (mais pas que, on aime les défis).
Lieu : Levallois-Perret (92300, Hauts-de-seine).

Contactez-moi à job@digitaldealer.fr pour plus d’infos et pour postuler, les risques de morts subites sont très peu probables (sauf si c’est pour un stage ou de l’alternance)

Bref, n’hésite pas à faire tourner pour la bonne cause (enfin surtout pour la mienne).

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.

S’il y a un raccourcie que les développeurs web (et surtout les intégrateurs) connaissent bien, c’est tout de même CTRL+F5 (ou CMD+R pour les mac). A chaque petite modification de notre fichier CSS, on l’enregistre, on le met en ligne puis on recharge la page sur laquelle on est. Mais cela peut poser quelques soucis et faire perdre du temps.

En effet, hier, je travaillais sur l’intégration d’une WebApp en JS quand je suis arrivé sur une page assez complexe. Chaque modification m’obligeait à revenir à l’accueil, recharger ma page et refaire tout le chemin pour revenir à cette fameuse page. Pas très pratique, vous en conviendrez. Vous pouvez effectivement modifier votre style CSS directement dans la console FireBug ou Chrome, mais cela ne reste pas très pratique.

Heureusement, il existe une solution toute simple ! Il vous suffit de glisser ce lien CSS Reload dans vos favoris et de cliquer dessus à chaque fois que vous voulez mettre à jour uniquement vos feuilles de style.

Comment ça marche ? C’est pas très compliqué à vrai dire. A chaque fois que vous cliquerez sur ce lien depuis votre barre de favoris, votre navigateur va exécuter un code javascript qui va aller scanner votre page et remplacer les fichiers CSS chargés par ceux présents sur le serveur,

Très simple et très pratique !