Un bundle de mise en maintenance pour vos sites avec Symfony2

Présentation

Voici le LexikMaintenanceBundle qui a pour but d’activer et désactiver la mise en maintenance de votre site. Quand un site à besoin pour X raisons d’être mis en maintenance, par exemple lors d’une mise à jour, vous allez pouvoir faire apparaître une page d’erreur où seront redirigés les visiteurs avec la possibilité d’en autoriser certains.

Pourquoi utiliser un bundle pour gérer la maintenance ?

Il existe de nombreuses manières de mettre un site Internet en maintenance, comme par exemple en éditant le .htaccess ou le virtual host. Symfony 1 proposait une mise en maintenance en ligne de commande et cette fonctionnalité n’a pas été reprise dans sa version 2, l’idée de ce bundle est de proposer une fonctionnalité similaire tout en laissant plus de souplesse, via l’utilisation de drivers et d’un service.

Nous avons choisi de créer ce bundle car nous voulions laisser aux utilisateurs plusieurs alternatives de mise en maintenance, ainsi que son activation depuis la console ou depuis le backend par exemple.

Fonctionnement

Un listener

Le bundle utilise un listener qui écoute l’événement onKernelRequest avec une priorité evelée pour être ainsi le premier à être appelé. Le listener va tout d’abord vérifier s’il y a des adresses IP autorisées à consulter le site en maintenance. Si oui, l’utilisateur peut continuer. Dans le cas contraire on va demander au driver utilisé dans la configuration de vérifier si la maintenance a été activé et de décider si on lève une exception qui retournera un status 503. Sinon on laisse passer l’utilisateur.

Des drivers

Un driver est une méthode choisie pour activer/désactiver la maintenance. Le bundle propose trois drivers différents.

• Le premier est le FileDriver dont l’utilisation consiste à créer un fichier quelque part et à vérifier si celui-ci existe.
• Le second est le MemCacheDriver qui utilise MemCache et qui va regarder si une donnée a été stockée dans le serveur de cache.
• Le troisième est le DatabaseDriver qui va créer une table dans une base de données et vérifier les informations présentes à l’intérieur.

Il y a d’autres implémentation de drivers possibles, libre à chacun de créer le sien.

Options

TTL

Chaque driver a la possibilité d’avoir un temps limite pour la durée de la maintenance -par défaut il n’y en a pas-. Cette option est le ttl -time to life- qui peut être modifié soit dans votre configuration soit dynamiquement via la console par exemple. (A l’exception du FileDriver).

IP autorisées

Vous avez la possibilité, comme écrit plus haut, d’ajouter dans un tableau des adresses IP qui seront autorisées à consulter le site.

Installation et configuration

L’installation se fait comme pour tous les autres bundle Symfony2 à l’aide des fichiers deps et deps.lock.

Fichier deps:

Enregistrer le namespace:

Activer le bundle:

Pour la configuration, les options de bases requises sont la classe du driver et les options qui iront avec.

Remarques pour la configuration:

• Pour utiliser la connexion Doctrine, vous n’êtes pas obligé de passer des options, vous pouvez écrire simplement le nom de la classe du driver.
• Pour utiliser une table existante sur une autre base de données (option dsn), vous devez avoir un champ ttl dans votre table.
• Pour le FileDriver, vous ne pouvez pas changer la durée en mode console, seulement pour DatabaseDriver et MemCacheDriver

Utilisation

Ce service met à disposition les méthodes `lock()` et `unlock()` permettant d’activer et désactiver le mode maintenance de votre site. L’intérêt majeur de ce service est qu’il vous permet de l’utiliser dans le contexte de votre choix, libre à vous d’implémenter une interface de backend permettant d’activer la maintenance. LexikMaintenanceBundle propose en standard les commandes console suivantes:

lexik:maintenance:lock qui aura pour effet d’appeler la méthode lock().

lexik:maintenance:unlock aura l’effet inverse.

Pour la vue

Element important de la maintenance, une page d’erreur à afficher. Lorsque le listener lève une exception avec le status 503, Symfony2 va afficher par défaut la vue error.html.twig située dans le bundle TwigBundle. Vous pouvez alors définir une vue appelée error503.html.twig dans app/Resources/TwigBundle/views/Exception/ qui sera appelée à la place.

Astuce: Cela fonctionne aussi pour les erreurs 404, 403 etc…

Information: Nous ne proposons pas de vue par défaut, c’est à vous d’en créer une.

Pour plus le reste, voici le lien vers les sources Github.