Cas d’étude : une application PHP sur Azure en mode PaaS
Temps de lecture : 5 minutes
Publié le 14 août 2017
Fondée en 2016, la startup française Allskreen entend s’imposer comme une plateforme de digitalisation de bandes dessinées et, plus globalement de contenus print visuels (plaquettes, supports promotionnels). Une ambition qui débouche sur de nombreux défis, de l’adaptation des contenus aux différents écrans à leur distribution en passant par l’analyse du comportement des lecteurs.
Pour y parvenir, Allskreen propose des outils et services à destination des créateurs de contenus et notamment une plateforme sécurisée de distribution de ces contenus pour l’ensemble des terminaux, de l’écran de TV au smartphone. Cette plateforme s’incarne à travers un site dédié, Les Auteurs Numériques, et une application mobile LesAutNum disponible sur iOS et Android – une version Windows étendue à la Xbox est prévue. Allskreen peut aussi déployer ses services en marque blanche pour des professionnels désireux de proposer un tel service.
PHP sur Azure en mode PaaS
Lors de l’élaboration de la plateforme, Allskreen s’est fixé les objectifs suivants :
- Apporter une expérience homogène aux utilisateurs même depuis un terminal mobile avec une connexion limitée
- Garantir que les contenus ne puissent être consommés que par les utilisateurs autorisés
- Pouvoir administrer la plateforme sans avoir à recruter une équipe dédiée.
Au regard de ses compétences techniques, l’équipe a opté pour le développement d’un back office en PHP (sans recourir à un framework). Membre d’Euratech, l’un des plus principaux accélérateurs français et du programme BizSpark Plus, Allskreen a décidé de mettrer à profit l’opportunité de collaborer avec Microsoft pour franchir un nouveau cap dans son développement. Au coeur de cette évolution, le recours à Azure app Service, Azure Traffic ou encore Azure Logic Apps. Une bonne manière d’évaluer la capacité d’Azure à soutenir une application PHP.
Plusieurs chantiers (et objectifs) ont rapidement été identifiés que nous vous proposons de détailler ici :
> Utiliser Azure App Service pour héberger de multiples applications web écrites en PHP
> Stocker les contenus dans Azure Storage et générer des Shared Access Signatures
> Designer une architecture globale capable de soutenir la performance attendue
> Créer un workflow de publication
Utiliser Azure App Service pour héberger de multiples applications web écrites en PHP
La solution se compose de 3 services principaux :
- Le frontal web utilisé par les utilisateurs pour s’abonner au service
et explorer le catalogue disponible- L’application web de création destinée, elle, aux créateurs et éditeurs
- L’application web d’administration à l’usage exclusif de l’équipe Allskreen
Afin de s’épargner la maintenance d’une infrastructure, Allskreen a privilégié le recours à un service de type Platform-as-a-Service, donc à Azure App Service. Un choix doublement attrayant. Tout d’abord, Azure App Service gère de manière transparente pour les utilisateurs toutes les tâches relatives à la performance, à la scalabilité ou encore à la sécurité. Ensuite, le service s’appuie sur la notion d” »App » (Web App, Mobile App and API App), qui représente une vue logique d’une application, et sur celle de « plan App Service » qui regroupe les ressources utilisées par les apps hébergées. Avantage de ce modèle : il est possible d’exécuter plusieurs apps dans un même plan afin de mutualiser les ressources et de maîtriser les coûts.
Stocker les contenus dans Azure Storage
et générer des Shared Access
Dans le contexte de Azure App Service, Azure Storage et blob Storage se sont imposées comme des solutions naturelles pour stocker les fichiers des contenus et les distribuer. Toutefois, cela devait être mis en oeuvre sans perdre de vue l’impératif de sécurité : garantir que les oeuvres sont vues par des personnes autorisées (qu’elles disposent par exemple du bon abonnement). C’est exactement pour ce type de besoins que la fonction « shared access signatures » (SAS) est disponible : donner un accès limité à des objets d’un compte à d’autres clients (sans exposer la clé du compte).
Pour mettre en oeuvre ce mécanisme, l’application PHP sur Azure doit être capable de vérifier l’identité de l’utilisateur avant de générer une SAS temporaire pour le client. L’application PHP devient alors le fournisseur du service SAS et le client (un navigateur web ou une un app mobile) peut utiliser cette clé afin d’accéder au contenu stocké dans Azure Storage.
Pour y parvenir, la librairie Microsoft Azure Storage for PHP a été mise à contribution. La fonction de génération de SAS n’étant pas encore disponible, l’équipe a opté pour la génération d’une SAS dans l’application PHP en utilisant l’API Rest Azure Storage.
> Vous pouvez découvrir sur github.com le code utilisé à cette fin
Designer une architecture globale
capable de soutenir la performance attendue
Pour fournir la meilleure expérience possible à tous les utilisateurs (en Europe et aux Etats-Unis notamment), l’équipe a choisi de déployer son application dans 2 régions Azure. Pouvoir déployer la même application sur 2 continents différents est l’un des grands atouts d’un cloud tel que Azure. À condition cependant d’utiliser les bons procédés de gestion de trafic et de synchronisation de données pour faire de cette géographie une réalité.
Concrètement, quand un client utilise la solution (depuis le web ou l’app mobile), le système détecte, sur la base de sa localisation, quel déploiement (région) lui apportera la meilleure performance. Ce comportement est fourni par Azure Traffic Manager, service qui s’appuie sur les DNS pour rediriger les requêtes vers le point le plus approprié. Le routage choisit le chemin qui présente la latence réseau la plus faible. Grâce à ce mécanisme, un utilisateur français est automatiquement « routé » sur l’instance européenne.
Avec ce type d’architecture, l’essentiel consiste à s’assurer que les données restent synchrones entre les différents déploiements. Même si le temps réel ne s’impose pas forcément dans le cas présent, un utilisateur américain doit pouvoir explorer le même catalogue qu’un utilisateur français.
Une partie des services exploités par Allskreen intègrent des fonctions à cette fin. La base de données Azure SQL comprend ainsi un mécanisme de géo-réplication qui permet la configuration de 4 copies secondaires accessibles en lecture dans la même région ou une autre. Pour Allskreen, une copie s’avère suffisante. Tous les services (Azure Storage, Azure Search, …) n’ont pas ce type de fonctions et requièrent des développements complémentaires, mis en oeuvre avec le workflow de publication.
Créer un workflow de publication
Pour rendre disponible un contenu, le créateur doit déclencher sa publication depuis l’application de création. Le processus se décompose en plusieurs étapes techniques :
- Insertion en base des méta-données (auteur, description, prix…)
- Copie du contenu dans chaque compte Azure Storage
- Indexation du contenu par Azure Search
- Envoi d’un email aux abonnés pour prévenir de la disponibilité d’une nouvelle publication
- Publication d’un Tweet dans les bons comptes
Pour orchestrer ces étapes, Azure Logic Apps a été appelé à la rescousse. Avec Logic Apps, un workflow se construit facilement en combinant conditions, boucles, déclencheurs et des connecteurs pour interagir avec des ressources variées, qu’il s’agisse de services Azure, de ressources on-premises ou encore de services en ligne (Twitter, Salesforce, SendGrid…). Dans le cas de Allskreen, la plupart des connecteurs requis étaient disponibles. Ceux qui manquaient à l’appel ont été développés en PHP et publiés comme des fonctions Azure.
Un cas d’étude probant pour les développements PHP sur Azure en mode PaaS
Le recours à Azure a permis à l’équipe Allskreen d’atteindre sans grosse difficulté ses objectifs en matière de performance, de sécurité et d’administrabilité de sa plateforme. En outre, la roadmap d’Azure pour le support de PHP ou d’autres technologies open source devrait permettre de belles évolutions de la plateforme Allskreen dans les mois à venir.
> Rendez-vous sur github.com pour accéder aux scripts utilisés dans le cadre de ce projet
