Cet article s’adresse aux développeurs découvrant le cloud Azure de Microsoft. Il a vocation à les accompagner dans la prise en main de la plateforme afin de les aider à devenir opérationnels pour créer et maintenir des applications web dans Azure. Ainsi, cet article présentera les composants les plus utiles pour les développeurs tels que les incontournables applications web (web apps), les bases de données (DBs), les espaces de stockage (storages) et les fonctions (functions).

Lien vers la plateforme Microsoft Azure : https://portal.azure.com

Lien vers le SDK Azure : https://azure.microsoft.com/fr-fr/downloads/

Vue globale

Figure 1 : Page d'accueil

Depuis la page d’accueil, vous avez accès aux liens les plus utiles dans le menu des Favoris situé dans la colonne de gauche. Celui-ci qui se décompose comme suit :

• All resources
• Resource groups
• App services
• Storage accounts
• SQL databases
• Azure Database for MySQL
• Azure Cosmos DB
• Function App

Vous allez à présent parcourir ces raccourcis qui vous sont proposés tant en termes d’utilité que d’interfaces.

All resources

Figure 2 : Vue "All resources"

Comme son nom l’indique, cette vue liste exhaustivement toutes les ressources (web apps, DBs, storages, functions, etc.) auxquelles vous avez accès, tous projets et environnements confondus. Il est possible de jouer avec les filtres comme illustré Figure 2 pour afficher, par exemple, toutes les ressources de l’environnement d’intégration (int) ou encore pour afficher uniquement les web apps de l’int.

Resource groups

Figure 3 : Vue "Resource groups"

Cette vue regroupe l’ensemble des ressources par projet, environnement et région. De nouveau, les filtres peuvent aider à ne visualiser que les ressources souhaitées comme par exemple l’intégralité des environnements d’un seul et même projet.

Au clic sur un Resource group, vous accédez à l’interface de la Figure 4.

Figure 4 : Vue "Resource group"

Cette vue détaille les composants d’un Resource Group (celui d’intégration). Les composants les plus intéressants sont les Web apps, les Storages (containers et queues), les DBs et les Function apps (fonctions serverless).

Maintenant que vous avez étudié les différentes vues permettant d’accéder aux ressources, vous allez voir le détail de chacun des composants pouvant s’avérer utiles au développement d’un projet.

Vue détaillée des ressources

Web apps

Figure 5 : Vue d'accueil d'une web app

Depuis cette vue, vous pouvez administrer votre web app notamment par les actions de démarrage, de redémarrage ou d’arrêt de la web app. Cette vue permet également de connaître l’URL de la web app qui permettra aux développeurs Front d’y accéder.

Dans le menu de gauche figurent des raccourcis utiles comme "Configuration" qui permet de configurer les variables d’environnement de la web app ou encore "Advanced tools" qui permet d’accéder aux logs applicatifs de la web app.

Figure 6 : Vue "Configuration" d'une web app

Cette vue liste les variables d’environnement que la web app récupère en fonction de l’environnement dans lequel elle est hébergée. Ainsi, il vous est aussi possible de les éditer mais aussi d’en créer ou d’en supprimer.

Figure 7 : Vue "Advanced tools" d'une web app

Cette vue très simple permet d’accéder à Kudu, le back-office des web apps d’Azure qui stocke les logs applicatifs de la web app.

Figure 8 : Vue "LogFiles" d'Apache Kudu

Cette vue est le répertoire LogFiles du serveur sur lequel est hébergée la web app. Il contient les logs applicatifs générés par la web app grâce à l’intégration d’Application Insights dans l’application.

Notez qu’il est possible de lire les logs directement depuis le navigateur ou de les télécharger localement sur sa machine.

Figure 9 : Documentation en ligne d'Application Insights

Pour configurer Application Insights (fonctionnalité d’Azure Monitor) dans votre application, vous pouvez suivre cette documentation qui redirige vers la page web présentée en Figure 9.

Databases

Figure 10 : Vue d'une DB SQL Server

Cette vue est la page d’accueil d’une DB SQL Server. Elle permet entre autre d’accéder au serveur SQL Server via le lien srvint situé sur la droite de l’écran. Elle fournit aussi deux indicateurs de monitoring sur la DB que sont le taux d’utilisation du CPU et le taux de remplissage du disque.

Dans le menu de gauche figurent des raccourcis utiles comme "Query Performance Insight" qui informe sur les performances de la base par type de métrique et "Connection Strings" qui liste les chaînes de connexion à la DB.

Figure 11 : Vue de la page Query Performance Insight

Cette vue liste permet de visualiser les performances de votre DB avec plusieurs filtres très utiles. En effet, on peut choisir d’observer les performances CPU, mais aussi les entrées/sorties en terme de données ou de logs, la durée des requêtes et enfin le nombre d’exécution des requêtes, le tout sur des intervalles de temps choisis par un autre filtre. Ainsi, cet outil peut s’avérer très utile lorsque le besoin d’analyser ou d’améliorer les performances de la DB se fait ressentir.

Passons à présent à la vue "Connection Strings".

Figure 12 : Vue de la page Connection Strings

Cette vue liste les différentes chaînes de connexion disponibles pour les langages C#, C++, Java, PHP, Go et enfin le standard ODBC pour plus d’ouverture. Normalement, vous devriez apercevoir ces chaînes dans les encadrés mais elles ont été retirées pour des raisons de confidentialité. Il vous suffira de recopier l’URL qui vous intéresse dans votre propre configuration d’accès à la DB et de customiser vos informations d’authentification, le fameux user/password !

Revenez à présent sur la page d’aperçu de la DB pour vous rendre sur son serveur en cliquant sur le lien srvint.

Figure 13 : Vue d'un serveur SQL Server

Depuis cet écran, vous avez le contact de l’administrateur de la DB dans le champ "Active Directory Admin" en cas de nécessité de support et un lien rapide de retour dbint qui vous redirige vers la DB.

Dans le menu de gauche figurent des raccourcis utiles comme SQL databases qui permet de nouveau de retrouver le lien vers la DB ou encore Firewalls and virtual networks qui permet de gérer les adresses IP autorisées à se connecter à la DB.

Figure 14 : Vue "SQL databases"

Cet écran liste toutes les DBs créées dans le serveur SQL Server dans lequel vous naviguez afin notamment de récupérer les chaînes de connexion aux différentes DB.

Figure 15 : Vue "Firewalls and virtual networks"

Cette vue permet de créer autant de règles que nécessaire pour autoriser des adresses IP uniques ou des plages d’adresses IP à se connecter à la DB. Les développeurs peuvent créer des règles pour autoriser les plages d’adresses IP de leur lieu de travail afin d’accéder aux DBs distantes depuis leur propre ordinateur.

Storages

Overwiew

Figure 16 : Vue d'aperçu des comptes de stockage

Cette vue est la page d’accueil d’un compte de stockage. Elle permet d’accéder aux différents services de stockage que sont les containers, les file shares, les tables et les queues (nous développerons uniquement les containers et les queues). Elle fournit également un lien rapide vers la documentation en ligne de Azure Storage.

Documentation

Figure 17 : Documentation en ligne d'Azure storage

Pour configurer Azure Storage dans votre application, vous pouvez suivre cette documentation qui redirige vers la page web présentée en Figure 16.

Dans le menu de gauche figurent également des raccourcis utiles comme Storage explorer qui permet de parcourir l’arborescence des ressources du storage ou encore Access keys qui permet de récupérer les informations de connexion applicative au storage code et enfin Shared access signature qui permet de générer des tokens d’accès aux ressources du storage en lecture et/ou écriture.

Figure 18 : les Access keys pour la connexion au storage

Cette vue fournit les deux éléments clé pour la connexion d’une web app à un Azure storage que sont l’Account name et l’Account key. Ces deux informations seront renseignées dans les variables d’environnement de l’application et utilisées par la librairie Azure au moment de la connexion au storage de l’environnement concerné.

Figure 19 : la Shared access signature pour l'obtention de droits sur le storage

Cette vue permet de générer des tokens d’accès (qui sont en fait des URIs) fournissant des droits d’accès au storage restreints et limités dans le temps afin de sécuriser les données qui y sont stockées. Sans signature, une web app ne pourra pas accéder aux ressources de son storage. Pour ce qui est de la génération des signatures, il est possible de générer une URI avec les droits en lecture et en écriture sur l’ensemble des ressources du storage pour une durée illimitée, mais attention à la sécurité. Il est également possible de ne fournir un token d’accès qu’en lecture pour une durée d’une heure. Tout dépend donc du besoin.

Containers

Figure 20 : les containers du storage

Cette vue liste l’ensemble des containers créés au sein du storage. Elle permet d’en créer de nouveaux, de les modifier après création et de les supprimer. Simulons la création d’un nouveau container.

Figure 21 : création d'un nouveau Blob container

Cette vue est l’interface de création d’un nouveau container. Très simple, elle requiert juste le nom du nouveau container et le niveau d’accès. Au clic sur la liste déroulante, on se voit afficher les trois options de la Figure 22.

Figure 22 : édition du niveau d'accès d'un Blob container

Les trois niveaux d’accès à un container sont Private, Blob et Container. Configuré sur Private, un token est nécessaire pour accéder aux ressources du container. Configuré sur Blob, il est possible d'accéder aux ressources hébergées dans le storage sans token d’accès. Enfin, configuré sur Container, il est possible d’accéder au contenu des containers sans token d’accès.

Figure 23 : édition du niveau d'accès d'un Container

Il est tout à fait possible de modifier le niveau d’accessibilité d’un container même après sa création à l’aide d’un clic droit sur celui-ci, ce qui peut s’avérer très pratique.

Enfin, rentrez dans le container pour en visualiser son contenu.

Figure 24 : Contenu d'un Blob container

Cette vue liste l’ensemble des blobs contenus dans un container. Un container peut contenir trois types de blobs à savoir les Block blobs, les Append blobs et les Page blobs.

Les Block blobs sont conçus pour stocker des fichiers texte ou binaires, et pour charger efficacement des fichiers volumineux. Les Append blobs sont conçus pour les opérations d’ajout comme les logs. Enfin, les Page blobs sont constitués de pages de 512 octets maximum pouvant atteindre une taille totale de 8 To. Ils sont conçus pour des opérations de lecture/écriture aléatoires fréquentes. Dans le contexte de notre projet, nous n’utilisons que les Block blobs.

Ainsi, la vue d’un container permet de visualiser les blobs contenus par celui-ci ainsi que l’URL publique à laquelle ils sont accessibles, mais également d’en uploader de nouveaux, d’en supprimer et même de créer des tokens d’accès spécifiques à ces blobs.

Queues

Figure 25 : les queues du storage

Cette vue liste l’ensemble des queues créées au sein du storage. Elle permet d’en créer de nouvelles et de les supprimer. Simulez la création d’une nouvelle queue en cliquant sur le bouton ‘+’ à côté du bouton Refresh.

Figure 26 : création d'une nouvelle queue

Cette vue est l’interface de création d’une nouvelle queue. Très simple, elle requiert juste le nom de la nouvelle queue. Sauvegardez, elle est créée et utilisable.

Functions

Dans le contexte de notre projet, nous n’avons pas eu l’occasion de les utiliser, mais sachez qu’Azure propose un service de Function apps qui sont des applications serverless pouvant être hébergées sur différents runtimes que sont Java, .Net, Node, Python ou encore Powershell.

Ainsi, vous pouvez très bien créer une function app faisant office de trigger à la dépose d’un fichier dans un container ou encore à la dépose d’un message dans une queue.

Conclusion

A travers cet article, vous avez fait un premier pas dans le cloud Azure proposé par Microsoft en parcourant les composants utiles aux développeurs d’applications web.

Vous avez notamment étudié les web apps qui hébergent le code de votre application web, les DBs qui stockent les données de votre web app, les storages qui s’avèrent utiles au stockage de fichiers et de messages et vous savez également que les functions sont à votre disposition pour configurer des triggers HTTP sur tous types d’événements observés par votre web app.