Retour sur la 8ème édition de Drupagora : Drupal au cœur du SI
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 côté front avec des frameworks tels que React ou Angular. Plusieurs retours d'expériences sur des migrations Drupal 8 et architectures découplées ont été partagés et sans oublier la talk très intéressant sur la sécurité.
Cette année, Drupagora a réuni plus de 350 professionnels pour partager leurs retours d'expérience sur des projets Drupal. Cette journée s'est déroulée le 14 juin 2018 à l'université Pierre-et-Marie-Curie à Paris. Le focus cette année s’est porté sur les architectures découplées (headless) et les usines à site. C’est Cyril Pierre de Geyer (directeur des executive MBA du groupe Ionis) qui a fait l’ouverture avec une keynote sur l’événement et le programme de la journée.
Drupal 8, architecture microservice & headless dans la vraie vie
Un des sujets majeurs de la Drupagora de cette année était le positionnement de Drupal 8 dans les architectures découplées. Ainsi, 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 exemple) et Drupal 8 pour servir du contenu via une API.
La digitalisation des entreprises a des impacts forts sur leur système d'information. Celle-ci qui était 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 plus importante à des sites transactionnels de grande envergure. 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.
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 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ées 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. En témoignage d’un projet concret réalisé avec beaucoup de réussite, on nous a présenté un retour d'expérience sur un projet de haute joaillerie utilisant plus de 20 services externes avec un seul front et GraphQL voyageurs pour servir les contenus Drupal.
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 précisément dans ce contexte que Frédéric Marand (spécialiste dans la sécurité et les hautes performances Drupal) a partagé les bonnes pratiques et les réflexes à suivre si notre site a été piraté. Il a également présenté les précautions à prendre afin d’éviter quelques pièges tels que l’archivage d’un malware dans les backup systems ou encore comment ne pas se précipiter à restaurer et reprendre une version antérieure nous laissant exposés et vulnérables à 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é d’OWASP 10 permettront également d’éviter un certain nombre d’attaques. Parmi les classiques à éviter :
- Des permissions trop étendues au niveau du code source,
- Une faille de parcours de système de fichiers,
- Une exécution distante de code téléchargé sur le projet,
- Se baser sur .htaccess pour les règles de lecture de dossier (aucun impact sur Nginx par exemple),
- Eviter au maximum de stocker du code PHP dans la base de données.
Pour finir, quelques outils tels que Hacked! ou MD5 Check permettent la signature et la comparaison du code source. Nous avons particulièrement été séduits par ce talk très riche en informations qui nous a apporté de nombreux conseils pratiques et fait découvrir des outils intéressants.
Drupal, multisite et usine à sites
Le retour d'expérience d'Alterway concernant les usines à site a retenu toute 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és sur ces problématiques.
- 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 à sites 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 chacune à un besoin que sont :
- Le multi-install,
- Le multi-espace,
- Le multi-domaine.
Une usine à sites de type multi-install offrira à chaque site sa propre base de données, ce qui permet de rendre les sites indépendants les uns des autres en ce qui concerne la contribution. Le multi-domaine consiste à 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. 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. 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. Bien que nous connaissions déjà ces approches, cette présentation nous a permis de mieux expliquer et anticiper les besoins pour la réalisation d'usines à sites.
Conclusion
Les participants des conférences Drupagora cette année ont mis l’accent sur la place qu'occupe Drupal dans une architecture multiservices et la complémentarité entre Drupal comme framework back et côté front avec des frameworks tels que React ou Angular. Plusieurs retours d'expériences sur des migrations Drupal 8 et architectures découplées ont été partagés et sans oublier la talk très pregnant 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 de grands projets ayant de multiples services externes sans pour autant rentrer en détail sur l’implémentation technique (le seul bémol de cette Drupagora). Tout ceci va nous servir au quotidien dans les projets que nous menons chez nos clients, nous avons donc hâte d'assister à la prochaine édition !