La question de la migration d’un site vers le Cloud, et plus précisément sur Azure, est aujourd’hui plus que jamais d’actualité.

Dans cet article, nous allons vous guider pas à pas pour migrer un site vers Azure. Le site sur lequel nous allons travailler est en environnement de développement ou de test et les configurations présentées seront donc adaptées en conséquence.

Dans l’exemple qui suit, le site a été réalisé avec les technologies suivantes :

 

Voici les différents pré-requis à avoir sur votre machine pour vous lancer dans ce tutoriel :

 

Afin de mener cette migration à bien, il est en effet nécessaire de faire des choix techniques.
Tout d’abord, il est important de savoir que le cloud Azure propose plusieurs technologies différentes pouvant répondre à nos besoins. Il est donc fondamental de comprendre à quel usage ces dernières sont destinées et si elles peuvent être utiles dans notre cas.

 

Choisir sa base de données sur Azure

Pour ce tutoriel, l’application à migrer possède une base de données de type SQL Server.

Azure nous propose ici deux types de base de données :

 

  Azure Cosmos DB Azure SQL Server
Type de système de Base de données No SQL Relationnel
Description Distribuée mondialement :

·       SLAs élevés

·       Latence faible

·       Scalabilité

 

Multi Model

SQL Server

Peut être répliqué en plusieurs instances

 

 

Model Unique

Compatibilité avec SQL Server Migration via outil pour les données et refonte de l’application back end Totalement Compatible

 

Azure Cosmos DB possède plusieurs caractéristiques intéressantes mais dans notre cas ces dernières ne sont pas forcément utiles.

Nous allons donc partir sur du Azure SQL Server qui offre comme principal avantage d’être totalement compatible avec les SQL server, cela nous permettra d’éviter une refonte de l’application back end.

Notre modèle de données ayant été conçu pour une base relationnelle, passer sous Cosmos DB entraînerait bien plus qu’une simple migration sous Azure.

 

Après avoir choisi notre système de base de données, nous allons chercher quelle solution proposée par Azure répond le mieux à notre besoin afin de présenter notre API en .net Core.

 

 

Quel Choix pour l’API

Actuellement nous avons notre API en .net Core qui tourne sur notre serveur IIS (pour Internet Information Service).
Afin de migrer cette dernière dans Azure nous avons plusieurs candidats :

  • Azure Functions
  • Azure App Service

 

Avant de choisir la meilleure solution, découvrons plus en détail l’efficacité de ces dernières.

 

Azure Functions

Les Azure Functions sont une solution “serverless”, elle permet d’exécuter des fonctions sans s’occuper de l’infrastructure qui doit être mis en place derrière pour les exécuter. Pour en savoir plus sur le Serverless, nous vous invitons à découvrir notre Livre Blanc dédié à ce sujet.

 

Azure App Service

Azure App Service est un “service http” créé pour l’hébergement d’application web, API REST et backends mobiles. Elle est forcément contenue dans un Service Plan afin de gérer les ressources.

 

De mon point de vue, le grand avantage des Azure Functions est que l’on n’a pas à dimensionner le projet. Dans ce cas, on « paie ce que l’on utilise », de plus il y aura toujours, sans modification ni configuration, assez de ressources allouées. Cela correspond à du “serveless” et c’est l’une de leurs principales utilités.

Dans notre cas, le projet a été développé de manière standard. Cela signifie que le concept de micro-service n’a pas été forcément suivi,  nous possédons donc plusieurs services et imbrications assez complexes.

Finalement, de par la multitude de service et la complexité de certains de ces derniers, je préfère m’orienter vers une Azure App Service qui sera contenu dans un Service Plan.

Je trouve personnellement que l’on ne doit pas abuser des Azure Functions dans un souci de maintenabilité. Dans notre cas je partirai donc sur un Azure App Service. En effet, choix ne nécessite pas de factorisation du code et permet surtout une meilleure maintenabilité d’une application complexe.

 

Déploiement de l’Architecture avec Terraform

Pour le déploiement de notre architecture, nous choisissons Terraform. Cet outil permettra de déployer automatiquement notre architecture sur Azure.

 

Pour ce faire, nous vous invitons à installer Terraform sur votre machine.

Ensuite, nous testons si tout est bien présent en tapant la commande suivante dans PowerShell : terraform -version

 

Une fois la version affichée, nous initialisons le projet Terraform.

Pour cela nous créons un dossier vide dans lequel nous allons créer les deux fichiers principaux :

  • tf
  • tf

Une fois les deux fichiers créés, nous allons configurer ses accès sur Azure. Afin de lui donner des droits restreints nous lançons la commande suivante qui va générer un service principal :

 

NB : Pour cette commande, remplacez ##suscription_id par l’id de votre suscription

Le résultat de cette commande exécutée, plusieurs informations s’affichent à l’écran.

Ces dernières seront utiles pour le fichier “provider.tf” afin de configurer Terraform.

 

En effet ce fichier ressemble à cela :

  • ##suscription_id par l’id de votre suscription

Remplacez les valeurs ##client_id, ##client_secret et ##tenant_id par les valeurs fournies lors de la création du service principal :

  • ##client_id => id
  • ##client_secret => password 
  • ##tenant_id => tenant

 

Une fois le fichier enregistré nous pouvons passer à la description de l’architecture souhaitée. Pour cela nous allons utiliser le fichier main.tf.

La description de l’architecture souhaitée ressemble à cela :

Description de l'architecture souhaitée

Nous allons ici décrire l’ensemble des ressources à déployer :

  • Resource Group
  • SQL Server Azure
  • Service Plan
  • App Service
  • Storage Account

Après avoir configuré le projet, nous allons exécuter ce que nous avons codé.

 

Premièrement il faut initialiser l’environnement (téléchargement des différents plugins et modules nécessaires). Pour ce faire, nous allons à la racine de notre dossier et tapons dans la console : terraform init

 

 

Une fois l’environnement initialisé, nous allons regarder si tous les éléments demandés vont bien être déployés. Pour cela il faut utiliser la commande : terraform plan

 

Résultat de la commande précédente

 

Enfin nous allons déployer sur Azure l’ensemble de notre architecture avec la commande : terraform apply

 

 

Publication

Suite aux différentes commandes que vous venez de réaliser, nous arrivons à l’étape finale qu’est la publication.

Définir votre configuration

Pour publier notre site, il est d’une importance primordiale de finir la configuration de l’architecture que nous avons générée. Voici les deux configurations que vous devez réaliser à la main :

  • Autoriser les requête CORS sur l’App Service (entre le front et le back)
  • Activer le Static website sur le storage account

 

Ensuite nous complétons la configuration des endpoint/connectionString sur le front et le back.

 

Générer le site web statique

Cela se fait simplement avec la commande “jouer” à la racine du projet angular :

Capture du code

 

Déployer le site web statique

Je vous conseille d’utiliser le plugin de Visual Studio Code « Azure Storage » .

Azure Storage

 

Cliquez sur l’icône qui apparaît sur la gauche, vous devrez à ce moment vous connecter à votre souscription Azure. Suite à cela, vous aurez ensuite accès à vos différents account storage.

Emplacement du site web

 

Normalement, nous devrions avoir cette arborescence : MonStorage/Blob Containers/$web

Si “$web” n’apparaît pas, c’est que vous n’avez pas activé le site web statique dans le storage account. Je vous invite donc à le faire.

 

Enfin pour publier le site, il suffit de :

  • Faire un clic gauche sur $web
  • Choisir «Deploy to Static Website… »
  • Parcourir l’arborescence du projet afin de sélectionner le dossier généré dans le dossier « dist »

Dans la console de VSC, vous aurez un message vous indiquant que le site a bien été chargé.
Nous en avons fini pour le moment avec la partie front, il nous reste seulement le back.

 

Publication du Back

Ici, Visual Studio nous permet de publier simplement notre code sur un App Service. Il ne nous reste plus qu’à sélectionner ce dernier afin que le tout soit publié.

Publication du back

 

Pour conclure

Dans cet article, nous avons vu comment migrer un site en local Angular / .net Core sur Azure. Dans notre cas j’ai choisi d’utiliser Terraform pour le déploiement de l’architecture sur Azure.
Il est aussi possible d’utiliser d’autre outils tel que Azure Resource Manager, vous arriverez au même résultat.

Vous pouvez retrouver l’ensemble des fichiers Terraform dans mon repo sur Github.

Comme vous avez pu le constater, nous avons utiliser différentes technologies et ou framework dans cet article. Si Azure Cosmos DB ou bien encore Terraform sont encore inconnu pour vous, nous vous conseillons vivement de découvrir notre livre blanc “Les Technos de la rentrée 2019” qui les présente.