Dans cet article, nous allons vous présenter l’une des méthodes existantes pour implémenter Semarchy xDM sous la forme d’un ensemble de Platform as a Service (PaaS) Azure.

Dans un premier temps, nous allons parcourir une liste non exhaustive des services Azure qui nous permettront de faire fonctionner Semarchy xDM. Nous aborderons par la suite la mise en place d’une configuration minimale permettant d’assurer le bon fonctionnement du MDM.

Liste des PaaS Azure

PaaS obligatoires

L’architecture de Semarchy xDM repose sur 2 composants :

  • un serveur applicatif (Tomcat, Eclipse Jetty, Wildfly, GlassFish,...) permettant d’exposer l’application web de Semarchy
  • une base de données relationnelle (Oracle, PostgreSQL ou SQL Server) permettant de stocker les données techniques et fonctionnelles des référentiels

Ci-dessous, nous allons vous présenter deux PaaS capables de prendre en charge ces rôles.

Azure App Service

Afin de jouer le rôle du serveur applicatif, nous pouvons utiliser la plateforme Azure App Service.
Pour fonctionner, ce service doit reposer sur la brique App Service Plan qui constitue le serveur sur lequel une ou plusieurs Apps Service pourront être exécutées.

Azure App Service vous propose plusieurs méthodes permettant d’exécuter un serveur Tomcat. Dans l’exemple que nous vous présentons ci-dessous, nous avons fait le choix d’installer ce service avec un environnement Docker.

Pour charger une image Docker, Azure App Service peut se connecter à plusieurs plateformes :

  • Docker Hub
  • Gestionnaire de registre privé
  • Azure Container Registry

Dans notre exemple, nous avons opté pour l'utilisation du service Azure Container Registry dont nous détaillerons les fonctionnalités ultérieurement dans cet article.

Azure Database for PostgreSQL

Le second composant nécessaire au bon fonctionnement de Semarchy xDM étant une base de données, nous avions le choix entre le service Azure SQL Database et le service Azure Database for PostgreSQL.

Azure SQL Database reposant sur des instances SQL Server, l’installation de Semarchy xDM sur cet environnement pourrait engendrer un grand nombre de bases de donnnées. En effet, lorsque Semarchy s’appuie sur une base de données SQL Serveur, le repository (la base système de Semarchy xDM) ainsi que l’ensemble des datalocations (emplacement de données sur lequel vos référentiels tourneront) se matérialisent aux travers d’une base de données pour chaque élément.

De ce fait, l’utilisation du service Azure Database for PostgreSQL devient généralement plus économique.

Composants facultatifs

Maintenant que nous avons passé en revue les éléments primordiaux pour le fonctionnement de Semarchy xDM, nous pouvons nous attarder sur quelques services Azure facultatifs qui vous permettront de personnaliser votre implémentation.

Azure Container Registry

Azure Container Registry vous permettra de stocker vos images Docker au sein de votre infrastructure Azure afin de pouvoir les utiliser au travers de vos divers services et notamment avec Azure App Service.

Azure Key Vault

Depuis la version 5.3 de Semarchy, les informations sensibles peuvent être chiffrées afin d’améliorer la sécurité des référentiels.

Pour ce faire, Semarchy xDM a besoin d’un service de gestion de clé de chiffrement. Il peut s’appuyer sur des services tels que les keystore java, AWS et notamment le service Azure Key Vault.
Afin de réaliser cette action, Semarchy a besoin qu’on lui fournisse une clé de chiffrement qui peut être stockée sur divers supports et notamment, sur un Azure Key Vault.
Ce service vous permet de stocker vos clés de chiffrement, vos certificats de manière sécurisée et de contrôler les accès à ces informations.

Virtual Network (vNet)

Dans le cas où vous vous satisferiez de "whitelister" l’ensemble des adresses IP de sortie de votre Azure App Service vers votre Azure Database for PostgreSQL, vous n’avez pas besoin d’un Virtual Network.

Cependant, bien que ces IP ne changent que très rarement, il existe toujours un risque que votre application ne puisse plus communiquer avec votre base de données. Pour contrer ce risque, vous pouvez utiliser un Virtual Network (vNet) afin de connecter l’Azure App Service avec votre Azure Database for PostgreSQL par le biais de terminaison de service.

App Service Domain

Si vous ne bénéficiez pas d’un nom de domaine et que vous souhaitez personnaliser le nom de domaine automatiquement attribué par Azure (********.azurewebsites.net), vous pouvez faire l’acquisition d’un nom de domaine grâce au service App Service Domain.
Lors de la création de votre nom de domaine, Azure vous créera une “DNS zone” afin que vous puissiez administrer votre nom de domaine.

Génération de certificats

Le protocole HTTPS devenu aujourd'hui la norme pour toute application Web, vous allez avoir besoin de générer des certificats.

Comme pour les précédentes ressources facultatives, vous pouvez très bien utiliser des services externes à Azure pour gérer cela. Cependant, si vous n’êtes pas coutumier de ceux-ci, Azure vous proposera une interface en plusieurs étapes vous permettant de générer simplement vos certificats et de les attribuer à vos ressources Azure.

Azure App Gateway

Le dernier composant facultatif que nous allons voir vous permettra, en fonction de sa configuration, d’exposer et de sécuriser l’ensemble de vos applications au travers d’un unique point d’accès.
En effet, là où chacune de vos App Services dispose d’une IP publique permettant de requêter votre application, l’application Azure Gateway vous permettra de rendre vos sites disponibles à partir d’une seule et même IP publique.
Cela vous permettra donc de sécuriser plus efficacement votre infrastructure Azure en évitant d’y exposer de multiples points d’accès.
En plus de cela, Azure App Gateway renforcera la sécurité de vos applications car elle peut embarquer un pare-feu d’applications qui vous protègera contre un grand nombre d'attaques (attaques XSS, injection SQL, …)

Autres services Azure

Ne pouvant parcourir l’ensemble des ressources Azure dans cet article, sachez qu'il existe d’autres ressources pouvant être utilisées pour ajouter des fonctionnalités supplémentaires à cette infrastructure ou bien pouvant être utilisées comme solutions alternatives aux services précédemment détaillés (Ex : Azure App Service vs Azure Kubernetes Service, ...).

Maintenant que nous avons détaillé des services vous permettant de déployer votre plateforme, passons à un exemple de configuration minimaliste.

Semarchy xDM : Configuration d’un exemple d’architecture

Pour cette démonstration, nous avons décidé d’utiliser notre propre image Docker.

Notez que Semarchy met à disposition des images officielles sur son repository que vous pouvez retrouver sur le hub docker, ainsi qu’un template de fichier de configuration Docker Compose récupérable au travers des démos disponibles sur leur propre site.

Notre image sera stockée dans un Azure Container Registry qui l’exposera à Azure App Service qui exécutera.

Pour la base de données, nous avons décidé d’utiliser le service Azure Database for PostgreSQL.

Configuration du service Azure

La première étape consiste à créer notre ressource Azure. Pour ce faire, nous allons utiliser une instance Azure Database for PostgreSQL en mode “Single Server”.

Concernant sa configuration, nous sommes relativement libres de configurer l’instance à notre guise. Le seul paramètre réellement important concerne la puissance de calcul. Afin de respecter les préconisations de Semarchy, nous devons allouer au minimum 4vCPU à notre instance. Pour ce faire, nous avons le choix entre le plan “Usage général” ou “Mémoire Optimisée”.

Configuration de la base de données

Notre instance étant maintenant créée, nous pouvons passer à la configuration de la base de données pour héberger le repository de Semarchy, ainsi que les divers emplacements de données qui serviront à stocker les données de nos référentiels.

Pour ce faire, nous vous recommandons de vous référer à la section “Configure the Database Schemas“ de la documentation “Install Semarchy xDM” disponible sur l'espace documentaire de Semarchy.

Voici quelques informations utiles pour configurer le repository ainsi que les emplacements de données :

  • Puisque nous utilisons une base PostgreSQL, il est recommandé de créer le repository ainsi que les emplacements de données sur la même base de données.
  • Si vous souhaitez stocker les emplacements de données sur une base de données différente de celle hébergeant le repository, il vous faudra créer le schéma “extension” sur toutes les bases de données en veillant à y installer les extensions “uuid-ossp” et “fuzzystrmatch”.
  • À chaque schéma utilisé par Semarchy doit correspondre un utilisateur ayant le même nom.

Configuration de l’Azure Container Registry

Pour notre démonstration, nous avons utilisé un Container Registry reposant sur un SKU “De base”. Ce type de SKU ne nous permet pas de personnaliser notre instance.
Cependant, pour une utilisation en production, nous recommandons d’utiliser un SKU “Premium” qui vous permettra de sécuriser les accès à votre Container Registry et de chiffrer les artéfacts stockés sur le container.

Pour configurer votre instance Azure Container Registry sur une SKU “de base” / “Standard”, il vous suffira de choisir un groupe de ressource ainsi qu’un nom d'instance.

Configuration de l’image Docker

1/ Préparation du fichier du Dockerfile

Afin de répondre aux pré-requis logiciels permettant de faire fonctionner Semarchy xDM, nous allons nous baser sur une image tomcat 9.0.45 avec un java 11 openjdk d’installé.
Nous devons ensuite configurer un keystore qui nous permettra d’y stocker une clé de chiffrement utilisée par Semarchy xDM afin de chiffrer les données sensibles stockées dans Semarchy. Pour ce faire, nous avons utilisé l’utilitaire keytool.

Nous devons également télécharger et ajouter le certificat publique utilisé par les services azure dans ce keystore afin de permettre le chiffrement des échanges avec les divers services que nous utilisons (notamment Azure Database for PostgreSQL).

Nous devons ensuite copier les divers fichiers de configuration et librairies utiles au fonctionnement de Semarchy. Nous ajouterons donc les éléments suivants :

  • semarchy.war : Permet de déployer l’application Sermarchy xDM sur le serveur tomcat
  • semarchy.xml : Fichier de configuration fourni par Semarchy lors du téléchargement des sources d’installation
  • setenv.sh : Fichier de configuration dans lequel nous définissons la configuration de l’accès à la base de données, le token utilisé pour l’initialisation du repository, l’accès au keystore…
  • server.xml (Si vous souhaitez personnaliser les options de connexions au service tomcat)
  • Librairies additionnelles

Pour finir nous configurerons les ports qui seront utilisés par le conteneur pour se connecter aux services configurés dans notre image, ainsi que le script utilisé pour l’initialisation du conteneur.

2/ Création et déploiement de l’image Docker

Notre fichier Dockerfile étant maintenant prêt, nous allons le "build" afin de pouvoir le déployer en image sur notre conteneur Azure. Pour ce faire, nous allons utiliser les commandes suivantes :

  • docker build . -t “[NOM DU CONTENEUR DE REGISTRE].azurecr.io/[NOM DE L’IMAGE]”
  • “az login” pour se connecter aux services azure
  • az acr login –name [NOM DU CONTENEUR DE REGISTRE] afin d’avoir les permissions de publier une image
  • docker push [NOM DU CONTENEUR DE REGISTRE].azurecr.io/[NOM DE L’IMAGE]

Configuration de l’Azure App Service

À nouveau, nous sommes relativement libres dans la configuration du PaaS Azure App Service. Les paramètres importants seront :

  • Son type : Application Web
  • La méthode de publication du code source : Conteneur Docker
  • Système d’exploitation : Linux

Une fois renseigné, nous pouvons passer à la configuration de l’App Service et du Docker :

  • Options : Conteneur unique
  • Source d’image : Registre de conteneurs Azure
  • Registre : [Nom du registre précédemment créé]
  • Image : [Nom de l’image précédemment créée]
  • Balise : [Tag de l’image à utiliser pour démarrer le conteneur]

Nous devrions maintenant avoir une application fonctionnelle. Cependant, plusieurs éléments peuvent encore être personnalisés :

  • Le domaine de votre application qui, par défaut est azurewebsites.net
  • Les certificats utilisés par Azure App Service
  • L’interconnexion de l’App Service avec les autres services Azure

Implémentation de Semarchy xDM en mode PaaS avec Azure

Pour en savoir plus sur la plateforme Semarchy xDM, suivez ce lien : Semarchy xDM

Vous souhaitez bénéficier d'experts, de développeurs, ou d'une formation sur Semarchy xDM ? Rendez vous sur la page Contact