Drupal Worst Current Practice

1/66 • Drupal : worst current practice • © OSInet
Drupal : Best Worst current practice Par Frédéric G. Marand

Drupagora Paris le 14 novembre 2014

DRUPAGEDDON

CAS D'ÉCOLE : DRUPAGEDDON LES DONNÉES https://www.drupal.org/SA-CORE-2014-005 https://www.drupal.org/PSA-2014-003 EN PRODUCTION : un site qui ne suit pas les bonnes pratiques a des difficultés à appliquer la MàJ rapidement • Combien de minutes avant de déployer sur votre site ? • Pourquoi si longtemps ? • Comment améliorer ? • Comment gérer les suites ? Introduction

OSInet, UN REGARD SPÉCIFIQUE DANS L’ÉCOSYSTÈME DRUPAL

CONTRIBUTEURS AUX PROJETS LIBRES OSInet • Contributeurs Drupal depuis 2005 • 100 % de l’effectif est contributeur Drupal core 8 • Autres contributions depuis 94 : Apache, Beego, Doctrine ODM, FirebirdSQL, MongoDB, Monolog, Samba, Silex… Frédéric G. Marand • (Co-)auteur et (co-)correcteur de plusieurs Security Advisories Drupal • Mainteneur Drupal 7 core XML- RPC • Mainteneur des contribs (References…) http://www.osinet.fr http://bit.ly/drupalosinet @OSInet http://drupal/u/fgm Introduction

ACTIVITÉ AUDIT CONSEIL ARCHITECTURE LEAD DÉV Introduction

L’AUDIT TECHNIQUE DRUPAL Problèmes récurrents motivant les audits : • Délais • Performance • Sécurité (réponse aux pénétrations) Les principales erreurs se répètent par ignorance : évitez-les Introduction

Quand les erreurs sont-elles constatées ? • Durant l’acquisition • Durant la réalisation • Durant le fonctionnement • Lors des visites anonymes • Lors de l'utilisation en connecté • Lors des opérations d'exploitation Introduction

Quelles sont les erreurs les plus fréquentes ? • Délais (coûts) excessifs de réalisation • Régressions durant le développement de code • Coûts excessifs en infrastructure • Failles XSS et autres • Performance front insuffisante • Performance back insuffisante Introduction

Qui est source d’erreurs ? • L’agence réalisatrice : mauvaises techniques de réalisation • Le studio graphique : maquettes ignorant les spécificités de build Drupal • L’hébergeur : ignorance des contraintes spécifiques de Drupal • La communauté Drupal et Open Source en général : peu de modules / thèmes (aucun ?) ont le même niveau d’exigence qualité que Drupal core • Le donneur d’ordres : analyse insuffisante des besoins, exigences inappropriées Introduction

BUY

Propriété intellectuelle Bloquer sur cession de propriété vs concession de licence • Définition du besoin • Certification de conformité (compliance) Ignorer l’impact de la viralité de la GPL sur les projets Drupal • Code source PHP, JS • Assets graphiques • Contenus • Look-and-feel PS I am not a lawyer. Achat

Le cas des appels d’offres publics Achat • Difficulté à déclarer un marché infructueux même quand il devrait l’être • Ne pas être à jour sur le CCAG-PI / CCAG-TIC et les circulaires associées • Définition de l’objet du marché : site vs logiciel • Procédures de recette : spécification vs agilité

Choix des prestataires : principaux problèmes Agences de communication traditionnelles ➔ Pas assez techniques pour les projets importants SSII (ESN) / SSLL (ENL) traditionnelles ➔ Pas assez créatives pour les projets importants Spécialistes AMOA ➔ Retour sur coût difficile à évaluer avant un premier échec Drupalshops ➔ Pas assez disponibles, problèmes d’agrément dans les grands comptes, pas assez de connaissances autres Achat

BUILD

Maîtrise d'ouvrage

Ne pas savoir choisir sa version core : 6, 7, 8 et son type de développement — Ces temps-ci… • Projets courts, à courte durée de vie (événementiel, one-off) : 7, build basique • Projets plus longs, livrés début 2015, destinés à une refonte assez rapide : 7, build best practice (cf session Best Practice) • Projets plus longs, livrés mi-2015, destinés à un cycle de vie plus long : 8, build best practice • Évoluer les sites bloqués en 6 en mode découplé/composant. • Ne plus lancer de nouveaux projets en 6 Build

Ne pas savoir définir ses choix en matière de versions contrib « STABLE ONLY » : de plus en plus, dans les projets Drupal, « stable » est synonyme d'« obsolescent » ⇒ coûts de maintenance adaptative « ANYTHING GOES » : risque que les constructeurs utilisent des modules expérimentaux, sans cycle de mise à jour disponible, voire non maintenus ⇒ coûts de maintenances corrective et adaptative Build

Et plus... • Ne pas réceptionner au fil de l’eau — pendant les itérations — pour intercepter rapidement les divergences (héritage du cycle en V) • Lors des réceptions d’itération, ne pas vérifier l’état de propreté du site (installation from scratch possible, absence de doublons fonctionnels, de traces de composants abandonnés...) Build

Processus de développement

Ne pas utiliser de gestionnaire de versions ...DU TOUT (dernier en date observé : ce mois-ci !) ...EFFICACEMENT : • code commenté en production au lieu d’être dans une révision • commentaires de commit inutilisables • commits trop espacés • pas de process de branching réfléchi (eg: git flow, github flow…) Build

Créer un site par accumulation de modules contrib à portée limitée • Souci additionnel de qualité, fragilité, maintenance et MàJ • Sauf dans le cas de couverture à 100 % de la fonctionnalité, l’adaptation est à long terme plus coûteuse qu’un spécifique Build

Créer un site par accumulation de changements, sans mécanisme de déploiement • Génération des fichiers • Drush Makefile / Composer : – Avantages: dépôt léger, MàJ permanente – Inconvénients : dépendance sur la disponibilité du réseau, non-compliance, MàJ permanente = risque de casse • Vendoring : – Avantages : disponibilité, rapidité, compliance – Inconvénients : défaut de MàJ automatique, dépôt lourd • Profil(s) d’installation Drupal • Chargement des données par migration (Migrate API) Build

Hacker core/contrib Build • Rarement nécessaire : le plus souvent, c’est un manque de connaissances • Si nécessaire, committer les patches de façon reproductible (ex : drush makefile, répertoire patches …)

Développer en PHP brut, sans passer par les API Drupal Exemples typiques, souvent sources de problèmes de sécurité : • API de bases de données natives au lieu de DB API/Schema API (injection SQL) • Accès aux superglobals, notamment $_GET (XSS) • Stockage de données privées dans $_COOKIE au lieu de $_SESSION (mascarade) • Actions de modification sur GET sans jeton ou formulaire non protégé (CSRF) Build

Développer sans visibilité des erreurs au niveau maximal (error_reporting = -1) Build • Les notices et warnings s’accumulent durant le développement • En fin de projet, on constate des masses d’insertions dans dblog (2014 : 1500 insertions watchdog/seconde sur un site) et plus le temps de corriger donc on le désactive • Du coup, plus de suivi des vraies alertes

Tests de recette et montée en charge Ne pas faire de TMC : tout va bien sur les postes de développement / recette Tester sur un environnement non iso- prod Tester depuis un poste local, notamment le serveur front Tester uniquement en anonyme Build

Négliger la prise en compte des pratiques permettant l’internationalisation • Formats en dur (dates, nombres, monnaies) au lieu des API Drupal • Assemblage de chaînes traduites : exemple t($a) . t($b) • Chaînes de texte non traduites dans les templates et modules Build

OWN

Hébergement

Confondre hébergement et infogérance Un site de production a besoin d’un infogérant (services système) et non simplement d’un hébergeur (location de matériel et infrastructure pour le ranger) • Backups • Configuration, MàJ et monitoring du serveur Web et ses modules, PHP et ses extensions, bases de données, serveurs de cache, serveur de file d’attentes, etc Own

Déployer sans cache d’opcodes ou sans monitoring • PHP 5.3 ou 5.4 : APC, PHP 5.5 : Opcache • Monitoring : apc.php, ocp, opcache- status, opcache- gui… Own

Déployer un Memcached sans comprendre sa configuration • settings.php : clusters, bins, préfixe... • extension, persistence, stratégie de hashing, ucp/tcp, text/binaire… • slab size • Monitoring: phpmemcacheadmin, memcache.php… • Un memcached mal réglé peut être beaucoup plus lent qu’un cache en base de données • Typique : • entrées > 1 Mo et slab size par défaut • multisites sans préfixe, • bins saturés, • mélange chaud/froid, gaspillage d’allocation • Documenté à partir de Drupal 7.33 Own

Déployer sur un système de fichiers inapproprié • Écritures synchrones : NFS système sans accélérateur • lstat() lents provoqués pour include_once -> tune realpath cache Own

Maintenance applicative : corrective et adaptative

Own Ne pas appliquer les MàJ de sécurité dans les délais Pourquoi ne pas les appliquer ? • Rigidités entre mainteneur et infogérant (procédures de déploiement) • Absence de réactivité du mainteneur • Difficultés de MàJ : typiquement conséquence des hacks core/contrib

Own

Travailler sans logger CAUSES TYPIQUES : • Désactivation de dblog faute d’avoir codé à error_reporting élevé, pour faire face aux masses de notices • Absence d’utilisation de syslog ou d’un mécanisme plus tolérant comme mongodb_watchdog Own

FRONT : PERFORMANCE

Gestion de cache

Cache de pages interne • Cache interne désactivé (cache enabled : décoché) • Expiration trop courte : limitation à la scalabilité interne (liée à l’infra propre) et non externe (web scale) Front

Pages non cachables • Écriture dans $_SESSION ou $_COOKIE pour les anonymes • démarrage de session qui marque la page non cachable • génération complète au hit suivant • grosse limite de scalabilité ramenant les anonymes à peu près au niveau des connectés • Utilisation de Varnish et/ou d’un CDN ou autre reverse proxy, mais émission par le code d’en- têtes de non-cachabilité • suppression de la scalabilité externe • inutilité complète de ces outils Front

Désaccord sur la durée du cache • Technique → long éditorial → court • En l’absence d’une stratégie claire, forte probabilité d’une absence de prise en charge technique valide Front

Agrégation des assets • Désactivée pour le CSS et/ou le JS • généralement, ce n’est pas un oubli, mais le prestataire indique que le site ne fonctionne pas avec : c’est le signe d’une erreur de réalisation, le plus souvent pour le code JS • Simple : il y a des mécanismes d’agrégation avancée plus efficaces, comme le module advagg, notamment si on utilise un CDN avec le module CDN Front

Domain sharding Front • ABSENCE : • Les cookies sont émis par les clients sur les requêtes d’asset • Avec Varnish ou un autre reverse proxy : nécessite un VCL spécifique pour permettre de les ignorer et servir quand même de cache • EXCÈS : multiplication des requêtes DNS pour les clients

Et tous les problèmes du back office pour les pages non cachées...

BACK

Requêtes sortantes durant le cycle de page • La durée des pages devient > au temps de réponse de la ressource externe et peut bloquer • Core: • update (uniquement pour les admins et sur certaines pages) • aggregator, si poormanscron n’a pas été désactivé SOLUTION Consommer dans des scripts CLI lancés par cron ou, mieux, depuis un worker de messaging externe (ex : Beanstalkd) Back

Pic de charge inexpliqué après une longue durée sans problème TYPIQUE Utilisation d’un memcached avec l’erreur t($var) et la taille de cache_locale vient de dépasser 1 Mo VARIANTE Sur un site en évolution, une nouvelle version est beaucoup plus lente en production qu'en développement CONFIRMATION Déboguer l’utilisation du cache avec Heisencache ou XHprof SOLUTION À court terme, augmenter la slab size, et rapidement corriger pour revenir à une taille normale Back

Site globalement lent sans pic spécifique

Cache de blocs désactivé CAUSE Typiquement un ou plusieurs modules de node_access CONFIRMATION Configurer stark pour n’avoir que le bloc contenu, basculer dessus momentanément, et comparer : il devrait être considérablement plus rapide SOLUTION 1 Repenser la logique de contrôle d’accès aux données SOLUTION 2 Introduire du cache dans chaque bloc Back

Back Cache de données PROBLÈME 1 Cache désactivé — courant sur les sites construits sur Views et Panels MALGRÉ le cache intégré de Views (durée) et Views Content Cache (invalidation) ET MALGRÉ Panels Hash Cache PROBLÈME 2 Utilisé à niveaux multiples ⇒ Cache de données, puis de fragments, puis d’assemblages, puis de rendu, puis de blocs … = n aller- retours vers le serveur de cache là où un seul suffirait DIAGNOSTIC Heisencache (PerformanceSubscriber) Too much of a good thing is wonderful

Cache de variables toujours en MISS CAUSE TYPIQUE Un variable_set dans un hook du cycle de page : hook_boot / hook_init / hook_exit, function de shutdown, etc ORIGINE Confusion entre settings/config/state (formalisés en D8) DIAGNOSTIC var_dump(debug_backtrace(FALSE)) dans variable_set() et remonter la pile pour trouver le coupable VARIANTE Autres caches toujours en MISS SOLUTION GÉNÉRALE Heisencache (WriteSubscriber) Back

Trop grand nombre de requêtes SQL DIAGNOSTIC devel.module ou utiliser les fonctions de trace de l’API DB SOLUTION Manuelle Back

Trop grand nombre d’interventions de hook, notamment sur les nodes CAUSE TYPIQUE Trop de modules SOLUTION Réduire le nombre d’implémentations en repensant la logique fonctionnelle HACK hook_module_implements_alter() pour supprimer les situations connues comme ne pouvant donner lieu à une modification en pratique — difficile et fragile, mais résultats rapides Back

Autres problèmes courants Opérations en boucle (node_load, node_view) au lieu d’opérations multiples (node_load_multiple) Back

CONCLUSION

Conclusion La clef : compétence • Compétence du maître d'ouvrage (MOA) : déléguer n’est pas ignorer ⇒ se faire bien entourer et suivre son projet

Conclusion

Conclusion La clef : compétence • Compétence du maître d'ouvrage (MOA) : déléguer n’est pas ignorer ⇒ se faire bien entourer et suivre son projet • Compétences internes ou AMOA • Compétence du maître d'œuvre (MOE)

Mesurer pour agir Conclusion • Savoir quoi mesurer • Savoir sur quoi agir selon la mesure

Adapter Adapter les pratiques à la taille du projet En-dessous de quelques milliers de visites/jour, le stack Drupal/LAMP pardonne à peu près tout sauf l’absence de MàJ. Conclusion

PASSEZ NOUS DIRE BONJOUR ! Frédéric G. Marand (fgm) Outi Munter (outi) www.osinet.fr

OSInet www.osinet.fr [email protected]

Drupal Worst Current Practice

Drupal Worst Current Practice

More Decks by Frédéric G. MARAND

Other Decks in Programming

Featured

Transcript