C’est là que les outils que je vais présenter dans cet article interviennent. Aujourd’hui je parlerai de Hudson, Mantis, Phing, Checkstyle, PhpDocumentor, Pdepend et je montrerai l’interconnexion de tout ça sur un projet symfony.

Mantis

Mantis est un bug tracker, c’est-à-dire un rapporteur de défaillances. Il permet de consigner tous les problèmes survenus sur une application, de déclarer des priorités plus ou moins importantes mais surtout d’avoir un réel échange entre le rapporteur (le client) et l’équipe technique (composée de… moi). L’avantage d’avoir ce type d’outil dépasse ce que je viens de dire mais je m’en sers essentiellement pour avoir un endroit adapté où récolter les défaillances de mes applications. Mantis s’occupe d’avertir tous les gens concernés par mail, lorsqu’un bug est ajouté ou résolu par exemple. Ainsi, je ne perds aucun retour client auparavant stocké dans ma boîte mail sous forme de dizaines de mails et lorsque je résous un bug, le rapporteur concerné est prévenu automatiquement.

Nous allons voir pourquoi c’est si intéressant.

Hudson

J’ai déjà parlé d’Hudson, sans vraiment rentrer dans les détails parce que je ne vais pas réécrire ce qui a déjà été publié x fois, mais cette fois-ci je vais rentrer plus dans les détails. Au passage, Hudson est un serveur d’intégration continue.

Pour un projet symfony, je crée un projet freestyle, connecté à Git avec un déclencheur sur tout changement dans le repository distant. J’ajoute ensuite une succession de tâches symfony :

- création du répertoire log/

- suppression de la base de tests SQLite

- création de la base de tests

- tests

Ceci est un projet basique qui me permet d’avoir une intégration continue et une alerte rapide par mail si un problème survient.

Oui mais voilà, ce n’est pas suffisant, on peut mieux faire. J’ai parlé de Mantis juste avant, il serait bien de pouvoir connecter Hudson avec Mantis. C’est justement ce que fait le Mantis Plugin pour Hudson. Ainsi, si je « commit » une modification qui a résolue un bug, exemple :

Le plugin va pouvoir lier ce changement avec la page Mantis du bug et ajouter les informations liées au commit. Dorénavant, lorsque je « commiterai » un fix, le rapporteur sera prévenu de la résolution du bug qu’il aura soumis. Le gain de temps est indéniable.

Configuration Hudson :

Mais on peut (encore) faire mieux d’une autre manière, c’est-à-dire que si la build est un succès, pourquoi ne pas la déployer. Pour avoir un changement, je dois faire un « push » vers le repository distant. Or, on ne « push » pas tous les jours ou du moins, pas derrière chaque commit. Ce serait un peu perdre l’avantage du mode décentralisé de Git. Ainsi, quand je choisis de faire un « push » c’est que j’estime avoir suffisamment modifié mon projet. Ceci m’amène à penser qu’il devient intéressant de le déployer.

Merci à Capistrano (lire ici mon article sur le déploiement d’applis symfony et diem avec Capistrano) et au SSH Plugin d’Hudson. Ce plugin n’est pas des plus parfaits mais il fonctionne. Si la build passe, je lance mon déploiement. Normalement, le déploiement n’échoue pas, si c’était le cas alors : capistrano ferait un rollback sur la dernière version fonctionnelle et les logs Hudson m’indiqueraient le problème. Je peux donc être rassuré de ce côté-là.

Jusqu’à présent, je n’ai parlé que d’automatisation des aspects « après développement » à savoir les feedbacks client et le déploiement. Ce sont les deux points essentiels après réussite des tests. Pour autant, Hudson peut aider l’équipe de développeurs en effectuant une série d’analyses.

Phing : l’Ant des temps modernes (ou pas)

Phing, c’est Ant (utilisé dans le monde Java) version PHP, en quelques mots, un outil d’automatisation de tâches répétitives. Il faut connaître Ant pour comprendre qu’il est génial de disposer d’un outil semblable pour PHP. C’est grâce à cet outil que je génère des rapports d’analyse.

Phing s’installe via PEAR.

Checkstyle : mon code a du style !

Checkstyle est un outil de contrôle de code. Il vérifie le style du code écrit (indentation, commentaires, …). Pour l’utiliser avec PHP, il faut PHP_CodeSniffer (on abrège en phpcs) et le Checkstyle Plugin d’Hudson. Pour l’utiliser avec symfony, on ajoutera le standard symfony : http://github.com/denderello/phpcs-symfony ou si vous utilisez la toute dernière version : http://github.com/willdurand/phpcs-symfony.

Configuration Hudson :

Configuration du build.xml (Phing) :

Et aperçu du résultat :

Pdepend : analyse de code statique

Pdepend, analyseur de code statique, permet de calculer des indices (couplage, instabilité, …) afin de déterminer la qualité du code de la build. Pour cela, il nous faut le Jdepend Plugin d’Hudson et avoir installé pdepend.

Configuration Hudson :

Configuration du build.xml :

DRY ! Analyser les répétitions de code

Don’t Repeat Yourself, adage symfony, on souhaite ici analyser le code dupliqué. Pour cela, on utilise phpcpd (toujours via PEAR) ainsi que le DRY Plugin d’Hudson.

Configuration Hudson :

Configuration du build.xml :

Et aperçu du résultat :

PhpDocumentor : génération de la documentation du projet

PhpDocumentor permet de générer la documentation d’un projet, tout comme Javadoc le ferait. Voici la configuration du build.xml :

On pourrait ajouter le DocLinks Plugin pour Hudson afin de lier la documentation générée à chaque build.

Invoquer Phing

Pour invoquer Phing dans Hudson, on peut soit utiliser le plugin qui gère Phing soit utiliser une commande shell. Je préfère la commande shell pour pouvoir passer des paramètres à mon script.

Couverture de code

Là je vous laisse lire cet article qui explique comment obtenir des rapports de couverture de code symfony dans Hudson.

Conclusion

En plus d’automatiser un certain nombre de tâches, j’obtiens des retours sur mon projet : des retours client grâce à Mantis et des retours sur la qualité de mon travail. Aujourd’hui, des outils pour PHP sont là, il est clair que PHP s’industrialise et grâce à la qualité du framework symfony, il devient intéressant d’adopter les bonnes méthodes et d’utiliser ces outils. PHP, ce n’est plus « Un mini-chat en PHP » par le Site du Zéro.

Il n’est jamais trop tard pour commencer à bien travailler.

Related Posts

• Faut-il tester… les tests ?
• Création automatique d’un projet symfony + MySQL + Git et Apache2
• Déploiement automatisé avec Capistrano et Git pour symfony et Diem
• L’erreur « suexec policy violation » avec symfony (chez OVH…)
• Intégrer un gestionnaire de fichiers dans dmCkEditorPlugin

La réplication en place me permet de sauvegarder les données contenues de manière instantanée. Si un crash est détecté au niveau du serveur de prod, d’une part il y a fort à parier que, peu voire aucune donnée n’aura été perdue (l’application est déployée sur un serveur unique), et d’autre part, je pourrais lancer un système de secours sur le serveur « esclave« .

Voilà ce qu’il y avait à lire : http://dev.mysql.com/doc/refman/5.0/fr/replication-howto.html

Et pour résumer :

On commence par la partie Maître, c’est-à-dire le serveur de prod numéro 1. On modifie le fichier de configuration /etc/mysql/my.cnf de la manière suivante (on veillera à relancer le service mysql) :



Une fois ceci fait on crée un utilisateur « replicateur » pour le deuxième serveur (l’esclave) :

On va devoir s’assurer qu’aucune nouvelle donnée ne soit enregistrée pendant un petit laps de temps. Cette partie est critique puisque il s’agit de bloquer l’écriture sur la base que l’on souhaite répliquer.

Il nous faut deux informations que l’on retrouve avec la commande ci-après : la position et le nom du fichier binaire.

Pour finir, on fait un dump de la base (mysqldump) et on l’envoie sur le serveur esclave (scp). C’est tout pour le serveur maître, on y reviendra à la fin pour le déverrouiller en écriture.

Au niveau du second serveur, les manip’ sont semblables. On commence par modifier le fichier de conf /etc/mysql/my.cnf puis on redémarre le service mysql.

On va ensuite se servir des deux infos relevées plus haut en exécutant la commande :

Puis on démarre le process maître/esclave depuis l’esclave :

Soit ça marche, soit ça ne marche pas… Par exemple, pour 1 warning détecté, on devra reprendre les paramètres de conf dans une requête de la forme :

A partir de là, la replication est prête. Seulement il faut effectuer le rattrapage sur le serveur esclave. La réplication est démarrée mais notre deuxième serveur n’est qu’un esclave qui ne peut recréer la base et se mettre à niveau du maître. Vous comprenez ? Non, tant pis, je recommence. C’est le maître qui donne les ordres donc comme on vient de commencer notre process maître/esclave, le maître ne sait pas que la base de l’esclave est vide. Voilà pour la petite histoire et pourquoi un dump était utile. Il suffit maintenant d’insérer le dump transféré au début.

On retourne sur le serveur maître et on enlève le verrou d’écriture :

La réplication est en place. On peut tester l’ajout d’une ligne dans une table pour voir si la réplication fonctionne parfaitement. Dorénavant, tout changement de la base maître (structures, données) sera répercuté sur la base esclave.

A noter qu’un peu de sécurité ne fait pas de mal. On veillera à créer une liaison très restreinte entre les deux serveurs sur le port 3306, port par défaut de MySQL.

Related Posts

• Dédibox v3 : Nginx + PHP-FPM + Apache2 + APC + Memcached + MySQL
• Connaissiez-vous … REPLACE en SQL ?
• Optimiser son application web en jouant sur PHP, MySQL et Apache2

Voici donc le script mkSfProject :

Je lance cette commande et en moins d’une minute, j’ai accès à un projet symfony fonctionnel dans mon navigateur. Voilà

Related Posts

• L’erreur « suexec policy violation » avec symfony (chez OVH…)
• symfony rencontre Hudson, Mantis et les autres
• Déploiement automatisé avec Capistrano et Git pour symfony et Diem
• Faut-il tester… les tests ?
• Dédibox v3 : Nginx + PHP-FPM + Apache2 + APC + Memcached + MySQL

La mise en production c’est passer un projet sur le serveur du client pour le rendre accessible aux utilisateurs finaux. Facile ? Non, très souvent les architectures sont différentes et il convient d’utiliser plusieurs environnements. Pour ma part, je dispose de 3 environnements : dev (sur ma machine), test (sur serveur distant) et préprod (sur serveur distant également). Ces environnements me permettent de tester mes projets sur plusieurs OS, plusieurs types de machine et sur deux SGBDR (bases de données) : j’ai pris l’habitude d’effectuer mes tests sous SQLite, j’ai ainsi  deux sons de cloche (en plus de MySQL) me permettant de corriger des étourderies lors de la configuration de la base.

Ok, tout ce speech pourquoi ? Pour pouvoir comprendre mon intérêt à automatiser le process de mise en prod’. En effet, mes trois environnements me garantissent une certaine stabilité de mon application, je n’ai donc pas à jongler avec les serveurs de chacun de mes clients (pas toujours…). Je peux donc déployer (mettre en prod’) mon application presque les yeux fermés. Et ça, ça n’a pas de prix !

Mais je ne joue pas le lanceur de couteaux sans avoir de lames bien aiguisées. J’utilise des outils éprouvés comme Capistrano et Git.

Capistrano est l’outil par excellence pour déployer des applis Rails. Le problème c’est que je ne m’y suis pas encore mis… Mais qu’importe, il déploiera mes applications symfony et Diem. La souplesse de configuration via redéfinition des méthodes permet de déployer à peu près ce que l’on souhaite. De plus, l’interconnexion avec Git se fait sans problème.

Maintenant, courte description :

• Capistrano va cloner votre projet (Git inside) ;
• Capistrano peut compresser votre projet (tar) et l’envoyer à vos X serveurs  ;
• ou Capistrano va demander à X serveurs de récupérer la dernière version de votre projet ;
• Capistrano va lier (symboliquement) la dernière version en tant que version courante ;
• Capistrano va migrer les bases de données (la migration ici, ce n’est pas l’histoire avec les oiseaux… C’est plutôt la mise à jour structurelle de vos bases) ;
• Capistrano va déployer votre appli très rapidement sur autant de serveurs que vous le souhaiter ;
• Capistrano exécute des commandes avant ou après le déploiement, pratique pour un sf cc ;
• Enfin, Capistrano ne fait pas le café (il ne faut pas abuser quand même…)

Intéressant non ? Une fois Capistrano installé (explications ici), on va pouvoir commencer à travailler.

Ce que je fais généralement, je crée un répertoire project_name et je tape la commande :

Ceci me crée un fichier Capfile, un répertoire config/ avec un fichier deploy.rb. C’est ce dernier qui nous intéresse. Le mieux est de partir d’un fichier vide. Pour pouvoir utiliser Git, il faut écrire ceci :

J’indique le chemin de mon dépôt, ici local et la branche (par défaut master). Les paramètres :checkout et :deploy_via ainsi défini permettent de faire un clone complet du projet. Ensuite, quelques paramètres nécessaires :

Maintenant, une petite chose à savoir. Capistrano versionne les déploiements et ça, c’est bon ! Mon déploiement plante, rollback automatique vers la version précédente. Je m’aperçois que j’ai fait une grosse faute d’orthographe, je lance un rollback et l’appli passe en version précédente. Pour cela, Capistrano construit sa propre structure dans le répertoire défini par :deploy_to :

current est le lien symbolique qui pointe toujours vers la version active de l’application. Le répertoire releases/ possède X répertoires correspondant aux différents déploiements passés. Vous l’aurez compris, le lien symbolique current pointe vers l’un de ces répertoires. Le répertoire shared/ quant à lui contient des fichiers partagés par toutes les releases. Exemple : le fichier databases.yml de symfony qui définit les identifiants de connexion à la base de données ou encore le répertoire uploads/ qui contient des données utilisateurs.

On peut désormais personnaliser les actions de déploiement. Pour cela, on va redéfinir les actions de :deploy, qui contient les tâches de déploiement appelées lors de tout déploiement.

Après déploiement, on va créer fixer les droits, les répertoires de logs et de cache. Ensuite on met à jour la base de données (Doctrine migration). Pour finir on exécute une série de tâches « custom » qui permettent de supprimer les contrôleurs de développement (frontend_dev, backend_dev, …), de recréer les liens symboliques pour les fichiers partagés, de vider le cache symfony ou Diem, …

Voyons la suite de commandes pour symfony :

Et voilà la suite de commandes pour Diem :

Et voilà ! Un simple cap deploy fait tout le reste. Vous pouvez ajouter autant de serveurs que vous le souhaiter et lancer également toutes les commandes qui vous font plaisir.

Si vous avez des problèmes d’hébergement, exemple chez OVH qui ne laisse pas d’accès externe sur leurs serveurs Plan (…), vous pouvez utiliser la configuration suivante qui va archiver votre projet et l’envoyer en SFTP :

Cette configuration est largement inspirée de ces articles :

• http://refineweb.co.uk/2010/01/18/preparing-a-symfony-project-ready-for-deployment-into-production-using-capistrano/
• http://blog.servergrove.com/2010/07/12/symfony-git-capistrano-capifony/
• http://blog.codingspree.net/2008/5/12/deploying-symfony-project-with-capistrano/

Pour terminer, hier je vous parlais d’Hudson, un serveur d’intégration continue. En liant les deux, j’obtiens une automatisation complète de mon « after code« . C’est-à-dire que j’écris mon code comme un barbu (et mes tests). Lorsque j’ai bien commité et que je push mes modifs, Hudson voit ces mises à jour, il va relancer les tests. Si tout passe la build estampillée « success » va être déployée automatiquement par Capistrano.

Et moi dans l’histoire ? Je n’ai rien à faire. Au pire, je suis alerté par mail si un test ne passe pas et si la build ne peut être déployée, Capistrano fera un rollback automatiquement sur sa dernière version stable. Manquerait plus qu’une cafetière USB et une tâche Hudson pour lancer le café et là… utopie !

A noter qu’un projet nommé Capifony a vu le jour depuis quelques temps. C’est un Capistrano réécrit pour gérer nativement les projets symfony, je n’ai pas testé mais cela me semble une excellente option : http://github.com/everzet/capifony. Pour Diem, j’ai vu passé quelque chose dans le Google Groups, à suivre donc.

Vous pouvez, si vous le voulez, utiliser Murder, un projet développé par Twitter pour déployer via Bittorent leurs applications sur tous leurs serveurs. C’est pas une mauvaise idée si vous avez beaucoup de serveurs, leurs temps de déploiements sont assez phénoménales. En parlant de temps, mes temps de déploiements sont de l’ordre de 2 minutes…

C’est tout, pour le moment

Related Posts

• Intégrer un gestionnaire de fichiers dans dmCkEditorPlugin
• symfony rencontre Hudson, Mantis et les autres
• Création automatique d’un projet symfony + MySQL + Git et Apache2
• Faut-il tester… les tests ?
• L’erreur « suexec policy violation » avec symfony (chez OVH…)

Il y a un presque deux ans maintenant, j’apprenais à écrire des tests unitaires et fonctionnels en Java, à l’aide de JUnit, JMeter, et compagnie. J’ai appris à écrire des scénarios de tests avec un logiciel dont je ne me souviens plus du nom, une alternative gratuite à HP Test Director. On écrit des scénarios de tests, des gens suivent les instructions et fournissent le résultat qu’ils obtiennent. C’est bien gentil tout ça mais je n’ai pas 50 personnes sous la main pour les faire exécuter mes tests et ce n’est pas mon associé qui voudrait suivre mes procédures…

Comme mon boulot consiste à écrire uniquement des sites web, j’ai cherché un outil qui pourrait faire ce boulot à ma place. Il ne m’a pas fallu longtemps pour trouver Selenium, une suite d’outils permettant d’enregistrer un enchaînement d’actions dans le navigateur, de rejouer cet enchaînement autant qu’on le souhaite, sur plusieurs navigateurs, en parallèle (test de « scalabilité« ), …

C’est donc l’outil parfait pour gérer les scénarios fonctionnels. J’enregistre mes tests et je les rejoue. Je vérifie ainsi que mon appli réponds correctement et que je n’ai rien cassé en modifiant une partie du code. Exemple avec symfony, la mise à jour du schema.yml.

D’ailleurs avec symfony, on peut faire des tests fonctionnels et c’est une chose que je ne faisais pas. Pour être franc, je ne faisais pas trop de tests en PHP, enfin si mais pas formellement. Maintenant cette période est terminée. J’adopte une nouvelle approche, l’approche TDD que j’expliciterai plus tard.
En symfony, on peut donc faire des tests fonctionnels avec les classes sfTestFunctional et sfBrowser (qui simule un navigateur). Pourquoi utiliser Selenium alors ? Et bien parce que ces tests sont bons mais ne remplacent pas Selenium, par exemple, on ne peut pas tester les appels Ajax. Voici un aperçu d’un test fonctionnel écrit en symfony :

C’est très intuitif, les tests sont formés de « blocs » commençant par with() et terminant par end(). Il y a déjà beaucoup d’articles sur le sujet donc je ne m’y étendrait pas. Par contre petit tuyau, pour aller plus vite j’utilise le plugin swFunctionalTestGenerationPlugin qui permet de générer un « stub » de test fonctionnel symfony directement depuis les actions que l’on effectue dans la navigateur, pratique !

Il n’y a pas que les tests fonctionnels dans la vie, il y a également les tests unitaires. Comme JUnit pour Java, on a le droit à PHPUnit pour PHP mais je ne l’ai pas encore essayé. J’utilise Lime, un framework de tests embarqué dans symfony, écrit par Maître @fapbot. Au lieu des classiques assertTrue(), assertFalse(), on dispose des méthodes is(), isnt(), … Comme pour les tests fonctionnels, l’écriture de tests unitaires est très intuitive.

Grâce à ces tests unitaires, mon code est contrôlé et je n’ai plus à me soucier d’éventuels effets de bord. Je sais exactement comment se comportent mes méthodes et mes objets. Je blinde ainsi mon modèle, ce qui fait une chose de moins à me soucier. Je passe 50% de mon temps à écrire du code dans mes actions et vues, 20% de mon temps à écrire du code dans mon modèle, 20% à écrire mes tests et le reste à boire du café… Je ne me soucis pas du reste, mon environnement de test est complètement découplé de mon environnement de dev et l’environnement de prod est distant.

Sauf que… lancer les tests c’est long et j’aime pas trop attendre. Je me suis tourné vers des outils qui font le boulot à ma place. C’est ce que l’on appelle des serveurs d’intégration continue. Je regrette de ne pas avoir pu tester Sismo, le serveur d’intégration continue (CI) de Sensio Labs (vous savez, le même que plus haut, décidément !).

J’ai testé Hudson et phpUnderControl (cruiseControl). Pour ce dernier, je n’en suis pas très satisfait avec symfony et Lime. Il fonctionne bien, l’utilisation de Ant fait plaisir mais je n’ai pas pu profiter de toutes les possibilités de ce serveur. Je l’ai donc laissé tombé au profit d’Hudson. C’est un serveur plaisant, rapide à prendre en main, très lisible et parfaitement customisable avec le nombre incommensurable de plugins dont il dispose. Pour savoir comment le faire fonctionner avec symfony, on lit cet article de Nicolas Perriault. Pour ma part, je n’utilise pas SVN mais Git, il suffit d’installer le plugin qui va bien.

Voilà, sachant que mon Gmail est tout le temps ouvert et que j’ai le checker qui va bien dans Chrome, je suis alerté assez rapidement par mail si je casse tout. Encore quelque chose de moins à me soucier. C’est ce qu’on appelle, je crois, l’efficience et la productivité s’en porte beaucoup mieux.

Il me reste cependant quelque chose à éclaircir : TDD. Test Driven Development ou Développement piloté par les tests. Pour faire simple, avant de développer une fonctionnalité, je réfléchis. Oui mais je réfléchis deux fois puis trois fois même. C’est-à-dire que je cherche comment l’écrire, comment elle pourrait mal se comporter et comment la tester. Ensuite, je prends le chemin inverse. J’écris mes tests, je veille à son comportement lors de son écriture. Et voilà, ma fonctionnalité est écrite, les tests passent, je continue mon travail. Je ne passe pas 30 minutes à chercher ce qui ne va pas…

Au fait, pourquoi cet intitulé d’article ? C’est une interrogation qui vient des cours de qualité logiciel que j’ai pu avoir auparavant. J’ai toujours gardé cette phrase à l’esprit lorsqu’on me parle de tests. La question n’est pas si simple qu’elle en a l’air. Si vous avez une idée, les commentaires sont fait pour cela. Moi, je garde mon idée

En résumé, j’ai passé de bonnes vacances

Related Posts

• symfony rencontre Hudson, Mantis et les autres
• Création automatique d’un projet symfony + MySQL + Git et Apache2
• Déploiement automatisé avec Capistrano et Git pour symfony et Diem
• L’erreur « suexec policy violation » avec symfony (chez OVH…)
• Intégrer un gestionnaire de fichiers dans dmCkEditorPlugin

Cette erreur engendre une erreur 500. C’est un peu dommage… Il s’agit simplement d’un problème de droits sur les fichiers mais aussi sur les dossiers.

Les fichiers doivent posséder les droits 644 (-rw-r–r–) et les dossiers les droits 705 (drwx—r-x). Pour les fichiers, ces droits sont classiques, pour les dossiers on peut surement faire mieux mais là, ça marche, c’est testé. Pour faire ça vite :

Ensuite, on passe un coup de project:permissions et le tour est joué. On notera que la seule commande :

ne suffit pas à résoudre les problèmes de droits.

On fixera les droits du .htaccess à 604. Voilà

Related Posts

• Création automatique d’un projet symfony + MySQL + Git et Apache2
• symfony rencontre Hudson, Mantis et les autres
• Déploiement automatisé avec Capistrano et Git pour symfony et Diem
• Faut-il tester… les tests ?
• Dédibox v3 : Nginx + PHP-FPM + Apache2 + APC + Memcached + MySQL

J’ai récemment pris une Dédibox v3 et pour le moment j’en suis très satisfait. On m’a pas mal sollicité ces derniers temps pour que j’explique comment j’ai configuré ce serveur ainsi que les services que j’ai pu mettre en place. C’est l’objet de cet article.

Premièrement, j’utilise Debian depuis toujours et c’est logiquement ce qui tourne sur la Dédibox (en version 64 bits).

Le serveur HTTP frontal n’est pas Apache2 mais Nginx (wiki) que j’ai appréhendé seulement depuis l’obtention de ce serveur. Et je dois avouer que j’en suis très satisfait, terriblement surpris d’ailleurs. Apache2 est bien en place mais sert de proxy à Nginx.

Nginx est couplé à php-fpm. La paire formée est excellente et permet l’utilisation de Memcached ou APC sans soucis. Notons que l’excellent repository Dotdeb fournit un package .deb de php-fpm. Ce repository est certainement un must-have puisque Debian n’est pas forcément très en avance sur les versions de PHP. Pour ma part, j’ai installé, via ce repository, PHP 5.3.2 ainsi que la dernière version d’APC (3.1.2 via pecl). Comme je l’ai dit plus haut j’ai installé Memcached avec l’extension PHP qui va bien. Passons à la configuration.

Nginx

Le paramètre worker_processes dépend de votre processeur (multi-coeurs ou non). Dans le cas d’une Dédibox, on ne dispose que d’un processeur mono-coeur donc on fixe ce paramètre à 1. Ensuite j’active la compression gzip, ce qui permettra de gagner un peu en performances (moins de données à envoyer d’un coup = plus de données envoyées en même temps).

Nginx va servir tous les fichiers statiques, les « assets » mais également les pages en cache. Il s’interface très bien avec Memcached. Il est aussi capable de servir n’importe quel fichier sur disque.

Voici les deux autres fichiers de configuration de Nginx : proxy.conf pour configurer Apache2 en proxy et fastcgi_params pour php-fpm.

Pour utiliser Apache2 en proxy ou php-fpm, il suffit d’insérer quelques lignes dans vos configurations de vhosts. C’est suffisamment détaillé ailleurs, je n’y reviendrai donc pas.

APC

Voilà ma configuration APC, fonctionne bien pour Symfony. Pour certaines applis dont le code laisse à désirer, je suggère de passer le paramètre include_once_override à 0. Cette config provient en grande partie de chez Romain Cambien.

PHP

La configuration de PHP est celle par défaut aux best practices près (short_tags off, magic quote gpc off, …). J’ai surtout calqué sur les « requirements » de Diem. A noter que l’on gère 3 fichiers php.ini : pour Apache2, pour php-fpm et pour cli.

Memcached

Aucun besoin de modifier la configuration par défaut. Par contre, on peut modifier la taille (64Mo par défaut) si besoin.

Apache2

Pour utiliser Apache2 en proxy, on doit nécessairement lui attribuer un port différent du port par défaut (80). Pour cela, on modifie le fichier /etc/apache2/ports.conf :

J’ai choisi le prefork MPM d’Apache2, la directive KeepAlive est désactivé car Apache2 ne sert que du PHP. Après quelques tests, voici la configuration retenue :

MySQL

En SGBD, j’ai installé MySQL et PostgreSQL qui ne sert pas pour le moment. La configuration MySQL est d’origine à l’exception d’un Ramdisk pour le répertoire temporaire. L’explication pour la création d’un Ramdisk est expliqué ici : http://www.willdurand.fr/optimiser-son-application-web-en-jouant-sur-php-mysql-et-apache2/. MySQL est également protégé par une couche Memcached, ce qui permet de faire tenir une charge correcte sans envoyer MySQL dans les choux.

Postfix

Configuré en « Site Internet », rien n’a été touché et les mails transitent bien. Je n’ai pas besoin de faire de gestion de mail autre.

Getmail

Dernière petite chose qui n’avait pas été relevé dans l’article précédent : http://www.willdurand.fr/sauvegarde-incrementale-avec-rsync-fichiers-et-base-de-donnees-mysql/, la sauvegarde de mes emails. Tout est dit ici. J’envoie toutes mes sauvegardes sur un autre serveur privé et inaccessible excepté le temps du transfert.

Voilà.

Related Posts

• Optimiser son application web en jouant sur PHP, MySQL et Apache2
• Réplication MySQL maître-esclave
• Création automatique d’un projet symfony + MySQL + Git et Apache2
• L’erreur « suexec policy violation » avec symfony (chez OVH…)
• Sauvegarde incrémentale avec rsync : fichiers et base de données MySQL

• http://www.ruas-blog.com/index.php/2006/03/06/33-script-de-sauvegarde-des-bases-mysql (pour backuper MySQL)
• http://www.casafire.com/fr/content/sauvegarde-incrémentale-de-fichiers-avec-rsync-et-ssh (pour backuper les fichiers)
• http://blog.mazenod.fr/2007/10/sauvegarde-cryptee-de-serveur-a-serveur/ (pour me rappeler les commandes d’usage)

Sauvegarde des bases MySQL

Je sauvegarde toutes les bases de données sur une durée d’une semaine. Voici le script, il est possible de le coupler à un envoi de la sauvegarde via FTP. Je conserve ainsi toutes mes sauvegardes sur un serveur distant et complètement déconnecté de ce dont je vais vous parler ensuite.

Sauvegarde incrémentale des fichiers avec rsync

Je sauvegarde mes fichiers à la semaine de la façon suivante :

• sauvegarde dans un répertoire nommé : <Année>-<Numéro de semaine>
• dans ce répertoire j’ai un dossier main qui contient l’intégralité des fichiers. Cette sauvegarde est faite le lundi.
• j’ai 6 répertoires nommés : <jour>_<date au format jj-mm-aaaa> contenant les sauvegardes incrémentales de la semaine.

J’ai modifié le script pour ajouter une conservation des sauvegardes de 4 semaines.

Je sauvegarde ces fichiers :

Et j’exclue ceux-là :

Automatisation

J’ai rajouté dans mon crontab, deux lignes pour lancer les sauvegardes différées de 2h :

Related Posts

• Dédibox v3 : Nginx + PHP-FPM + Apache2 + APC + Memcached + MySQL
• Gravatar : De beaux avatars dans les commentaires
• API Google Analytics – Une classe PHP5 et des résultats d’intégration
• API Google Analytics Round 2 – Graphiques et statistiques par page
• API Google Analytics, découverte par l’exemple

je laisse ici une petite astuce pour intégrer KFM (http://kfm.verens.com/), un excellent gestionnaire de fichiers en AJAX, au plugin Diem nommé dmCkEditorPlugin. Ce plugin offre un nouveau widget contenant, comme son nom l’indique, l’éditeur WYSIWYG CkEditor.

Pour installer KFM, on télécharge la dernière version que l’on place dans dmCkEditorPlugin/js/kfm.

Ensuite on ouvre dmCkEditorPlugin/config/dm/config.yml et on ajoute cette ligne :

KFM utilise une base de données, il faut donc la configurer. Le choix que j’ai fait est de parser le fichier databases.yml afin de récupérer les paramètres de connexion directement. Il faut donc modifier le fichier de configuration de KFM (dmCkEditorPlugin/js/kfm/configuration.php). J’ai placé ce code tout en haut en remplaçant les variables en rapport avec la base de données :

C’est une manière simple et efficace d’intégrer ce gestionnaire de fichiers. Ce n’est pas parfait mais fonctionnel

Related Posts

• Déploiement automatisé avec Capistrano et Git pour symfony et Diem
• symfony rencontre Hudson, Mantis et les autres
• Création automatique d’un projet symfony + MySQL + Git et Apache2
• Faut-il tester… les tests ?
• L’erreur « suexec policy violation » avec symfony (chez OVH…)

Non, vous ne vous êtes pas trompés. J’ai effectivement changé de moteur de blog, passant de mon propre moteur (wMVC) à WordPress.

Pourquoi ?

Ceux qui me connaissent savent ce que je pense de WordPress (via mister @palleas) mais j’ai franchi le pas pour ce blog personnel. Pourquoi donc ? Pour des raisons pratiques uniquement. Le nombre de plugins, le nombre de fonctionnalités, … en fait un bon produit pour faire un blog « Ikéa », je décompresse, je configure, ça marche, point.

J’ai donc repris l’ensemble des fonctionnalités de mon ancien blog (toutes écrites par mes soins), j’ai importé les articles et j’en ai profité pour changer de thème. Fini le paysage campagnard, je passe sur un thème plus « clean », plus sobre et qui privilégie le contenu au reste.

Autre raison ?

En fait, oui. Ce n’était pas nécessaire pour moi mais j’ai fait cette manip’ pour une autre raison. J’ai récemment pris une Dédibox v3, ce blog tourne dessus entre autres.

Le serveur web est Nginx (« engine X »), j’y reviendrai dans de prochains articles. J’ai voulu tester les performances de cette Dédibox et avec un WordPress + Nginx + APC bien configuré, j’ai été bluffé. Voilà le résultat, ce blog passe en prod

Et sinon ?

Fin d’année, je change de statut juridique avec un associé et des financiers : Bazinga, l’agence web de développement web (Symfony, Diem) et mobile (iPhone, Android) va naître. (Enfin !). J’y reviendrai également dans un prochain article.

J’ai pas mal d’articles en préparation depuis un petit moment sur du Git, Capistrano, Symfony, Diem, Nginx, et autres. J’espère pouvoir les écrire au plus vite.

N’hésitez pas à me donner vos avis, impressions, … sur ces changements

Related Posts

• No Related Posts