Nous avons assisté à la 8ème édition Drupagora 2018 cette année qui a réuni plus de 350 professionnels réunis pour partager leurs retours d'expérience sur des projets Drupal. Le focus cette année est porté sur les architectures découplées (headless) et les usines à site.

C’est Cyril Pierre de Geyer qui a fait l’ouverture avec une keynote sur l’événement et le programme de la journée.

1 Drupal 8, architecture microservice & headless dans la vraie vie

Maxime Topolov co-fondateur d’Adyax nous a présenté quelques exemples d’architectures découplées (DRUPAL, VUE, REACT, ANGULAR) en mettant l’accent sur les avantages respectifs de chacune des solutions.

L'idée de ce type d'architecture est d'avoir un front unifié (VUE, REACT ou ANGULAR) découplé avec un serveur node et une Api management (apigee par exempe) et Drupal 8 pour servir du contenu via une API.

Un retour d'expérience sur un projet de haute joaillerie utilisant +20 services externes avec un seul front et GraphQL voyageurs pour servir les contenues Drupal témoigne d’un projet concret réalisé avec beaucoup de réussite.

Drupal et architecture découplée

Un des sujets majeurs de la Drupagora de cette année était le positionnement de Drupal 8 dans les architectures découplées.

La digitalisation des entreprises a des impacts forts sur leur système d'information. Celle-ci encore réservée il y a quelques années au B2C touche aujourd'hui de plus en plus le B2B.

Si les sites institutionnels ont occupé une part prépondérante des sites internet au début des années 2000, les entreprises accordent aujourd'hui une place de plus en plus importante à de gros sites transactionnels : l'objectif est de fournir à l'utilisateur une expérience unifiée. C'est le cas des sites client sur lesquels l'utilisateur peut se connecter et gérer l'ensemble de ses services. Sqli intervient, en ce sens, par exemple, chez Generali qui les a sollicité pour refondre leur espace client.

Comment s'intègre Drupal 8 dans ce type d'architecture ?

Dans les architectures monolithiques, au sein d'un SI, Drupal accomplit un rôle qui dépasse sa fonction première de CMS qui est de servir du contenu : il expose et consomme des services "métier". Ces services "métier" sont le cœur du fonctionnement d'une API : ils définissent les règles métier d'une entreprise et doivent être dévolus aux backends des SI.

Dans le cheminement vers une architecture plus moderne, la cible est le découplage complet des applications : Drupal doit servir du contenu et permettre à des contributeurs de le saisir, les backends doivent gérer le métier et ne pas être exposés sur internet (ils sont cloisonnés dans le SI pour des raisons de sécurité), un middle ou une gateway (par exemple Apigee) doit exposer les services du backend. L'affichage du site est réservé à au front pour des raisons d'optimisation de l'expérience utilisateur.

Afin d'exposer ses contenus Drupal 8 propose nativement une API REST. D'autres modules contributeurs comme JSON Api (https://www.drupal.org/docs/8/modules/json-api) ont enrichi les fonctionnalités REST de Drupal et répondent aux JSON API Specifications. L'idée est donc que Drupal expose à tous les fronts le demandant, ses contenus contribués, via son API REST.

Côté front, les applications qui vont consommer l'API REST de Drupal seront développés en ANGULAR, REACT ou VUE.JS

Ce découplage des objets métier (contribution, backend, front) s'accompagne fatalement d'un découplage des tâches de développement. Les équipes doivent s'organiser en feature team : c'est la fonctionnalité qui va créer et organiser l'équipe de développement. Cela va donc nécessiter la mise en place d'une nouvelle organisation qui ne pourra prendre sa vitesse de croisière qu'après un certain temps d'apprentissage.

2 Mon site est hacké ! Que faire ?

Un soin particulier en matière de sécurité doit être apporté lors de la création d'un projet, c’est ce contexte que Frédéric Marand spécialiste dans la sécurité et les hautes performances Drupal nous a partagé les bonnes pratiques et les réflexes à suivre si notre site a été piraté et les précautions à prendre afin d’éviter quelques pièges tel que l’archivage d’un Malware dans les backup system ou encore se précipiter à restaurer et reprendre une version antérieure ce qui nous laisse exposé et vulnérable à la même pénétration. Ce qui est conseillé dans le cas d’une attaque est de préserver autant que possible la “scène du crime” en prenant des clichés de tout ce qu’on observe avec les étapes détaillées et les découvertes horodatées.

Le respect des recommandations et les règles de sécurités d’OWASP 10 permetra également d’éviter un certain nombre d’attaques.

Parmi les classiques à éviter :

• Permissions trop étendues au niveau du code source
• Une faille de parcours de système de fichiers 
• Exécution distante de code téléchargé sur le projet
• Se baser sur .htacess pour les règles de lecture de dossier (aucun impact sur Nginx par exemple)
• Eviter au maximum le module PHP ayant du code dans la base de données

Pour finir quelques outils tel que Hacked limitations qui permet la signature et la comparaison du code source (md5check sur D7).

Nous avons trouvé ce talk très riche en information, conseil pratique et outils intéressants.

3 Drupal, multisite et usine à site

Le retour d'expérience d'Alterway concernant les usines à sites a particulièrement retenu notre attention car nous sommes très souvent engagés dans ce type de projet chez SQLI. Pour juste parler de Drupal 8, trois de nos clients nous ont sollicité sur ces problématiques.

Pour ceux qui ne connaissent pas cette architecture, réaliser une usine à sites consiste à développer une application unique pouvant être réutilisée pour le déploiement de plusieurs sites différents. Pour donner un exemple, nous pouvons imaginer une entreprise désirant créer un site pour chaque pays dans lequel elle est implantée, ayant chacun ses contenus spécifiques mais s'appuyant sur la même base fonctionnelle.

Réaliser une usine à sites peut s'avérer fastidieux. De plus, les choix d'implémentation effectués dès le début du projet auront une incidence sur l'adéquation du produit aux besoins du client. Il est ainsi nécessaire de se poser les questions suivantes avant de démarrer un tel projet :

• Quel sont les éléments communs et les spécificités de chaque site ?
• Comment va-t-on pouvoir livrer les mises à jour une fois l'usine à site déployée ?
• Doit-on mutualiser les contenus à travers l'usine à sites ?

En effet, les usines à sites sont réparties en 3 grandes familles répondant chacun à un besoin que sont le multi-install, le multi-espace et le multi-domaine.

Une usine à sites de type multi-install offrira à chaque site sa propre base de données. Cela permet de rendre les sites indépendants les uns des autres en ce qui concerne la contribution. Le multi-domaine, consiste quant lui à garder les mêmes contenus et les mêmes utilisateurs sur toutes les plateformes tout en permettant de les compartimenter, il n'y a donc qu'une seule base de données. Le sous-domaine (www.sitea.com, www.siteb.com) permet ensuite de contextualiser l'affichage du site.

Enfin, le multi-espace est basé sur le même principe que le multi-domaine à la différence que l'affichage du site est contextualisé à la typologie de l'utilisateur connecté. De cette façon, un espace client pourra changer selon le site auquel est associé l'utilisateur.

Ainsi, un multi-install est recommandé dans le cas où chaque site peut "vivre" de façon indépendante. Le multi-espace ou le multi-domaine sont quant à eux utilisés pour permettre une mutualisation des contenus.

Parmi les solutions présentées et au regard de nos retours d'expérience, nous proposons surtout des solutions basées sur du multi-domaine car celles-ci se rapprochent le plus souvent des besoins du client en termes de maintenance applicative et d'expérience utilisateur en ce qui concerne les aspects liés au webmastering. Nous préférons néanmoins développer notre propre solution car le module domain access qui nous a été présenté à la conférence se révèle assez complexe d'utilisation et implique une segmentation sur de trop nombreux aspects et risque donc de perdre le client.

En conclusion et bien que nous connaissions déjà ces approches, cette présentation nous a permis de mieux expliquer et anticiper les besoins en vue de la réalisation d'usines à sites.

Conclusion

Les participants aux conférences Drupagora cette année ont mis l’accent sur la place qu'occupe Drupal dans une architecture multiservice et la complémentarité entre Drupal comme Framework back et javascript côté front avec des Framework tel que React et Angular, plusieurs retours d'expérience sur des migrations Drupal 8 et architectures découplées ont été partagé et sans oublier la talk très intéressant sur la sécurité.

Notre participation à cet événement francophone qui a réuni des profils ciblés nous a permis d’avoir des retours d’expérience sur des projets concrets sur les architectures découplées et l’intérêt de leurs mises en place sur des grand projets ayant de multiples services externes sans pour autant rentrer en détail sur l’implémentation technique le point à reprocher à cette édition.

Franck Girodon, William Nomichith et Samir Djili - SQLi