Retour d’Expérience – Mécanismes d’intégration des Azure App Services

Au cours d’une mission chez un client, nous avons eu l’opportunité de travailler sur les mécanismes d’intégration des Azure App Services dans un environnement datacenteurs hybrides.

Cet article a pour but de vous présenter succinctement les différents services utilisés et d’approfondir sur les problématiques d’intégration rencontrées et les solutions apportées.

Contexte

Avant de rentrer dans le vif du sujet, quelques mots sur le contexte client : nous sommes intervenus dans le cadre de la migration de leur progiciel de backoffice.

L’ensemble des applications existantes étant fortement intégrées à ce progiciel, la question s’est vite posée de la pertinence de les réintégrer au nouveau backoffice ou de les refondre également. C’est cette seconde solution qui a été retenue.

enioka est intervenu pendant la phase de cadrage sur le volet architecture et aujourd’hui nous continuons ce travail pendant la phase de réalisation.

Parmi les grandes problématiques rencontrées, il y a l’intégration d’applications web hébergées sur le PaaS Azure (que nous allons détailler ici).

Quelques mots sur l’architecture macro du SI cible :

• D’un côté, nous avons un datacenter On-Premises infogéré où se trouve notre nouveau backoffice assurantiel
• De l’autre, une région Azure qui héberge un ensemble de sites web (frontoffice) à destination de clients finaux

Ce choix d’architecture hybride a été dicté par différentes contraintes éditeurs et réglementaires liées aux données.

Besoins

Nos applications web hébergées sur Azure sont composées des technologies suivantes :

• Azure App Services
• Azure MySQL Database
• Azure Redis Cache

L’ensemble de ces technos ont comme point commun d’être des services PaaS (Plateform as a Service). Les deux premiers seront détaillés dans les chapitres suivants.

Les problématiques d’intégration sont les suivantes :

• Comment intégrer ces différents services entre eux ? (Nos App Services ont besoin d’accéder à la base de données et au cache)
• Comment intégrer nos applications avec notre backoffice assurance hébergé sur un datacenter On-Premises ?

Ces questions, classiques, peuvent paraitre anodines. Mais c’est l’environnement Cloud et l’usage de services managés qui les rend complexe et nous offre un beau cas d’intégration. En particulier si on cherche à respecter la politique de sécurité de l’entreprise ainsi que les exigences techniques et métier.

Azure App Services

Tout d’abord, quelques mots sur nos services principaux en commençant par les Azure App Services aussi connues sous le nom de Web Apps.

Qu’est ce qu’un App Service ? De quoi est-il composé ? Quelle différence avec un App Service Plan ? Pourquoi les utiliser ?

Azure App Service Plan

On trouve différentes terminologies sous cette offre Azure : un Azure App Service ou Web App est un serveur d’application et un App Service Plan s’apparente à une ferme de serveurs.

L’App Service Plan est une unité de facturation dont le prix dépend principalement du type (sizing) et du nombres d’instances choisies. Vous payez à partir du moment où vous avez au moins une Web App allumée et attachée à celle-ci. La facturation n’est pas liée au nombre de Web Apps au sein d’un même App Service Plan donc la mutualisation permet d’optimiser les coûts.

Une notion importante à comprendre est la notion d’instance. Un App Service Plan s’apparente à une VM et peut contenir une ou plusieurs Web Apps. L’App Service Plan peut être instancié plusieurs fois. C’est à dire qu’on peut avoir la copie d’un App Service Plan plusieurs fois pour, par exemple, répondre à une forte charge (mise à l’échelle horizontale). Cette multi-instanciation est gérée par un compteur (obligatoirement plus grand ou égal à 1) nommé « instance count ».

A préciser que les différentes instances d’un App Service Plan sont identiques. C’est-à-dire que l’on ne peut pas mettre une Web App sur l’un, deux sur l’autre, etc. Ce sont des clones.

Le schéma ci-dessous représente un App Service Plan multi-instancié.

Un App Service Plan, tout comme les App Services que nous verrons dans le chapitre suivant, ne peuvent pas être créés au sein d’une zone réseau de type VNet ou Subnet… Et une grosse partie de la problématique vient de ce fait. Les App Services n’ont qu’une adresse IP public en entrée et c’est tout. Impossible d’utiliser vos propres IPs privées.

Une offre est apparue pour répondre entre autres à cette demande d’avoir des App Services dans des réseau privés, les Azure App Service Environment, mais son coût est beaucoup beaucoup trop élevé.

Azure App Services

Un App Service est un serveur d’application managé. On trouve en plus des fonctionnalités classiques d’un serveur d’application des fonctionnalités autour de la sauvegarde, de la mise à l’échelle horizontale et beaucoup d’autres plus ou moins utiles que nous n’allons pas commenter ici. Un App Service se rattache obligatoirement à un App Service Plan.

Au sein d’un App Service on peut créer des « Deployment Slots » (DS) qui sont un clone de votre App Service initial, un virtual host en quelque sorte qui possède donc sa propre URL.
A sa création, vous avez la possibilité de copier la configuration de votre App Service ou non, ce qui vous permet d’assurer un certain cloisonnement. Ils permettent de créer rapidement des environnements projet et de faire du Blue/Green deployment.
Ces DS partagent l’infrastructure disponible dans l’App Service Plan.

Azure MySQL

« Configures the server’s firewall to accept connections from all Azure resources, including resources not in your subscription. »

AZure portal

Nous avons dans le chapitre précédent détaillé les Azure App Services. Parlons sommairement du service managé Azure MySQL.

Contrairement aux App Services, il est possible de communiquer avec une base de données Azure MySQL depuis un réseau privé (aka VNET/Subnet) via un VNET service endpoint. Cependant, le service endpoint ne fournit pas d’adresse IP privée au sein du VNET et on ne peut pas bénéficier du filtrage niveau 4 (Network Security Group) sur l’instance MySQL. Et c’est justement sur la partie sécurité d’accès que va s’orienter ce chapitre plus que sur la base de données MySQL ou sur le service PaaS en lui même.

On se retrouve donc avec une base de données condamnée à avoir une IP public. Pour garantir la sécurité de cette base de données Microsoft nous fournit en tout et pour tout une sorte de firewall qui se compose de 3 encéphales :

• Autoriser l’accès aux services Azure : un bouton « ON/OFF » qui permet aux services Azure, quelqu’ils soient, d’intéragir avec votre base de données… (cf. citation ci-dessus)
• White listing d’IP : Permet de whitelister des IPs (CIDR non acceptés). Ce qui se rapproche le plus ici d’un véritable parefeu, mais il nous est permis d’en douter (cf. chapitre suivant)
• VNet Service Endpoint : permet de lier un réseau privé à la base de données et d’en autoriser l’accès

Mécanismes d’intégration

Azure App Services et Azure MySQL

Comment faire communiquer une Web App avec une base de données Azure MySQL ?Rappelons qu’il s’agit ici de deux services PaaS Azure pour lesquels il est impossible de les inclure dans un réseau privé. Pour cela, deux moyens possibles :

• Utilisation du Firewall Azure MySQL : cette méthode décrite dans le chapitre précédent présente plusieurs inconvénients, l’idée d’ouvrir le service à l’ensemble des services Azure n’est pas idéale malgré l’existence de ce « firewall » , de plus, ce mécanisme de sécurité semble reposer sur la base de données elle-même et non pas par un équipement de sécurité (firewall, proxy, etc.)
  • Les logs remontés en cas de blocage semblent confirmer cette hypothèse : ERROR 9000 (HY000)
  • L’arrivée de la nouvelle offre Azure Advance Threat Protection aussi
• Utilisation du VNet Integration : n‘offre ici aucune solution à notre problématique
• Utilisation du New VNET Integration : nous permettrait de nous interfacer avec un VNET et de bénéficier d’adresses IPs privées issues d’un subnet créé uniquement dans ce principe. Il reste à créer un VNET Service Endpoint (Azure MySQL Database) sur un autre subnet et à s’appuyer sur le routage Azure pour y accéder. Cette solution comporte plusieurs avantages :
  • On n’ouvre pas la base de données à l’ensemble des services Azure, ce qui limite les attaques (cf. Advance Threat Protection)
  • La sécurité est portée par les mécanismes réseau au sein du VNET : blocage de l’ensemble des flux qui n’appartiennent pas au subnet sur lequel est paramétré le VNET Integration. Malheureusement, il n’est toujours pas possible de libérer l’IP Public ni d’en couper l’accès au niveau 4 (OSI)

Azure App Services et Datacenter OnPremises

• Utilisation de l’Hybrid Connection :
  • Nécessite une machine supplémentaire côté On-Premises
  • Ce n’est pas compatible avec une Express Route
• Utilisation du VNET Integration :
  • La mise en place et l’exploitation est lourde et complexe (plusieurs gateways, pour plusieurs réseau VPN)
  • Ce n’est pas compatible avec une Express Route sauf si l’on configure une Gateway en mode coexistence ce qui s’accompagne d’une exploitation lourde et un certains nombre de contraintes.
• Utilisation du New VNet Integration :
  • Ne nécessite pas un VPN entre les App Services et le VNet
  • Est compatible avec les Express Route
  • Permet de résoudre à la fois la problématique d’intégration avec la base de données et la problématique d’interconnexion avec le datacenter On-Premises. On utilise donc qu’une seule technologie pour répondre à nos différentes problématiques
  • Cette solution n’est pas compatible avec les App Services Linux et aucune date n’a encore été annoncée

La New VNet Integration dans les faits

Nous avons testé le New VNet Integration sur nos environnements de test :

• Cette solution est toujours en preview, nos tests d’intégration ont échoués jusqu’à présent pour la partie base de données. Microsoft nous confirme que c’est un bug connu et que la communication par VNet Service Endpoint n’est pas encore opérationnelle
• L’interconnexion avec le datacenter On-Premises fonctionne en laboratoire, mais reste à éprouver (montée en charge, latence, etc.)
• D’autres travaux restent à réaliser comme l’impact d’une augmentation du nombre d’instance de nos App Services et tout ce qui est lié à la robustesse et la fiabilité de la solution

Architecture cible

A noter qu’ici nous utilisons des App Services Windows parce que les VNet Integrations ne sont pas disponibles à court terme sous Linux. Nous ferons la migration le moment voulu.

Des App Services Standard sont utilisés pour nos environnements projet pour pouvoir bénéficier des VNet Integration. Les App Services de niveau inférieur n’en bénéficient pas.

Conclusion

Les différentes options disponibles ou prochainement disponibles de ce type de services cloud rendent la conception des architectures PaaS délicates. Se poser les bonnes questions, concevoir une solution opérationnelle et même la maquetter n’est pas suffisant, tant les alternatives possibles évoluent vite. L’opacité des solutions, le manque d’information et la vitesse d’évolution des solutions en sont les principaux problèmes.

Nous avons eu la chance pour ce projet de pouvoir échanger avec les équipes Microsoft fastTrack pour nous assurer de la pertinence de notre architecture.