Deuxième édition

Iain Foulds
APPRENEZ AZURE EN
DÉJEUNANT, EN UN
MOIS SEULEMENT !

<br /> }*

///////// #
 Obtenez de l’aide
pour votre projet
Parlez avec
un commercial >

CommencezIci(Azure) ;

Bénéficiez d’une base solide dans Azure avec les

Découvrez les enseignements tirés de cet Ebook. Ouvrez un

21 leçons Azure compte Azure gratuit et utilisez votre crédit de

200 USD pour réaliser les exercices. Continuez
d'utiliser votre compte et bénéficiez de 12 mois
de services gratuits populaires et de plus de 25
services toujours gratuits.

Démarrez gratuitement
 ÉCONOMISEZ 40 % SUR LES LIVRES ET VIDÉOS DES ÉDITIONS MANNING !
Manning publie des livres et des vidéos de grande qualité pour les professionnels de la technologie comme vous.
Utilisez ce code de réduction spécial pour économiser 40 % sur tous les Ebooks, les livres imprimés, les programmes
d'accès anticipé Manning (MEAP) et les cours vidéo en ligne sur manning.com , y compris sur cette sélection,de titres.
Il vous suffit d'entrer azuremsft2 dans la fenêtre de code promotionnel au moment de valider votre commande.

Learn Windows PowerShell in a Month of Lunches Learn Docker in a Month of Lunches

par Don Jones et Jeffery Hicks Elton Stoneman
Décembre 2016, 384 pages Été 2020, 530 pages

Autres livres de la collection Apprendre en déjeunant !

Learn Windows PowerShell in a Month of Lunches, troisième édition
Learn Docker in a Month of Lunches
Learn dbatools in a Month of Lunches
Learn PowerShell in a Month of Lunches, Linux and macOS Edition
Learn PowerShell Scripting in a Month of Lunches
Learn Linux in a Month of Lunches
Learn Amazon Web Services in a Month of Lunches
Learn Cisco Network Administration in a Month of Lunches
Livres pour les développeurs Microsoft et les professionnels de l’informatique
Azure Data Engineering ASP.NET Core in Action Core Kubernetes
Dependency Injection Principles, Entity Framework Core in Action GitOps and Kubernetes
Practices, and Patterns C# in Depth (quatrième édition) Docker in Action (deuxième édition)
Microservices in .NET Core Functional Programming in C# Docker in Practice
.NET Core in Action Kubernetes in Action (deuxième édition)
Microservices Security in Action Knative in Action Docker in Motion
Concurrency in .NET Bootstrapping Microservices OpenShift in Action
Reactive Applications with with Docker, Kubernetes, Cloud Native Patterns
Akka.NET and Terraform

Lisez gratuitement les livres des éditions Manning sur liveBook

La plateforme liveBook de Manning offre une expérience de lecture en ligne agréable et souple. Chaque jour,
vous bénéficiez pendant cinq minutes d’un accès complet GRATUIT à tous les livres des éditions Manning.
Dans liveBook, vous pouvez :
• Poser des questions, partager du code et des exemples, et interagir avec d’autres lecteurs
dans le forum liveBook.
• Effectuer une recherche en texte intégral dans tous les livres Manning, y compris ceux
que vous ne possédez pas.
• Inscrivez-vous GRATUITEMENT sur liveBook à l'adresse livebook.manning.com.
Vous pouvez utiliser vos cinq minutes d'accès GRATUIT comme vous le souhaitez : démarrez et arrêtez
le minuteur, passez d'un livre à l'autre et essayez les exercices interactifs. Connectez-vous et parcourez
le site. C'est sans risques !
 Éloges pour la première édition

À partir de la première édition de Apprenez Azure en déjeunant ! par Iain Foulds :

« Une mine d'informations : parfait pour apprendre en un seul mois les concepts de base et avancés d’Azure ! »
—Sushi Sharma, galvaniser

« Microsoft Azure devient rapidement un leader dans le domaine du Cloud public. Grâce aux exercices
décrits dans cet ouvrage, vous serez rapidement à la pointe de cette technologie. »
—Michael Bright, conseiller en développement indépendant

« Excellente introduction à Azure avec de nombreux exemples pratiques. Couvre un large éventail de
sujets actuels. »
—Sven Stumpf, ING-DiBa AG

« Azure est semblable à un océan. Ce livre vous maintient à flot en vous proposant le meilleur moyen
d'apprendre en déjeunant et en profitant de leçons riches en activités pratiques et en exemples. »
—Roman Levchenko, Microsoft MVP

« Tout ce dont les développeurs proactifs ont besoin pour exploiter Azure. »
—Rob Loranger, freelance developer

«  Grâce à une approche concise axée sur la pratique, ce livre permet d'appréhender l'offre étendue
d'Azure. »
—Dave Corun, Avanade

«  Le livre le plus complet sur Azure que j’ai trouvé pour commencer à développer mes projets
académiques ! »
—Marco Giuseppe Salafia, PhD student, Università degli Studi di Catania

« Il s’agit d'un ouvrage incontournable sur la plateforme Azure. Il est bien organisé, approfondi et com-
plet. Il explique les bases et guide le lecteur en créant des configurations de plus en plus complexes avec la
plateforme Azure pour fournir une évolutivité, des performances élevées et une redondance pour les appli-
cations et services hébergés. Ce livre servira à la fois de tutoriel pour les débutants et de référence pour les
utilisateurs plus expérimentés. »
—Robert Walsh, Excalibur Solutions
Apprenez Azure en
déjeunant !
deuxième édition

IAIN FOULDS

MANNING
Shelter Island
Pour plus d’informations et pour commander ce livre et d’autres ouvrages publiés par Manning,
rendez-vous sur le site www.manning.com. L'éditeur propose des remises sur ce livre si vous
commandez plusieurs exemplaires. Pour en savoir plus, veuillez contacter :
Special Sales Department
Manning Publications Co.
20 Baldwin Road
PO Box 761
Shelter Island, NY 11964
Adresse e-mail : orders@manning.com

© 2020 Manning Publications Co. Tous droits réservés

Aucune partie de cette publication ne peut être reproduite, stockée dans un système d’extraction ou
transmise sous quelque forme ou par quelque moyen que ce soit (voie électronique, voie mécanique,
photocopies ou autres), sans autorisation écrite préalable de la part de l’éditeur.

Bon nombre des désignations utilisées par les fabricants et les vendeurs pour distinguer leurs produits
sont des marques déposées. Lorsque de telles désignations apparaissent dans le livre, si Manning
Publications avait connaissance qu'une marque avait été déposée, elles sont écrites avec une majuscule
initiale ou tout en majuscules.

Dans un souci de préservation des écrits, la politique de Manning est d'imprimer ses livres sur du
papier non acide, et nous déployons tous les efforts dans ce sens. En outre, dans un souci de
préservation des ressources de la planète, les livres Manning sont imprimés sur du papier au moins
15 % recyclé et traité sans chlore élémentaire.

Manning Publications Co. Rédacteur responsable des commandes : Mike Stephens

20 Baldwin Road Rédacteur responsable du développement : Frances Lefkowitz
PO Box 761 Éditeur développement technique : Karsten Strøbaek
Shelter Island, NY 11964 Éditeur révision : Aleksandar Dragosavljevic
Rédacteur responsable de la publication : Anthony Calcara
Éditeur graphique : Jennifer Houle
Éditeur publication : Kathy Simpson
Correcteur : Katie Tennant
Relecteur technique : Karsten Strøbaek
Typographe : Marija Tudor
Designer de la couverture : Leslie Haimes

ISBN 9781617297625
Imprimé aux États-Unis d'Amérique
Aux trois femmes de ma vie :
Abigail, Bethany et Charlotte
 table des matières
Préface xv
remerciements xvi
à propos de ce livre  xvii
à propos de l'auteur  xxi

Partie 1 Principaux services Azure...........................1

1 Avant de commencer  3
1.1 Ce livre est-il fait pour vous ?  3
1.2 Comment utiliser ce livre  4
Les principaux chapitres  4    Testez dès maintenant  5 
■

  Ateliers pratiques  5    Code source et documents complémentaires  5

■ ■

1.3 Création de votre environnement de laboratoire  5

Création d’un compte Azure gratuit  5    Exercice pratique bonus :
■

créer un compte GitHub gratuit  7

1.4 Un petit coup de main  8

1.5 Compréhension de la plateforme Windows Azure  8
La virtualisation dans Azure  10    Outils de gestion  12
■

2 Création d'une machine virtuelle  14

2.1 Notions de base de la configuration d'une machine virtuelle  15
Régions et options de disponibilité  15   Images de machine
■

virtuelle 16    Tailles de machines virtuelles 17    Stockage Azure  18 

■ ■

  Mise en réseau virtuelle  19

■

vii
viii table des matières

2.2 Création d’une paire de clés SSH pour l’authentification  20

2.3 Création d'une machine virtuelle à partir de votre navigateur
Web 22
2.4 Connexion à la machine virtuelle et installation du serveur
Web 24
Connexion à la machine virtuelle avec SSH  24    Installation du
■

serveur Web  26
2.5 Comment permettre au trafic Web d'atteindre la machine
virtuelle  28
Création d'une règle autorisant le trafic Web  28    Observation du
■

serveur Web en action 28

2.6 Exercice : création d'une machine virtuelle Windows  29
2.7 Nettoyage des ressources  30
2.8 Houston, nous avons un problème  31

3 Azure Web Apps  33
3.1 Présentation et concepts d'Azure Web Apps  34
Langages et environnements pris en charge  34    Tests
■

des différentes versions grâce aux emplacements de

déploiement 35    Plans de service d'application  35
■

3.2 Création d'une application Web  37

Création d'une application Web de base  37    Déploiement d'un
■

exemple de site HTML  39
3.3 Affichage des journaux de diagnostic  42
3.4 Exercice pratique : création et utilisation d'un emplacement
de déploiement  44

4 Présentation de Stockage Azure 

4.1 Disques gérés  47
47

Disques du système d’exploitation  48    Disques temporaires et

■

disques de données  49    Options de mise en cache du disque  50

■

4.2 Ajout de disques à une machine virtuelle  50

4.3 Stockage Azure  52
Stockage en table  53    Stockage en file
■

d’attente 55    Disponibilité et redondance du stockage  56

■

4.4 Exercice pratique : exploration du stockage dans Azure  57

Pour se concentrer sur les machines virtuelles  57 
  Pour se concentrer sur le développement  57
■

5 Notions de base de la mise en réseau Azure 

5.1 Composants d'un réseau virtuel  58
58
Sous-réseaux et réseaux virtuels  59    Cartes d'interface de réseau
■

virtuel 61    Adresse IP publique et résolution DNS  62

■
 table des matières ix

5.2 Sécurisation et contrôle du trafic avec les groupes de

sécurité réseau  64
Création d'un groupe de sécurité réseau  64    Association d'un
■

groupe de sécurité réseau à un sous-réseau  66    Création de règles

■

de filtrage pour les groupes de sécurité réseau  67

5.3 Création d'un exemple d'application Web avec un trafic
sécurisé 68
Création de connexions réseau d'accès distant  68    Création ■

de machines virtuelles  69    Utilisation de l'agent SSH pour se

■

connecter à vos machines virtuelles  70

5.4 Exercice pratique : installation et test du serveur Web LAMP  72

Partie 2 Haute disponibilité et évolutivité..........73

6 Azure Resource Manager  75
6.1 L'approche Azure Resource Manager  75
Conception tout au long du cycle de vie des applications  76    Sécurisation
■

et contrôle des ressources  78    Protection des ressources à l'aide de

■

verrous 79     Gestion et regroupement des ressources avec des balises  80

■

6.2 Modèles Azure Resource Manager  81

Création et utilisation de modèles  82    Création de plusieurs
■

instances d'un type de ressource  84    Outils permettant de créer vos

■

propres modèles  85    Stockage et utilisation des modèles  87

■

6.3 Laboratoire : déploiement de ressources Azure à partir

d'un modèle  87

7
Haute disponibilité et redondance  90
7.1 Le besoin de redondance  90
7.2 Redondance des infrastructures avec zones de disponibilité  92
Création de ressources réseau dans une zone de disponibilité  94
  Création de machines virtuelles dans une zone de disponibilité  95
■

7.3 Redondance des machines virtuelles avec des groupes à

haute disponibilité  96
Domaines d’erreur  96    Domaines de mise à
■

jour 97    Distribution des machines virtuelles dans un groupe à

■

haute disponibilité  98    Affichage de la distribution des machines

■

virtuelles dans un groupe à haute disponibilité  101

7.4 Exercice pratique : déploiement de machines virtuelles
hautement disponibles à partir d’un modèle  102

8 Applications d'équilibrage de charge  106

8.1 Composants de l'équilibreur de charge Azure  106
Création d'un pool IP front-end  108    Création et configuration
■

de sondes d'intégrité  110    Définition de la distribution du trafic

■

avec des règles d'équilibrage de charge  112    Routage du trafic direct

■
x table des matières

à l'aide de règles de traduction d'adresses réseau  114    Affectation

■

de groupes de machines virtuelles à des pools back-end  116

8.2 Création et configuration de machines virtuelles avec
l'équilibreur de charge  119
8.3 Exercice pratique : consultation de modèles de
déploiements existants  122

9 Des 9.1 applications évolutives  124

Pourquoi créer des applications évolutives, fiables ?  125
Mise à l'échelle des machines virtuelles verticalement  125    Mise à
■

l'échelle des applications Web verticalement  127     Mise à l'échelle

■

des ressources horizontalement  128

9.2 Les VMSS (Virtual Machine Scale Sets)  129
Création d’un VMSS  131    Création de règles de mise à l'échelle
■

automatique 133
9.3 Mise à l'échelle d'une application Web  136
9.4 Exercice pratique : installation d'une application sur un
VMSS ou une application Web  139
Les VMSS (Virtual Machine Scale Sets)  139    Applications Web  140
■

10 Les 10.1 basesQu'est-ce

de données mondiales avec Cosmos DB 
que Cosmos DB ?  141
141

Les bases de données structurées (SQL)  142    Les bases de données

■

non structurées (NoSQL)  142    Mise à l'échelle de bases de

■

données 143    Mise en place avec Cosmos DB  144

■

10.2 Création d'un compte Cosmos DB et d'une base de données  145

Création et alimentation d'une base de données Cosmos DB  145
  Ajout d'une redondance mondiale à une base de données Cosmos DB  149
■

0.3 Accès aux données distribuées mondialement  152

1

10.4 Exercice pratique : déploiement d'une application Web
qui utilise Cosmos DB  156

11 Gestion du trafic réseau et du routage 

11.1 Qu’est-ce qu’Azure DNS ?  158
158

1.2 Délégation d’un domaine réel à Azure DNS  160

1
11.3 Routage mondial et résolution avec Traffic Manager  162
Création de profils sur Traffic Manager  164    Distribution du
■

trafic vers l’instance la plus proche à l’échelle mondiale  167

11.4 Exercice pratique : Déploiement d’application Web pour
voir Traffic Manager à l’œuvre  174
 table des matières xi

12 Surveillance et dépannage  175

12.1 Diagnostics de démarrage des machines virtuelles  175
12.2 Mesures de performances et alertes  178
Consultation des mesures de performances avec l'extension de
diagnostic de machine virtuelle  178    Création d'alertes pour les
■

conditions de performances  181

12.3 Azure Network Watcher  182

Vérification des flux IP  183    Affichage des règles NSG
■

effectives 184    Capture de paquets réseau  186

■

12.4 Exercice pratique : création d'alertes de performances  188

Partie 3 Sécurisation par défaut........................... 189

13 Sauvegarde, récupération et réplication 

13.1 Azure Backup  191
191

Stratégies et conservation  193    Planification des

■

sauvegardes 196     Restauration d'une VM  198

■

3.2 Azure Site Recovery  201

1
13.3 Exercice pratique : configuration d'une VM pour Site
Recovery 204

14 Chiffrement des données  206

14.1 Qu'est-ce que le chiffrement des données ?  206
4.2 Chiffrement au repos  208
1
14.3 Storage Service Encryption  209
14.4 Chiffrement de machine virtuelle  211
Stockage des clés de chiffrement dans Azure Key Vault  211 
  Chiffrement d'une machine virtuelle Azure  213
■

14.5 Exercice pratique : chiffrement d'une machine virtuelle  214

15 Sécurisation des informations avec Azure Key Vault  216

15.1 Sécurisation des informations dans le cloud  216
Coffres avec protection logicielle et modules de sécurité
matérielle 217    Création d'un coffre de clés et d'un secret  219
■

5.2 Identités gérées pour les ressources Azure  221

1
15.3 Obtention d'un secret à partir d'une machine virtuelle
à l'aide d'une identité de service géré  224
15.4 Création et injection de certificats  229
15.5 Exercice pratique : configuration d'un serveur Web sécurisé  232
xii table des matières

16 Azure Security Center et mises à jour 

16.1 Centre de sécurité Azure  234
234

6.2 Accès Juste à temps  237

1
16.3 Azure Update Management  241
Services de gestion Azure associés  243    Consultation et
■

application des mises à jour  245

16.4 Exercice pratique : activation de l'accès JIT et des mises
à jours pour une VM Windows  249

Partie 4 Les technologies vraiment

intéressantes............................................................. 251

17 Machine Learning et intelligence artificielle  253

17.1 Présentation de l'intelligence artificielle (IA) et du
Machine Learning (ML), ainsi que du lien entre les
deux technologies  254
Intelligence artificielle  254    Machine Learning  255
■

Association de l'IA et du Machine Learning  256    Outils Azure■

de Machine Learning pour les data scientists  257

7.2 Azure Cognitive Services  259
1
17.3 Création d'un bot intelligent pour aider les clients
à commander des pizzas  260
Création d'un bot d'application Web Azure  260    Langage ■

et compréhension de l'intention avec LUIS  261    Création et

■

exécution d'un bot d'application Web avec LUIS  264

17.4 Exercice pratique : ajout de canaux de communication
avec un bot  267

18 Azure Automation 269
18.1 Qu'est-ce que Azure Automation ?  269
Création d'un compte Azure Automation  271    Actifs
■

multimédias et procédures opérationnelles Azure Automation  272

18.2 Azure Automation, exemple de procédure opérationnelle  274
Exécution et affichage du résultat à partir d'un exemple de procédure
opérationnelle 276
18.3 PowerShell et configuration d'état souhaité (DSC)  278
Définition et utilisation de PowerShell DSC et d'un serveur
pull Azure Automation  280
18.4 Exercice pratique : utilisation de DSC avec Linux  282

19 Conteneurs Azure  284

19.1 Que sont les conteneurs ?  284
9.2 L'approche microservices des applications  287
1
19.3 Azure Container Instances  289
 table des matières xiii

19.4 Azure Kubernetes Service  293

Création d'un cluster avec Azure Kubernetes service  294
  Exécution d'un site Web de base dans Kubernetes  295
■

19.5 Exercice pratique : mise à l'échelle de vos déploiements

Kubernetes 298

20 Azure et l'Internet des objets  300

20.1 Qu’est-ce que l’Internet des objets ?  300
20.2 Gestion centralisée des appareils avec Azure IoT Hub  303
20.3 Création d'un Raspberry Pi simulé  306
20.4 Streaming de données Azure IoT Hub vers des
applications Web Azure  309
20.5 Examen des composants Azure IoT  315
20.6 Exercice pratique : exploration de cas d'utilisation pour
l'IoT 316

21 Informatique Serverless  317

21.1 Qu’est-ce que l’informatique Serverless ?  317
21.2 Plateformes de messagerie Azure  319
Azure Event Grid  320    Azure Event Hubs et Service Bus  321
■

  Création d’un service bus et intégration de ce service bus à un hub

■

d’IoT 322

21.3 Création d’une application logique Azure  325

21.4 Création d’une application de fonction Azure pour
analyser les données de l’appareil IoT  328
21.5 N'arrêtez pas d'apprendre  332
Matériel didactique supplémentaire  333    Ressources
■

GitHub 333    Un dernier mot  333

■

index 335
 Préface
Cette deuxième édition d'Apprendre Azure en déjeunant me rappelle que tout
évolue rapidement et qu'il est toujours nécessaire d'apprendre. Fini le temps où vous
pouviez suivre un cours d’une semaine au sujet de Windows Server afin de pouvoir
l'utiliser confortablement pendant des années sans rien changer. Le monde informa-
tique n'est pas forcément devenu un endroit effrayant, mais vous devez aborder le
cloud computing avec un esprit ouvert et être prêt à vous adapter constamment.
Lorsque j'ai commencé à travailler avec Azure, il y avait presque trop de services dis-
ponibles. Je savais que je devais m'occuper de la sécurité, de la performance, de la
redondance et de l'évolutivité, mais je ne savais pas comment m'adapter après plus de
dix ans d'expérience en tant qu'administrateur de serveurs dans une structure impor-
tante du domaine cloud computing. Avec le temps, j'ai appris à utiliser les différents
services Azure qui offrent ces composants clés. Ces services fonctionnent rarement de
façon autonome, mais je ne connaissais pas la meilleure façon de les intégrer, et je ne
savais pas quel service utiliser pour chaque tâche. J'ai écrit ce livre comme si j'expliquais
à moi-même à cette période, et aux nombreuses autres personnes qui ont vécues la
même expérience, comment comprendre rapidement le fonctionnement des princi-
paux services Azure et comment les utiliser conjointement.
Ce livre fait plus de 350 pages, et pourtant il ne vous offre qu'un aperçu de ce que
vous pouvez faire avec Azure ! Pour vous offrir des connaissances solides sur les con-
cepts nécessaires à la conception de solutions réussies dans Azure, j'ai dû opérer une
sélection des sujets abordés. Ce livre ne parle pas des plus de 100 services disponibles
dans Azure et ne prétend pas détailler de façon exhaustive ceux qui sont abordés. Il se
concentre sur les principes fondamentaux de certains des services clés, propose des
exemples illustrant la manière de connecter les différents éléments de façon sécurisée,
et présente les possibilités de conception offertes par Azure.
Le cloud computing est en constante évolution. Pas de cycles de sortie de trois/qua-
tre ans, ni de vastes déploiements de mises à jour. Je crois que c'est le moment idéal
pour commencer à concevoir des solutions et à écrire du code. Les occasions d'appren-
dre quelque chose et de s'améliorer ne manquent jamais. Je vous souhaite d'apprendre
à exécuter de supers applications dans Azure, et j'espère que vous apprécierez de
découvrir les services disponibles.

xv
 remerciements
De nombreuses personnes chez Manning Publications ont contribué à la publication
de cet ouvrage. Je remercie en particulier Mike Stephens pour m'avoir poussé à démar-
rer ce projet. Merci à mon éditeur Marjan Bace, à toute l'équipe éditoriale et à toute
l'équipe de production. Je remercie également les relecteurs techniques dirigés par
Aleksandar Dragosav- ljevic´—Ariel Gamino, Charles Lam, Ernesto Cardenas Canga-
huala, George Onofrei, Glen Thompson, Jose Apablaza, Juraj Borza, Michael Lang-
don, Michael Wall, Peter Kreyenhop, Rick Oller, Rob Ruetsch, Robert Walsh, et Vishal
Singh. Enfin, côté technique, merci à Karsten Strøbaek, qui a assumé les rôles de
rédacteur en chef technique et de relecteur.
Pour cette deuxième édition, je remercie grandement Phil Evans et Davanand Bahall
pour leur soutien et la liberté qu'ils m'ont offert pour mettre ce livre à jour. J'ai mené ce
projet en dehors de mes heures de travail chez Microsoft, et j'ai apprécié l'enthousi-
asme et l'implication de nombreuses personnes. Merci e ncore à David Tolkov et à Tim
Teebken, qui m'ont offert les occasions grâce auxquelles j'ai pu devenir la personne qui
a écrit cet ouvrage. Et d'ailleurs, Jean-Paul Connock, nous avons gagné une coupe Stan-
ley depuis la dernière fois !  
Merci à Rick Claus pour m'avoir fourni la solide documentation technique néces-
saire sur Azure, et à Marsh Macy et Neil Peterson pour leur soutien personnel et les
conseils qu'ils m'ont apportés lors de la rédaction de la version originale de cet ouvrage.
Nous devons toutefois travailler sur le fameux bus scolaire.

xvi
 À propos de ce livre
Ce livre est conçu pour vous offrir une solide base de connaissances qui vous permettra
de mener à bien vos projets Azure en tant qu'ingénieur ou développeur IT. Vous
découvrirez les solutions Infrastructure as a Service (IaaS) et Plat
form as a Service (PaaS), et saurez quand utiliser chacune de ces deux approches.
À mesure que vous avancerez dans les chapitres, vous apprendrez à dresser des plans
adéquats pour la disponibilité et l'évolutivité sans compromettre la sécurité, et sans
perdre de vue les contraintes de coûts et de performances. Quand vous aurez terminé
le livre, vous devriez être capable d'intégrer les technologies d'avenir telles que les con-
teneurs et Kubernetes, l'intelligence artificielle et le Machine Learning (AI + ML),
et l'Internet des objets (IoT).
En ce qui concerne la conception et l'exécution de vos applications et services, Azure
vous laisse le choix du système d'exploitation, des outils d'application et de la plate-
forme. Vous pouvez choisir ceux qui vous conviennent le mieux. Ce livre aborde princi-
palement les technologies non-Microsoft telles que Linux, Python et node.js. Les
exemples de commandes s'appliquent à la CLI Azure, et non à Azure PowerShell. C'est
un choix délibéré, pour vous montrer que vous pouvez utiliser Azure sans adopter Win-
dows Server, IIS ou ASP.NET.
Travailler dans le cloud implique souvent de s'adapter à différentes plateformes
et   d'apprendre de nouvelles façons de procéder. C'est une autre des raisons pour
lesquelles j'ai choisi de présenter des technologies et des plateformes non-Microsoft.
Je  voulais vous présenter ces nouveaux univers avant que vous ne les rencontriez en
production. Tout au long de ce livre, je vous enseigne les concepts et les étapes néces-
saires à l'intégration de services Azure de façon que vous puissiez jongler à l'envi entre
les plateformes et les langages, sans avoir à tout réapprendre.

xvii
xviii À propos de
 ce livre

Feuille de route
Le livre est organisé en 4 parties et 21 chapitres :
¡ La partie  1 aborde certains des services d'infrastructure et de plateforme clés
d'Azure : mac hines virtuelles, applications Web, stockage et mise en réseau.
¡ Dans la partie 2, vous découvrirez comment mettre en place la haute disponibilité
et la redondance : modèles, ensembles et zones de disponibilité, équilibreurs de
charge, mise à l'échelle automatique, bases de données distribuées et routage de
trafic. À la fin du chapitre 12, vous devriez disposer de connaissances solides qui
vous permettront de concevoir des applications hautes performances et dis-
tribuées dans Azure.
¡ La partie 3 couvre les aspects liés à la sécurité tels que la sauvegarde et la récupéra-
tion, le chiffrement, la gestion des clés numériques et les mises à jour. Une fois
que vous aurez terminé le chapitre 16, vous aurez toutes les cartes en main pour
offrir des applications Azure stables et sécurisées.
¡ Enfin, dans la partie 4, nous pourrons nous amuser un peu en explorant de nou-
veaux aspects de l'informatique comme l'informatique Serverless et les applica-
tions conteneurisées. Ces chapitres présentent des domaines d'Azure qui vous
donnent un aperçu de ce à quoi l'avenir des applications de production pourrait
ressembler.
Sauf pour la partie  4 (qui porte le titre fort à propos «  Les technologies vraiment
intéressantes »), essayez de lire les chapitres dans l'ordre. D'un chapitre à l'autre, vous
ne travaillerez pas sur le même projet, mais chacun d'entre eux s'appuie sur les con-
naissances théoriques et les exemples pratiques des précédents.
Le chapitre  1 vous guide lors de la création d'un compte d'essai gratuit
dans Azure. Ce compte vous permet d'effectuer tous les exercices pratiques
proposés dans les chapitres. Tout au long du livre, vous trouverez également
des informations plus générales sur Azure, ainsi que des ressources qui vous
permettront de vous renseigner plus avant. Je mentionne cette page Web plusieurs
fois dans l'ouvrage (je ne suis peut-être pas le mieux placé pour être objectif), mais
je crois que http://docs.microsoft.com/azure est le meilleur endroit pour vous
documenter sur Azure de façon générale, ainsi que sur les domaines spécifiques
qui vous intéressent.

À propos des exemples et des codes source

Ce livre contient de nombreux exemples de code source, aussi bien dans des extraits
numérotés qu'intégrés aux phrases. Dans les deux cas, le code source est signalé par
une police à chasse fixe comme ceci pour le distinguer du reste du texte.
Nous avons modifié le code source d'origine dans de nombreux cas : en ajoutant des
sauts de ligne et en réorganisant l'indentation pour l'adapter à l'espace disponible dans les
pages du livre. Dans de rares cas, cela ne suffisait pas, et les extraits de code contiennent des
marqueurs de continuation de ligne (➥). Par ailleurs, dans les extraits, nous avons sup-
primé les commentaires du code source lorsque le code était expliqué dans le texte.
De nombreux extraits de code sont annotés pour insister sur les concepts importants.
Le code source de ce livre, ainsi que les scripts d’accompagnement, les modèles et les
ressources d’ aide, sont disponibles à l'adresse https://www.manning.com/books/
learn-azure-in-a-month-of-lunches-second-edition et dans le référentiel GitHub du livre
(https://github.com/fouldsy/azure-mol-samples-2nd-ed).
 À proposde ce livre xix

Tous les exercices pratiques peuvent être réalisés dans le portail Azure et avec Azure
Cloud Shell, un shell interactif en navigateur pour la CLI Azure et Azure PowerShell.
Vous n'avez aucun outil à installer sur votre poste, et vous pouvez utiliser n'importe quel
ordinateur sous n'importe quel système d'exploitation, à partir du moment où il est
équipé d'un navigateur Web moderne.
Des modifications mineures sont souvent apportées au portail Azure. Ce qui peut
être difficile lorsqu'on utilise un service Cloud, c'est que les choses peuvent variées d'un
jour à l'autre.
Cette deuxième édition tente de minimiser les captures d'écran du portail, mais ne
vous inquiétez pas si ce que vous voyez à l'écran est un peu différent. Les paramètres
proposés sont généralement identiques. Seule la mise en page peut varier. Si vous êtes
invité à sélectionner des options que je n'ai pas évoquées dans un exercice, générale-
ment, vous pouvez accepter sans risque les paramètres par défaut proposés.
Si vous travaillez en dehors d'Azure Cloud Shell, attention avec les exemples de com-
mandes fournis. Les shells Windows, comme PowerShell et CMD, ne traitent pas les
sauts de ligne et les caractères de continua tion de ligne de la même manière que les
shells de type *nix comme Azure Cloud Shell. Plusieurs commandes fournies à titre
d'exemple sont réparties sur plus d'une ligne. La barre oblique inverse (\) indique que
la commande continue à la ligne suivante, comme dans cet exemple :
az resource group create \
--name azuremol \
--location eastus

Vous n'êtes pas obligé d'utiliser ces barres obliques inverses, mais elles facilitent la lec-
ture des longues commandes à l'écran. Si vous choisissez de travailler en local sur votre
ordinateur avec un shell Windows, vous pouvez utiliser un accent grave (`) à la place
de la barre oblique inverse. Dans un shell Power- Shell ou CMD dans lequel vous avez
installé Python pour Windows, modifiez par exemple la commande précédente
comme ceci :
az resource group create `
--name azuremol `
--location eastus

Cela peut sembler déstabilisant, mais j'ai suivi cette convention parce que la documen-
tation officielle disponible sur https://docs.microsoft.com/azure utilise ce format.
Les commandes de la CLI Azure, utilisées dans ce livre, doivent être saisies dans un
shell de type *nix et utilisent donc une barre oblique inverse. Les commandes
Azure PowerShell doivent être saisies dans un shell de type Windows et utilisent donc
un accent grave. Vous vous ferez vite à cette différence de comportement, et pourrez
facilement jongler entre ces deux shells. Si vous n'avez pas encore l'habitude de passer
d'une plateforme à une autre, ce sera une victoire à célébrer.
Je vous recommande de consulter Windows Subsystem for Linux (WSL) si vous
exécutez Windows 10 et si vous souhaitez en savoir plus sur les systèmes basés sur CLI
Azure et *nix. Consultez https://docs.microsoft.com/windows/wsl pour obtenir
davantage d'informations. WSL et les dernières améliorations apportées à WSL2 vous
offrent une expérience native du noyau Linux, tout en exécutant Windows. Ne vous en
faites pas trop à ce sujet  ! Il vous suffit de savoir que vous pouvez exécuter des
xx À proposde ce livre

commandes et des applications Linux natives sans vous soucier des différ ents sauts de
ligne ou définitions de variables. Pour vous couper le souffle, PowerShell est dispo
nible pour .NET Core, qui s’exécute également sur Linux. Vous pouvez exécuter Pow-
erShell sous Linux tout en étant sur Windows.

Forum de discussion liveBook

L'achat du livre Apprenez Azure en déjeunant ! vous octroie un accès gratuit à un forum
Web de Manning Publications. Vous pouvez donner vos avis sur l'ouvrage, poser des
questions techniques et demander l'aide de l'auteur et des autres utilisateurs. Pour
accéder au forum, cliquez sur https://livebook.manning.com/book/learn-azure-in-a-
month-of-lunches-second-edition/discussion. Pour en savoir plus sur les forums de
Manning et leurs règles de conduite, consultez https://livebook.manning.com/
discussion.
L'objectif de Manning est d'offrir à ses lecteurs un lieu dans lequel ils peuvent dia-
loguer de façon constructive, entre eux et avec l'auteur. Manning ne s'engage aucune-
ment à un quelconque niveau de participation de la part de l'auteur. Sa contribution au
forum repose sur la base du volontariat (et du bénévolat). Nous vous suggérons d'es-
sayer de lui poser des questions difficiles, pour susciter son intérêt  ! Tant que cet
ouvrage sera imprimé, le forum et les archives des discussions précédentes resteront
accessibles sur le site Web de l'éditeur.
 À propos de l'auteur
IAIN FOULDS est développeur de contenus senior chez Microsoft. Il rédige actuelle-
ment la documentation technique d'Azure Active Directory. Auparavant, il était
ingénieur de terrain responsable pour les technologies de virtualisation Microsoft,
telles qu'Azure, Hyper-V et System Center Virtual Machine Manager. Avec plus de
15 ans d'expérience en informatique, la plupart dans les opérations et les services, il a
commencé très tôt dans la virtualisation avec VMware, et contribue depuis plusieurs
années à l'amélioration et à l'adoption du cloud computing.
Originaire d'Angleterre, il vit aux États-Unis depuis plus d'un dix ans, et réside actu-
ellement en périphérie de Seattle avec sa femme et ses deux jeunes enfants, à qui il
dédie ce livre. Il est amateur de football (malheureusement appelé « soccer » dans sa
région) et apprécie également le hockey sur glace ainsi toutes sortes (ou presque) de
compétitions motorisée. En dehors de l'informatique, Iain Foulds s'intéresse aux voi-
tures de sport et classiques et à la photogra phie d'aviation. Et il joue même de la gui-
tare. Enfin, c'est un amoureux du modélisme ferroviaire. Il assiste et participe
régulièrement à des conventions sur la côte Nord-Ouest du Pacifique.

xxi
 Partie 1

Principaux services Azure

P our développer votre prochaine application d'excellence, vous avez besoin

d’une connaissance approfondie des ressources de base dans Azure. Le stockage
et la mise en réseau ne sont peut-être pas les aspects les plus agréables à prendre
en compte, mais ils sont indispensables à la plupart des opérations menées dans
Azure. Avant de pouvoir aborder les ordinateurs virtuels redondants ou des
applications Web Azure multi-instances, il est utile de connaître les options et les
tâches de gestion disponibles pour une seule instance. Cela vous permet d’en
apprendre davantage sur les différences et les similitudes entre l’approche IaaS
des machines virtuelles et l’approche PaaS des applications Web. Dans les
chapitres 1 à 5, nous explorerons les machines virtuelles et les applications Web,
ainsi que les principales fonctionnalités associées au stockage et aux réseaux
virtuels.
 Avant de commencer

1
Azure est l'un des plus grands fournisseurs de cloud computing public pour les
services tels que les machines virtuelles (VM), les conteneurs, l'informatique Serverless
et le Machine Learning. Nous n'allons pas analyser en détail les quelque 100 services
Azure présentés dans ce livre. En revanche, vous allez enrichir vos connaissances sur
les fonctions et les services de base qui couvrent l'essentiel de ce dont vous avez besoin
pour commencer à développer et exécuter des solutions dans Azure. Nous allons
étudier un exemple type de la manière de développer et d’exécuter une application
Web. Vous verrez également comment utiliser certains services de plateforme et
d’infrastructure de base susceptibles de simplifier votre travail.
Avec Azure, nul besoin d’une baguette magique pour prévoir le nombre de
serveurs ou le volume de stockage dont vous aurez besoin au cours des trois
prochaines années. Ne perdez plus de temps à attendre l’approbation du budget,
attendre l’expédition du nouveau matériel, pour ensuite l'installer et tout configurer.
Lors de la rédaction de votre code, vous n’avez pas à vous préoccuper de savoir
quelles bibliothèques ou quelles versions logicielles sont installées.
Il vous suffit de sélectionner un bouton pour créer toutes les ressources requises.
Vous ne payez rigoureusement que pour la stricte durée d'exploitation de ces
ressources ou pour le volume de stockage ou de bande passante réseau utilisé.
Lorsque vous n’avez plus besoin des ressources, vous pouvez les désactiver ou les
supprimer. Si vous avez soudainement besoin de multiplier par 10 la puissance de
calcul, sélectionnez un bouton, attendez quelques minutes, et le tour est joué. Et tout
cela est géré par quelqu’un d’autre, ce qui vous laisse libre de vous concentrer sur
vos applications et vos clients.

1.1 Ce livre est-il fait pour vous ?

L’industrie de l’informatique connaît une période de transition pour ce qui concerne
les intitulés de postes. Vous pouvez vous désigner informaticien, développeur de
logiciels, administrateur système ou ingénieur DevOps. Quel que soit votre rôle,
si  vous voulez acquérir les compétences de base nécessaires pour développer et
exécuter des applications sécurisées et hautement disponibles dans le cloud,
3
4 Chapitre 1  Avant de commencer

vous êtes au bon endroit. En termes génériques, vous êtes probablement soit du côté
opérationnel informatique, soit du côté développement. En réalité, il existe beaucoup
de recoupements entre les deux, surtout lorsque vous travaillez dans le cloud computing.
Que vous travailliez du côté développement ou opérationnel, il est important de
comprendre les services d'infrastructure et de plateforme de base, pour développer et
exécuter des applications qui répondent le mieux aux exigences de vos clients.
Cette seconde édition présente certains de ces concepts de base dans Azure en vous
permettant d'acquérir les compétences nécessaires pour prendre des décisions
éclairées. Pour commencer la lecture de ce livre, vous devez posséder une expérience
préalable dans le domaine des machines virtuelles et connaître les bases de la mise en
réseau et du stockage. Vous devez également être capable de créer un site Web basique
et savoir ce qu’est un certificat SSL ou une base de données. Une fois les processus de
base couverts, nous aborderons succinctement les technologies nouvelles et à venir.
Pour garder une longueur d’avance sur le plan professionnel, vous devrez maîtriser les
concepts des conteneurs, de l’Internet des objets, du Machine Learning, de
l’intelligence artificielle et de l’informatique Serverless. Que vous vous définissiez
comme développeur ou professionnel de l'informatique, vous devriez trouver quelques
nouveaux domaines intéressants à explorer !

1.2 Comment utiliser ce livre

J’aime manger sur le pouce ; le déjeuner est donc pour moi le moment idéal pour
découvrir de nouvelles technologies sympas. Vous êtes peut-être du genre couche-tard
ou du genre lève-tôt (qu’est-ce qui ne va pas chez vous ?!) et pouvez donc toujours
trouver un peu de temps le soir ou le matin respectivement pour parcourir un chapitre.
Il n’y a pas de bon ou de mauvais moment pour apprendre, mais si vous pouvez y
consacrer environ 45 minutes, vous devriez être en mesure de lire un chapitre et de
mener à bien les exercices qu'il propose. Chaque chapitre couvre un nouveau sujet,
alors donnez-vous le temps d’absorber chaque leçon quotidienne.

1.2.1 Principaux chapitres

Le livre est divisé en quatre  parties, ce qui est judicieux quand on considère qu'un
mois compte quatre semaines :
¡ La partie  1 (chapitres 1  à  5) couvre certaines des ressources de base d’Azure.
Au minimum, essayez d’étudier ces chapitres dans l’ordre afin d’en dégager une
bonne compréhension. Vous pouvez ensuite vous concentrer sur les autres
chapitres qui vous intéressent le plus.
¡ La partie 2 (chapitres 6 à 12) couvre la disponibilité et l’échelle. Vous découvrirez
comment dimensionner automatiquement les ressources internes et externes,
équilibrer les charges de trafic et gérer les événements de maintenance sans
occasionner de temps d’arrêt. Si vous souhaitez en savoir plus sur l’exécution
d’applications hautement disponibles à l’échelle mondiale, cette partie est pour vous.
¡ La partie 3 (chapitres 13 à 16) est pour les mordus de la sécurité. Elle traite des
aspects tels que la façon de crypter les machines virtuelles, de stocker des
certificats  SSL dans un coffre-fort sécurisé, ou encore de sauvegarder et de
restaurer vos données.
¡ La partie 4 (chapitres 17 à 21) couvre un mélange de domaines sympas donnant
un avant-goût de ce qu'Azure peut faire pour vous et vos clients. Nous examinerons
l’automatisation, les conteneurs, l’Internet des objets et l’informatique Serverless.
Choisissez un sujet qui vous intéresse et amusez-vous !
 Création de votre environnement de laboratoire 5

1.2.2 Tester
Voulez-vous simplement prendre connaissance du contenu ou souhaitez-vous vous
retrousser les manches et expérimenter Azure ? Tout au long du livre, vous découvrirez
des petites tâches qui vous permettent d'expérimenter rapidement de nouvelles
connaissances. Si vous en avez le temps, essayez-les. La plupart des manipulations
s'inscrivent dans un exercice pratique à la fin du chapitre, mais il est également
intéressant d'interrompre la lecture pour tester de nouveaux concepts en cours de
route. Certains de ces exercices vous guideront étape par étape, tandis que d'autres
vous feront réfléchir un peu plus, en vous apprenant à créer des solutions par vous-
même, comme vous le feriez dans la vraie vie.

1.2.3 Ateliers pratiques

Chaque chapitre se termine par un exercice pratique. Certains chapitres, comme
celui-ci, comportent en leur milieu un exercice pratique. Ces exercices pratiques sont
l'occasion de voir comment s'assemblent toutes les pièces d’Azure et vous permettent
d'exercer votre cerveau et votre mémoire. Prenez votre clavier, votre souris et
commencez à développer quelque chose de génial !

1.2.4 Code source et documents complémentaires

Le code source de ce livre, ainsi que les scripts d’accompagnement, les modèles et les
ressources d’aide, sont disponibles à l'adresse https://www.manning.com/books/
learn-azure-in-a-month-of-lunches-second-edition et dans le référentiel GitHub du
livre à l'adresse https://github.com/fouldsy/azure-mol-samples-2nd-ed. En outre,
vous pouvez participer au forum du livre à l’adresse https://livebook.manning.com/
book/learn-azure-in-a-month-of-lunches-second-edition/discussion.

1.3 Création de votre environnement de laboratoire

Ce livre ne s’appesantit pas sur les concepts et l’architecture, il se concentre surtout
sur la pratique avec la plate-forme Azure. Pour réaliser ces exercices, vous avez besoin
d’un compte Azure.

1.3.1 Création d’un compte Azure gratuit

Azure propose un compte d’essai gratuit valable 30 jours et jusqu’à 200 USD de crédit
gratuit. Ce crédit gratuit devrait être suffisant pour venir à bout de tous les chapitres et
exercices, avec même de la marge pour prolonger l'exploration et vous amuser au
passage ! De nombreux services et fonctionnalités Azure restent gratuits même après la
fin de la période d’essai.

Tester
Suivez les étapes de cette section pour créer votre compte gratuit Azure :

1 Ouvrez votre navigateur Web à l'adresse https://azure.microsoft.com/freeet

choisissez l’option qui vous permet de démarrer avec un compte Azure gratuit.
2 Connectez-vous à votre compte Microsoft lorsque vous y êtes invité. Si vous avez
besoin d’un compte Microsoft ou si vous souhaitez en créer un nouveau,
choisissez le lien Créer un compte Microsoft.
3 Une fois connecté à un compte Microsoft, suivez les instructions pour créer un
compte gratuit Azure :
6 Chapitre 1  Avant de commencer

¡ Saisissez vos données personnelles.

¡ Pour aider à minimiser les abus et la fraude, fournissez un numéro de
téléphone permettant de vérifier votre identité via un SMS ou un appel
téléphonique.
¡ Une carte de crédit est également nécessaire aux fins de la vérification
d’identité, mais aucun prélèvement n'a lieu à ce stade. Votre compte n’est
facturé qu’après 30 jours ou si vous dépassez votre crédit gratuit de 200 USD.
À  la fin de votre essai, vous n'évoluerez pas automatiquement vers un
abonnement de paiement à l’utilisation. Une petite somme d'un  USD (ou
l'équivalent en monnaie locale) est susceptible d'être prélevée à titre
de  vérification, mais elle vous sera remboursée quelques jours plus tard.
4 Lisez et acceptez le contrat d’abonnement Azure et la déclaration de
confidentialité, puis cliquez sur S’inscrire. Cela peut prendre quelques minutes
avant que votre abonnement ne soit effectif.
5 Une fois le processus d’inscription terminé et le portail Azure chargé, faites un
tour d’horizon rapide pour prendre vos marques.
Votre tableau de bord (la page d’accueil du portail) semble vide pour le moment. Mais
dans le chapitre 2, vous allez vous plonger dans la création de votre première machine
virtuelle et le tableau de bord va commencer à s'apparenter à celui de la figure 1.1.

Figure 1.1  Le portail Azure est prêt à vous aider à créer vos propres applications et solutions
 Création de votre environnement de laboratoire 7

Est-ce bel et bien gratuit ?

Azure propose un Marketplace qui contient des centaines d’images (la base
des VM) et de solutions prêtes à l’emploi que vous pouvez déployer. Nous utilisons
certaines offres de ce Marketplace tout au long du livre et c’est un excellent moyen
de déployer rapidement une suite d’applications entière.
Toutes les offres du Marketplace Azure ne sont pas gratuites : certains éditeurs tiers
affectent des coûts de licence ou de support à la solution que vous déployez. Une
machine virtuelle que vous déployez à partir de Red Hat peut par exemple engager des
frais supplémentaires qui couvrent le contrat de maintenance et la licence de Red Hat.
Ces frais ne sont pas couverts par votre crédit d’essai gratuit ; seule l’utilisation de la
machine virtuelle de base est couverte.
Les exercices dans ce livre n’utilisent que des ressources qui font partie de l’essai
gratuit. Mais si vous partez explorer d’autres offres de marché intéressantes dans Azure,
faites attention à ce que vous développez. Toute solution qui inclut des frais
supplémentaires doit clairement l’annoncer avant que vous ne la déployiez !

1.3.2 Exercice pratique bonus : création d'un compte GitHub gratuit

GitHub est un service Web gratuit que beaucoup d’organisations et d’individus
utilisent pour gérer des projets impliquant du code, des modèles et de la
documentation. Azure propose des centaines de modèles gratuits et d’exemples de
script que vous pouvez utiliser et auxquels vous pouvez contribuer. C’est l’un des points
forts de la communauté open source : partager et redonner aux autres.
Certains des exercices de ce livre utilisent des ressources de GitHub. Vous n’avez pas
besoin d’un compte GitHub pour réaliser ces exercices mais, faute de disposer d'un tel
compte, vous ne serez pas en mesure d’enregistrer toutes les modifications, ni de
commencer à construire votre propre collection de modèles et de scripts. La création
d’un compte GitHub est une partie facultative de la construction de votre
environnement de pratique, mais elle est fortement recommandée :

1 Ouvrez votre navigateur Web à l'adresse https://github.com.

2 Pour créer un compte GitHub gratuit, fournissez un nom d’utilisateur,
une adresse e-mail et un mot de passe. Vous recevrez un message de validation
de GitHub.
3 Cliquez sur le lien dans l’e-mail de validation pour activer votre compte.
4 Découvrez certains référentiels d’Azure fournissant des exemples de ressources :
¡ Modèles rapides Azure—https://github.com/Azure/azure-quickstart-templates
¡ CLI Azure—https://github.com/Azure/azure-cli
¡ utilitaires DevOps d’Azure—https://github.com/Azure/azure-devops-utils
¡ Ressources du livre Apprenez azure en déjeunant  ! —https://github.com/
fouldsy/azure-mol-samples-2nd-ed
8 Chapitre 1  Avant de commencer

1.4 Un petit coup de main

Ce livre ne peut pas couvrir tout ce qu’offre Azure. Il y a fort à parier que le temps que
vous lisiez ce chapitre, une nouveauté aura été apportée à Azure ! Le cloud computing
évolue rapidement. Ainsi, de nouveaux services et fonctionnalités sont sans cesse
publiés. Je ne suis peut-être pas tout à fait objectif, mais comme vous commencez à
découvrir Azure et que vous voulez en savoir plus sur les services complémentaires,
l’excellent site https://docs.microsoft.com/azure est le meilleur point de départ.
Chaque service Azure y est documenté avec des exemples de démarrage rapide, des
tutoriels, des exemples de code, des références pour les développeurs et des guides
d’architecture. Vous pouvez également accéder à des options de support gratuites
et  payantes si vous avez besoin d’aide en cours de route.

1.5 Compréhension de la plateforme Windows Azure

Avant d’aller plus loin, prenons un peu de recul et essayons de comprendre ce qu’est
Azure et ce que sont les services proposés. Comme je l'ai mentionné précédemment,
Azure est un fournisseur de cloud computing à l'échelle mondiale. À l’heure actuelle,
il existe 54  régions Azure. Chaque région contient au moins un datacenter.
En  comparaison, les deux  autres principaux fournisseurs de cloud opèrent dans
23 régions (Amazon Web Services [AWS]) et 20 régions (Google Cloud).
Le cloud computing offre bien plus que des ressources de calcul. Azure
propose plus  de 100 services, regroupés dans des familles de services connexes : calcul,
web + mobile, conteneurs et identité. Avec tous ces services, Azure couvre de nombreux
modèles de services. Prenons une part de pizza pour le déjeuner afin de comprendre ce
que cela signifie (figure 1.2).

Fait maison Prête à cuire Livraison à domicile Restaurant

Table à manger Table à manger Table à manger Table à manger

Boissons Boissons Boissons Boissons

Four Four Four Four

Cuisson Cuisson Cuisson Cuisson

Pâte à pizza Pâte à pizza Pâte à pizza Pâte à pizza

Sauce tomate Sauce tomate Sauce tomate Sauce tomate

Garnitures Garnitures Garnitures Garnitures

Sauce Sauce Sauce Sauce

Vous gérez Géré par le fournisseur

Figure 1.2  Modèle Pizza as a Service. Lorsque vous passez d’un modèle de pizza faite maison, où vous
fournissez tout, à un modèle de pizza en restaurant, où vous avez juste à mettre les pieds sous la table,
les responsabilités et les exigences de gestion changent en conséquence.

Dans le modèle Pizza as a Service, quatre options vous sont proposées. Plus on avance
dans les modèles, moins on se préoccupe du processus de manger une part de pizza :
 Compréhension de la plateforme Windows Azure 9

¡ Fait maison : vous devez faire la pâte ; ajouter la sauce, les garnitures et le fromage ;
faire cuire la pizza dans votre four ; sortir des boissons ; et vous attabler pour manger.
¡ Prête à cuire : vous achetez une pizza préparée. Vous avez juste besoin de la faire
cuire dans votre four, de sortir des boissons et de vous attabler pour manger.
¡ Livraison à domicile : vous commandez une pizza livrée à domicile. Vous avez juste
besoin sortir des boissons et de vous attabler pour manger.
¡ Restaurant : vous voulez sortir et déguster une pizza avec un minimum d’effort !
Maintenant que vous avez faim, observons le modèle plus traditionnel qui implique
quelques ressources de calcul (figure 1.3). Ce modèle s'apparente un peu plus à que
vous pouvez voir dans Azure.

Geson classique Infrastructure en Plateforme en tant Logiciel en tant

sur site tant que service (IaaS) que service (PaaS) que service (SaaS)

Applications Applications Applications Applications

Données Données Données Données

Intergiciel Intergiciel Intergiciel Intergiciel

Système Système Système Système

d’exploitation d’exploitation d’exploitation d’exploitation

Virtualisation Virtualisation Virtualisation Virtualisation

Serveurs Serveurs Serveurs Serveurs

Stockage Stockage Stockage Stockage

Réseau Réseau Réseau Réseau

Vous gérez Géré par le fournisseur

Figure 1.3  Modèle de service de cloud computing

Au fur et à mesure que vous progressez dans les modèles, vous gérez moins de ressources
sous-jacentes et pouvez concentrer davantage de temps et d’énergie à vos clients :
¡ Sur site : vous configurez et gérez l’ensemble du datacenter, dont, par exemple, les
câbles réseau, le stockage et les serveurs. Vous êtes responsable de toutes les
composantes de l’environnement d’application, de la maintenance et de la
redondance. Cette approche confère un contrôle maximum, mais génère une
importante surcharge de gestion.
¡ Infrastructure en tant que service (IaaS) : vous achetez les ressources de calcul de base
auprès d’un fournisseur qui gère l’infrastructure essentielle. Vous créez et gérez
les machines virtuelles, les données et les applications. Le fournisseur de cloud
est responsable de l’infrastructure physique, de la gestion de l’hôte et de la
résilience. Vous pouvez toujours avoir une équipe d'infrastructure pour sous-
tendre l'assistance et le déploiement des machines virtuelles, mais elle s'affranchit
du temps et des coûts de gestion de l'équipement physique.
10 Chapitre 1  Avant de commencer

Cette approche convient lorsque vous commencez à déplacer des applications

hors de votre propre environnement sur site. La gestion et les opérations sont
souvent similaires à un environnement sur site. L’IaaS constitue donc une
évolution naturelle qui permet à l’entreprise, à l’équipe informatique et aux
propriétaires d’applications d’apprivoiser le cloud.
¡ Plateforme en tant que service (PaaS) : vous achetez la plateforme sous-jacente auprès
d'un fournisseur qui gère le système d'exploitation ainsi que les correctifs et qui
met à disposition vos applications et vos données. Vous ne vous préoccupez pas des
machines virtuelles ni du réseau virtuel et votre équipe opérationnelle peut passer
plus de temps à se concentrer sur la fiabilité et la performance des applications.
Cette approche marque souvent le début de l’organisation informatique et
l’entreprise devient à l’aise avec l’exécution des applications dans le cloud. Vous
vous concentrez sur les applications et vos clients, en vous préoccupant moins de
la capacité de l’infrastructure à exécuter ces applications.
¡ Logiciel en tant que service (SaaS) : vous avez juste besoin d’accéder au logiciel, un
fournisseur pourvoyant au reste. Les développeurs peuvent s’appuyer sur une
plateforme existante pour fournir des personnalisations ou des fonctionnalités
uniques, sans avoir à maintenir une base de code volumineuse.
Cette approche est souvent intimidante au début, mais vous connaissez et
utilisez probablement déjà une offre SaaS qui a fait ses preuves telles que
Salesforce, Office 365, ou la suite Google Mail ou Docs. Vous utilisez la messagerie
électronique, créez des documents ou des présentations, ou bien gérez les
informations de contact client et les informations commerciales. Vous vous
concentrez sur le contenu que vous créez et gérez, et non sur la façon de faire
fonctionner l’application.
La plupart de ce que vous créez dans Azure relève du domaine de l’IaaS et de la PaaS.
Les principaux cas d’utilisation comprennent les machines virtuelles et la mise en
réseau virtuelle (IaaS), ou les applications Web Azure, les fonctions et les services
Cosmos DB (PaaS). Si vous êtes un développeur, les solutions de PaaS sont
probablement les domaines qui vous intéressent le plus, car Microsoft gère la partie
infrastructure pour vous permettre de vous concentrer sur le code. Les informaticiens
peuvent se pencher davantage sur les solutions d’IaaS pour élaborer et contrôler
l’infrastructure Azure.

Ne jamais cesser d’apprendre

N’oubliez pas que même si une entreprise passe du modèle IaaS au modèle de PaaS, les
informaticiens restent un atout ! Il est important de comprendre ce qui se passe derrière
le PaaS lorsque vous concevez ou dépannez une solution. Si vous êtes un informaticien,
n'omettez pas les chapitres sur les solutions PaaS dans Azure. Le fait de bien
comprendre la transition vers ce modèle de déploiement peut en effet vous permettre
d'apporter beaucoup à votre entreprise et à vos clients.

1.5.1 La virtualisation dans Azure

La virtualisation est ce qui rend Azure si extraordinaire. Les services des modèles IaaS,
PaaS et SaaS reposent sur la virtualisation. Le concept de virtualisation n’a rien de
nouveau : il remonte à l’ordinateur central des années 1960. Au milieu des années 2000,
la virtualisation de serveur dans le datacenter a commencé à prendre de l’essor et,
à l’heure actuelle, seules quelques charges de travail sont déployées sur des serveurs
physiques plutôt que d’être virtualisées.
 Compréhension de la plateforme Windows Azure 11

Des livres entiers sont consacrés à la virtualisation, mais pour être bref  : la
virtualisation divise logiquement les ressources physiques d’un serveur en ressources
virtuelles qui peuvent être accessibles en toute sécurité par des charges de travail
individuelles. Une machine virtuelle est l’une des ressources les plus courantes du
cloud computing. Une machine virtuelle contient une unité centrale virtuelle (vCPU),
une mémoire virtuelle (vRAM), un système de stockage virtuel (vDisk), et une
connectivité réseau virtuelle (vNIC), comme illustré à la figure 1.4.

Hôte physique dans Azure

VM 1 VM 2
Applicaƒon Web IIS + .NET applicaƒon web node.js

Windows Server 2019 Ubuntu 18.04 LTS

vCPU vRAM vDisk vNIC vCPU vRAM vDisk vNIC

vCPU vCPU vRAM vRAM vDisk vDisk vNIC vNIC

Hyperviseur Hyper-V

Processeurs Mémoire Stockage NIC

Figure 1.4  Fonctionnement de la virtualisation sur un hôte physique dans Azure

En plus des serveurs physiques, le stockage et la mise en réseau sont couramment

virtualisés, ce qui permet à la plateforme Azure de définir rapidement tout ce dont
vous avez besoin dans le logiciel. Aucune intervention physique ou configuration
manuelle des appareils n’est requise. Vous n’avez pas à attendre qu’une autre équipe
fournisse une adresse IP, ouvre un port réseau ou ajoute du stockage pour vous.
Azure est conçue pour être exécutée sous Windows, ou presque. Une version
modifiée de l’hyperviseur  Hyper-V sous-tend les serveurs de calcul. Hyper-V est un
hyperviseur (natif) de type  1 qui est disponible sous Windows  Server depuis une
décennie. Ne vous inquiétez pas, vous pouvez toujours exécuter Linux sous la forme
d'une charge de travail de première classe, totalement gérée  ! Microsoft est un
contributeur très important pour la communauté et le noyau  Linux Certains des
réseaux Software-defined dans Azure exploitent une solution personnalisée basée sur
Linux Debian (logiciel pour SONiC (Software for Open Networking in the Cloud)),
mis à disposition en open source par Microsoft. Visitez virtuellement les datacenters
Microsoft à l’adresse https://azure.microsoft.com/global-infrastructure.
12 Chapitre 1  Avant de commencer

1.5.2 Outils de gestion

Comment peut-on utiliser tous ces services Azure ? Vous les utilisez à votre guise ! Si
vous voulez tout sélectionner dans un navigateur Web, il existe un impressionnant
portail Web. Vous êtes à l’aise avec PowerShell ? Tant mieux, car il existe un module
Azure PowerShell. Il existe également un outil multiplateforme d’interface de ligne de
commande (CLI) qui est parfait si vous utilisez MacOS ou Linux. Les développeurs
peuvent également interagir avec Azure via les API REST en utilisant une variété de
langages courants tels que .NET, Python et Node.js.
Portail Azure
Le portail Azure devrait fonctionner dans n’importe quel navigateur web récent. C’est
un moyen pratique d’utiliser Azure sans installer quoi que ce soit sur votre ordinateur.
Le portail est également un excellent moyen d'apprendre à créer et à gérer des
ressources en obtenant rapidement une représentation graphique de chaque élément.
De nouvelles fonctionnalités et services sont constamment ajoutés à Azure. Aussi le
portail peut-il être légèrement différent par rapport aux captures d’écran visibles dans
ce livre ou dans la documentation en ligne et les blogs. Le texte d'un bouton peut
changer un peu ou une nouvelle option peut être ajoutée, mais les opérations de base
restent toutes les mêmes. Bienvenue dans le nouveau monde du cloud computing !
Azure Cloud Shell
Si vous voulez mettre la main au clavier et saisir des commandes, le portail inclut
également Azure  Cloud  Shell (voir figure  1.5). Ce Shell est une console interactive
Web qui fournit un shell Bash, le CLI  Azure, et certains outils de développement
d’applications préinstallés tels que Git et Maven. Il existe également une version
PowerShell du Cloud Shell qui, comme son nom l’indique, fournit l’accès aux cmdlets
de commande Azure PowerShell les plus récents.

Figure 1.5  Azure Cloud Shell dans le portail Web

 Compréhension de la plateforme Windows Azure 13

Vous pouvez accéder au Azure Cloud Shell à partir d’un navigateur depuis n’importe

quel ordinateur à l'adresse https://shell.azure.com sans avoir à installer quoique ce
soit. Les éditeurs tels que Visual Studio Code (https://code.visualstudio.com) donnent
accès à Cloud Shell dans l’application. Il existe même une application Azure disponible
pour iOS et Android qui vous permet d’utiliser Azure Cloud Shell directement à partir
de votre smartphone.
Avec Azure Cloud Shell, vous avez toujours accès à la dernière version des outils CLI
ou PowerShell. Le stockage persistant vous permet de créer et d’enregistrer des scripts,
des modèles et des fichiers de configuration.
Outils CLI et PowerShell locaux Azure
Bien qu’il y ait des avantages à utiliser Azure Cloud Shell, vous avez souvent besoin
d’accéder à vos outils et votre système de fichiers locaux. Vous pouvez installer
localement Azure CLI ou Azure PowerShell afin de pouvoir travailler avec les ressources
locales et les ressources Azure.
Dans ce livre, nous utiliserons principalement Azure  CLI
(Azure CLI 2.0 techniquement). Il peut sembler étrange de choisir cette solution plutôt
que le PowerShell natif de Microsoft ; l’avantage en est que les exemples et les exercices
peuvent fonctionner à la fois dans Azure Cloud Shell et localement sur votre ordinateur,
quel que soit votre système d’exploitation. Bien que cela ne fasse pas partie de la
configuration de votre environnement de test, les guides suivants détaillent l’installation
des outils de gestion Azure sur votre ordinateur :
¡ Premiers pas avec Azure  PowerShell—https://docs.microsoft.com/powershell/
azure/get-started-azureps
¡ Installer CLI Azure—https://docs.microsoft.com/cli/azure/install-azure-cli
Création d'une machine virtuelle

2
Êtes-vous prêt à voir à quelle vitesse vous pouvez configurer un serveur Web dans
Azure ? Dans ce chapitre, nous abordons directement l'une des demandes les plus
courantes en matière de machines virtuelles : la construction d'un serveur Web de
base. Cette charge de travail est un excellent exemple des composants de base de
l'infrastructure en tant que service (IaaS) dans Azure.
Supposons que vous travailliez pour une pizzéria qui souhaite étendre ses activités et
accepter les commandes en ligne dans le cadre de la livraison de pizzas ou la vente à
emporter. Pour créer une présence en ligne, vous avez besoin d'un site Web. Dans les
deux premières parties de ce livre, nous explorons les différents services et fonctionnalités
d'Azure qui vous permettent de développer et d'exécuter à la fois des applications Web
IaaS et de plateforme en tant que service (PaaS). Vous pouvez commencer à prendre des
décisions éclairées quant au moment auquel développer et exécuter une machine
virtuelle pour sous-tendre un site Web, et quant à celui d'utiliser la solution PaaS pour ce
faire. La première étape consiste néanmoins à créer un serveur Web.
Dans ce chapitre, vous créerez une machine virtuelle Linux Ubuntu et
installerez   un serveur Web de base. Ne vous préoccupez pas de l'utilisation
de  Linux : c'est une machine virtuelle Windows que vous allez créer dans le cadre de
l'exercice pratique à la fin de ce chapitre

Ouvrez le port 80
pour permere aux
clients de parcourir
votre site. Client sur PC

Machine Connectez-vous Machine

Créez dans un et installez les virtuelle Linux
navigateur Web. virtuelle packages. Client sur
Linux Serveur
smartphone
Web de base

Client sur
tablee

Figure 2.1  Dans ce chapitre, vous créez une machine virtuelle de base, vous vous connectez pour
installer un serveur Web, puis vous ouvrez un port réseau pour permettre aux clients d'accéder au site
Web de démonstration.
14
 Notions de base de la configuration d'une machine virtuelle 15

exercice pratique ! Ubuntu est une plateforme de serveur Web répandue, et représente
un excellent moyen d'en apprendre sur l'authentification par clé publique SSH. Vous
verrez ensuite comment ouvrir un port réseau pour que les clients accèdent à votre site
Web sur Internet. Une vue d'ensemble de haut niveau de cet environnement de base
est illustrée à la figure 2.1.

2.1 Notions de base de la configuration d'une machine virtuelle

Les machines virtuelles font partie des éléments constitutifs les plus courants que vous
utiliserez lorsque vous commencerez à exécuter des applications dans le Cloud.
Pourquoi  ? Elles sont généralement bien connues. La plupart des
services informatiques exécutent de nombreuses charges de travail à l'aide d'Hyper-V
ou de VMware dans un environnement local. Il est donc fort probable que vous ayez
déjà une certaine expérience dans la création et l’exécution de machines virtuelles.
Les entreprises font souvent leurs premiers pas dans Azure avec des machines virtuelles,
car les charges de travail IaaS ne nécessitent pas l'adaptation mentale qui est nécessaire
pour commencer à exécuter des charges de travail PaaS.
Des solutions permettent de migrer des machines virtuelles à partir d’un
environnement local, notamment Hyper-V ou VMware vers Azure. Avant de vous emballer
au sujet des possibilités offertes par Azure (dont certaines seront abordées dans les
chapitres suivants), examinons quelques notions de base. Ces prochaines pages peuvent
sembler contenir des considérations familières et des options déjà proposées avec les
machines virtuelles sur site. Si c'est le cas, tant mieux ! Si ce contenu est inédit pour vous,
pas d'inquiétude : une grande partie de la gestion est abstraite dans Azure, et certains
éléments, comme les réseaux virtuels sont généralement créés et configurés une seule
fois, puis laissés en autonomie. Nous examinerons chaque domaine plus en  détail dans
les chapitres à venir. Prenez une grande inspiration et procédez pas à pas.
2.1.1 Régions et options de disponibilité
Azure est divisé en régions dans le monde entier et chacune d'entre elles contient
un ou plusieurs datacenters. Ces datacenters fournissent les ressources de calcul, de
stockage et de réseau de base nécessaires à l'exécution de vos applications et charges
de travail. Azure s’exécute dans plus de 50 régions, et celles-ci ne cessent de croître
tous les mois. Grâce à ces nombreuses régions, vous pouvez déployer des applications
à  proximité de vos collaborateurs ou clients. Cette disponibilité régionale réduit
la latence et améliore l’expérience utilisateur.
Une région Azure peut ne pas offrir tous les services disponibles dans Azure. Compte
tenu des centaines de services disponibles, l’ensemble le plus commun de services
basiques est généralement proposé partout, même si les nouveaux services ou les
services de niche sont déployés au fil du temps. À mesure que vous planifiez vos
applications in Azure, vérifiez la disponibilité des produits selon les régions à l'adresse
https://azure.microsoft.com/global-infrastructure/services.
Dans le chapitre 8, nous étudierons certaines des options haute disponibilité, telles
que les groupes à haute disponibilité et les zones de disponibilité. Ces options de
redondance permettent à Azure de distribuer plusieurs instances de vos machines
virtuelles ou applications au sein d’un seul datacenter ou dans une région entière.
Cette capacité vous permet de définir votre tolérance aux mises à jour de maintenance
ou aux défaillances matérielles. Dans les premiers chapitres de ce livre, vous ne créerez
généralement qu’une ou deux machines virtuelles, ne vous préoccupez donc pas de ces
options de disponibilité pour le moment.
16 Chapitre 2  Création d'une machine virtuelle

2.1.2 Images de machine virtuelle

Un point de départ doit être établi pour créer une machine virtuelle. Généralement,
ce point de départ se résume au choix du système d’exploitation : Windows ou Linux.
Vient ensuite le choix de la version Windows à utiliser (comme Windows Server 2016
ou 2019) ou de la distribution Linux à utiliser (comme Ubuntu, Red Hat Enterprise
Linux ou SUSE).
Une image  : un ensemble de systèmes d’exploitation préconfigurés associé à des
options de configuration basiques, constitue ce point de départ. Azure contient des
centaines de ces images prédéfinies dans Azure Marketplace, qui peuvent être utilisées
pour créer des machines virtuelles. Souvent, des licences Windows existantes peuvent
être appliquées, selon votre modèle de licence actuel. Vous pouvez également opter
pour une prise en charge supplémentaire de Canonical pour exécuter Linux Ubuntu
ou des mises à jour à partir de Red Hat, par exemple.
Pour garder ces leçons simples et suffisamment courtes pour que vous puissiez les
suivre pendant votre heure de déjeuner, vous utiliserez ces images prédéfinies dans
Azure tout au long du livre. Dans le monde réel, il est préférable de les personnaliser
pour répondre aux besoins et aux exigences de votre entreprise. Pour ce faire, vous
créerez souvent vos propres images de machine virtuelle. La charge de travail dédiée à
la création et à la gestion des machines virtuelles est similaire à celle qui est utilisée pour
les images Azure Marketplace, même si souvent, la création de vos propres images
requiert beaucoup de planification, et de nombreuses heures pour configurer,
généraliser et collecter au préalable vos propres images.

Tester
Voici quelques points à prendre en compte lors de la planification des applications dans
Azure. Ces décisions semblent élémentaires et la plupart du temps, elles sont prises
automatiquement, sans nécessiter beaucoup de réflexion. Il est néanmoins important
de comprendre les besoins de votre application avant de commencer à la créer et
à l'exécuter !

¡ Dans quelles régions votre application doit-elle être exécutée ? Une région spécifique
compte-t-elle de nombreux utilisateurs ? Comment garantir la redondance ?
Si vous créez des applications internes, exécutez-les dans la région Azure la
plus proche de vos utilisateurs. Si vous avez un bureau important à Houston, au
Texas, par exemple (peut-être aimez-vous les fusées !), exécutez vos applications
et machines virtuelles Azure dans le Centre-Sud des États-Unis.
Si vous créez des applications externes, pensez-vous que des clients appartenant
à des régions spécifiques les utiliseront  ? Cette configuration peut nécessiter le
déploiement de plusieurs instances dans différentes régions (et la fourniture d'une
haute disponibilité). Nous procéderons à cette configuration au chapitre 12.
¡ Avez-vous besoin de nombreuses personnalisations de machines virtuelles  ?
Combien de temps le test et la validation de tous ces changements nécessitent-ils ?
À quels services incombent-ils ?
Dans un environnement traditionnel sur site, un temps considérable est
souvent consacré à la création d’images préconfigurées pour les déploiements.
Essayez de minimiser ce temps dans le Cloud. Les images préintégrées Azure
incluent les dernières mises à jour de sécurité. Elles sont testées pour vous, puis
géo-répliquées pour garantir les délais de déploiement les plus rapides.
 Notions de base de la configuration d'une machine virtuelle 17

Si vous créez vos propres images, utilisez des fonctions comme Azure
Shared Image Gallery pour distribuer et répliquer ces images selon les besoins
(https://docs.microsoft.com/azure/virtual-machines/windows/
shared-image-galleries).

2.1.3 Tailles de machine virtuelle

Il existe diverses gammes de tailles de machine virtuelle dans Azure. Ces gammes con-
tiennent des groupes de types de matériel informatique virtuel similaires adaptés à
certaines charges de travail. Les tailles sont parfois mises à jour à mesure que de nou-
velles offres de matériel et de charge de travail deviennent disponibles, mais les
gammes de base restent constantes. Les types de gammes sont les suivants :
¡ Usage général : idéal pour le développement et les tests, ou les serveurs Web ou les
bases de données de production à faible utilisation.
¡ Calcul optimisé  : processeurs hautes performances, par exemple pour les
serveurs d'application de production
¡ Mémoire optimisée : options de mémoire plus volumineuses, comme lorsque vous
devez exécuter de grandes bases de données ou des tâches nécessitant beaucoup
de traitement de données en mémoire
¡ Stockage optimisé : faible latence, hautes performances de disque pour les applica-
tions gourmandes en disques
¡ GPU : machines virtuelles spécialisées en graphismes basées sur NVIDIA, si vous
avez besoin d'un rendu graphique ou d'un traitement vidéo
¡ Calcul haute performance : beaucoup de tout ! Unité centrale, mémoire et débit
réseau au meilleur de leur forme pour les charges de travail les plus exigeantes
Quelle taille de machine virtuelle pouvez-vous créer dans Azure ? Les choses évoluent
en permanence, mais au moment où nous écrivons ces lignes, la plus grande machine
virtuelle que vous pouvez créer est une série  Mv2 (qui fait partie de la famille à
mémoire optimisée) avec 208 UC virtuelles et 5,7 Tio de mémoire. Cela devrait con-
stituer un serveur Minecraft plus que correct, vous ne pensez pas ?!
L'enseignement le plus important en la matière, c'est que le nombre de machines
virtuelles et la quantité d'UC et de mémoire que vous pouvez demander dans Azure ne
sont limités que par votre budget. Vous auriez probablement du mal à créer des
machines virtuelles de cette taille dans le monde réel.
Lorsque vous créez une machine virtuelle dans le portail Azure ou à l’aide de CLI ou
de PowerShell, vous devez choisir la taille de la machine virtuelle. Une taille de machine
virtuelle commune, telle que D2s_v3, est souvent utilisée par défaut pour commencer.
Cela représente probablement beaucoup trop de puissance pour un serveur Web de
base dans ce chapitre, mais permet rapidement de créer la machine virtuelle et d'in-
staller les packages requis !
Le portail Azure vous permet d'appliquer des filtres en fonction d’une taille approx-
imative (petite, moyenne ou grande) ou d’une famille spécifique (telles que les
machines virtuelles à usage général ou à mémoire optimisée). L'estimation des frais
mensuels est également indiquée pour vous donner une idée du coût de chaque
machine virtuelle. Faites attention aux coûts, car ils peuvent rapidement augmenter !
Dans des limites raisonnables, vous pouvez généralement modifier la taille des
18 Chapitre 2  Création d'une machine virtuelle

machines virtuelles une fois qu'elles sont opérationnelles, même si elles doivent être
arrêtées et redémarrées pour effectuer le processus.

Réduction des coûts des machines virtuelles

Les machines virtuelles créées par défaut sont souvent surpuissantes pour ce dont vous
avez besoin, mais elles sont rapides à déployer et à utiliser. Cela vous permet donc de
réduire le temps consacré à installer des packages lors de votre pause déjeuner.
Dans le monde réel, faites attention aux exigences en termes de mémoire, d'UC et de
stockage de vos machines virtuelles. Créez des machines virtuelles de taille appropriée.
Cette approche est la même que dans le monde physique, où vous pouvez vous retrouver
avec des machines virtuelles qui ont beaucoup plus de mémoire ou beaucoup plus d'UC
virtuelles affectées qu'il n'en faut.
Il existe aussi un type spécial de machine virtuelle dans Azure : la série B. Ces tailles de
machines virtuelles utilisent des ressources de mémoire et d'UC à la carte, et vous
pouvez utiliser des crédits bancaires pour les ressources de calcul inutilisées. Si vous voulez
sauvegarder vos crédits Azure, vous pouvez choisir cette série de machines virtuelles
pour les besoins des exercices de ce livre. Leur prix est inférieur et elles sont tout à fait
adaptées à des scénarios où vous n'avez pas toujours besoin de beaucoup de ressources
en UC et en mémoire. Attention néanmoins : selon la taille de la machine virtuelle de
série B que vous créez, elle peut avoir moins de CPU et de mémoire que celle d'une série
D2s_v3. Son exécution sera donc un peu plus lente.

2.1.4 Stockage Azure

Le stockage pour les machines virtuelles dans Azure est simple. Combien de disques
voulez-vous, de quelle capacité et de quel type ? Les deux premières caractéristiques ne
sont pas vraiment spécifiques à Azure, c'est pourquoi nous ne les aborderons pas. Voici
les types de stockage disponibles :
¡ Disques SSD Premium  : utilisation de disques SSD à faible latence et aux
performances élevées, idéaux pour les charges de travail de production. Ce type
de disque est à utiliser principalement en vue d'obtenir les meilleures
performances pour vos applications.
¡ Disques SSD standard  : utilisation de disques SSD standard qui offrent des
performances cohérentes par rapport aux disques durs (HDD). Ils conviennent
parfaitement aux charges de travail de développement et de test, ou à un usage
de production à faible demande et respectueuse du budget,
notamment les serveurs Web.
¡ Disques durs HDD standard  : utilisation de disques durs mécaniques ordinaires,
parfait pour les données dont l’accès est ponctuel, telles que des archives ou des
sauvegardes. Ce type de disque n'est pas recommandé pour l'exécution de
charges de travail applicatives.
Vous n'avez pas besoin d'approfondir davantage les spécificités du stockage pour créer
un serveur Web rapide. Vous en saurez plus au chapitre 4, notamment sur les disques
Ultra, qui ne sont destinés qu’aux disques de données associées. Pour l'instant, il suffit
de savoir que lorsque vous choisissez une taille de machine virtuelle, laquelle permet
de définir le type de stockage que vous utilisez.
Les disques virtuels que vous utilisez, quel que soit leur type, sont appelés disques gérés
Azure. Ces disques gérés vous permettent de créer une machine virtuelle et d'y associer
des disques de données supplémentaires sans vous soucier des comptes de stockage
sous-jacents, des limites de ressources ou des quotas de performance. Les disques gérés
 Notions de base de la configuration d'une machine virtuelle 19

sont également cryptés automatiquement au repos : vous n'avez rien à configurer pour
sécuriser vos données  ! Encore une fois, nous étudierons ce juste plus en détail au
chapitre 4. Pour l’instant, vous pouvez généralement laisser Azure créer le disque le
plus approprié en fonction de la taille de machine virtuelle sélectionnée.

Tester
Pour vérifier vos connaissances, réfléchissez aux questions suivantes :

¡ Pour la plupart des charges de travail de production, quel type de disque offre-t-il
les meilleurs perfo rmances ?
Un disque SSD Premium est généralement celui que vous devez exécuter pour
les charges de travail de production. Ce Type de disque est souvent choisi par
défaut lorsque vous créez une machine virtuelle. Les disques SSD standard con-
stituent un deuxième choix correct, et les Ultra SSD ne doivent être utilisés que
sur des applications très gourmandes en disques qui nécessitent une faible
latence. Bien que les disques HDD standard soient un peu moins onéreux, leurs
performances sont souvent excellentes, tout comme dans les environnements vir-
tuels sur site.
¡ Quelle famille de machines virtuelles est-elle appropriée pour un serveur de base
de données ?
Une machine virtuelle à mémoire optimisée constitue une bonne option, car
les bases de données nécessitent souvent une plus grande quantité de mémoire
que les ressources processeurs. Veillez toujours à estimer les besoins en ressources
et à surveiller les performances après le déploiement. N’hésitez pas à modifier la
taille de la machine virtuelle pour obtenir les performances souhaitées.

2.1.5 Mise en réseau virtuelle

Cela semble évident, mais une machine virtuelle nécessite une connectivité réseau afin
que les applications soient accessibles. Vous avez besoin à la fois d'un réseau virtuel et
d'une connectivité externe pour un serveur Web de base. Le chapitre 5 couvre la mise
en réseau Azure de base en détail, et le chapitre  9 explique comment distribuer le
trafic vers plusieurs machines virtuelles à l’aide d’équilibreurs de charge. Le chapitre 11
est quant à lui passionnant, car il traite d'Azure DNS et du routage mondial des
utilisateurs avec Traffic Manager. Même si vous ne deviendrez pas un ingénieur réseau,
vous allez en apprendre beaucoup sur la mise en réseau Azure dans ce livre !
Pour commencer avec les bases nécessaires pour ce chapitre, un réseau virtuel dans
Azure est composé des mêmes caractéristiques de base qu’un réseau physique normal :
¡ Un espace d'adressage et un masque de sous-réseau, de type 10.0.0.0/16
¡ Un ou plusieurs sous-réseaux, que vous pouvez utiliser pour répartir le trafic
externe, de bases de données ou d'applications, par exemple
¡ Des cartes d'interface réseau virtuelles (NIC) qui connectent des machines virtu-
elles à un sous-réseau donné
¡ Des adresses IP virtuelles affectées à des ressources telles qu'une carte réseau vir-
tuelle ou un équilibreur de charge
Vous pouvez créer une machine virtuelle associée uniquement à un réseau virtuel sans
fournir de connectivité externe, ce qui peut être le cas pour les serveurs de base de
20 Chapitre 2  Création d'une machine virtuelle

données ou d'applications back-end. Pour vous connecter à ces machines virtuelles à

des fins d'administration et de maintenance, vous pouvez créer une connexion VPN
(Virtual Private Network), ou vous pouvez utiliser une connexion privée dédiée à
Azure à partir de votre équipement de réseau local. Dans Azure, cette connexion
dédiée s'appelle ExpressRoute.
Le serveur Web de base que vous allez créer dans ce chapitre nécessite un type
spécifique d'adresse IP virtuelle : une adresse IP publique. Cette adresse IP publique est
affectée à la carte réseau virtuelle et permet au trafic externe d'atteindre votre machine
virtuelle. Vous pouvez ensuite contrôler le flux du trafic vers votre machine virtuelle
avec des NSG (groupes de sécurité réseau). Pensez à un pare-feu standard que vous
utilisez pour ouvrir ou fermer différents ports et protocoles ; dans Azure, les groupes de
sécurité réseau verrouillent le trafic par défaut et n'autorisent que le trafic spécifique
que vous définissez. Le trafic couramment autorisé est HTTP ou HTTPS sur les ports
TCP 80 et 443. La gestion à distance à l’aide du protocole de bureau à distance (RDP)
ou de Secure Shell (SSH) peut également être autorisée, avec prudence, ce que vous
ferez plus loin dans ce chapitre pour découvrir comment vous connecter et
installer certains packages.

2.2 Création d’une paire de clés SSH pour l’authentification

Dans l’exercice pratique de fin de chapitre, vous allez créer ce que vous connaissez
probablement déjà  : une machine virtuelle Windows Server. Ce type de machine
virtuelle utilise l’authentification basée sur un mot de passe. De nombreuses
applications dans le Cloud s’exécutent sous Linux. En effet, plus de la moitié des
machines virtuelles dans Azure exécutent Linux. Généralement, vous n’utilisez pas
d’authentification basée sur les mots de passe avec Linux. Vous utilisez plutôt SSH et
une paire de clés publiques. Le serveur Web de base de ce chapitre exécute Linux en
vue de commencer à développer vos compétences. Vous devez donc apprendre à créer
et à utiliser SSH. Vous n'avez pas besoin de connaître Linux pour travailler dans le
Cloud, mais je vous recommande vivement d’apprendre quelques notions de base !

Paires de clés SSH

SSH est un protocole utilisé pour communiquer en toute sécurité avec des ordinateurs dis-
tants et représente le moyen le plus commun pour se connecter à une machine virtuelle
Linux. Cela s'apparente à l'utilisation d'une connexion RDP à une machine virtuelle Windows,
sauf que sous Linux la session SSH est généralement basée sur une console. Avec le chif-
frement à clé publique, vous pouvez utiliser une paire de clés numériques pour vous
authentifier auprès d’une machine virtuelle Linux à distance.
Une paire de clés SSH comporte deux parties : une clé publique et une clé privée. La clé
publique est stockée sur votre machine virtuelle Linux dans Azure. Vous conservez une
copie de la clé privée. Lorsque vous devez vous connecter à votre machine virtuelle
Linux, la clé publique de la machine virtuelle distante est comparée à la clé privée que
vous conservez localement. Si les paires de clés correspondent, vous êtes connecté à la
machine virtuelle. C'est un peu plus complexe que cela dans la réalité, mais intrinsèque-
ment, le chiffrement à clé publique est un excellent moyen de contrôle d'identité.
Je voudrais que vous preniez l'habitude d'utiliser des clés SSH pour vous connecter aux
machines virtuelles Linux. Les clés SSH sont beaucoup plus sûres que les mots de passe
car, entre autres choses, elles ne sont pas sensibles aux attaques de mots de passe par
force brute. Vous devriez toujours considérer la sécurité comme un concept central, en
particulier dans le cloud, et insister sur cet aspect.

Tester
Créons une paire de clés publiques SSH à l'aide d'Azure Cloud Shell :
 Création d’une paire de clés SSH pour l’authentification 21

1 Ouvrez votre navigateur Web à l'adresse https://portal.azure.com. Connect-

ez-vous au compte Azure que vous avez créé au chapitre  1, puis sélectionnez
l’icône Cloud Shell, située dans la partie supérieure du tableau de bord, comme
illustré à la figure 2.2. Vous pouvez également ouvrir Cloud Shell directement à
l’adresse https://shell.azure.com.

Figure 2.2  Sélectionnez et lancez Cloud Shell sur le portail Azure en sélectionnant l'icône Shell.

2 La première fois que vous ouvrez Cloud Shell, la création d'un système de stock-
age persistant qui sera toujours connecté à vos sessions prend quelques instants.
Ce stockage vous permet de sauvegarder et de récupérer des scripts, des fichiers
de configuration et des paires de clés SSH. Acceptez toutes les invites pour per-
mettre la création de cette solution de stockage.
3 Si nécessaire, choisissez Bash dans le menu déroulant situé dans le coin supérieur
gauche de Cloud Shell. La prise en charge de PowerShell est également dis-
ponible, bien que ce ouvrage porte principalement sur Bash et CLI Azure.
4 Pour créer une paire de clés, saisissez la commande suivante :
ssh-keygen
5 Acceptez les invites par défaut en appuyant sur la touche Entrée. En quelques
secondes, vous disposez de deux  clés publiques SSH que vous pouvez utiliser
avec toutes vos machines virtuelles ! La commande ssh-keygen est par défaut
une clé de longueur de 2 048 bits et utilise le protocole RSA version 2. Il s'agit
d'un bon équilibre en termes de sécurité et c'est le type recommandé pour la
plupart des cas d'utilisation. La figure 2.3 présente un exemple d'une paire de
clés SSH définie dans Cloud Shell.

Figure 2.3  Une paire de clés SSH créée dans Azure Cloud Shell à l'aide de la commande ssh-keygen
22 Chapitre 2  Création d'une machine virtuelle

6 Pour afficher votre clé publique et l'utiliser avec une machine virtuelle, saisissez
la commande suivante :
cat .ssh/id_rsa.pub

7 Sélectionnez le résultat et copiez-le dans un simple fichier texte sur votre

ordinateur. Vous utiliserez cette clé publique pour créer une machine virtuelle
dans la section  2.3. Cette machine virtuelle est référencée à partir de la
CLI Azure dans tout le reste du livre. Généralement, vous n’avez pas besoin de
copier et de coller la clé entière à chaque fois, mais il préférable de comprendre
ce qui se passe au début. Ceci n'est pas topsecret en formation. Il est donc
convenable d'utiliser le bloc-notes ou TextEdit pour créer et enregistrer une
copie de la clé. Attention lors de la copie du résultat de la clé publique à ne pas
saisir d'espaces typographiques supplémentaires et à ne pas omettre de
caractères. Exemple de clé publique SSH complète :
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDPGaOBsfhJJOHAWAv+RLLR/vdUTzS9HOIj
➥JyzWWLsnu0ESH2M6R+YYPPNXv9X7dmVyM1zCXXEaLucpnyFjevbwPedxTgifyxgCFTgylr1
➥kg7o4EyCTGBGhTA+hSHuhXGXa12KPdKWehsPwHMa6Hs8fbt/in9Z1k2ZAwvbT+LWPcmJgNO
➥FuolIHOsOEeoQQqdXLrGa7NU/3fzSXdT9Y2BT1KLINc4KnwdOuONddLw3iANvK+Gkwax8iK
➥7IicKMoammwvJUCRf+MTEK9pZ84tfsc9qOIAdhrCCLbQhtoWjZpIwYnFk+SNBE8bZZtB8b2
➥vkDFNZlA5jcAd6pUR3tPuL0D iain@cc-a444-9fdee8b2-2014310619-v5cl5
ASTUCE  Cloud Shell s'appuie sur un navigateur. Les raccourcis clavier pour
copier et coller peuvent fonctionner un peu différemment de ce à quoi vous êtes
habitué. Les raccourcis Ctrl-Inser et Maj-Inser se substituent aux combinaisons
de touches habituelles Ctrl-C et Ctrl-V pour les opérations copier et coller.

2.3 Création d'une machine virtuelle à partir de votre navigateur Web

Maintenant que vous connaissez un peu la théorie des machines virtuelles Azure et
que vous avez créé une paire de clés SSH, vous êtes prêt à vous lancer dans la création
d'une machine virtuelle. Je vais vous aider à démarrer, avant de vous laisser configurer
la machine virtuelle grâce aux connaissances acquises. Soyez donc attentif !
Les outils CLI Azure et Azure PowerShell sont incroyablement puissants, mais une
des grandes forces d'Azure, c'est le temps consacré à l'élaboration d'une grande
expérience de portail. Le portail Azure est un outil graphique orienté Web qui vous
permet de vérifier comment tous les différents composants s'assemblent et de contrôler
rapidement, de façon visuelle, que tout va bien. Le portail comporte deux éléments
uniques dont ne disposent pas les autres outils. De plus, il est rapide à utiliser, car vous
n'avez rien à installer.

Tester
La création d’une machine virtuelle dans Azure vous donne beaucoup de valeurs par
défaut que vous pouvez utiliser pour réduire le nombre de choix à effectuer. Pour cet
exercice, examinez les ressources créées par Azure en fonction de ce que vous avez
appris dans la section 2.2, notamment pour le réseau et le stockage :

1 Dans le portail Azure (https://portal.azure.com), sélectionnez Créer une

ressource, dans le coin supérieur gauche du tableau de bord. Les ressources
populaires doivent être répertoriées, y compris la version la plus récente de la
prise en charge à long terme (LTS) d’Ubuntu (au moment de la rédaction du
présent document, il s'agit d'Ubuntu Server 18.04 LTS).
2 Sélectionnez la version LTS.
 Création d'une machine virtuelle à partir de votre navigateur Web 23

Vous pouvez également effectuer une recherche dans le Marketplace en haut de la

fenêtre ou parcourir la liste des services de haut niveau (tels que le calcul et la mise en
réseau) pour obtenir une idée des éléments disponibles pour répondre à vos besoins
futurs. Essayez d'utiliser Ubuntu Server 18.04 LTS afin de pouvoir effectuer l’un des
prochains exercices visant à installer les composants du serveur Web.
3 Créez un groupe de ressources pour votre serveur Web.
Lorsque vous créez des ressources dans Azure, elles sont logiquement
contenues dans un groupe de ressources que vous définissez. Ces groupes
contiennent généralement des ressources similaires pour vos applications. Le
chapitre  7 explique comment planifier et gérer les applications à l’aide des
groupes de ressources.
Pour l'instant, je vous suggère de nommer vos groupes de ressources par
chapitre, pour organiser les choses au fur et à mesure que vous progressez.
Nommez par exemple le groupe de ressources de cet exercice
azuremol-chapter2.
4 Nommez votre machine virtuelle, par exemple webvm, puis choisissez une région
proche de vous. Laissez la redondance des infrastructures de côté pour l’instant.
Regardez les options de l'image de machine virtuelle, pour connaître les autres
options. Conservez néanmoins Ubuntu Server 18.04  LTS pour cet exercice.
La taille de machine virtuelle par défaut convient parfaitement à cet exercice,
mais encore une fois, regardez les autres options et découvrez comment
utiliser différentes tailles et le matériel qu’elles exécutent. Découvrez comment
les tailles correspondent aux familles de machines virtuelles vues précédemment
dans ce chapitre.
5 Veillez à utiliser l’authentification par clé publique SSH, puis indiquez un nom
d’utilisateur, tel qu'azuremol. Vous utiliserez ce nom d’utilisateur pour vous
connecter à la machine virtuelle dans l’exercice suivant.
6 Copiez et collez la clé publique SSH que vous avez créée dans la section
précédente. Encore une fois, veillez à ne saisir aucun espace, ni aucune mise en
forme supplémentaires lorsque vous copiez et collez la clé publique. La clé SSH
doit être contenue sur une seule ligne. Le retour à la ligne dans le bloc-notes est
susceptible de causer des problèmes ! Attendez que le portail Azure valide la clé
avant de continuer.
7 Pour vous connecter à la machine virtuelle dans l’exercice suivant et installer les
composents du serveur Web, ouvrez SSH sur le port 22.
L’ouverture de SSH sur une machine virtuelle publique n’est pas une bonne
pratique de sécurité. Le chapitre  16 explique comment ouvrir et restreindre
l’accès automatiquement à l’aide d’un accès juste à temps aux machines virtuelles.
Étudiez les autres ports que vous pouvez ouvrir. HTTP et HTTPS sont des ports
couramment ouverts, et vous êtes censé créer un serveur Web dans ce chapitre,
n’est-ce pas ? Ne trichez pas et n'ouvrez pas ces ports maintenant, je vais vous
présenter CLI Azure dans l’exercice suivant, où vous autoriserez le trafic HTTP.

Connectez-vous en toute sécurité à l’aide d’un hôte bastion

Dans des scénarios réels, vous ne devez pas ouvrir de ports de gestion à distance pour
SSH ou RDP à l'Internet public. Ne le faites pas ! Suivez les bonnes pratiques que vous
devez appliquer dans le monde non-Cloud sur site, en vous connectant uniquement lor-
sque cela est nécessaire et en limitant l’accès à distance à un ensemble spécifique
d’adresses de gestion.
24 Chapitre 2  Création d'une machine virtuelle

(suite)
Un hôte bastion ou une boîte de saut sont couramment utilisés pour fournir un accès
à distance. Dans ce type de configuration, vous ne vous connectez pas directement aux
serveurs d’application à partir de votre ordinateur portable ou du bureau. Au lieu de cela,
vous vous connecter à un hôte bastion dédié, puis vous vous connectez au serveur que
vous devez gérer. Cette approche bloque l’accès à un ensemble limité d’adresses et
garantit une gestion à distance en toute sécurité.
Azure Bastion (https://docs.microsoft.com/azure/bastion) fournit une approche gérée
qui répond à ce besoin de connexion à distance sécurisée. Vous créez un hôte Azure
Bastion dans un sous-réseau dédié, puis vous utilisez cet hôte pour vous connecter aux
machines virtuelles qui exécutent vos applications. Ces machines virtuelles n’ont pas
besoin d’être accessibles au public. Vous pouvez tout faire via le portail Azure sans ouvrir
de ports réseau pour SSH ou RDP. L'hôte bastion lui-même est géré pour vous en termes
de mises à jour de sécurité et de règles appliquées aux groupes de sécurité réseau.

8 Regardez certaines des autres options de configuration de machine virtuelle

pour le stockage et la mise en réseau afin de vous familiariser avec les options,
même si vous pouvez laisser toutes les valeurs par défaut pour l’instant.
9 Il existe également des options de gestion intéressantes, telles que l’activation de
l'arrêt automatique, des sauvegardes et des diagnostics, qui sont abordés dans les
chapitres 12 et 13. Pour l’instant, désactivez les diagnostics de démarrage et les
diagnostics du système d’exploitation, car vous devez créer et configurer un
compte de stockage pour qu’ils puissent fonctionner.
10 Lorsque vous êtes prêts, déterminez vos besoins et créez une machine virtuelle
de base.

2.4 Connexion à la machine virtuelle et installation du serveur Web

Une fois que votre machine virtuelle est opérationnelle, vous pouvez utiliser la clé SSH
que vous avez créée précédemment pour vous y connecter. Vous pouvez ensuite com-
mencer à installer et configurer le serveur Web, et vous pouvez effectuer ces opéra-
tions via Cloud Shell.
2.4.1 Connexion à la machine virtuelle avec SSH
Cette section explique comment obtenir rapidement les informations de connexion à
votre machine virtuelle.

Tester
Si Linux est nouveau pour vous, ne vous inquiétez pas ! Suivez les étapes ci-après pour
vous connecter à votre machine virtuelle :

1 Sur le portail Azure, depuis la barre de navigation du côté gauche de l'écran,

accédez à Machines virtuelles et sélectionnez cette option. La création de la
machine virtuelle prend quelques minutes. Par conséquent, sélectionnez le bou-
ton Actualiser jusqu'à ce que l'état de la machine virtuelle affiche En cours d'exécu-
tion. Sélectionnez votre machine virtuelle lorsque vous êtes prêt et cliquez sur le
bouton Connecter, comme illustré à la figure 2.4.
 Connexion à la machine virtuelle et installation du serveur Web 25

Figure 2.4  Sélectionnez votre machine virtuelle sur le portail Azure, puis sélectionnez Se connecter pour générer
les informations de connexion SSH.

Avec une machine virtuelle Linux, la commande SSH qui comprend votre nom
d'utilisateur et l'adresse  IP publique est affichée. Copiez cette commande de
connexion SSH, telle que ssh azuremol@104.209.208.158.
Sur une machine virtuelle Windows, le bouton Connecter permet de
télécharger un fichier de connexion RDP sur votre ordinateur, pré-rempli avec
l'adresse IP publique de votre machine virtuelle.
2 Au besoin, ouvrez à nouveau Cloud Shell. Si vous êtes amené à basculer entre
Cloud Shell et le portail, vous pouvez réduire la fenêtre Cloud Shell pour la
garder disponible en arrière-plan.
3 Collez la commande SSH dans Cloud Shell, puis appuyez sur Entrée. La clé SSH
que vous avez créée précédemment est automatiquement utilisée dans le cadre
de l'authentification.
La première fois que vous vous connectez à une machine virtuelle avec une clé
SSH, il vous est demandé de l'ajouter à une liste d'hôtes approuvés. Il s'agit d'une
autre couche de sécurité qu'apporte la technologie SSH. Si quelqu'un tente
d'intercepter le trafic et de vous diriger vers une autre machine virtuelle distante,
votre client SSH local sait que quelque chose a changé et vous avertit avant que
vous vous connectiez.
Acceptez l'invite pour enregistrer la connexion à la machine virtuelle distante.
La figure 2.5 montre le processus de connexion SSH dans Azure Cloud Shell.
26 Chapitre 2  Création d'une machine virtuelle

Figure 2.5  Utilisez la chaîne de connexion affichée sur le portail Azure pour créer une connexion SSH
à votre machine virtuelle à partir de Cloud Shell.

À ce stade, soit vous voilà désormais chez vous mais à distance, soit l'invite Linux vous
est totalement étrangère. Ne vous inquiétez pas. Vous n'avez pas besoin de connaître
un grand nombre de commandes Linux, et chaque commande sera expliquée au fur
et à mesure que nous progresserons. Cela dit, je vous recommande fortement
d'acquérir au moins quelques compétences de base de l'administration Linux. Une
grande partie du cloud est basé sur les systèmes Linux, et il existe une forte tendance
en faveur des conteneurs et des micro-services à des fins de développement et de
gestion d'applications. Si vous êtes un administrateur Windows de la vieille école,
bienvenue ! Une surprise vous attend à la fin du chapitre, alors soyez patient.

2.4.2 Installation du serveur Web

Créer une machine virtuelle ? C'est fait. Se connecter à la machine virtuelle avec SSH ?
C'est fait. Vous pouvez maintenant installer les packages pour un serveur Web et vous
préparer à le voir en action.
Azure prend on charge de nombreuses distributions Linux (distros). Les outils de
gestion des packages et l'emplacement des fichiers de configuration varient un peu
entre les distros. Nous allons utiliser Ubuntu dans le cadre de ce livre car c'est l'une des
distributions Linux les plus populaires et les mieux documentées pour le cloud
computing. Si vous êtes bloqué en cours de route, vous trouverez certainement pléthore
de documents pour vous aider, notamment à l'adresse https://help.ubuntu.com. Si
vous souhaitez utiliser une distribution différente avec laquelle vous êtes déjà à l'aise,
n'hésitez pas à l'utiliser ! Sinon, gardez Ubuntu.
 Connexion à la machine virtuelle et installation du serveur Web 27

Tester
Depuis votre session SSH sur la machine virtuelle, installez les packages du serveur
Web grâce à l'APT :

1 Dans Ubuntu, vous installez des packages avec un outil de paquetage avancé
(APT, Advanced Packing Tool) : il s'agit d'un outil super-puissant de gestion des
packages, qui installe automatiquement tous les packages supplémentaires
requis. Tout ce que vous avez à faire, c'est de lui demander d'installer un serveur
Web, et APT se charge d'installer tous les composants nécessaires.
Pour les besoins de cet exemple, installez la pile Web LAMP. C'est probablement
l'ensemble le plus répandu de composants Web : Linux, Apache (serveur Web),
MySQL (serveur de base de données) et PHP (langage de programmation Web) :
sudo apt update && sudo apt install -y lamp-server^

La première commande met à jour les packages disponibles, ce qui est une bonne
pratique pour vous assurer que vous pouvez installer les packages les plus récents
et les meilleurs. Une fois cette commande effectuée, exécutez la commande
suivante avec &&. Pourquoi ne pas tout simplement commencer par écrire une
nouvelle ligne pour la commande suivante  ? L'instruction && n'exécute la
commande suivante que si la commande précédente a abouti. Par exemple, en
l'absence de connectivité réseau nécessaire à apt pour récupérer les
derniers packages (moquez-vous de moi, je sais très bien que vous devez disposer
d'une connectivité réseau pour vous connecter en premier lieu !), alors il n'y a
aucun intérêt à exécuter la commande install.
Si la commande update est fructueuse, la commande apt détermine ensuite les
packages supplémentaires qu'il lui faut et commence à installer lamp-server.
Pourquoi un symbole caret est-il présent à la fin (^) ? Ce symbole indique à la
commande apt d'installer l'ensemble des packages qui constituent le serveur LAMP,
et pas uniquement un seul package nommé lamp-server.
2 Le programme d'installation peut vous demander un mot de passe, ou utiliser
par défaut un mot de passe MySQL vide. Il n'est pas très sécurisé, et pour une
utilisation réelle en production, vous devez spécifier un mot de passe fort.
Au  chapitre 15, nous monterons en puissance et stockerons un mot de passe fort
et sécurisé dans Azure Key Vault, qui est automatiquement injecté dans
cet Assistant d'installation MySQL.
Cela prend une minute environ pour installer tous les packages de votre pile
Web LAMP. C'est ensuite terminé.
3 Tapez exit pour vous déconnecter de votre machine virtuelle et revenir à l'invite
Cloud Shell.
Très bien ! Votre serveur Web est opérationnel et en cours d'exécution, mais pour l'in-
stant, vous n'êtes pas encore en mesure d'y accéder à partir d'un navigateur Web. Pour
ce faire, vous devez autoriser le trafic Web à atteindre la machine virtuelle.
28 Chapitre 2  Création d'une machine virtuelle

2.5 Comment permettre au trafic Web d'atteindre la machine virtuelle

Votre serveur Web est opérationnel et en cours d'exécution, mais si vous saisissez
l'adresse IP publique de votre machine virtuelle dans un navigateur Web, la page Web
ne se charge pas. Pourquoi  ? Vous vous rappelez des groupes de sécurité réseau
évoqués brièvement dans la section 2.1.5 ? Lorsque vous avez créé la machine virtuelle,
un groupe de sécurité réseau a été généré pour vous. Une règle a été ajoutée pour
permettre la gestion à distance, dans ce cas, SSH.Le reste de la machine virtuelle est
verrouillé. Pour permettre aux visiteurs d'accéder à votre serveur Web via Internet,
vous devez créer une règle dans le groupe de sécurité réseau autorisant le trafic Web.
Sinon, personne ne peut commander de pizzas !
2.5.1 Création d'une règle autorisant le trafic web
Cette section mélange les choses quelque peu en utilisant Azure CLI pour créer une
règle régissant le trafic Web. Vous auriez pu ouvrir ce port HTTP dans le portail lorsque
vous avez créé la machine virtuelle, mais si vous l'aviez fait à ce moment-là, ça aurait été
beaucoup moins intéressant !
L'interface CLI Azure est disponible dans Cloud Shell. Vous n'avez rien à installer.
Le chapitre 5 traite plus en détail les réseaux virtuels et les groupes de sécurité réseau ;
pourl'instant, vous pouvez vérifier à quel point l'interface CLI Azure est rapide et
puissante avec une seule commande.

Tester
Ouvrez Azure Cloud Shell et suivez ces étapes pour voir CLI Azure en action :

1 Si vous avez fermé votre fenêtre Cloud Shell, rouvrez-la à partir du portail Azure.
Assurez-vous que le shell Bash se charge, mais pas PowerShell. Si nécessaire,
passez à la version Bash.
2 Pour voir CLI Azure et les modules installés, tapez az --version. Une liste de
modules et de numéros de version est affichée. Ce qui est génial dans Cloud
Shell, c'est qu'il possède toujours la version la plus récente et la meilleure.
REMARQUE  Si vous êtes attentif, vous avez peut-être constaté que la commande
génère des informations sur la version de Python. Pourquoi cette information est-
elle importante ? Python est un langage de programmation puissant et populaire.
L'interface CLI Azure est écrite en Python, ce qui la rend multiplateforme et
disponible en vue d'une installation locale sur n'importe quel ordinateur si vous ne
voulez pas toujours utiliser Cloud Shell. Pour préserver la volonté de Microsoft de
contribuer à la communauté open source, l'interface CLI Azure est mise
à disposition sur GitHub pour que quiconque puisse apporter des contributions,
des suggestions ou signaler des problèmes (https://github.com/Azure/azure-cli).

3 Pour ouvrir un port, vous spécifiez le nom de la machine virtuelle et son groupe de
ressources, ainsi que le numéro de port. Dans le cas du trafic Web, vous devez ouvrir
le port 80. Saisissez le groupe de ressources (-g) et le nom de machine virtuelle (-n)
que vous avez spécifiés lorsque vous avez créé votre machine virtuelle :
az vm open-port -g azuremolchapter2 -n webvm --port 80

2.5.2 Observation du serveur Web en action

Maintenant que vous avez un port ouvert pour votre machine virtuelle, nous allons
voir ce qui se passe lorsque vous essayez d'y accéder depuis un navigateur Web :
 Exercice : création d'une machine virtuelle Windows 29

1 Sur le portail Azure, sélectionnez votre machine virtuelle si vous avez navigué
hors de celle-ci. L'adresse  IP publique est répertoriée dans le coin supérieur
droit de la page de présentation de la machine virtuelle.
2 Sélectionnez l'adresse et copiez-la.
3 Dans votre navigateur Web, ouvrez un nouvel onglet ou une nouvelle fenêtre,
puis collez-y l'adresse IP publique. Le site Web d'Apache par défaut se charge,
comme illustré à la figure 2.6. Bon c'est vrai, il ne ressemble pas à une pizzeria,
mais les bases sont prêtes sur lesquelles vous pouvez générer votre code et à
commencer à développer votre application !

Figure 2.6  Pour observer votre serveur Web en action et afficher la page par défaut d'Apache 2,
saisissez l'adresse IP publique dans un navigateur Web.

2.6 Exercice : création d'une machine virtuelle Windows

Les sections précédentes ont détaillé les étapes de l'installation de la pile LAMP sur
une machine virtuelle Ubuntu Linux. Il s'agit d'une plateforme commune pour les
sites Web, mais vous pouvez vouloir un peu d'intérêt et d'attention si vous avez un his-
torique Windows ! Vos équipes de développement ou les décideurs de votre entreprise
peuvent vouloir utiliser .NET, par exemple. Ainsi, vous pouvez exécuter .NET Core sur
les machines virtuelles Linux, donc ne laissez pas le langage mener votre décision.
À partir de ce que vous avez appris dans l'exemple étape par étape, essayez de créer
une machine virtuelle qui exécute IIS (Internet Information Services). Voici quelques
suggestions :
¡ Vous avez besoin d'une machine virtuelle qui exécute Windows Server 2019.
¡ Vous utilisez RDP, pas SSH, alors attendez-vous à une expérience de connexion
un peu différente.
30 Chapitre 2  Création d'une machine virtuelle

¡ Dans Server Manager, recherchez une option Ajouter des rôles et des
fonctionnalités.
¡ Il vous faut installer le serveur Web (IIS).
¡ N’oubliez pas d’ouvrir un port réseau pour le trafic HTTP sur le port TCP 80.
Vous pouvez utiliser le portail si vous le souhaitez.

2.7 Nettoyage des ressources

Lorsque vous créez des ressources dans Azure, le compteur de facturation commence
à tourner. Vous êtes facturé à la minute, il est donc sage de prendre de bonnes
habitudes et de ne pas laisser des ressources telles que les machines virtuelles en cours
d'exécution une fois que vous en avez terminé avec elles. Deux façons vous permettent
de mettre fin aux frais de facturation pour l'exécution d'une machine virtuelle :
¡ Annuler l'assignation d'une machine virtuelle. Vous pouvez sélectionner le bouton Arrêter
du portail pour arrêter et annuler l'assignation d'une machine virtuelle, ce qui libère
toutes les ressources de calcul et de réseau détenues.
¡ Supprimer une machine virtuelle. Cette option parle d'elle-même. S'il ne reste rien
dans Azure, il ne reste rien à payer. Assurez-vous que vous n'avez plus besoin d'une
machine virtuelle avant de la supprimer. Il n'existe pas de bouton permettant de
faire marche arrière dans Azure !
Je vous conseille de créer un groupe de ressources pour chaque déploiement
d'application lorsque vous commencez à construire des éléments dans Azure. Au fur et
à mesure que vous progresserez dans les exercices de ce livre, c'est ce que vous ferez. Si
vous nommez vos groupes de ressources par chapitre, par exemple azuremolchapter2,
il vous sera plus facile de suivre vos ressources et ce qu'il faut supprimer. Cette pratique
facilite le nettoyage, car vous pourrez ensuite supprimer l'ensemble du groupe
de ressources à la fin de chaque chapitre. Sélectionnez Groupes de ressources dans
le menu de navigation à gauche de l'écran, ouvrez chaque groupe de ressources que
vous avez créé dans ce chapitre, puis sélectionnez Supprimer le groupe de ressources,
comme illustré à la figure  2.7. Pour confirmer l'opération, vous serez invité à saisir
le nom du groupe de ressources.

Figure 2.7  Pour réduire les coûts, supprimez les groupes de ressources dont vous n'avez plus besoin.

Si vous avez l'habitude de supprimer des ressources une fois que vous en avez terminé
avec elles, vous pouvez sans problème procéder ainsi dans le cadre de la lecture de ce
livre concernant les crédits Azure gratuits. Vous pouvez tout au moins annuler l'assig-
nation de votre machine virtuelle à la fin de chaque leçon, puis la relancer le lende-
main afin de contrôler le compteur de la facturation.
 Houston, nous avons un problème 31

2.8 Houston, nous avons un problème

Parfois, vous rencontrerez des problèmes dans Azure. Ça y est, je l'ai dit. Généralement,
la plateforme Azure permet de traiter correctement les problèmes qui surviennent
lorsque vous créez des ressources :
¡ L'interface CLI Azure ou Azure PowerShell Reports génère un rapport lorsque
vous exécutez des commandes. Lorsque quelque chose ne fonctionne pas
correctement, vous en êtes averti de façon manifeste. Azure PowerShell attire
votre attention avec du joli texte rouge. Vous ne pouvez pas le manquer.
¡ La CLI Azure est peut-être un peu moins explicite, car elle inclut généralement
les réponses effectives aux appels sous-jacents de l'API REST émanant du serveur.
Quand tout est nouveau, il faut parfois quelques succès et quelques échecs pour
comprendre ce qui se passe mal. L'intérêt d'obtenir des réponses de REST est que
vous pouvez copier-coller les messages d'erreur dans votre moteur de recherche
préféré et obtenir des résultats tangibles pour vous aider à résoudre le problème.

Vous RESTez de marbre ? Nous avons de quoi vous convaincre !

Lorsque vous ouvrez une page Web dans votre navigateur, votre ordinateur communique
avec un serveur Web à l'aide du protocole HTTP. Je suis à peu près certain que vous avez
déjà reçu un message d'erreur 404 en voulant consulter un site Web. Ce message
indique que la page Web n'a pas pu être trouvée. Parmi les autres codes d'erreur communs,
citons l'erreur 403 (lorsque vous n'avez pas les autorisations d'afficher la page) et 500
(lorsque le serveur rencontre une erreur).
Même lorsque les choses vont bien, sans que vous le sachiez votre navigateur reçoit des
messages Code 200 lorsque la page se charge bien, ou des messages Code 301 si une
page a été redirigée vers un nouvel emplacement. Vous n'avez pas besoin de
comprendre et de garder une trace de tous ces codes ; c'est juste la façon standard qu'a
le protocole HTTP de faciliter la communication entre ordinateurs.
Plus tôt dans ce chapitre, nous avons parlé de la façon de créer et de gérer des
ressources Azure via le portail Web, CLI ou PowerShell. Tous les services Azure sont
accessibles par les interfaces de programmation d'applications (API) de transfert d'état
représentationnel (REST).
Si tout cela est nouveau pour vous, les API REST sont un moyen (quelque peu)
standardisé d'exposer les services via HTTP. Vous utilisez des demandes HTTP standard
telles que GET et POST pour demander des informations ou apporter une modification, et
une fois que la plateforme accepte et traite la demande, vous recevez un message d'état.
Azure possède un ensemble bien défini d'API REST.
Vous n'avez pas besoin de comprendre ce que tout cela signifie. Il suffit d'avoir
conscience que lorsque vous recevez un message d'erreur, il n'est pas toujours exprimé
dans le format le plus utile et lisible par l'homme. Parfois, vous obtenez une réponse
HTTP brute de l'API REST que vous devez déchiffrer par vous-même. Là encore, collez
cette erreur dans votre moteur de recherche préféré. Il y a une bonne chance que
quelqu'un ait déjà rencontré le problème et ait fourni une explication plus lisible par
l'homme de ce qui s'est (mal) passé et de ce que vous devez corriger.

Les problèmes les plus courants avec les machines virtuelles se produisent lorsque vous
vous y connectez. Vous avez peut-être tenté de vous connecter en vue d'une
administration à distance avec SSH ou RDP, ou vous avez tenté d'accéder à vos
applications via un navigateur Web ou un client de bureau. Ces problèmes sont souvent
liés au réseau. Je ne veux pas non plus totalement incriminer les responsables de
réseau (du moins jusqu'au chapitre 5). Voici donc deux points rapides à vérifier :
32 Chapitre 2  Création d'une machine virtuelle

¡ Pouvez-vous vous connecter à d'autres machines virtuelles Azure ou à des applica-

tions fonctionnant dans Azure ? Si ce n'est pas le cas, un incident local au niveau
de votre réseau empêche probablement l'accès.
Si vous pouvez vous connecter à d'autres ressources Azure, assurez-vous d'avoir
ouvert les règles du groupe de sécurité réseau (section 2.5). Le chapitre 5 aborde
ces règles plus en détail.
¡ Pour les problèmes d'authentification, essayez ce qui suit :
– Vérifiez que vous disposez des bonnes clés SSH. Azure doit vous indiquer lor-
sque vous créez la machine virtuelle si la clé publique n'est pas valide. Si vous
possédez plusieurs clés privées, assurez-vous que vous utilisez la bonne.
– Pour les problèmes RDP, essayez de vous connecter à localhost\<username> et
saisissez votre mot de passe. Par défaut, la plupart des clients RDP tentent de
présenter des informations d'identification locales ou des informations
d'identification réseau, que votre machine virtuelle ne comprendra pas.
 Azure Web Apps

3
Au chapitre  2, vous avez créé une machine virtuelle et installé manuellement des
packages afin d'exécuter un serveur Web de base. Une petite faim ? Avec cette machine
virtuelle, vous pourriez créer une pizzéria en ligne. Les machines virtuelles Azure sont
principalement utilisées pour l'exécution d'applications Web, généralement à grande
échelle. Les applications Web représentent une charge de travail confortable pour les
machines virtuelles. Confortable certes, mais seulement si vous appréciez également la
maintenance qui accompagne la gestion de toutes ces machines virtuelles. Vous savez,
toutes ces choses passionnantes telles que les mises à jour logicielles, les correctifs de
sécurité, la journalisation centralisée et les rapports de conformité. Et si vous pouviez
disposer de la puissance d'un serveur Web sécurisé pour exécuter vos applications Web,
y compris la possibilité de faire évoluer automatiquement votre configuration au gré de
la demande, sans avoir besoin de vous soucier de la création et de la gestion de toutes
ces machines virtuelles ? Permettez-moi de vous présenter le service Azure Web Apps.
Dans ce chapitre, nous allons comparer l'approche IaaS (Infrastructure en tant
que service) des machines virtuelles et des serveurs  Web avec l'approche  PaaS
(Plateforme en tant que service). Vous découvrirez les avantages d'Azure Web Apps à
mesure que vous créerez une application  Web, et verrez comment travailler avec
ses versions de production et de développement. Vous apprendrez ensuite à déployer
automatiquement votre application Web depuis un contrôle de code source tel que
GitHub. Cette charge de travail est illustrée à la figure 3.1. Azure Web Apps vous
permet de déployer et de lancer votre pizzeria en ligne

Créer une App Service Déployer l’exemple App Service

Créer un service applicaon d’applicaon
d’applicaon. Web. depuis GitHub. Applicaon
Plan App Applicaon Web
Service Web
Site

Figure 3.1  Dans ce chapitre, vous allez apprendre à créer un plan de service d'application et une
application Web de base, puis à déployer un site Web à partir de GitHub.

33
34 Chapitre 3  Azure Web Apps

en seulement quelques minutes, sans passer par l'installation ni la configuration d'une

machine virtuelle et de packages de serveurs Web.

3.1 Présentation et concepts d'Azure Web Apps

Avec Azure Web  Apps, vous commencez à découvrir le monde merveilleux des
solutions  PaaS. Si vous pensez que le cloud computing concerne uniquement les
machines virtuelles, vous devriez probablement vous pencher un peu plus sur le sujet.
Au début de ce livre, j'ai parlé d'acheter de la puissance informatique et de mettre
l'accent sur vos applications et vos clients. Lorsque vous évoluez de solutions  IaaS,
comme les machines virtuelles, vers des solutions PaaS, telles que les applications Web,
vos applications et vos clients deviennent votre priorité.
Pour exécuter des applications Web sur des machines virtuelles IaaS, il est nécessaire
de gérer le système d'exploitation, les mises à jour d’application, les règles de sécurité
et de trafic, ainsi que la configuration de l'ensemble du réseau. Avec Web Apps, vous
téléchargez votre application  Web, et toutes ces tâches de gestion sont
prises en charge pour vous. Vous pouvez dorénavant vous concentrer sur l'amélioration
de l'expérience d'application pour vos clients, ou l'amélioration de la disponibilité avec
des options d'évolutivité et une gestion du trafic.
Cela signifie-t-il que vous ne devriez jamais exécuter de machine virtuelle pour
héberger une application Web ? Probablement pas. Il existe des raisons parfaitement
valables d'exécuter l'ensemble de la pile d'application et de la configurer vous-même,
notamment si vous avez besoin d’une prise en charge d’application très spécifique ou
d’un temps d’exécution de langage. Cependant, Web  Apps peut intervenir dans la
majorité des cas d'exécution d'applications Web.
3.1.1 Langages et environnements pris en charge
Quelle flexibilité Web Apps offre-t-il en termes de langages de programmation que vous
pouvez utiliser pour développer votre application Web ? Le choix est large ! Windows et
Linux sont les deux plateformes principales pour exécuter Web  Apps. Vous pouvez
exécuter des applications Web .NET Core, node. js, Python, Java, Ruby et PHP en mode
natif sur des instances d'applications Web Windows et Linux. Sur Windows, vous pouvez
également exécuter l’intégralité de l'infrastructure .NET. Le summum serait d'exécuter
votre application  Web dans des conteneurs. Pour ce faire, il existe Web  Apps for
Containers vous permettant d'exécuter des conteneurs Docker natifs pour Linux. Nous
aborderons plus en détail les conteneurs et Docker au chapitre 19. Tout ce dont vous
devez savoir pour l'instant, c'est que Web Apps vous propose une multitude d'options !
Dans quelle situation Web Apps n'est-il pas utile ? Tous les langages d’application ne
sont pas pris en charge par Web Apps. Imaginons que vous souhaitiez vous torturer
délibérément avec une application Web écrite en Perl. Dans un tel cas de figure, vous
reviendriez probablement à l'utilisation de machines virtuelles IaaS que vous gérez vous-
même, car Perl n'est pas pris en charge par Web Apps. Cependant, Web Apps prend en
charge les langages de programmation les plus courants que vous pourriez vouloir utiliser.
Vous devriez également envisager une version plus récente de votre application.
Web Apps prend non seulement en charge de nombreux langages, mais également
plusieurs versions de ces langages. Prenons l’exemple de PHP. Trois ou quatre versions
sont généralement disponibles, vous permettant ainsi de faire le choix le plus judicieux
pour votre application. Mieux encore, vous n'avez pas à vous soucier des dépendances
au serveur Web sous-jacent pour la prise en charge, comme vous le feriez si vous gériez
la machine virtuelle  IaaS vous-même. Python est un autre exemple des différences
entre les versions stable 2.7 et 3.6 (et versions ultérieures), comme illustré à la figure 3.2.
 Présentation et concepts d'Azure Web Apps 35

Figure 3.2  Sélectionnez une version spécifique du

langage dans les paramètres de l'application
Web Apps.

Web Apps demeure également à jour concernant les correctifs de sécurité. Mais ne vous
attendez pas à ce qu'une ancienne version de PHP ou de Python continue d'être prise en
charge éternellement. À un moment donné, les versions les plus anciennes ne seront
plus prises en charge. Encore une fois, il s'agit d'un cas où vous pourriez revenir à
l'utilisation d'une machine virtuelle  IaaS, si votre application nécessite une ancienne
version d'un langage. Mais si vous avez besoin d'exécuter une ancienne version d'un
langage spécifique afin de prendre en charge une application héritée, ne tombez pas
dans le travers d'adopter une approche de maintenance constante. Cherchez toujours à
déplacer ces applications héritées vers des plateformes prises en charge plus modernes.

3.1.2 Tests des différentes versions grâce aux emplacements de déploiement

Les emplacements de déploiement fournissent un environnement d'essai pour votre
application Web. De cette façon, vous pouvez transférer par push de nouvelles versions
de votre application vers un emplacement de déploiement et les faire fonctionner à
l'aide de variables environnementales ou de connexions de base de données, sans
impacter le site actif. Une fois satisfait de l'aspect et du fonctionnement de la version
dans l'emplacement de déploiement, vous n'avez plus qu'à la basculer vers le site actif en
un clin œil. L'ancienne version du site est alors déplacée vers son propre emplacement
de déploiement, qui devient une version archivée. Vous pouvez au contraire, si cela
s'avère nécessaire, renvoyer l'ancienne version vers l'environnement de production.
Le nombre d'emplacements de déploiement disponibles varie selon le niveau de
l'application Web que vous choisissez. Avec un plus grand nombre d'emplacements de
déploiement, différents développeurs peuvent utiliser plusieurs versions d'essai
pendant leurs tests et évaluer leurs propres mises à jour.

3.1.3 Plans de service d'application

Web Apps fait partie de la grande famille App Service dans Azure. App Service inclut
également Mobile Apps, API Apps et Logic Apps. Toutes ces applications, à l'exception
de Logic Apps, sont disponibles dans l'ensemble des régions couvertes par Azure. Voici
une excellente ressource qui permet de vérifier la disponibilité des services Azure par
zone géographique  : https://azure.microsoft.com/regions/services. De nombreux
services sont disponibles dans le monde entier.
36 Chapitre 3  Azure Web Apps

Lorsque vous devez créer une ressource App Service, telle qu'une application Web,
vous créez ou utilisez un plan de service existant. Le plan de service détermine la
quantité de ressources à votre disposition, dans quelle mesure l'automatisation est
disponible pour dimensionner et sauvegarder votre application Web et à quel point
rendre votre site hautement disponible avec des emplacements intermédiaires et
Traffic Manager (un moyen d’acheminer géographiquement le trafic vers l’instance la
plus proche d'un utilisateur, sujet que nous examinerons au chapitre 11). Comme pour
tout, vous en avez pour votre argent. Votre application et les besoins de votre entreprise
doivent déterminer la quantité de ressources requises et les fonctionnalités
supplémentaires nécessaires. Chaque niveau de service inclut les fonctionnalités des
niveaux inférieurs, avec généralement des ressources disponibles supplémentaires et
une capacité de stockage plus importante.
Les quatre niveaux principaux du plan de service sont les suivants :
¡ Gratuit/partagé : utilise une infrastructure partagée, offre un stockage minimal et ne
bénéficie d'aucune option permettant de déployer différentes versions d'essai,
d'effectuer le routage du trafic ou des sauvegardes. Le niveau Partagé vous permet
d'utiliser un nom de domaine personnalisé et entraîne donc des frais pour ce domaine.
¡ De base : fournit des ressources de calcul dédiées pour votre application Web et
vous permet d'utiliser SSL et de dimensionner manuellement le nombre
d'instances d'application Web que vous exécutez. Les niveaux gratuits/partagés
et de base offrent un bon environnement pour tester le service Web Apps.
Toutefois, je vous déconseille d’y exécuter des charges de travail de production
ou de développement réelles. Les performances ne sont pas un facteur limitant,
mais certaines des fonctions automatisées, telles que les sauvegardes et la mise à
l’échelle, ne seront pas prises en charge.
¡ Standard  : inclut des sauvegardes quotidiennes, un dimensionnement
automatique des instances d'application Web ainsi que des emplacements de
déploiement, et vous permet de router les utilisateurs avec Traffic Manager. Ce
niveau peut être adapté aux applications à faible demande ou aux environnements
de développement dans lesquels vous n’avez pas besoin d’un grand nombre de
sauvegardes ou d’emplacements de déploiement.
¡ Premium  : fournit des sauvegardes plus fréquentes, une capacité de stockage
accrue et un plus grand nombre d'emplacements de déploiement et d'options de
dimensionnement d'instances. Ce niveau est idéal pour la plupart des charges de
travail de production.
La question de l'isolation
Avec des solutions PaaS telles que Web  Apps, l'infrastructure est volontairement
réduite. Comme le laissent entendre les noms de certains niveaux de plan de service,
les applications Web sont exécutées simultanément sur une plateforme partagée de
ressources disponibles. Cela ne signifie pas que les applications Web ne sont pas
sécurisées et que des tierces personnes peuvent consulter vos données
personnelles ! Cependant, pour des raisons réglementaires ou de conformité, vous
pouvez être amené à exécuter vos applications dans un environnement isolé et
contrôlé. Découvrez les environnements App Service : des environnements isolés qui
vous permettent d'exécuter des instances App Service comme des applications Web,
dans une partie séparée d'un datacenter Azure. Vous contrôlez le trafic réseau
entrant et sortant et vous pouvez mettre en place des pare-feu et créer des
connexions réseau privées (VPN) sur vos ressources sur site.
Tous ces composants d'infrastructure sont déjà amplement intégrés avec les
environnements App  Service, mais cette approche fournit un excellent équilibre
lorsque vous souhaitez bénéficier de la flexibilité des solutions  PaaS tout en
conservant des contrôles précis sur le trafic des connexions réseau.
 Création d'une application Web 37

Vous pouvez déjà accomplir beaucoup de choses avec les niveaux Gratuit et De base,
bien que pour les charges de travail de production, les niveaux Standard ou Premium
se révéleront certainement plus appropriés. L'exemple de ce chapitre utilise le niveau
Standard, afin que vous puissiez découvrir toutes les fonctionnalités disponibles.
Lorsque vous utilisez Web Apps avec vos propres applications, vous pouvez définir le
nombre de fonctionnalités dont vous avez besoin et pouvez, en conséquence,
sélectionner le niveau de plan de service le plus approprié.

3.2 Création d'une application Web

Avec la théorie que vous venez d'acquérir, penchons-nous à présent sur une
application  Web en action. Quelques étapes sont nécessaires pour exécuter une
application. Premièrement, vous créez l'application Web de base et observez le site par
défaut dans votre navigateur. Vous utilisez ensuite un exemple de page  Web de
GitHub et faites un push vers Azure. Vos développeurs Web ont peut-être déjà
commencé à élaborer une interface pour votre pizzéria en ligne, afin que votre site soit
prêt à être téléchargé.
REMARQUE  Si vous n'avez jamais utilisé Git auparavant, ne vous en faites pas. Vous
n'avez pas besoin de comprendre ce que fait Git à ce stade, et vous aurez le temps de
découvrir cela plus en détail à la fin de ce chapitre. Learn Git in a Month of Lunchespar
Rick Umali (https://www.manning.com/books/learn-git-in-a-month-of-lunches), est
une excellente introduction à l’utilisation de Git si vous souhaitez en savoir un peu plus.
Cet ouvrage peut être lu gratuitement sur la plateforme Manning liveBook.
3.2.1 Création d'une application Web de base
Comme je l’ai fait au chapitre  2, je vais vous donner quelques conseils,
mais vous verrez surtout si vous êtes capable d'appliquer la théorie sur les temps
d’exécution des applications et les plans de service d’application pour créer une
application Web. Si vous doutez de certaines options, il est plus prudent d’accepter les
valeurs par défaut pour l’instant.

PaaS, et non IaaS

Cette application Web est une nouvelle ressource et n'est pas liée aux machines
virtuelles, comme celles que vous avez pu créer au chapitre 2, lesquelles représentent
une approche IaaS à la création et à l'exécution d'applications Web. Web Apps constitue
l'approche PaaS. Il n'existe pas réellement de relation entre les deux types.
En réalité, si vous avez suivi les conseils dispensés au chapitre 2 et que vous avez
supprimé votre machine virtuelle, cette application Web fonctionne alors sans aucune
machine virtuelle dans votre abonnement Azure !

Tester
Pour créer votre application Web, procédez comme suit :

1 Ouvrez un navigateur Web et accéder à https://portal.azure.com, et connect-

ez-vous à votre compte Azure.
2 Une fois sur le portail, sélectionnez Créer une ressource, dans le coin supérieur
gauche du tableau de bord.
3 Sélectionnez Web dans la liste des ressources que vous pouvez créer, puis choisis-
sez Application Web.
4 Afin de faire en sorte que les choses soient claires et bien organisées, comme au
chapitre 2, je vous suggère de créer un groupe de ressources dédié pour votre
application Web, par exemple azuremolchapter3.
38 Chapitre 3  Azure Web Apps

5 Attribuez un nom unique au monde à l'application Web. Ce nom doit être

unique, car cela crée l'URL de votre application Web sous la forme http://<name>
.azurewebsite.net. Si vous vous posez la question : oui, il est possible d'appliquer
un nom de domaine personnalisé ici. Pour l'instant, utilisez l'adresse par défaut
azurewebsites.net.
6 Vous allez transférer par push un code HTML de base, pas un conteneur Docker.
Regardez toutefois toutes les différentes piles d’exécution disponibles. Vous pouvez
modifier ce paramètre une fois que vous avez créé l’application Web, mais pour
l’instant, choisissez un temps d’exécution ASP.NET qui s’exécute sur Windows.
7 Laissez Azure créer automatiquement un plan de service d’application, en
modifiant simplement la taille à la taille Standard S1. Ce niveau fournit toutes les
fonctionnalités de base sans proposer trop de ressources pour votre site de
démonstration de base. Dans les déploiements réels, cette procédure permet de
créer et de configurer manuellement vos propres plans de service d’application
ou de sélectionner un plan existant.
8 Lorsque vous êtes prêt, examinez et créez votre première application Web.

Votre service d'application est créé en quelques secondes. Lorsque vous êtes prêt,
accédez à App Services et sélectionnez-la dans la barre de navigation, à gauche de
l’écran. Choisissez ensuite votre application Web dans la liste. Dans la fenêtre Vue
d'ensemble de votre application Web, affichez et sélectionnez l'URL de l'application,
telle que https://azuremol.azurewebsites.net.
Lorsque vous sélectionnez l'URL de votre application Web, un nouvel onglet ou une
nouvelle fenêtre s'ouvre dans votre navigateur. La page par défaut de l'application se
charge, comme illustré à la figure 3.3. Toujours aucune trace de pizza. . . .

Figure 3.3  Pour voir la page par défaut de l'application Web en action, accédez à l'URL de votre site via
un navigateur Web.
 Création d'une application Web 39

3.2.2 Déploiement d'un exemple de site HTML

Certes, vous avez maintenant une application  Web dans Azure, mais il s'agit du
monotone site Web par défaut. Comment obtenir son propre site Web dans Azure ?
L'une des méthodes multiplateformes les plus courantes est d'utiliser Git. La majorité
des développeurs et des équipes en charge des applications utilisent un système de
contrôle de code source. Plutôt que de stocker des fichiers sur votre ordinateur et
d'enregistrer les modifications au fur et à mesure, les systèmes de contrôle de code
source gardent une trace des modifications et vous permettent de collaborer avec
d'autres personnes. Vous pouvez créer des versions de test qui n'auront aucun impact
sur votre code de production, et vous pouvez restaurer une version antérieure si des
problèmes surviennent. Git est l'un des systèmes de contrôle de code source les plus
utilisés. GitHub est un service basé sur le cloud qui vous permet de partager du code
avec le reste du monde et d'y contribuer. Microsoft a fait l'acquisition de GitHub en
juin 2018, mais rien ne vous oblige à utiliser GitHub avec Azure, ou vice versa. Tous les
exemples donnés dans ce livre sont disponibles dans GitHub.
Pour cet exemple, vous créez une copie locale de l'exemple de site HTML statique,
puis vous transférez par push les fichiers vers votre application Web Azure. Cette charge
de travail est illustrée à la figure 3.4.

Copie des
Exemples de Créer une fichiers dans
git clone git push
fichiers HTML copie locale l’applicaon
dans GitHub. des fichiers. Web Azure.

Figure 3.4  Vous créez une copie locale des fichiers d'exemple à partir de GitHub avec la commande git
clone. Pour transférer par push ces fichiers locaux sur votre application Web Azure, utilisez git push.

Tester
Pour obtenir une copie de l'exemple de page HTML depuis GitHub et la transférer par
push vers votre application Web, procédez comme suit :

1 Ouvrez Cloud Shell dans le portail Azure, puis attendez quelques secondes que
votre session se connecte. Pour commencer, vous devez obtenir l'exemple de
site HTML de GitHub.
Pour clonerou copier l'exemple de site HTML de GitHub, entrez la commande
suivante :
git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

Si vous utilisez Git dans Cloud  Shell pour la première fois, vous devez définir
certains paramètres pour permettre à Git de comprendre qui vous êtes. Pour la
plupart des exercices dans ce livre, Git ne s'intéresse pas vraiment à votre identité ;
mais pour une utilisation avec vos propres projets et applications, c'est une
excellente façon de suivre qui effectue certaines actions dans un système de
contrôle de code source. Vous n'avez besoin de définir ces paramètres qu'une
seule fois. Entrez votre propre adresse e-mail et votre nom complet dans git
config comme suit :
40 Chapitre 3  Azure Web Apps

git config --global user.email "iain@azuremol.com"

git config --global user.name "Iain Foulds"

2 Accédez au répertoire azure-mol-samples-2nd-ed qui a été créé lorsque vous avez

cloné le référentiel Git :
cd azure-mol-samples-2nd-ed/03/prod

3 Pour être prêt à télécharger les exemples de page HTML, vous devez initialiser
Git, puis ajouter et valider vos fichiers. À ce stade, ne vous souciez pas trop des
commandes Git  ! Vous devez indiquer à Git quels fichiers suivre et ajouter, et
trouver un moyen de suivre ces changements plus tard si nécessaire :
git init && git add . && git commit -m "Pizza"

4 Vous pouvez maintenant vous préparer à transférer par push cet exemple de
site HTML vers votre application Web. Tout d’abord, définissez les informations
d’identification de déploiement. Pour sécuriser Web Apps lorsque vous utilisez
une méthode de déploiement comme Git ou FTP, vous devez fournir un nom
d’utilisateur et un mot de passe. Web Apps peut utiliser un ensemble
d’informations d’identification valides à travers tous les plans de service
d’application dans Azure ou des informations d’identification au niveau de
l’application qui s’appliquent uniquement à une seule application.
Dans le monde réel, je vous recommande d’utiliser des informations
d’identification au niveau de l’application pour minimiser l'ampleur d’une
attaque si l’une des informations d’identification est compromise. Azure génère
automatiquement les informations d’identification au niveau de l’application,
mais vous devez récupérer et attribuer ces informations d’identification à chaque
fois. Pour simplifier les choses, utilisez des informations d'identification
définies que vous pourrez réutiliser dans les prochains chapitres.
Créez les informations d'identification de déploiement et indiquez votre propre
nom d'utilisateur et un mot de passe sécurisé. Le nom d'utilisateur doit être unique
au monde. Si cela peut vous aider, ajoutez vos initiales au nom d’utilisateur ou à une
convention de nommage qui correspond à votre environnement.
az webapp deployment user set --user-name azuremol --password @azurem0l!

5 Vous devez ensuite obtenir l’URL du référentiel Git de votre application Web.
Saisissez le nom de l’application Web (pas le nom d’utilisateur que vous avez créé
à l’étape 4) et le groupe de ressources que vous avez spécifié lors de la création
de l’application Web pour afficher l’URL du référentiel Git.

Pourquoi ce regard oblique ?

Dans l'exemple suivant et les prochains chapitres, la barre oblique inverse (\) signifie
que la commande se poursuit à la ligne d’après. C’est une façon d’encapsuler de
longues lignes. Cette approche est d’ailleurs utilisée dans un grand nombre d’échantil-
lons en ligne où vous pouvez copier/coller les commandes. Vous n’êtes pas obligés de
taper les barres obliques inverses présentes dans les exemples de ce livre ! Il suffit de
continuer à taper les paramètres supplémentaires comme des éléments faisant partie
d’une seule longue ligne.
Si vous utilisez l’invite de commande Windows plutôt qu’un shell Bash, n’incluez pas
les barres obliques inverses. Sinon vous n’obtiendrez vraiment pas le résultat escompté !
 Création d'une application Web 41

az webapp deployment source config-local-git \

--name azuremol \
--resource-group azuremolchapter3 -o tsv

6 Votre application Web est configurée pour fonctionner avec les référentiels Git,
vous devez donc indiquer le référentiel au Cloud Shell. Dans Git, vous définissez
ces emplacements comme distants.
Copiez l'URL de votre clone Git créée à l'étape 5, puis définissez cette URL
comme destination pour l'exemple de site HTML dans Cloud Shell à l'aide de la
commande suivante :
git remote add azure your-git-clone-url

7 Pour télécharger ou copier des fichiers avec Git, vous devez les transférer par
push. Où Git fait-il un push de ces fichiers ? Dans un référentiel distant comme celui
que vous avez configuré à l'étape  6, comme Azure. La dernière partie de
la commande est une branche, généralement maître. Dans Git, une branche est
ce qui permet de suivre les différents modèles de travail en cours. Une bonne
pratique dans les environnements de production est de faire un push pour
libérer des branches que vous pouvez nommer comme vous le souhaitez, par
exemple dev ou staging. Ces branches supplémentaires permettent à votre code
de production d'être exécuté normalement ; vous pouvez ensuite travailler sur
de nouvelles fonctionnalités ou mises à jour en toute sécurité et sans impacter les
charges de travail réelles utilisées par vos clients.
Transférez par push l'exemple de site HTML vers votre application Web :
git push azure master

8 Lorsque vous y êtes invité, saisissez le mot de passe que vous avez créé pour les
informations d'identification de déploiement. Vous pouvez copier et coller le
mot de passe pour minimiser les erreurs.
Vous pouvez voir à partir du résultat que la page par défaut existante du site Web est
supprimée et que l'exemple de site  HTML est téléchargé, configuré et prêt à être
exécuté. Voici quelques exemples de résultat :
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 510 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Updating branch 'master'. remote: Updating submodules.
remote: Preparing deployment for commit id 'dda01e9d86'.
remote: Generating deployment script.
remote: Generating deployment script for Web Site
remote: Running deployment command...
remote: Handling Basic Web Site deployment.
remote: Creating app_offline.htm
remote: KuduSync.NET from: 'D:\home\site\repository' to:
'D:\home\site\wwwroot'
remote: Deleting file: 'hostingstart.html'
remote: Copying file: 'index.html'
remote: Deleting app_offline.htm
remote: Finished successfully.
remote: Running post deployment command(s)...
remote: Deployment successful.
To https://azuremolikf@azuremol.scm.azurewebsites.net/azuremol.git
  * [new branch] master -> master
42 Chapitre 3  Azure Web Apps

Pour voir le résultat de votre application Web mise à jour, actualisez votre site dans un
navigateur Web ou ouvrez-le de nouveau à partir de la fenêtre Vue d'ensemble, dans le
portail Azure. Celui-ci devrait ressembler au magnifique exemple de la figure 3.5. En
effet, le site est très rudimentaire, mais que ce soit pour déployer le plus basique des
sites HTML statiques ou une application Web Node.js ou .NET complexe, la charge de
travail reste la même !

Figure 3.5 Actualisez
votre navigateur Web
pour constater que
la page par défaut
de l'application Web
a été remplacée par
le site HTML statique
de base de GitHub.

3.3 Affichage des journaux de diagnostic

Maintenant que vous avez vu comment créer une application Web de base et déployer un
site HTML simple, qu'en est-il de la gestion générale ? Si vous rencontrez des problèmes, il
peut se révéler utile de consulter les journaux du serveur Web ou des applications. Pour
faciliter la résolution des problèmes de vos applications, vous pouvez écrire le résultat de
votre application dans ces fichiers journaux. Les fichiers journaux peuvent être visualisés
en temps réel ou consignés dans des fichiers journaux et revus ultérieurement.
Votre application  Web fonctionne en grande partie toute seule. En termes de
maintenance de l'hôte Web sous-jacent, vous n'avez pas grand-chose à faire. Si votre
application rencontre des difficultés, vous voudrez peut-être consulter les journaux
pour voir ce qui se passe et résoudre le problème. Avec Azure Web Apps, vous pouvez
configurer des options comme le niveau des messages de journaux à réviser,
l'emplacement de stockage des journaux et leur durée de conservation. La figure 3.6
explique comment générer et consulter des fichiers journaux avec Web Apps.

Événements
d’application diffusés
dans les journaux Journaux
d’application
Journaux Accès via
Application collectés en
temps réel pour FTP ou flux
Web Azure examen en direct
Événements de s
Journaux de
erveur diffusés serveur Web
dans les journaux

Figure 3.6  Votre application peut générer des journaux d'applications et des journaux de serveur. Pour
vous aider à examiner ou résoudre des problèmes, vous pouvez télécharger ces journaux via FTP ou les
consulter en temps réel.
 Affichage des journaux de diagnostic 43

Tester
Pour configurer votre application Web pour les journaux de diagnostic, procédez comme suit :

1 Dans le portail Azure, sélectionnez l'application Web que vous avez créée dans
l'exercice précédent.
2 Faites défiler la fenêtre Vue d'ensemble jusqu'à la section Surveillance et
sélectionnez Journaux App Service.
3 Examinez les options de journal disponibles, telles que le niveau de détail et si
vous souhaitez activer ou non le suivi des demandes ayant échoué. Si vous traitez
avec la partie infrastructure d'Azure, vous devrez peut-être collaborer avec vos
développeurs d'applications afin de déterminer les journaux dont ils ont besoin
pour aider à résoudre les problèmes. Vous pouvez ensuite activer ici la
journalisation appropriée. Les journaux peuvent être stockés dans le système de
fichiers local de l’application Web ou transférés par push vers le Stockage Azu
pour être traités avec une autre application.
4 Pour l’instant, activez la journalisation de l’application (système de fichiers).
Activez également la journalisation du serveur Web vers le système de fichiers
avec une période de rétention de sept jours. Le niveau d’erreur par défaut est
susceptible de ne rien montrer si tout fonctionne correctement. Attention
toutefois lors de l'activation du Débogage ou du suivi, car vos journaux peuvent
se remplir rapidement et il est difficile de se recompte de la situation ! Si vous
rencontrez un problème, augmentez graduellement le niveau du journal jusqu’à
ce que vous capturiez suffisamment d’informations pour résoudre les problèmes
sans être submergé par les données du journal.
Si vous souhaitez explorer en détail les données, vous pouvez accéder aux journaux
stockés sur le système de fichiers à l’aide de FTP. Les adresses FTP sont affichées dans
la section Télécharger les journaux ou dans la fenêtre Vue d’ensemble de l’application
Web. Peut-être que vous vous dites : « Le FTP est un moyen compliqué d'obtenir des
journaux de diagnostic. N'existe-t-il pas une méthode plus simple ? » Eh bien, figurez-
vous que si ! Vous pouvez trouver une option Flux de journaux dans le portail Azure, à
l'endroit précis où vous avez configuré vos journaux de diagnostic. Pouvez-vous
deviner son utilité ? Laissez-moi vous donner un indice : cela a quelque chose à voir
avec le flux de vos fichiers journaux.
Si vous sélectionnez ce bouton dans le portail Azure, vous pouvez choisir entre les
Journaux d'applications et les Journaux de serveur Web. Ces journaux accèdent en
lecture à partir des mêmes journaux de diagnostic qui sont écrits dans le fichier.
L'affichage des données dans le flux peut nécessiter quelques minutes, et ce qui est
affiché varie selon les niveaux de journalisation que vous définissez et si votre
application Web génère des événements d'application. Pour le site HTML de base, le
flux est plutôt ennuyeux, mais c'est une fonctionnalité intéressante à utiliser dans votre
navigateur Web. La figure 3.7 illustre un exemple de flux des journaux de serveur Web
dans le portail Azure.
44 Chapitre 3  Azure Web Apps

Tester
Affichez le flux des fichiers journaux dans le portail Azure. Vous devrez peut-être
actualiser plusieurs fois la page dans votre navigateur Web pour générer de l'activité
dans les journaux.

Figure 3.7  Vous pouvez consulter les flux de journaux dynamiques du serveur Web Web Apps depuis
votre application afin de faciliter la vérification et le débogage des performances des applications. La
console située sur la partie droite de l'écran présente le flux de journaux en temps réel depuis votre
application Web.

Une fois que vous serez habitué à Azure et à l'utilisation des modules CLI Azure ou
Azure PowerShell, vous pourrez exploiter ces outils pour diffuser des journaux. Les
développeurs peuvent aussi activer le débogage distant avec Visual  Studio, ou
configurer Application Insights pour autoriser une application  Web à fournir des
mesures de télémétrie à des services supplémentaires, à des fins de surveillance et de
diagnostic. Le point important à retenir est que lorsque vous évoluez vers des
solutions  PaaS, comme les applications  Web, vous pouvez toujours obtenir des
journaux de diagnostic et des données d’application afin de résoudre les problèmes
et de surveiller les performances de votre application Web.

3.4 Exercice pratique : création et utilisation d'un emplacement

de déploiement
Nous sommes parvenus à créer un site HTML simple et à transférer par push la page
vers Azure Web Apps avec Git. Comment faire si vous souhaitez maintenant ajouter
quelques nouvelles pizzas à la carte et pouvoir les consulter avant de rendre le site actif
pour les clients ? Découvrez comment utiliser un emplacement de déploiement qui
nous servira d'espace pour télécharger vos modifications, les réviser, puis les basculer
vers l'environnement de production :
 Exercice pratique : création et utilisation d'un emplacement de déploiement 45

1 Dans votre application Web, choisissez Emplacements de déploiement. Ajoutez

un emplacement de déploiement nommé Dev, mais ne clonez aucun paramètre
de l’emplacement de déploiement existant.
2 Lorsque vous êtes prêt, sélectionnez l’emplacement de test dans la liste. Le
portail affiche les mêmes options de configuration et de journalisation que celles
de l’emplacement de production. Vous pouvez ainsi savoir comment modifier les
paramètres dans cet emplacement de déploiement sans affecter le site actif.
3 Cette fois, explorez les options du portail Azure pour le centre de déploiement.
Vous devez utiliser Git local pour contrôler le code source qui utilise le service de
développement App Service pour l'emplacement de test. Cela s'est passé en
coulisses lorsque vous avez utilisé CLI Azure dans l’exercice précédent. Vous avez
toutefois d’autres options quant aux emplacements à partir desquels vous pouvez
déployer votre code et au service qui conçoit et crée ce déploiement.
4 Une fois terminé, copiez l’Uri du clone Git , par exemple https://azuremol-dev.
scm.azurewebsites.net:443/azuremol.git. Notez que le référentiel Git inclut le
-dev pour l’emplacement de test.
Un exemple de site de développement est inclus dans les exemples GitHub
que vous avez clonés précédemment.
5 Dans Azure Cloud Shell, modifiez le répertoire de développement comme suit :
cd ~/azure-mol-samples-2nd-ed/03/dev

6 Comme précédemment, initialisez, ajoutez et validez vos modifications dans Git

avec les commandes suivantes :
git init && git add . && git commit -m "Pizza"

7 Créez un lien vers le nouveau référentiel Git dans votre emplacement de test
avec git remote add dev, suivi de l'URL de déploiement Git de votre
emplacement de test.
8 Utilisez la commande git push dev master pour transférer par push vos
modifications vers l'emplacement de déploiement.
9 Sélectionnez l'URL de votre emplacement de test à partir de la fenêtre Vue
d'ensemble du portail Azure. Même s'il ne s'agit pas d'un changement
important, le titre de la page indique qu'il s'agit de version de
développement.
10 Dans le portail Azure pour l’application
Web, que se passe-t-il si vous
sélectionnez le bouton Échanger, comme
illustré à la figure  3.8  ? Sélectionnez-le,
puis actualisez la page principale, par
exemple https://azure- mol.azurewebsites.
net, dans votre navigateur Web.

Figure 3.8  Lorsque vous échangez des emplacements pour

une application Web, vous choisissez les instances source et
de destination à modifier. Vous pouvez également prévisualiser
le nouvel aspect avant de valider les modifications.
46 Chapitre 3  Azure Web Apps

Dans les coulisses des emplacements de déploiement

Lorsque vous échangez des emplacements, le contenu actif qui était auparavant dans
l'emplacement de production se trouve dorénavant dans l'emplacement de
développement, et inversement. Tous les paramètres ne peuvent pas être échangés (les
paramètres SSL et les domaines personnalisés, par exemple). Cependant, dans
l'ensemble, les emplacements de déploiement sont une excellente façon d'organiser et
de valider le contenu avant qu'il ne soit mis en ligne et accessible par vos clients. Vous
pouvez également effectuer un échange avec aperçu, qui vous offre la possibilité de
vous assurer que le contenu échangé fonctionne correctement avant qu'il ne soit
transféré publiquement et actif dans l'environnement de production.
Pour une utilisation en production dans des workflows DevOps, vous pouvez également
configurer la fonctionnalité Échange automatique. Ici, lorsqu'une validation de code
est inscrite dans le système de contrôle de code source tel que GitHub, cela peut générer
une build vers un emplacement de déploiement Azure Web Apps. Une fois la
build terminée et l'application prête à être déployée, les emplacements de déploiement
sont  échangés automatiquement afin de rendre le code
actif dans l'environnement de production. Cette charge de travail est généralement
utilisée avec un environnement de test afin de réviser les modifications apportées au code
en premier lieu, et non pas pour publier du contenu directement vers l'environnement de
production !
 4
Présentation de
Stockage Azure

Il y a une chose dans le monde de l’informatique dont nous pouvons être certains :

quand les choses tournent mal, le stockage et le réseautage sont inévitablement
coupables. Et je le dis alors que j’ai moi-même endossé le costume d’administrateur
SAN dans une de mes vies passées ! J’étais le meilleur ami de l’équipe de gestion de
réseau. Je ne plaisante qu’à moitié (à propos d’être meilleurs amis), la qualité de la
construction et de l’écriture d’une application importe peu  : les composantes
fondamentales de l’infrastructure doivent être en place pour la soutenir. Ne m’en
voulez pas pendant que nous explorerons Stockage Azure et Azure  Networking
dans les deux prochains chapitres. Vous êtes peut-être tenté de vous débarrasser de
ces services pour passer aux trucs sympas des chapitres suivants, mais ça vaut le coup
de prendre un certain temps pour découvrir et étudier ces services essentiels. Ça ne
donnera pas un meilleur goût à votre cuisine, mais ça pourrait aider vos clients
quand ils commandent de délicieuses pizzas !
Dans ce chapitre, nous examinons les différents types de stockage dans Azure et le
moment opportun pour les utiliser. Nous abordons également les options de
redondance et de réplication pour le service Stockage Azure ainsi que la façon
d’obtenir les meilleures performances pour vos applications.
4.1 Disques gérés
Il y a quelques années, le stockage sur serveur était coûteux, lent et trop compliqué.
Il n’était pas rare qu’un fournisseur de stockage vous vende du matériel valant des
centaines de milliers de dollars et dont la configuration confiée à une armée de
consultants et ingénieurs prenait des jours, voire des semaines. Lorsque la
virtualisation a commencé à s’implanter dans le datacenter et que VMware et
Hyper-V ont commencés à être acceptés, le stockage est souvent devenu le goulot
d’étranglement. Et c’est sans parler de l’inadéquation entre les micrologiciels et les
adaptateurs de stockage dans le serveur et dans la baie de stockage, de la défaillance
des chemins de réseau redondants ni du fait que les SSD sont considérés comme la
seule façon d’améliorer les performances.
Azure a-t-il miraculeusement résolu tous ces problèmes de stockage ? Bien sûr que
non ! Mais il évacue 95 % de ces soucis et vous permet de vous concentrer sur la

47
48 Chapitre 4  Présentation deStockage Azure

conception et la création de superbes expériences pour vos clients. Ce chapitre couvre

les 5 % restant auxquels vous devez être attentifs.
Le service Disques gérés Azure simplifie l’approche du stockage sur machines virtuelles. Les
disques gérés éliminent une grande partie du travail réalisé en arrière-plan pour vous offrir. . . eh bien,
un disque. C'est tout ce dont vous devez savoir concernant les machines virtuelles : leur taille et leur
rapidité, et à quoi elles sont connectées. Tout au long du livre, et au sein de tous vos propres
déploiements dans le monde réel, les disques gérés doivent toujours être utilisés pour les machines
virtuelles. Les disques gérés constituent l’option par défaut, et rares sont les bonnes raisons de
modifier ce comportement.
Avant l'existence des disques gérés, vous deviez créer un compte de stockage nommé de
manière unique, limiter le nombre de disques virtuels créés dans chaque compte et déplacer
manuellement des images de disque personnalisées pour créer des machines virtuelles dans
différentes régions. Ces types de disques sont connus sous le nom de disques non gérésou disques
classiques. Avec le service de disques gérés, il n’y a plus besoin d’un compte de stockage, vous êtes limité
à 50 000 disques « seulement » par abonnement et vous pouvez créer des machines virtuelles à
partir d’une image personnalisée dans différentes régions. Vous avez également la possibilité de
créer et d’utiliser des instantanés de disques, de chiffrer automatiquement les données stockées
et d’utiliser des disques d’une capacité allant jusqu’à 64 Tio.
Pourquoi est-ce important ? Si vous lisez de la documentation ou des billets de blog qui ne sont
plus d'actualité, ils peuvent vous recommander de créer un compte de stockage pour vos machines
virtuelles. Arrêtez-vous tout de suite  ! Oui, vous pouvez convertir des machines virtuelles pour
passer de disques non gérés à des disques gérés, mais si vous partez de zéro, envisagez de commencer
chaque projet avec des disques gérés dès le début. Les disques non gérés sont plutôt utilisés pour
maintenir la rétrocompatibilité avec les déploiements existants. Mais à mon avis, vous devriez plutôt
chercher à convertir ces charges de travail vers des disques gérés !

4.1.1 Disques du système d’exploitation

Vous vous souvenez de ce que j’ai dit plus tôt concernant le fait que si vous vouliez la meilleure
performance possible, vous deviez acheter une solution SSD ? Il n’y a pas de solution miracle
pour contourner cette exigence dans Azure. Désolé. La vérité est que les SSD surpassent de loin
les disques durs mécaniques ordinaires. Il y a des limites physiques à la vitesse à laquelle ces
disques mécaniques peuvent. . . eh bien, tourner. Les ingénieurs de Microsoft n’ont pas encore
été en mesure de s’affranchir des lois de la physique ! Les disques durs mécaniques standard
conservent une utilité dans certains cas, comme le stockage d'archives à faible coût, et tout
comme dans les baies de stockage ordinaires, les dernières technologies peuvent fournir de
bonnes performances à partir d’un pool de disques mécaniques.
La première, et principale, décision à prendre pour une machine virtuelle Azure est le type de
stockage à utiliser :
¡ Disques SSD Premium : utilisez des disques SSD haute performance pour des performances
optimales, un IOPS (nombre d’opérations d’entrée/sortie par seconde) plus élevé et une
faible latence. C’est le type de stockage recommandé pour la plupart des charges de travail.
¡ Disques SSD standard : utilisation de disques SSD standard qui offrent des performances
cohérentes par rapport aux disques durs (HDD). Ces disques conviennent parfaitement
aux charges de travail de développement et de test, ou à un usage de production à faible
demande et respectueuse du budget.
¡ Disques durs HDD standard : utilisez des disques durs mécaniques ordinaires pour des don-
nées dont l’accès est ponctuel, telles que des archives ou des sauvegardes.
La taille de machine virtuelle choisie aide à déterminer le type de stockage que vous pouvez
sélectionner. Au chapitre  2, vous avez choisi une taille pour obtenir rapidement une machine
virtuelle, lorsque vous l’avez créée. La taille par défaut était probablement quelque chose comme
une machine virtuelle de série D2S_v3, qui vous a donné accès à des disques SSD premium. Comment
savoir quelles machines virtuelles peuvent accéder aux disques SSD Premium  ? Cherchez un s,
désignant SSD, dans la taille de la machine virtuelle. Même si cette règle connaît quelques exceptions,
c'est un bon modèle à suivre. Les exemples suivants vous aident à identifier les machines virtuelles
qui accèdent aux disques Premium et celles qui accèdent aux disques SSD ou HDD standard :
 Disques gérés 49

¡ Les machines virtuelles des séries D2S_v3, Fs, GS, et Ls peuvent accéder aux
disques SSD Premium.
¡ Les machines virtuelles des séries D, A, F et M ne peuvent accéder qu’aux disques
SSD ou HDD standard.
Même si vous sélectionnez une taille de machine virtuelle qui peut utiliser des disques
SSD Premium, il n’y a aucune obligation de le faire. Vous pouvez créer et utiliser des
disques SSD ou HDD standard. En choisissant des disques SSD Premium, vous
pérennisez l’application et vous vous donnez la possibilité d’utiliser des disques SSD
haute performance en cas de besoin, sans avoir à redimensionner vos machines
virtuelles ni à subir un peu de temps d’arrêt dans le processus. Les disques SSD
standard sont utilisables dans toutes les tailles de machines virtuelles.

Disque de système d’exploitation éphémère

Il existe un type spécial de disque de système d’exploitation appelé disque éphémère. Il s’agit
toujours d’un disque géré, en quelque sorte, mais il est local à l’hôte Azure sous-jacent. C'est
la raison pour laquelle un disque éphémère est très rapide, en présente une faible latence.
Étant donné que les données ne sont pas écrites dans une baie de stockage distante, les
données sont susceptibles de ne pas persister lors des redémarrages des machines
virtuelles si vous passez à un autre hôte sous-jacent. Les disques éphémères sont
idéaux pour les charges de travail sans état qui peuvent gérer le démarrage avec une
image propre chaque fois, sans avoir besoin de stocker des données localement pour
y accéder après les redémarrages.
Seules certaines tailles de machines virtuelles prennent en charge les disques
éphémères. Leur utilisation n'engendre aucun coût supplémentaire et ils sont
disponibles dans toutes les régions. Même si vous perdez certaines fonctionnalités dans
certains cas, notamment pour AzureSite Recovery et Chiffrement de disque Azurez
(chapitres 13 et 14, respectivement), les disques éphémères offrent un stockage
à grande vitesse et à faible latence.

Tester
Comment savoir à quelles tailles de machines virtuelles vous avez accès ? Ouvrez
Cloud Shell dans le portail Azure. Entrez la commande suivante (n’hésitez pas à utiliser
votre propre région) :
az vm list-sizes --location eastus --output table

Rappelez-vous que toutes les tailles comprenant un s vous donnent accès à des disques
SSD Premium.

4.1.2 Disques temporaires et disques de données

Maintenant que vous avez pu définir quel type de performance vous aviez besoin pour
vos applications, abordons une autre paire de composants. Les disques sont connectés
de deux manières différentes :
¡ Disques temporaires  :chaque machine virtuelle possède automatiquement un
stockage SSD local attaché à l’hôte sous-jacent. Il offre un petit volume de stockage
haute performance. Faites très attention quand vous utilisez ce disque temporaire !
Comme son nom l’indique, ce disque ne va pas forcément rester avec la machine
virtuelle. Si la machine virtuelle est déplacée vers un nouvel hôte lors d’une
opération de maintenance, un nouveau disque temporaire lui sera associé, et toutes
les données que vous stockerez seront perdues. Le disque temporaire est conçu
comme un espace de travail ou comme un cache de l’application.
50 Chapitre 4  Présentation deStockage Azure

¡ Disques de données : tous les disques que vous créez et associez spécifiquement à la
machine virtuelle agissent comme prévu en termes de partitions, de systèmes de
fichiers et de points de montage persistants. Les disques de données sont réassociés
lorsque l’ordinateur virtuel est déplacé au sein du datacenter Azure. Ils sont donc
là où la majeure partie de vos applications et données doivent être stockées. Vous
avez toujours la possibilité d’utiliser des espaces de stockage ou un logiciel RAID
pour regrouper les disques de données au niveau de la machine virtuelle afin
d’accroître encore la performance.
Un type spécifique de disque de données pouvant être associé à une machine virtuelle
vous offre des performances maximales et une faible latence : les disques Ultra. Ces
disques sont encore plus performants que les disques SSD Premium et sont disponibles
uniquement pour les disques de données. Les disques Ultra sont conçus pour les
grandes bases de données et les charges de travail gourmandes en données, comme
SAP HANA. De quelle vitesse parlons-nous ? Au moment où ce document a été rédigé,
les disques Ultra présentent une taille maximale de 64  Tio de taille offrent jusqu’à
160 000 IOPS par disque avec un débit maximal de 2 000 Mbits/s.
4.1.3 Options de mise en cache du disque
Il importe également de prendre en considération le disque du système d’exploitation
associé à la machine virtuelle. Lorsque vous créez une machine virtuelle, vous obtenez
toujours au moins un disque  : le disque où le système d’exploitation lui-même est
installé. Il est tentant d’utiliser ce disque pour y installer vos applications ou écrire des
fichiers journaux. À moins que ce soit pour un petit déploiement de proof-of-concept,
n’exécutez pas vos applications sur le disque du système d’exploitation ! Il y a de fortes
probabilités que vous n’obteniez pas la performance escomptée.
Les disques dans Azure peuvent avoir été définis avec une stratégie de mise en cache.
Par défaut, le paramètre de cache en lecture/écriture est activé sur les disques du système
d’exploitation. Ce type de mise en cache n’est généralement pas l’idéal pour les charges
de travail de l’application qui écrivent des fichiers journaux ou des bases de données,
par exemple. Les disques de données, en revanche, ont une stratégie de cache
paramétrée par défaut sur Aucun. Il s’agit d’une bonne stratégie pour les charges de
travail qui effectuent beaucoup d’écritures. Vous pouvez également appliquer une
stratégie de cache en lecture seule, mieux adaptée aux charges de travail de l’application
qui effectuent principalement de la lecture de données sur les disques.
De manière générale, associez et utilisez toujours des disques de données pour
installer et exécuter vos applications. Même la stratégie de cache paramétrée par défaut
sur Aucun offre probablement de meilleures performances que la stratégie de cache en
Lecture/Écriture du disque du système d’exploitation.
4.2 Ajout de disques à une machine virtuelle
Cette section explique comment ajouter des disques à une machine virtuelle à mesure
que vous la créez. Au chapitre 2, vous avez créé une machine virtuelle grâce au portail
Azure. Cette fois, nous allons utiliser la CLI Azure pour créer une machine virtuelle.
La CLI Azure fournit un moyen rapide de créer une machine virtuelle et d'associer un
disque de données en même temps.

Tester
Pour créer une machine virtuelle et voir les disques de données à l’œuvre, procédez
comme suit :

1 Dans Azure Cloud Shell, créez un groupe de ressources à l’aide de la commande

az  group create, en fournissant un nom et un emplacement au groupe de
ressources :
az group create --name azuremolchapter4 --location eastus
 Ajout de disques à une machine virtuelle 51

2 Créez une machine virtuelle à l’aide de la commande az vm create. Le paramètre

final, --data-disk-sizes-gb, vous permet de créer un disque de données
parallèlement à la machine virtuelle. Dans l’exercice pratique à la fin du chapitre,
vous pouvez vous connecter à cette machine virtuelle et initialiser les disques.
¡ Pour cet exercice, créez une machine virtuelle Linux ou Windows Si vous êtes à
l’aise avec Linux ou si vous voulez apprendre à initialiser et à préparer un dis-
que pour Linux, utilisez la commande suivante pour créer une machine virtu-
elle Ubuntu LTS :
az vm create \
--resource-group azuremolchapter4 \
--name storagevm \
--image UbuntuLTS \
--size Standard_B1ms \
--admin-username azuremol \
--generate-ssh-keys \
--data-disk-sizes-gb 64

¡ Si vous êtes plus à l’aise avec Windows, utilisez la commande suivante pour créer
une machine virtuelle Windows Server 2019. Vous pouvez ensuite utiliser RDP
pour vous connecter à la machine virtuelle pour configurer les disques plus tard :
az vm create \
--resource-group azuremolchapter4 \
--name storagevm \
--image Win2019Datacenter \
--size Standard_B1ms \
--admin-username azuremol \
--admin-password P@ssw0rd! \
--data-disk-sizes-gb 64

¡ Cela prend quelques minutes pour créer une machine virtuelle. Celle-ci dis-
pose déjà d’un disque de données associé et prêt à l’emploi.
Que faire si vous voulez ajouter un autre disque de données au bout de quelques
semaines ou quelques mois  ? Utilisez à nouveau la CLI Azure pour voir comment
ajouter rapidement un disque. Le processus est le même pour une machine virtuelle
Linux ou Windows. Tout ce que vous avez à faire c’est d’indiquer à Azure de créer un
nouveau disque et de l’associer à votre machine virtuelle.

Tester
Ajoutez un disque de données supplémentaire à votre machine virtuelle comme indiqué
ci-après.

Créez un nouveau disque avec la commande az vm disk attach. Fournissez un nom

et une taille au disque. Vous vous souvenez de la discussion précédente sur les disques
standard et Premium ? Dans l’exemple suivant, vous créez un disque SSD Premium :
az vm disk attach \
--resource-group azuremolchapter4 \
--vm-name storagevm \
--name datadisk \
--size-gb 64 \
--sku Premium_LRS \
--new
52 Chapitre 4  Présentation deStockage Azure

Reconnaissez-vous la dernière partie de ce type de stockage ? LRS signifie stockage locale-

ment redondant (locally redundant storage). Nous examinerons les options de redondance
dans la section 4.3.3.
En deux commandes, vous avez créé une machine virtuelle incluant un disque de
données à l’aide de la CLI Azure, puis simulé la manière d’associer ultérieurement un
disque de données supplémentaire. Ce n’est pas parce que vous avez associé ces dis-
ques, que vous pouvez immédiatement y écrire des données. Comme pour n’importe
quel disque, qu’il s’agisse d’un disque physique associé à un serveur local, ou d’un dis-
que virtuel associé à une machine virtuelle, vous devez initialiser le disque puis créer
une partition et un système de fichiers. Vous pourrez le faire dans l'exercice facultatif
pratique en fin de chapitre.

4.3 Stockage Azure

Le stockage n’est peut-être pas le sujet qu’on pense d’emblée à étudier pour constru-
ire et exécuter des applications, mais c’est un service étendu qui recouvre bien plus
d'aspects que vous ne le pensez. Le service Stockage Azure propose bien plus qu’un
endroit pour stocker des fichiers ou des disques virtuels pour vos machines virtuelles.
Regardons ce dont votre compagnie de pizza fictive a besoin pour construire une
application qui traite les commandes clients à emporter ou à livrer. L’application a
besoin d’une banque de données qui contient les pizzas disponibles, la liste des
garnitures et les prix. Lorsque les commandes sont reçues et traitées, l’application a
besoin d’un moyen pour envoyer des messages entre les composants de l’application.
Ensuite le site front-end a besoin d’images alléchantes pour montrer aux clients à quoi
ressemblent les pizzas. Comme l'illustre la figure 4.1, Stockage Azure propose diverses
fonctions de stockage et peut répondre à ces trois besoins.

Compte Stockage Azure

Blob Table File d'attente Fichier Disque
Données non Banque de données Messages entre Partages de fichiers de Disques gérés, la base
structurées, telles que NoSQL non structurée, composants de PME traditionnels pour de tous les systèmes
les images des pizzas telle que la liste des l’application, pour les machines virtuelles, d’exploitation et les
que vend votre pizzeria pizzas de votre pizzeria traiter les commandes par exemple pour stocker disques de données
de pizzas les journaux de des machines
l’application de la pizzeria virtuelles

Figure 4.1  Un compte Stockage Azure vous permet de créer et d’utiliser une grande variété de
fonctionnalités de stockage ; cela dépasse amplement la simple solution de stockage de fichiers.

¡ Stockage Blob : pour les données non structurées telles que les fichiers multimédias
et les documents. Dans un stockage Blob, les applications peuvent stocker des
données, telles que des images, puis les restituer. Vous pouvez stocker des images
de vos pizzas dans un stockage Blob.
¡ Stockage en table : pour les données non structurées dans une banque de données
NoSQL. Faut-il opter pour des banques de données SQL ou NoSQL  ? C'est
l'éternel débat. Pour trancher, planifiez votre application et évaluez les exigences
de performances liées au traitement de grandes quantités de données. Vous
pouvez stocker la liste des pizzas de votre menu dans une table de stockage. La
section 4.3.1 explore NoSQL plus en détail.
 Stockage Azure 53

¡ File d’attente de stockage  : pour que les applications cloud communiquent entre
différents niveaux et composants de manière fiable et cohérente. Vous pouvez
créer, lire et supprimer des messages qui passent entre les composants de
l’application. Vous pouvez utiliser la file d’attente de stockage pour passer des
messages entre le Web front-end, quand un client passe une commande, et le
back-end, pour préparer et cuire les pizzas.
¡ Stockage de fichiers : pour un bon partage de fichiers SMB (Server Message Block) à
l’ancienne, accessible à la fois par les plateformes Windows et Linux/MacOS. Souvent
utilisé pour centraliser la collecte des journaux à partir des machines virtuelles.
La solution Stockage Azure pour les machines virtuelles est simple. Vous créez et
utilisez des disques gérés Azure, un type de disque dur virtuel (VHD) qui permet de
s'affranchir de nombreuses considérations de conception liées à la performance et à la
distribution des disques virtuels sur la plateforme. Vous créez une machine virtuelle,
y  associez n’importe quels disques gérés de données et laissez la plateforme Azure
identifier la redondance et la disponibilité.

4.3.1 Stockage en table

Abordons maintenant quelques types de stockage de données. Tout d’abord, le stockage
en table. La plupart des gens utilisent probablement une base de données SQL
traditionnelle telle que Microsoft SQL Server, MySQL ou PostgreSQL. Il s’agit de bases
de données relationnelles, constituées d’une ou de plusieurs tables contenant une ou
plusieurs lignes de données. Les bases de données relationnelles sont couramment
utilisées pour le développement d’applications et peuvent être conçues, visualisées et
interrogées de manière structurée : c’est le S de SQL (pour Structured Query Language,
en français langage de requête structurée).
Les bases de données NoSQL sont un peu différentes. Elles ne suivent pas la même
approche structurée et les données ne sont pas stockées dans des tables où chaque ligne
contient les mêmes champs. Il existe différentes implémentations de bases de données
NoSQL  : citons notamment MongoDB et CouchDB. Trois avantages des bases de
données NoSQL sont mis en avant : leur évolutivité est horizontale (ce qui signifie que
vous pouvez ajouter plus de serveurs plutôt que d’ajouter plus de mémoire ou d'UC) ;
elles peuvent gérer de plus grandes quantités de données ; elles sont plus efficaces pour
traiter ces grands ensembles de données.
La façon dont les données sont stockées dans une base de données NoSQL peut être
précisée par quelques catégories :
¡ Clé/valeur, comme dans Redis
¡ Colonne, comme dans Cassandra
¡ Document, comme dans MongoDB
Chaque approche a des avantages et des inconvénients d’un point de vue de la
performance, de la souplesse ou de la complexité. Une table de stockage Azure utilise un
magasin clé/valeur et constitue une bonne introduction aux bases de données NoSQL
lorsque vous êtes habitué à une base de données SQL telle que Microsoft SQL ou MySQL.
Vous pouvez télécharger et installer Microsoft  Azure Storage Explorer à partir de
l’adresse https://azure.microsoft.com/features/storage-explorer si vous souhaitez
visualiser les données. Vous n’avez pas besoin de le faire tout de suite. Storage Explorer
est un excellent outil pour apprendre à quoi ressemblent de manière concrète les tables
54 Chapitre 4  Présentation deStockage Azure

et les files d’attente. Dans ce chapitre, je ne veux pas vous entraîner trop
loin dans le monde des bases de données NoSQL : nous allons explorer en profondeur
quelques bases de données NoSQL intéressantes avec Azure Cosmos DB au chapitre 10.
En fait, dans l’exercice suivant, vous allez utiliser l’API Cosmos DB pour vous connecter à
Stockage Azure et créer une table. L’utilisation des tables Azure est plus une introduction
aux bases de données NoSQL qu’un exemple solide à des fins de production.
Pour l’instant, nous allons lancer un exemple d’application rapide pour voir comment
vous pouvez ajouter et interroger des données, exactement comme vous le feriez avec
une vraie application. Ces échantillons sont basiques, mais montrent comment vous
pouvez stocker les types de pizzas que vous vendez et le tarif de chaque pizza. Plutôt que
d’utiliser une solution imposante comme Microsoft SQL Server ou MySQL, nous allons
utiliser une base de données NoSQL avec le stockage en table Azure.

Tester
Pour afficher les tables Azure en cours d’exécution, procédez comme suit :

1 Ouvrez le portail Azure dans un navigateur Web, puis ouvrez Cloud Shell.

2 Au chapitre 3, vous avez récupéré une copie des échantillons d’Azur sur GitHub.
Si vous ne l’avez pas fait, procurez-vous une copie à l’adresse :
git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

3 Passez au répertoire contenant les exemples de Stockage Azure :

cd ~/azure-mol-samples-2nd-ed/04

4 Installez quelques dépendances Python, si elles ne le sont pas déjà. Installez ici le
package azurerm, qui contrôle la communication vous permettant de créer et de
gérer des ressources Azure; ainsi que deux packages azure, qui sont les SDK
Python sous-jacents pour Azure CosmosDB et Stockage :
pip install --user azurerm azure-cosmosdb-table azure-storage-
➥queue==2.1.0
Que signifie --user lorsque vous installez les packages  ? Si vous utilisez
Azure Cloud Shell, vous ne pouvez pas installer de packages dans le système prin-
cipal. Vous n’avez pas les permissions nécessaires. Au lieu de cela, les packages
sont installés dans l’environnement de l’utilisateur. Ces packages d’installation
sont conservés entre les sessions et vous permettent d’utiliser tous les SDK d’Azure
dans ces exemples.
5 Exécutez l’exemple d’application Python pour les tables. Suivez les invites pour
déguster des pizzas :
python storage_table_demo.py

Des serpents dans l’avion

Python est un langage de programmation largement utilisé, souvent enseigné dans les
classes d’« Introduction à l’informatique ». Si vous travaillez principalement dans les
opérations de maintenance ou d’administration informatique, du côté matériel des
choses, imaginez Python comme un langage de script puissant qui fonctionne dans les
systèmes d’exploitation. Python n’est pas seulement utile pour les scripts, il peut
 Stockage Azure 55

également servir pour construire des applications complexes. Par exemple, la CLI Azure
que vous avez utilisée est écrite en Python.
J’utilise Python pour certains des exemples dans ce livre parce qu’ils doivent pou-
voir  fonctionner à l’extérieur de Cloud  Shell, sans être modifiés. Les distributions
macOS et Linux sont fournies avec Python. Les utilisateurs de Windows peuvent
télécharger et installer rapidement Python, puis exécuter ces scripts localement.
Python est idéal pour ceux qui ont peu ou pas d’expérience de programmation,
ainsi que pour les développeurs plus chevronnés dans d’autres langues. La documenta-
tion Azure pour Stockage Azure et de nombreux autres services fournit de l’aide pour de
nombreux langages, dont .NET, Java et Node.js. Lorsque vous construisez vos propres
applications utilisant des tables, vous n’êtes pas limité à Python.
L'ouvrage Quick Python, 3ème édition, de Naomi ceder (http://mng.bz/6QZA), peut
vous aider à rattraper votre retard si vous souhaitez en savoir plus. Il existe également
une formation vidéo intitulée Get Programming Python in Motion, réalisée par Ana Bell
(http://mng.bz/oPap).

4.3.2 Stockage en file d’attente

Les tables Azure sont idéales quand vous commencez à vous aventurer dans le monde
du développement d’applications cloud. Lorsque vous commencez à créer et à gérer
des applications directement dans le cloud, vous scindez généralement une applica-
tion en composants plus petits qui peuvent s’adapter et traiter les données individuel-
lement. Pour permettre à ces composants de communiquer et de transmettre des
données, une certaine forme de file d’attente de messages est généralement néces-
saire. Découvrez Azure Queues.
Le service Azure  Queues, c’est-à-dire le système de gestion des files d’attentes
d’Azure, vous permet de créer, lire et supprimer des messages qui transportent de petits
segments de données. Ces messages sont créés et récupérés par différents composants
d’application lorsqu’ils transmettent des données. Un message lu n'est pas supprimé
par Azure Queues, tant qu’une application n’a pas terminé le traitement des données
de message.

Tester
Pour voir Azure Queues à l’œuvre, exécutez le script Python ci-dessous. Il est disponible
dans le même répertoire : azure-samples/4. Suivez les invites pour voir les messages
être écrits, lus et supprimés de la file d’attente :
python storage_queue_demo.py

Continuons à travailler sur l'application de gestion des commandes de pizza qui nous
sert d'exemple. Il se peut que vous ayez un composant d’application front-end avec
lequel les clients interagissent pour commander leurs pizzas, puis une file d’attente de
messages qui transmet des messages à un composant d’application back-end qui traite
ces commandes. Les messages de la file d’attente peuvent être visualisés au fur et à
mesure que les commandes sont reçues, comme illustré à la figure 4.2.
56 Chapitre 4  Présentation deStockage Azure

Figure 4.2  Les messages sont envoyés par le composant front-end de l’application. Ils indiquent la pizza
commandée par chaque client dans la propriété Message Text.

Les messages sont supprimés progressivement de la file d’attente, tandis que chaque
commande de pizza est traitée par le composant d’application back-end. La figure 4.3
montre à quoi ressemble la file d’attente une fois que vous avez une pizza végétarienne
au four et que le premier message est supprimé.

Figure 4.3  Dès qu’un message est traité, il est supprimé de la file d’attente. Le premier message illustré à la
figure 4.2 a été supprimé une fois qu’il a été traité par le composant d’application back-end.

4.3.3 Disponibilité et redondance du stockage

Les datacenters d’Azure sont conçus pour être tolérants aux pannes liées, entre autres,
aux connexions Internet redondantes, aux générateurs électriques, aux chemins
d’accès réseau multiples ou aux groupes de stockage. Il vous reste encore du travail
à accomplir lorsque vous concevez et exécutez des applications. Avec Stockage Azure,
vous choisissez le niveau de redondance de stockage dont vous avez besoin. Ce niveau
varie selon chaque application et la sensibilité des données. Voici les options de
redondance de stockage disponibles :
¡ Stockage localement redondant (LRS) : vos données sont répliquées trois fois au sein
du datacenter unique dans lequel votre compte de stockage a été créé. Cette
option permet la redondance en cas de défaillance matérielle unique, mais si
l’ensemble du datacenter est en panne (ce qui est rare, mais possible), vos
informations sont également inaccessibles.
¡ Stockage redondant interzone (ZRS) : le niveau au-dessus du LRS réplique vos données
trois fois dans deux ou trois datacenters d’une région (quand une région compte
plusieurs datacenters) ou dans plusieurs régions. Le ZRS est également accessible
dans les zones de disponibilité, que nous abordons plus en détails dans le chapitre 7.
¡ Stockage géoredondant (GRS) : avec le GRS, vos données sont répliquées trois fois
dans la région principale (dans laquelle votre stockage est créé), puis répliquées
trois fois dans une région appariée. Les deux régions sont généralement éloignées
d’au moins plusieurs centaines de kilomètres. Par exemple, la région de l’ouest
des États-Unis est appariée avec celle de l’est des États-Unis, l’Europe du nord est
appariée avec l’Europe de l’ouest, et l’Asie du sud-est est appariée avec l’Asie de
l’est. Le GRS fournit une option de redondance particulièrement adaptée aux
applications de production.
 Exercice pratique : exploration du stockage dans Azure 57

¡ Stockage géoredondant en accès en lecture (RA-GRS) : Il s’agit de l’option premium

pour la redondance des données. Vos données sont répliquées dans des régions
appariées comme dans le GRS, mais vous disposez en plus d’un accès en lecture
aux données à partir de cette zone secondaire.

4.4 Exercice pratique : exploration du stockage dans Azure

Voici l’occasion de tester vos compétences. Accomplissez au choix l’une des tâches
suivantes dans le cadre de votre exercice pratique.

4.4.1 Pour se concentrer sur les machines virtuelles

Si vous souhaitez vous connecter à une machine virtuelle et observer que le processus
pour initialiser un disque et créer un système de fichiers est le même que pour toute
autre machine virtuelle avec laquelle vous avez travaillé, essayez l’un de ces exercices :

1 Connectez-vous à la machine virtuelle que vous avez créée à la section 4.2. En

fonction de votre choix, vous vous connecterez avec SSH ou RDP.
2 Initialisez le disque et créez une partition.
¡ Sous Linux, le flux est fdisk, mkfs, puis mount.
¡ Sous Windows, utilisez n’importe quelle séquence avec laquelle vous êtes à
l’aise, sans doute : Gestion des disques > Initialiser > Créer un volume > Format.

4.4.2 Pour se concentrer sur le développement

Si vous êtes plutôt un développeur et que vous ne voulez pas découvrir l’initialisation
des disques de données sur une machine virtuelle, retournez dans Cloud  Shell et
explorez les deux démos Python qui utilisent des tables et des files d’attente. Même si
vous débutez dans Python, vous devriez être en mesure de suivre ce qui se passe :
¡ Réfléchissez à certains scénarios dans lesquels vous pourriez implémenter des
tables ou des files d’attente dans vos propres applications. Que faudrait-il pour
construire des applications cloud natives à
partir de composants d’application individuels qui pourraient utiliser des files
d’attente, par exemple ?
¡ Modifiez l’un des exemples qui vous intéresse, pour créer un élément
supplémentaire sur le menu pizza (si vous utilisez une table) ou pour créer un
nouveau message de commande de pizza (si vous utilisez une file d’attente).
 Notions de base de la mise
en réseau Azure
5
Au chapitre 4, vous avez découvert le service Stockage Azure. La mise en réseau Azure
est l'un des autres services de base destinés aux applications cloud. Azure propose de
nombreuses fonctionnalités réseau puissantes pour sécuriser et acheminer votre trafic
à l'échelle mondiale. Ces fonctionnalités sont conçues pour que vous privilégiiez le
développement et à la maintenance de vos applications, afin que vous n'ayez pas à
vous préoccuper de détails tels que les adresses IP et les tables d'itinéraire. Si vous
développez et lancez un site de commandes de pizzas, il faut que le site transmette les
données client et traite les transactions de paiement en toute sécurité.
Ce chapitre porte sur les réseaux virtuels et les sous-réseaux Azure, et explique
comment créer des interfaces de réseau virtuel. Pour sécuriser et contrôler le flux de
trafic, vous allez créer des groupes et des règles de sécurité réseau. Si vous ne
connaissez pas la mise en réseau, ou si vous n’avez pas travailler avec des adresses IP
et des cartes réseau depuis un moment, il se peut que vous consacriez plus de temps
à ce chapitre. Il contient de nombreux exercices « Essayez dès maintenant ». Je vous
recommande néanmoins de prendre le temps nécessaire pour comprendre ce
chapitre, car la mise en réseau est essentielle à de nombreux services dans Azure.

5.1 Composants d'un réseau virtuel

Pensez au nombre de câbles qui se cachent derrière votre bureau ou dans votre
centre de divertissement. Imaginez maintenant tous les câbles nécessaires pour
connecter les ordinateurs de tout un étage dans un immeuble de bureaux. Qu'en
est-il de l'immeuble entier ? Avez-vous déjà visité ou vu des photos d'un datacenter ?
Essayez d'imaginer la taille des datacenters Azure. Imaginez maintenant des dizaines
de datacenters Azure, dans le monde entier. Étant donné que les maths ne sont pas
mon point fort, je serais incapable de calculer le nombre exact de kilomètres de
câbles réseau nécessaires au transport du trafic chez Azure !

58
 Composants d'un réseau virtuel 59

La connectivité réseau est un aspect essentiel de la vie moderne. Chez Azure, le réseau
est au cœur de toute la communication. Pour les milliers de périphériques réseau
physiques et les kilomètres de câbles réseau qui servent à tout connecter dans un
datacenter Azure, vous travaillez avec des ressources de réseau virtuel. Comment ? Les
réseaux software-defined. Lorsque vous créez une machine virtuelle ou une
application Web, il n'est pas nécessaire qu'un technicien coure d'un bout à l'autre du
centre de données Azure pour connecter physiquement des câbles et affecter des
adresses  IP (quoique la situation puisse être amusante  !). Au lieu de cela, toutes les
ressources réseau qui définissent l'ensemble de votre environnement réseau sont gérées
en toute logique par la plateforme Azure. La figure 5.1 présente les différents composants
du réseau virtuel que vous allez créer au fur et à mesure que vous avancez dans ce chapitre.

Réseau virtuel

Sous-réseau : Web Règle Sous-réseau : distant Règle

pour autoriser le trafic HTTP pour autoriser le trafic SSH
Adresse IP publique de Adresse IP publique de
l’interface réseau + DNS l’interface réseau + DNS

VM Web VM jump-box

Figure 5.1  Les connexions au réseau software-defined dans Azure

Certains composants du réseau peuvent devenir transparents pour l'utilisateur dans le

cadre de l'utilisation de ressources PaaS. Les principaux composants utilisés pour les
machines virtuelles sont les suivants :
¡ Sous-réseaux et réseaux virtuels (y compris des pools d'adresses IP)
¡ Cartes d'interface de réseau virtuel
¡ Une ou plusieurs adresses IP publiques
¡ Nom DNS interne et noms DNS publics facultatifs pour la résolution de nom externe
¡ Groupes et règles de sécurité réseau, qui sécurisent et contrôlent le flux du trafic
réseau, à la manière d'un pare-feu standard

5.1.1 Sous-réseaux et réseaux virtuels

Lorsque vous avez créé une machine virtuelle au chapitre  2, vous n'avez pas eu à
configurer les paramètres réseau. La plateforme Azure peut créer ces ressources à
votre place avec des plages d'adresses IP et des noms par défaut. Créons les ressources
réseau à l'avance dans cette section, et voyons comment elles se présentent pour une
machine virtuelle.
60 Chapitre 5  Notions de base de la mise en réseau Azure

Tester
La mise en réseau est souvent plus facile à visualiser une fois que vous l'avez vue
à  l'œuvre. Vous allez utiliser le portail Azure pour démarrer, en réalisant finalement
plusieurs étapes distinctes. Vous découvrirez toutefois la puissance de la CLI Azure plus
loin dans le chapitre.
Ne vous inquiétez pas trop de l'utilisation de vos propres espaces d’adressage ou du nom
DNS personnalisé pour le moment. Procédez comme suit pour créer votre réseau
et sous-réseau virtuels :

1 Ouvrez le portail Azure et sélectionnez Créer une ressource, dans le coin

supérieur gauche du tableau de bord.
2 Dans la liste des services Marketplace, sélectionnez Mise en réseau, puis choisissez
Réseau virtuel.
3 Saisissez un nom pour le réseau virtuel, tel que vnetmol.
4 Afin de bénéficier d'un peu plus de marge de manœuvre, changez l'espace
d'adressage en 10.0.0.0/16.

Plages d'adresses IP
Les réseaux virtuels couvrent une certaine plage d'adresses IP : c'est ce que l'on appelle
un espace d'adressage. Si vous avez déjà vu une adresse IP, vous avez peut-être
remarqué le masque de sous-réseau, qui ressemble généralement à ça :
255.255.255.0. Ce masque de sous-réseau est souvent utilisé sous une forme abrégée
qui spécifie l'étendue de cette plage, par exemple /24.
Le portail Azure dispose d'un espace d'adressage par défaut de /24. Dans notre situation,
vous souhaitez augmenter le nombre de plages IP supplémentaires, sans avoir beaucoup
de connaissances réseau. Augmentez donc l'espace d'adressage à /16. Vous ne donnez
pas ce type d'adresse IP directement à une machine virtuelle.À l'étape suivante, vous
allez créer un sous-réseau qui couvre une section plus petite de cet espace d'adressage.
Si les espaces d'adressage réseau sont un concept totalement étranger pour vous, ne
vous inquiétez pas. Dans la plupart des cas, vous ne les rencontrerez pas au quotidien.
Une gouvernance Azure pertinente peut fonctionner de la même façon que dans votre
environnement informatique sur-site existant. Un groupe de personnes peut gérer les
réseaux virtuels Azure, et vous déposez vos applications dans un espace précréé.

5 Créez un groupe de ressources, tel que azuremolchapter5, puis sélectionnez

une région Azure proche de vous.
6 Saisissez un nom de sous-réseau, tel que websubnet et spécifiez la plage d'adresses de
sous-réseau 10.0.1.0/24. Cette plage d'adresses fait partie du réseau virtuel
plus étendu mentionné précédemment. Vous ajouterez un autre sous-réseau plus tard.
7 Examinez certaines des autres options, telles que la protection contre les attaques
distribuées de déni de service (DDoS), les points de terminaison de service et le
pare-feu Azure. Laissez les valeurs par défaut pour l’instant.
J'espère néanmoins que cet exemple vous donnera une idée des possibilités
offertes au-delà des réseaux virtuels de base.
8 Lorsque vous êtes prêt, créez le réseau virtuel le sous-réseau.
 Composants d'un réseau virtuel 61

5.1.2 Cartes d'interface de réseau virtuel

Maintenant que vous avez créé un réseau virtuel et un sous-réseau, vous devez
connecter une machine virtuelle. Comme avec un ordinateur de bureau ordinaire,
un ordinateur portable ou une tablette, vous utilisez une carte d'interface réseau (NIC)
pour vous connecter au réseau virtuel. Et non, il n'y a pas de connexion Wi-Fi gratuite !
Cependant, certaines tailles de machines virtuelles dans Azure permettent de
bénéficier de jusqu'à huit  cartes réseau pouvant atteindre une vitesse de 32  Gbit/s.
Même si je suis nul en maths, je sais qu'il s'agit là d'une sacrée bande passante !
Vous vous demandez peut-être à quoi cela peut bien servir de créer à l'avance
chacune de ces ressources. Vous pouvez le faire lorsque vous créez une machine
virtuelle. C'est vrai, mais prenez du recul et pensez aux ressources réseau comme à des
ressources à long terme.
Les ressources réseau existent séparément des ressources de machines virtuelles
et peuvent perdurer au-delà du cycle de vie d'une machine virtuelle donnée. Ce concept
vous permet de créer des ressources réseau fixes et de créer, supprimer et créer à
nouveau une machine virtuelle qui conserve les mêmes ressources réseau, telles que
des adresses IP et des noms DNS. Pensez à une machine virtuelle de laboratoire, ou à un
environnement de développement et de test. Vous pouvez rapidement reproduire
exactement le même environnement, car seule la machine virtuelle change.

Tester
Pour créer un NIC, procédez comme suit :

1 Dans le portail Azure, sélectionnez Créer une ressource, dans le coin supérieur
gauche du tabl eau de bord.
2 Recherchez et sélectionnez Interface réseau, puis sélectionnez Créer.
3 Entrez un nom pour votre interface réseau, tel quewebvnic. Sélectionnez ensuite
le réseau virtuel et le sous-réseau que vous avez créé dans l’exercice précédent.
4 J'ai parlé de ressources à long terme, alors voyons comment cela fonctionne.
Créez une affectation d’adresses IP statiques qui utilise l’adresse 10.0.1.4.

ASTUCE  Pourquoi 4 ? Qu'en est-il des trois premières adresses dans l'espace

d'adressage ? Azure se réserve les trois premières adresses IP de chaque plage
pour ses propres besoins de gestion et de routage. La première adresse que
vous pouvez utiliser dans chaque plage est .4.

5 Ne créez aucun groupe de sécurité réseau pour l'instant, nous y reviendrons

dans quelques minutes. Si vous êtes de ceux qui connaissent tout ce qu'il y a à
savoir sur IPv6, vous pouvez cocher Adresse IP privée (IPv6) et saisir un nom.
Si ce n'est pas le cas, gardez IPv4.
6 Sélectionnez le groupe de ressources existant de l’exercice précédent, puis créer
le Nic dans la même région que le réseau virtuel.
7 Lorsque vous êtes prêt, créez le NIC.
62 Chapitre 5  Notions de base de la mise en réseau Azure

Séparation des rôles dans Azure

Vous n'avez pas à créer d'autres ressources de calcul dans le même groupe de
ressources que votre réseau virtuel. Pensez de nouveau au concept de gouvernance
d'Azure dont nous avons parlé plus tôt. Vous pouvez avoir un groupe d'ingénieurs réseau
qui gèrent toutes les ressources réseau virtuelles dans Azure. Lorsque vous créez des
ressources pour vos applications, telles que les machines virtuelles, vous les créez et les
gérez dans vos propres groupes de ressources.
Les chapitres suivants portent sur certaines des fonctionnalités de sécurité et de
stratégie dans Azure, qui vous permettent de définir qui peut accéder et apporter des
modifications à certaines ressources. L'idée est que si vous ne savez pas
(ou ne souhaitez pas savoir) grand-chose sur les ressources du réseau, vous pouvez
simplement vous connecter en utilisant ce qui vous est donné. Cela s'applique
également aux ingénieurs ou aux développeurs : ils peuvent voir vos ressources
d'application, mais ne peuvent pas les modifier ni les supprimer.
Ce genre de modèle de gouvernance dans Azure peut paraître agréable, mais veillez
à éviter le piège du travail cloisonné. Dans les grandes entreprises, il est parfois
inévitable de devoir suivre les directives de département. Toutefois, l'un des grands
avantages des fournisseurs de cloud computing comme Azure est d'accélérer le temps
de déploiement des applications, puisque vous n'avez pas à attendre que les ressources
réseau physiques soient câblées et configurées. Prévoyez d'avoir les ressources réseau
Azure déjà créées et configurées, et vous devriez alors être en mesure de créer et de
gérer facilement vos ressources d'application.

5.1.3 Adresse IP publique et résolution DNS

Personne ne peut encore accéder à vos ressources, car aucune adresse IP publique ou
aucun nom DNS ne leur est associé. Suivons une nouvelle fois le principe des ressou-
rces à long terme pour créer une adresse IP et un nom DNS publics, puis assignez-les à
votre interface réseau.

Tester
Pour créer une adresse IP et une entrée DNS publiques pour votre interface réseau,
procédez comme suit :

1 Dans le portail Azure, sélectionnez Créer une ressource, dans le coin supérieur
gauche du tabl eau de bord.
2 Recherchez et sélectionnez Adresse IP publique, puis sélectionnez Créer.
3 Créez une référence de base et une adresse  IPv4. Les adresses IPv6 et les
références standard sont à utiliser avec les équilibreurs de charge (que nous
abordons au chapitre 8). À ce stade, ne vous souciez pas trop des différences.
4 Saisissez un nom, tel que webpublicip, qui utilise une affectation dynamique.

Les différents types d'affectation d'adresses IP

Une affectation dynamique attribue une adresse IP publique lorsque la machine virtuelle
démarre. Une fois que la machine virtuelle est arrêtée, l'adresse IP publique est
désallouée. Voici les points importants à retenir :
 Composants d'un réseau virtuel 63

¡ Vous ne disposerez d'aucune adresse IP publique tant que vous n'en aurez pas
assigné une à une machine virtuelle, et démarré cette dernière.
¡ Il est possible que l'adresse IP publique change si vous arrêtez, désallouez et
redémarrez la machine virtuelle.
Une affectation statique signifie que vous disposez d'une adresse IP publique allouée
sans machine virtuelle associée. Cette adresse ne sera pas modifiée par la suite. Cette
affectation se révèle utile lorsque vous utilisez un certificat SSL mappé à une adresse IP,
ou un nom et un enregistrement DNS personnalisés pointant vers l'adresse IP.
Pour l'instant, vous n'utilisez qu'une seule machine virtuelle. Pour une utilisation en
production, il faudrait idéalement que vous exécutiez votre application sur plusieurs
machines virtuelles, avec un équilibreur de charge face à ces dernières. Dans cette
situation, l'adresse IP publique est attribuée à l'équilibreur de charge et crée
généralement une affectation statique à ce stade.

5 Saisissez un nom DNS unique. Celui-ci compose le nom de domaine qualifié

complet (FQDN) pour votre ressource, selon la région Azure dans laquelle vous la
créez. Si vous créez un nom DNS azuremol dans la région Est des États-Unis, le
nom de domaine qualifié complet est donc azuremol.eastus.cloudapp.azure.com.

Entrées DNS
Est-il possible de configurer un nom DNS personnalisé ? En effet, le FQDN par défaut
n'est pas des plus conviviaux ! Utilisez une adresse IP publique statique, puis créez
un enregistrement CNAME dans votre zone DNS enregistrée. Vous gardez ainsi le
contrôle de l'enregistrement DNS et vous pouvez créer autant d'entrées que vous
le souhaitez pour vos applications.
Dans la zone DNS de manning.com par exemple, vous pouvez créer un CNAME pour
azuremol pointant vers une adresse IP publique statique dans Azure. Pour obtenir
votre application, tout utilisateur devrait dans un premier temps accéder à
azuremol.manning.com. Cette adresse n'est-elle pas beaucoup plus conviviale
que webmol.eastus.cloudapp.azure.com ?

6 Sélectionnez le groupe de ressources existant de l’exercice précédent, puis

créer l'adresse IP publique dans la même région que le réseau virtuel.
7 Lorsque vous êtes prêt, créez l’adresse IP publique.
8 Associez l'adresse IP publique et l'étiquette de nom DNS avec l'interface réseau
que vous avez créée à la section  5.1.2. Recherchez et sélectionnez Groupe de
ressources dans la barre de navigation, dans la partie gauche du portail Azure.
Choisissez ensuite le groupe de ressources dans lequel vous avez créé vos
ressources réseau, tel que azuremolchapter5.
9 Sélectionnez votre adresse IP publique dans la liste des ressources, puis choisissez
Associer.
10 Choisissez d’associer une interface réseau (remarquez néanmoins les autres
options pouvant être associées à l'adresse IP publique), puis choisissez l’interface
réseau que vous avez créée, par exemple webvnic.
64 Chapitre 5  Notions de base de la mise en réseau Azure

Après quelques instants, la fenêtre d'adresses IP publiques se met à jour et indique que
l'adresse IP est à présent associée à votre interface réseau. Si vous avez choisi une
affectation dynamique, le champ d'adresse IP reste vide, comme illustré à la figure 5.2.
N'oubliez pas qu'une adresse IP publique est allouée une fois qu'une machine virtuelle
associée est démarrée.

Figure 5.2  L'adresse IP publique est à présent associée à une interface réseau. En choisissant une
affectation dynamique, aucune adresse IP n'est affichée tant qu'une machine virtuelle n'a pas été créée
et démarrée.

5.2 Sécurisation et contrôle du trafic avec les groupes de

sécurité réseau
Petite question : devriez-vous connecter une machine virtuelle à Internet sans aucun
pare-feu pour contrôler et limiter le flux de trafic ? Si vous avez répondu « Bien sûr,
pourquoi pas ? », alors vous devriez peut-être envisager de consacrer un peu de votre
temps libre pour vous renseigner sur la sécurité de réseau sur Internet !
J'espère que votre réponse était plutôt un « Non ! » catégorique. Le risque que votre
machine virtuelle soit victime d'une cyberattaque automatique juste après avoir été
démarrée est malheureusement trop important. Vous devriez toujours adopter les
meilleures pratiques afin que votre système d'exploitation et votre logiciel d'application
soient à jour, sauf si vous ne voulez pas que le trafic réseau atteigne votre machine si cela
peut être évité. Tout ordinateur ordinaire équipé d'un système Windows ou macOS
dispose d'un logiciel pare-feu intégré, et chaque réseau local (digne de ce nom) de ma
connaissance est muni d'un pare-feu réseau entre Internet et le réseau interne. Dans
Azure, les règles de trafic et de pare-feu sont fournies par les groupes de sécurité réseau.

5.2.1 Création d'un groupe de sécurité réseau

Dans Azure, un NSG applique généralement un ensemble de règles aux ressources
réseau. Ces règles déterminent le trafic pouvant circuler dans et hors de votre machine
virtuelle. Vous pouvez définir les ports, les protocoles et les adresses IP permis, ainsi
que leur direction. Ces ensembles de règles peuvent être appliqués à une interface
réseau unique ou à tout un sous-réseau. Cette flexibilité vous permet de contrôler
précisément comment et à quel moment appliquer les règles, afin de répondre aux
besoins de votre application en matière de sécurité.
 Sécurisation et contrôle du trafic avec les groupes de sécurité réseau 65

La figure 5.3 illustre le flux logique d'un paquet réseau entrant lorsqu'il passe par
un NSG. Le processus serait identique pour des paquets sortants. L’hôte Azure ne fait
pas la différence entre le trafic Internet et le trafic provenant d'ailleurs dans votre
environnement Azure, tel qu'un autre sous-réseau ou réseau virtuel. Chaque paquet
réseau entrant se voit appliquer les règles NSG entrantes, tandis que les règles NSG
sortantes sont appliquées aux paquets réseau sortants.

Appliquer la règle Oui

NSG suivante

Appliquer la La règle Non D’autres

première règle NSG correspond ? règles ?

Oui Non Figure 5.3  Les paquets

entrants sont examinés,
Refuser la Oui Supprimer et chaque règle NSG est
règle ? le paquet appliquée selon un ordre
de priorité. En cas de
Non correspondance avec
une règle de Refus ou
Autoriser d'Autorisation, le paquet est
le paquet soit transmis à la machine
virtuelle, soit rejeté.

Voici ce qui arrive à chaque paquet réseau :

1 La première règle NSG est appliquée.

2 Si la règle ne correspond pas au paquet, la prochaine règle est chargée jusqu'à ce
qu'il n'en reste plus aucune. Ensuite, la règle par défaut pour abandonner le
paquet est appliquée.
3 En cas de correspondance avec une règle, vérifiez si l'action consiste à refuser le
paquet. Dans ce cas, le paquet est abandonné.
4 Au contraire, si la règle consiste à accepter le paquet, celui-ci est alors transmis à
la machine virtuelle.
Nous allons ensuite créer un NSG afin de révéler la logique de ces concepts.

Tester
Pour créer un groupe de sécurité réseau, procédez comme suit :

1 Dans le portail Azure, sélectionnez Créer une ressource, dans le coin supérieur
gauche du tabl eau de bord.
2 Recherchez et sélectionnez Groupe de sécurité réseau, puis Créer.
3 Saisissez un nom, par exemple webnsg, et choisissez d’utiliser le groupe
de ressources existant.
C'est tout ! La majeure partie de la configuration d'un NSG intervient lorsque vous
créez les règles de filtrage. La section 5.2.2 explique comment procéder pour rendre
votre NSG fonctionnel.
66 Chapitre 5  Notions de base de la mise en réseau Azure

5.2.2 Association d'un groupe de sécurité réseau à un sous-réseau

Sans règles, le NSG n'assure pas une grande protection de vos machines virtuelles.
Vous devez également l'associer à un sous-réseau, de la même manière que vous avez
précédemment associé votre adresse IP publique à une interface réseau. Commençons
par associer votre NSG à un sous-réseau.

Tester
Pour associer votre sous-réseau virtuel à votre groupe de sécurité réseau, procédez
comme suit :

1 Recherchez et sélectionnez Groupe de ressources dans la barre de navigation,

dans la partie gauche du portail Azure. Choisissez ensuite le groupe de ressou-
rces dans lequel vous avez créé vos ressources réseau, tel que azuremolchapter5.
2 Sélectionnez votre NSG (webnsg, par exemple).
3 Vous trouverez à gauche, sous les Paramètres, les options de Sous-réseaux et d'In-
terfaces réseau. Choisissez Sous-réseaux.
4 Sélectionnez le bouton Associer, puis sélectionnez le réseau virtuel et le sous-ré-
seau que vous avez créé précédemment. Sélectionnez OK pour associer votre
NSG au sous-réseau.
Grâce à la flexibilité des NSG, il est possible d'associer plusieurs sous-réseaux,
sur de nombreux réseaux virtuels, avec un NSG unique. Il s'agit d'un mappage
un-à-plusieurs, qui vous permet de définir des règles de sécurité réseau de base
s'appliquant à un large éventail de ressources et d'applications.
Voici à quoi ressemble votre NSG et les règles par défaut qui lui sont
appliquées.
5 Sélectionnez Règles de sécurité de trafic entrant, dans la partie gauche de votre
NSG. Aucune règle de sécurité n'y est répertoriée, du moins aucune que vous
ayez créée.
6 Pour vous faire une idée des règles qu'Azure crée pour vous, comme illustré à la
figure 5.4, sélectionnez Règles par défaut.

Figure 5.4  Des règles de sécurité par défaut sont créées afin d'autoriser le trafic provenant du réseau virtuel
interne ou de l'équilibreur de charge, mais refusant tout autre trafic.
 Sécurisation et contrôle du trafic avec les groupes de sécurité réseau 67

Trois règles par défaut ont été créées pour vous. Il est important de comprendre ces
différentes règl es :
¡ AllowVnetInBound  : autorise tout trafic interne au réseau virtuel. Lorsque
vous disposez de plusieurs sous-réseaux au sein de votre réseau virtuel, aucun
filtrage n'est configuré par défaut et le trafic est donc autorisé.
¡ AllowAzureLoadBalancerInBound : autorise tout trafic provenant d'un équilibreur
de charge Azure vers votre machine virtuelle. Si vous placez un équilibreur de
charge entre vos machines virtuelles et Internet, cette règle permet de s'assurer
que le trafic provenant de l'équilibreur de charge arrive jusqu'à vos machines
virtuelles, comme on le ferait pour contrôler un rythme cardiaque.
¡ DenyAllInBound : ceci est la dernière règle appliquée. Tous les paquets entrants
qui arrivent jusque-là sont alors abandonnés. S'il n'existe aucune règle
d'Autorisation antérieure, alors tout trafic est rejeté. Vous n'avez donc qu'à
autoriser le trafic souhaité. Le reste sera alors rejeté.
La priorité d'une règle NSG est importante. Lorsqu'une règle de Refus ou
d'Autorisation est appliquée, aucune règle supplémentaire n'est appliquée par la suite.
Les règles sont appliquées selon un ordre de priorité numérique croissant, c'est-à-dire
qu'une règle de priorité 100 sera appliquée avant une règle de priorité 200.
Tout comme pour les précédentes discussions sur la gouvernance des ressources
Azure, ces règles NSG sont peut-être déjà créées pour vous et appliquées à un sous-
réseau spécifique. Vous créez vos machines virtuelles et exécutez vos applications,
tandis que quelqu'un d'autre s'occupe de gérer les NSG.
Il est essentiel de comprendre comment circule le trafic afin de pouvoir réagir en cas
de problème. Dans Azure, certains outils peuvent vous aider à déterminer pourquoi le
trafic ne parvient pas jusqu'à votre application alors que vous pensez que rien ne devrait
l'en empêcher !

5.2.3 Création de règles de filtrage pour les groupes de sécurité réseau

Maintenant que votre NSG est associé au sous-réseau, et que nous avons passé en revue
les règles par défaut, nous allons à présent créer une règle NSG de base visant à
autoriser le trafic HTTP.

Tester
Pour créer vos propres règles avec le groupe de sécurité réseau, procédez comme suit :

1 Pour créer une règle NSG à partir de la fenêtre précédente du portail Azure,
sélectionnez Ajouter dans la section Règles de sécurité de trafic entrant.
2 Vous disposez de deux options pour créer des règles : de base et avancée. Pour
créer rapidement des règles prédéfinies, sélectionnez De base, dans la partie
supérieure de la fenêtre.
3 Sélectionnez HTTP dans le menu déroulant Service. De nombreux services par
défaut sont proposés, tels que SSH, RDP et MySQL. Lorsque vous sélectionnez
un service, la plage de ports appropriée est appliquée (dans ce cas, il s'agit du
port 80). L’action par défaut des règles de base autorise le trafic.
68 Chapitre 5  Notions de base de la mise en réseau Azure

4 Une valeur de priorité est attribuée à chaque règle. Plus le nombre est petit, plus
la priorité est élevée. Acceptez la priorité basse par défaut, 100 par exemple.
5 Acceptez le nom par défaut ou indiquez le votre, puis sélectionnez OK.

5.3 Création d'un exemple d'application Web avec un trafic sécurisé

Jusqu'à présent, vous avez créé un réseau virtuel et un sous-réseau. Vous avez ensuite
créé une interface réseau et associé une adresse IP publique ainsi qu'une étiquette de
nom DNS. Vous avez créé et appliqué un NSG à l'ensemble du sous-réseau, puis vous
avez créé une règle NSG afin d'autoriser le trafic HTTP. Il ne vous manque plus qu'une
seule chose : la machine virtuelle.
5.3.1 Création de connexions réseau d'accès distant
Dans l'environnement de production, vous ne devriez pas ouvrir d'accès à distance
(comme SSH ou RDP) aux machines virtuelles qui exécutent vos applications.
Généralement, vous vous connectez à une machine virtuelle jumpbox distincte depuis
Internet, puis vous accédez à des machines virtuelles supplémentaires via la connexion
interne. Jusqu’à présent, vous avez créé toutes les ressources réseau virtuelles dans le
portail Azure. Passons à la CLI Azure pour découvrir à quelle vitesse vous pouvez créer
ces ressources à partir de la ligne de commande.

Tester
Vous avez créé le premier NSG dans le portail Azure. Pour créer un autre NSG avec la
CLI Azure , procédez comme suit :

1 Sélectionnez l'icône Cloud Shell, située dans la partie supérieure du tableau de

bord du portail Azure. Vérifiez que c'est bien le shell Bash qui s'ouvre, et non pas
PowerShell.
2 Créez un NSG supplémentaire dans le groupe de ressources existant. Comme
dans les chapitres précédents, les barres obliques inverses (\) présentes dans les
commandes suivantes sont utilisées pour faciliter l'identification des sauts de
ligne. Il n'est donc pas nécessaire de les taper. Entrez un nom, par
exemple remotensg :
az network nsg create \
--resource-group azuremolchapter5 \
--name remotensg

3 Dans le nouveau NSG, créez une règle qui autorise le port 22. Entrez le groupe de
ressources et le NSG que vous avez créés dans l'étape précédente, et saisissez un
nom (allowssh par exemple) :
az network nsg rule create \
--resource-group azuremolchapter5 \
--nsg-name remotensg \
--name allowssh \
--protocol tcp \
--priority 100 \
--destination-port-range 22 \
--access allow
4 Créez un sous-réseau pour votre machine virtuelle distante. Entrez un nom, tel
que remotesubnet, ainsi qu'un préfixe d’adresse compris dans la plage du réseau
virtuel 10.0.2.0/24 par exemple. Associez également le NSG que vous avez créé
à l'étape 3 au sous-réseau, tel que remotensg :
 Création d'un exemple d'application Web avec un trafic sécurisé 69

az network vnet subnet create \

--resource-group azuremolchapter5 \
--vnet-name vnetmol \
--name remotesubnet \
--address-prefix 10.0.2.0/24 \
--network-security-group remotensg

Il suffit seulement de trois commandes pour créer un sous-réseau, créer un NSG et créer
une règle. Commencez-vous à vous représenter la puissance de la CLI Azure  ?
Azure PowerShell est tout aussi puissant, ne vous sentez donc pas obligé de créer toutes
les ressources dans le portail Azure. À mesure que nous progresserons dans ce livre, nous
préférerons, dans la majorité des cas, utiliser Azure CLI plutôt que le portail Azure.

5.3.2 Création de machines virtuelles

Une fois tous les composants réseau en place, vous pouvez créer deux  machines
virtuelles. Une des machines virtuelles est créée dans le sous-réseau qui autorise le
trafic HTTP, afin que vous puissiez installer un serveur  Web. D'un autre côté, la
deuxième machine virtuelle étant créée dans le sous-réseau autorisant SSH, vous
disposez donc d'une jumpbox afin de sécuriser davantage l'environnement de votre
application et de commencer à répliquer un déploiement de production. La figure 5.5
illustre ce que vous êtes en train de mettre en place.

Réseau virtuel
Sous-réseau : Web Règle Sous-réseau : distant Règle
pour autoriser le trafic HTTP pour autoriser le trafic SSH
Adresse IP publique de Adresse IP publique de
l’interface réseau + DNS l’interface réseau + DNS

VM Web VM jump-box

Figure 5.5  Vous réunissez deux sous-réseaux, des NSG, des règles, des interfaces réseau et des
machines virtuelles. Cet exemple ressemble presque à un déploiement prêt pour la production avec d'un
côté, une première machine virtuelle qui exécute le serveur Web et est ouverte au trafic publique, et de
l'autre une deuxième dans un sous-réseau distinct, utilisée pour les connexions à distance au reste de
l'environnement de l'application.

Lorsque vous créez une machine virtuelle, vous pouvez fournir l'interface de réseau
virtuel que vous avez créée dans les étapes précédentes. Si vous n'avez pas spécifié cette
ressource réseau, La CLI Azure crée pour vous un réseau virtuel, un sous-réseau et une
carte réseau avec les paramètres par défaut. Cela peut se révéler très utile pour créer
rapidement une machine virtuelle. Cependant, nous souhaitons suivre le principe des
ressources réseau à long terme pouvant être gérées par une autre équipe, et dans
lesquelles vous créerez vos machines virtuelles.
70 Chapitre 5  Notions de base de la mise en réseau Azure

Tester
Pour créer des machines virtuelles jumpbox et de serveur Web avec la CLI Azure,
procédez comme suit :

1 Créez la première machine virtuelle pour votre serveur Web et donnez-lui un nom

(webvm par exemple). Associez l'interface réseau, telle que webvnic, et entrez une
image (par exemple, UbuntuLTS). Choisissez un nom d'utilisateur, comme
azuremol. La dernière commande, --generate- ssh-keys, permet d'ajouter les
clés SSH que vous avez créées dans le chapitre 2 à la machine virtuelle :
az vm create \
--resource-group azuremolchapter5 \
--name webvm \
--nics webvnic \
--image UbuntuLTS \
--size Standard_B1ms \
--admin-username azuremol \
--generate-ssh-keys

2 Créez ensuite la deuxième machine virtuelle pour la jumpbox. Cet exemple

présente comment vous pouvez utiliser un sous-réseau et un NSG existants,
et laisser ainsi la CLI Azure créer l'interface réseau et effectuer les connexions
appropriées. Dans cette commande, vous créez une adresse IP publique
(remotepublicip par exemple) :
az vm create \
--resource-group azuremolchapter5 \
--name remotevm \
--vnet-name vnetmol \
--subnet remotesubnet \
--nsg remotensg \
--public-ip-address remotepublicip \
--image UbuntuLTS \
--size Standard_B1ms \
--admin-username azuremol \
--generate-ssh-keys

La sortie des deux commandes affiche une adresse IP publique. Prenez note de ces
adresses IP. Dans le prochain exercice, si vous essayez de vous connecter en SSH à la
première machine virtuelle pour le serveur Web, vous échouez. Pourquoi  ? Vous
pouvez vous connecter en SSH à la machine virtuelle distante car vous avez créé une
règle NSG pour autoriser uniquement le trafic HTTP vers la machine virtuelle Web.

5.3.3 Utilisation de l'agent SSH pour se connecter à vos machines virtuelles

Il faut que je vous présente un outil fabuleux avec SSH qui vous permet d'utiliser
correctement votre jumpbox et de vous connecter à votre machine virtuelle Web via le
réseau virtuel Azure  : il s'agit de l'agent SSH. Cet agent s'applique uniquement aux
machines virtuelles Linux, alors si vous travaillez principalement avec des machines
virtuelles Windows et des connexions Bureaux à distance (RDP), ne vous inquiétez pas
si cela ne vous paraît pas familier. Vous pouvez créer des connexions RDP vers des
machines virtuelles Windows depuis votre jumpbox avec les informations
d'identification distantes locales, ou avec les informations d'identification de domaine,
si vous configurez correctement le serveur.
 Création d'un exemple d'application Web avec un trafic sécurisé 71

Un agent SSH peut stocker vos clés SSH et les transmettre selon les besoins. Au
chapitre 2, lorsque vous avez créé une paire de clés publiques SSH, j'ai mentionné les
clés publique et privée. La clé privée est conservée localement sur votre ordinateur.
Seule la clé publique est copiée sur les machines virtuelles distantes. Même si la clé
publique a été ajoutée aux deux  machines virtuelles créées, vous ne pouvez pas
simplement vous connecter en SSH à votre jumpbox, puis à votre machine virtuelle Web.
Pourquoi ? Cette jumpbox ne dispose d'aucune copie de votre clé privée. Lorsque vous
essayez d'effectuer la connexion SSH depuis la jumpbox, celle-ci ne dispose d'aucune
clé privée à associer avec la clé publique sur la machine virtuelle pour pouvoir vous
authentifier.
Il est nécessaire de protéger la clé privée, il s'agit donc de ne pas choisir la voie de la
facilité et de ne pas la copier dans la jumpbox. Tout autre utilisateur accédant à la
jumpbox pourrait potentiellement se procurer une copie de votre clé privée et pourrait
se faire passer pour vous chaque fois que cette clé est utilisée. C'est à ce moment que
l'agent SSH entre en jeu.
Si vous exécutez l'agent SSH dans votre session Cloud Shell, vous pouvez y ajouter
vos clés SSH. Pour créer votre connexion SSH à la jumpbox, vous devez spécifier
l'utilisation de cet agent afin de faire le lien avec votre session. Cette technique vous
permet de transmettre efficacement votre clé privée pour l'utiliser depuis la jumpbox,
sans jamais la copier. Lorsque vous vous connectez en SSH à la machine virtuelle Web
depuis la jumpbox, l'agent SSH communique votre clé privée par la jumpbox et vous
permet de vous authentifier.

Tester
Pour utiliser SSH avec votre machine virtuelle jumpbox, procédez comme suit :

1 Dans Cloud Shell, démarrez l'agent SSH de la façon suivante :

eval $(ssh-agent)

2 Ajoutez à l'agent la clé SSH que vous avez créée dans le chapitre 2, en procédant
comme suit :
ssh-add

3 Connectez-vous en SSH à votre machine virtuelle jumpbox. Spécifiez l'utilisation

de l'agent SSH avec le paramètre -A. Entrez votre propre adresse IP publique,
affichée dans la sortie lorsque vous avez créé la machine virtuelle jumpbox :
ssh -A azuremol@<publicIpAddress>

4 Étant donné qu'il s'agit de la première fois que vous créez une connexion SSH à
la machine virtuelle jumpbox, vous devez accepter l'invite de connexion avec les
clés SSH.
5 Vous souvenez-vous avoir créé une affectation d'adresse IP privée statique pour la
machine virtuelle Web dans la section 5.1.2 ? Cette adresse statique simplifie con-
sidérablement la connexion SSH. Connectez-vous en SSH à la machine virtuelle
de la manière suivante :
ssh 10.0.1.4
72 Chapitre 5  Notions de base de la mise en réseau Azure

6 Acceptez l'invite pour poursuivre la connexion SSH. L'agent SSH a transmis

votre clé privée SSH via la jumpbox et vous permet de vous connecter à la
machine virtuelle Web. Et ensuite ? Eh bien, voici un exercice pratique pour voir
comment cela fonctionne !

5.4 Exercice pratique : installation et test du serveur Web LAMP

Vous avez déjà effectué le plus gros du travail tout au long de ce chapitre. Cet exercice
rapide reprend la méthode d'installation d'un serveur Web et vous permet de voir une
démonstration des règles NSG en action sur votre machine virtuelle :

1 Installez un serveur Web Linux de base. Pensez de nouveau au chapitre 2, lorsque

vous avez créé une connexion SSH à la machine virtuelle, puis installé un
package de serveur Web LAMP avec apt. Depuis la connexion SSH à votre
machine virtuelle Web créée en section 5.3.2, installez et configurez la pile Web
LAMP par défaut.
2 Accédez au site Web par défaut. Une fois que la pile Web LAMP est installée, ouvrez
votre navigateur et accédez à l'étiquette de nom DNS que vous avez entrée
lorsque vous avez créé une adresse IP publique dans la section  5.1.3. Dans
l'exemple, il s'agissait de azuremol.eastus.cloud- app.azure.com. Vous pouvez
également utiliser l'adresse IP publique produite lorsque vous avez créé la
machine virtuelle Web. Rappelez-vous cependant que cette adresse IP publique
est différente de la machine virtuelle jumpbox à laquelle vous vous êtes
connecté !
 Partie 2

Haute disponibilité et évolutivité

B ien, le moment est venu de s'amuser un peu  ! Maintenant que vous

maîtrisez les principales ressources disponibles dans Azure, nous pouvons étudier
plus en détail des domaines comme la redondance, l'équilibrage de charge et la
distribution géographique des applications. Cette partie devient vraiment
intéressante, et vous allez commencer à trouver dans ce que vous apprenez des
solutions et bonnes pratiques que vous pourrez utiliser dans le cadre de
déploiements réels. Azure propose d'excellentes fonctionnalités pour répliquer
les données à l'échelle mondiale, distribuer le trafic client sur l'instance la plus
proche de votre application et dimensionner automatiquement en fonction de la
demande. Ces fonctionnalités font toute la puissance du cloud computing et
vous permettent d'apporter de la valeur ajoutée à votre travail.
 Azure Resource Manager

de développement et
6
La plupart du temps, vous souhaitez passer le moins de temps possible à réfléchir
sur la façon dont vous déployez un environnement d'application, afin de pouvoir
vous consacrer au déploiement réel. Dans de nombreux environnements IT,
les  équipes opérationnelles ont
plus en plus tendance à travailler en étroite collaboration, grâce à l'engouement
pour le DevOps qui fait l'objet d'un grand nombre de conférences et de blogs.
de

La culture du DevOps n'a rien d'intrinsèquement nouveau ou révolutionnaire, mais il

arrivait souvent que les différentes équipes ne travaillent pas ensemble comme il aurait
fallu. Les outils modernes ont stimulé l'essor du DevOps, avec des solutions d'intégration
continue/livraison continue (CI/CD) capables d'automatiser l'ensemble du
déploiement des environnements d'application en se basant sur un seul enregistrement
de code effectué par un développeur. C'est généralement l'équipe opérationnelle qui
crée et gère ces pipelines CI/CD, ce qui permet d'accélérer considérablement les tests et
les déploiements des mises à jour applicatives pour les développeurs.
Le modèle de déploiement Azure Resource Manager est essentiel pour votre
processus de création et d'exécution des ressources, même si vous ne vous en êtes
probablement pas encore rendu compte. Resource Manager offre une approche
pour la création et le déploiement de ressource, au même titre que les modèles et les
processus d'automatisation qui sous-tendent ces déploiements. Dans ce chapitre,
vous apprendrez à utiliser les fonctionnalités de Resource Manager telles que les
contrôles d'accès et les verrous, les déploiements de modèles cohérents et les
déploiements à plusieurs niveaux automatisés.

6.1 L'approche Azure Resource Manager

Lorsque vous avez créé une machine virtuelle ou une application Web, vous avez
commencé par créer un groupe de ressources, la structure de base utilisée pour
contenir toutes vos ressources. Le groupe de ressources est essentiel pour toutes les
ressources : les machines virtuelles, les applications Web, les réseaux virtuels ou les
tables de stockage ne peuvent pas exister en dehors de ce groupe. Mais le groupe de
75
76 Chapitre 6  Azure Resource Manager

ressources est bien plus qu'un simple emplacement pour organiser vos ressources.
Cette section explique ce qu'est le modèle Azure Resource Manager, et démontre
pourquoi il est important lorsque vous créez et exécutez des applications.

6.1.1 Conception tout au long du cycle de vie des applications

Croisons les doigts pour que vous ne développiez jamais une application pour en
négliger la maintenance ! Vous avez généralement des mises à jour à développer et
déployer, de nouveaux packages à installer, de nouvelles machines virtuelles à ajouter
et des emplacements de déploiement d'applications Web supplémentaires à créer. Il se
peut que vous deviez apporter des modifications aux paramètres du réseau virtuel et
aux adresses IP. J'ai évoqué dans les chapitres précédents le fait que vos réseaux virtuels
dans Azure peuvent être gérés par une autre équipe. Vous devez commencer à réfléchir
à la façon dont vous allez procéder à une échelle plus étendue, mondiale, et dont vous
allez assurer la gestion et le cycle de vie de votre application.
Plusieurs grandes approches en matière de regroupement de ressources sont
proposées dans Azure :
¡ Toutes les ressources associées à une application donnée dans le même groupe de ressources :
comme illustré à la figure 6.1, cette approche fonctionne bien pour les applica-
tions de moindre envergure et les environnements de développement et de test.
Si vous n'avez pas besoin de partager de grands espaces de mise en réseau et pou-
vez gérer individuellement le stockage, vous pouvez créer toutes les ressources en
un seul endroit, puis gérer les mises à jour et les modifications de configuration
en une seule opération.

Réseau virtuel

Sous-réseau frontend Sous-réseau frontend

NIC 1 NIC 2 NIC 3 NIC 4

VM 1 VM 2 VM 3 VM 4

Disque du Disque du Disque du Disque du

Disque de Disque de Disque de Disque de
système système données système système
données données données
d’exploitaon d’exploitaon d’exploitaon d’exploitaon

Groupe de ressources uniques

Figure 6.1  L'une des méthodes pour créer une application dans Azure consiste à créer toutes les
ressources liées au déploiement de cette application dans le même groupe de ressources et à les
gérer comme une entité unique.

¡ Ressources similaires regroupées par fonction dans le même groupe de ressources : comme illus-
tré à la figure 6.2, cette approche est souvent plus courante dans les applications et
environnements plus importants. Votre application peut exister dans un groupe de
ressources avec uniquement les machines virtuelles et les composants d'application
nécessaires. Les ressources réseau virtuelles et les adresses IP peuvent exister dans un
autre groupe de ressources, sécurisé et géré par un autre groupe d'ingénieurs.
 L'approche Azure Resource Manager 77

Réseau virtuel

Sous-réseau frontend Sous-réseau backend

NIC 1 NIC 2 NIC 3 NIC 4

Groupe de ressources réseau

VM 1 VM 2 VM 3 VM 4

Disque du Disque du Disque du Disque du

Disque de Disque de Disque de Disque
système système système système
données données données de données
d’exploitaon d’exploitaon d’exploitaon d'exploitaon

Groupe des ressources de traitement

Figure 6.2  Une autre approche consiste à créer et à regrouper les ressources en fonction de leur rôle.
Un exemple courant de ce cas de figure est quand toutes les ressources réseau principales se trouvent
dans un autre groupe de ressources que les ressources de traitement d'application principales.
Les machines virtuelles situées dans le groupe de ressources de traitement peuvent accéder aux
ressources réseau situées dans l'autre groupe, mais les deux ensembles de ressources peuvent être
gérés et sécurisés de façon indépendante.

Pourquoi ces approches différentes ? Il ne s'agit pas uniquement de sécurité des tâches
et des silos rassurants dans lesquels certaines équipes aiment travailler. Cela concerne
la façon dont vous devez gérer les ressources sous-jacentes. Dans les environnements et
applications de moindre envergure, où toutes les ressources sont situées dans le même
groupe de ressources, vous êtes responsable de tout ce qui se trouve dans
l'environnement ou l'application en question. Cette approche est également bien
adaptée aux environnements de développement et de test, où tout est regroupé
ensemble. Les modifications apportées au réseau virtuel impactent uniquement votre
application et votre groupe de ressources.
La réalité, c'est que les réseaux ne sont pas souvent modifiés. Les plages d'adresses
sont souvent bien définies et planifiées de façon à pouvoir coexister à l'échelle des sites
et des bureaux d'Azure à travers le monde. Bien souvent, il paraît logique de placer les
composants réseau dans leur propre groupe de ressources. Le réseau est géré
séparément de l'application. De la même façon, le stockage peut être géré et mis à jour
de façon indépendante. Cette division des ressources n'a rien d'intrinsèquement
mauvais, tant que les équipes IT ne restent pas bloquées dans une «  mentalité de
cloisonnement » entraînant un manque de coopération.
Pour vos applications, la division des ressources peut également être un avantage,
car vous restez dans une grande mesure libre d'effectuer les modifications et mises à
jour de votre choix. C'est justement parce que les composants réseau ne se
trouvent pas dans votre groupe de ressources que vous n'avez pas à vous en préoccuper
lorsque vous réalisez des mises à jour d'application.
78 Chapitre 6  Azure Resource Manager

6.1.2 Sécurisation et contrôle des ressources

Différentes autorisations de sécurité peuvent être appliquées à chaque ressource. Ces
stratégies définissent qui peut faire quoi. Réfléchissez-y : voulez-vous qu'un stagiaire
puisse redémarrer votre application Web ou supprimer les disques de données des
machines virtuelles ? Et pensez-vous que vos collègues de l'équipe réseau seraient ravis
de vous voir créer un nouveau sous-réseau virtuel ? Probablement pas. Dans Azure, il
existe quatre rôles principaux que vous pouvez affecter aux ressources, de la même
façon que des autorisations de fichiers :
¡ Propriétaire : contrôle complet, en gros, il s'agit d'un administrateur
¡ Contributeur : entière gestion des ressources, sauf lorsqu'il s'agit d'apporter des
modifications aux affectations de sécurité et de rôles
¡ Lecteur : capacité à afficher toutes les informations sur les ressources, mais ne peut
pas y apporter de modifications
¡ Administrateur de l'accès utilisateur : capacité à attribuer ou supprimer l'accès aux
ressources
Le contrôle d'accès en fonction du rôle (RBAC) est une fonctionnalité essentielle des res-
sources Azure, et il est automatiquement intégré aux comptes utilisateur de vos abonne-
ments. Pensez aux autorisations de fichiers sur votre ordinateur normal. Les autorisations
de fichiers de base sont lecture, écriture et exécution. Vous pouvez les combiner afin de
créer différents ensembles d'autorisations pour chaque utilisateur ou groupe sur votre
ordinateur Lorsque vous travaillez avec des partages de fichiers réseau, les autorisations
sont couramment utilisées pour contrôler les accès. Dans Azure, le RBAC fonctionne sur
ce même principe de contrôle de l'accès aux ressources, exactement comme les autorisa-
tions de fichiers sur votre ordinateur local ou votre partage réseau (figure 6.3).

Figure 6.3  Pour chaque ressource Azure, le contrôle d'accès répertorie les affectations actives. Vous
pouvez ajouter des affectations ou sélectionner Rôles pour afficher des informations sur les ensembles
d'autorisations disponibles.
 L'approche Azure Resource Manager 79

Tester
Ouvrez le portail Azure dans un navigateur Web, puis sélectionnez n'importe laquelle
de vos ressources, par exemple cloud-shell-storage. Appuyez sur le bouton Contrôle
d'accès (IAM), comme illustré à la figure 6.3. Passez en revue les attributions de rôles
actives. Découvrez comment ajouter une attribution de rôle, ainsi que toutes les
attributions de rôle disponibles. L'icône d'information en regard de chaque rôle
indique quelles autorisations sont affectées.

En examinant les différents rôles disponibles, vous remarquerez peut-être plusieurs

rôles spécifiques aux ressources, notamment :
¡ Contributeur de machine virtuelle
¡ Contributeur de site Web
¡ Contributeur réseau
Pouvez-vous deviner ce que signifient ces rôles ? Le principe consiste ici à appliquer le
rôle Contributeur de base à un type de ressource spécifique. Là encore, il est question
de la façon dont vous gérez les ressources similaires. Vous pouvez vous voir attribuer le
rôle de Contributeur de machine virtuelle ou de Contributeur de site Web. Vous
pourriez alors gérer toutes les machines virtuelles ou applications Web créées dans ce
groupe de ressources. Mais vous ne pourriez pas gérer les ressources réseau, qui se
trouvent peut-être toutes dans un autre groupe de ressources.

6.1.3 Protection des ressources à l'aide de verrous

L'approche basée sur les autorisations du RBAC est idéale pour contrôler qui peut
accéder à quoi. Mais des erreurs restent possibles. Généralement, vous ne vous connectez
pas à un serveur en tant qu'utilisateur avec des autorisations racine ou d'administration,
et voici pourquoi  : il suffit d'une frappe ou d'un clic erroné(e) pour supprimer des
ressources par erreur. Même si vous disposez de sauvegardes (vous avez bien des
sauvegardes, n'est-ce pas  ? et vous les testez régulièrement  ?), il s'agit d'un
processus chronophage qui peut entraîner une perte de productivité ou de revenus pour
l'entreprise. Dans le chapitre 13, vous en apprendrez davantage sur la façon dont les
services de sauvegarde, de récupération et de réplication d'Azure protègent vos données.
Les verrous de ressources sont une autre fonctionnalité intégrée au modèle Resource
Manager. Chaque ressource peut se voir appliquer un verrou pour restreindre son
accès en lecture seule ou empêcher les opérations de suppression. Le verrou de
suppression est particulièrement utile, car il peut être trop facile de supprimer par
erreur le mauvais groupe de ressources. Une fois que vous démarrez une opération de
suppression, aucun retour en arrière ou annulation n'est possible dès lors que la
plateforme Azure a accepté votre requête.
Pour les charges de travail de production, je vous conseille d'appliquer des verrous sur
vos ressources principales pour empêcher les suppressions. Ces verrous fonctionnent
uniquement aux niveaux des ressources et de la plateforme Azure, pas pour les données qui
se trouvent dans vos ressources. Par exemple, vous pourriez supprimer des fichiers dans
une machine virtuelle ou une table dans une base de données. Les verrous de ressources
Azure s'appliquent uniquement si vous essayez de supprimer l'intégralité de l'Azure SQL
database ou de la machine virtuelle. La première fois qu'un verrou vous empêchera de
supprimer involontairement un groupe de ressources, vous me remercierez !
80 Chapitre 6  Azure Resource Manager

Figure 6.4  Créez un verrou de ressource sur le portail Azure.

Tester
Pour voir les verrous de ressources Azure en action, comme illustré à la figure  6.4,
procédez comme suit :

1 Ouvrez le portail Azure dans un navigateur Web, puis sélectionnez n'importe

lequel de vos groupes de ressources, par exemple cloud-shell-storage.
2 Choisissez Verrous sur le côté gauche du portail.
3 Indiquez le nom du verrou, par exemple Protéger, sélectionnez Supprimer dans
le menu déroulant Type de verrou et cliquez sur OK. Votre nouveau verrou
apparaît alors dans la liste.
4 Sélectionnez Présentation pour le groupe de ressources, puis essayez de
supprimer le groupe de ressources. Vous devez saisir le nom du groupe de
ressources pour confirmer que vous souhaitez le supprimer (ce qui est également
utile pour vous assurer que vous sélectionnez la bonne ressource à supprimer !).
5 Lorsque vous cliquez sur le bouton Supprimer, examinez le message d'erreur qui
s'affiche pour voir comment votre verrou a empêché Azure de supprimer la ressource.

6.1.4 Gestion et regroupement des ressources avec des balises

Je voudrais maintenant aborder une dernière fonctionnalité disponible dans le modèle
Azure Resource Manager : les balises. La façon dont vous balisez les ressources dans
Azure n'a rien de nouveau ni de spécial, mais cette méthode de gestion est souvent
négligée. Vous pouvez appliquer des balises à une ressource dans Azure pour décrire
des propriétés telles que l'application dont fait partie cette ressource, le service qui en
est responsable, ou encore indiquer s'il s'agit d'une ressource de développement ou de
production.
 Modèles Azure Resource Manager 81

Vous pouvez ensuite cibler des ressources en fonction des balises

pour appliquer des verrous ou des rôles RBAC, ou encore pour signaler
les coûts et la consommation d'une ressource. Les balises ne sont pas propres à un
groupe de ressources et peuvent être réutilisées dans le cadre de votre abonnement.
Vous pouvez appliquer jusqu'à 50 balises à une seule ressource ou groupe de
ressources, cela vous offre donc une grande flexibilité en matière de balisage des
ressources et de filtrage des ressources balisées.

Tester
Pour voir les balises de ressources Azure en action, procédez comme suit :

1 Ouvrez le portail Azure dans un navigateur Web, puis sélectionnez n'importe

quelle ressource, par exemple cloud-shell-storage. Même si c'est possible,
ne choisissez pas de marquer un groupe de ressources pour cet exercice.
2 Une fois votre ressource sélectionnée, sélectionnez le bouton Balises, comme
illustré à la figure 6.5.
3 Entrez un nom, par exemple workload, et une valeur, par exemple development.
4 Cliquez sur Enregistrer.
5 Ouvrez Cloud Shell.
6 Pour filtrer les ressources en fonction des balises, utilisez az resource list avec
le paramètre --tag. Utilisez votre nom et votre valeur comme suit :
az resource list --tag workload=development

Figure 6.5  Vous pouvez créer jusqu'à 50 balises name:value pour chaque ressource ou groupe de
ressources Azure.

6.2 Modèles Azure Resource Manager

Jusqu'à présent, vous avez créé un petit nombre de ressources Azure à la fois. Pour ce
faire, vous avez utilisé le portail Azure ou la CLI Azure. Même si je ne vous ai pas encore
montré le module Azure PowerShell, j'en ai parlé dans le premier chapitre, et il est
disponible dans le Cloud Shell. Vous l'avez d'ailleurs peut-être testé sans moi. C'est
bon, je ne vous en veux pas ! Comme je l'ai expliqué dans le chapitre 1, Azure propose
des outils qui vous permettent de choisir ce qui convient le mieux pour vous et
l'environnement dans lequel vous travaillez.
82 Chapitre 6  Azure Resource Manager

Lorsque vous utilisez le portail, la CLI ou les commandes PowerShell, l'inconvénient

est que vous devez cliquer sur de nombreux boutons dans le navigateur Web ou taper
des lignes de commandes pour créer votre environnement d'application. Vous pouvez
créer des scripts pour faire toutes ces tâches, mais il vous faut dans ce cas créer une
logique pour gérer la création de plusieurs ressources en même temps ou l'ordre dans
lequel les ressources sont créées.
L'utilisation d'un script qui englobe les commandes PowerShell et la CLI Azure est
un premier pas dans la bonne direction en matière de création et de déploiement
d'environnements d'application, pas seulement dans Azure, mais sur n'importe quelle
plateforme. La tendance est à l'utilisation de l'infrastructure en tant que code (IaC),
qui doit vous être familière si vous êtes dans l'informatique depuis longtemps. Cette
interface fonctionne sur le principe suivant  : vous n'avez plus besoin d'intervention
humaine pour saisir des commandes et suivre un ensemble d'étapes ; au lieu de cela,
vous créez programmatiquement votre infrastructure à partir d'un ensemble
d'instructions. Les déploiements manuels introduisent un facteur humain qui peut
souvent être à l'origine d'erreurs de configurations mineures et de légères différences
entre les machines virtuelles finales, comme illustré à la figure 6.6.

Scripts VM 1
Différences
Opérateur potentielles
Check-lists VM 2
humain dans les VM
déployées
Packages
Plusieurs étapes et d’installation VM 3
scripts pour créer des
machines virtuelles

Figure 6.6  Les humains commettent des erreurs, comme des fautes de frappe ou l'oubli d'une étape
dans le cadre d'un déploiement. Vous pouvez vous retrouver avec des machines virtuelles légèrement
différentes à la fin de la sortie. L'automatisation est souvent utilisée pour éliminer le facteur humain
de l'équation et créer des déploiements cohérents et identiques chaque fois.

Même avec des scripts, vous avez toujours besoin de quelqu'un pour les écrire, les gérer
et les maintenir à jour à mesure que les nouvelles versions des modules CLI Azure ou
PowerShell sont publiées. Oui, il arrive parfois que des changements importants soient
apportés aux outils pour pouvoir intégrer de nouvelles fonctionnalités, même si cela
reste rare.

6.2.1 Création et utilisation de modèles

Les modèles Resource Manager peuvent contribuer à réduire l'erreur humaine et la
dépendance des humains vis-à-vis des scripts écrits. Les modèles sont écrits en
JavaScript Object Notation (JSON), un format standard ouvert et inter-plateformes qui
permet de les éditer dans un éditeur de texte de base. Ils vous permettent de créer des
déploiements cohérents et reproductibles qui contribuent à réduire le nombre
d'erreurs. Autre fonctionnalité intégrée des modèles  : la plateforme comprend les
dépendances et peut, dans la mesure du possible, créer les ressources en parallèle afin
d'accélérer le temps de déploiement. Si vous créez trois machines virtuelles, il n'est pas
nécessaire d'attendre que le déploiement de la première soit terminé pour créer la
deuxième. Resource Manager peut créer les trois machines virtuelles en même temps.
 Modèles Azure Resource Manager 83

Voici un exemple de dépendances : si vous créez une carte réseau virtuelle, vous
devez la connecter à un sous-réseau. Logiquement, le sous-réseau doit exister avant que
vous puissiez créer la carte réseau virtuelle. Et le sous-réseau doit faire partie d'un
réseau virtuel, de sorte que le réseau doit être créé avant le sous-réseau. La figure 6.7
montre la chaîne de dépendances en action. Si vous essayez d'écrire vous-même un
script, vous devez planifier soigneusement l'ordre dans lequel les ressources sont
créées, et même alors il vous faut créer une logique pour savoir quand les ressources
parentes sont prêtes et quand vous pouvez passer aux ressources dépendantes.

Carte
Dépend de Sous- Dépend de Réseau
réseau
réseau virtuel
virtuelle

Figure 6.7  Azure Resource Manager gère les dépendances à votre place. La plateforme sait dans quel
ordre créer les ressources et connaît l'état de chaque ressource sans utiliser de logique écrite à la main
ni de boucles comme celles que vous devez utiliser dans vos scripts.

Vous voulez apprendre quelque chose d'intéressant ? Vous avez déjà utilisé des modèles
Resource Manager dans le chapitre 2 et pour la toute première machine virtuelle que
vous avez créée. Au fur et à mesure que vous créez une machine virtuelle sur le portail
ou dans la CLI Azure, un modèle est créé et déployé programmatiquement en catimini.
Pourquoi ? Eh bien, pourquoi réinventer la roue et passer par le processus visant à
créer toute cette logique pour les déploiements ? Laissez Azure Resource Manager le
faire à votre place !
Voyons à quoi ressemble une section d'un modèle Resource Manager. La liste
suivante montre la section qui crée une adresse IP publique, exactement comme dans
les exemples précédents lorsque vous avez créé une machine virtuelle.

Liste 6.1  Création d'une adresse IP publique dans un modèle de gestionnaire de

ressources

{
    "apiVersion": "2019-04-01",
    "type": "Microsoft.Network/publicIPAddresses",
    "name": "publicip",
    "location": "eastus",
    "properties": {
     "publicIPAllocationMethod": "dynamic",
     "dnsSettings": {
      "domainNameLabel": "azuremol"
  }
 }
},

Même si le format JSON est nouveau pour vous, il est (relativement)

lisible par l'homme. Vous définissez un type de ressource, dans cet exemple,
Microsoft.Network/publicIPAddresses. Vous indiquez ensuite un nom, par exemple
publicip, et un emplacement, par exemple eastus. Pour terminer, vous définissez la
méthode d'allocation, dynamic dans cet exemple, ainsi qu'une étiquette de nom DNS,
84 Chapitre 6  Azure Resource Manager

par exemple azuremol. Ce sont les mêmes paramètres que ceux que vous avez fournis
lorsque vous avez utilisé le portail Azure ou la CLI. Et si vous utilisez PowerShell,
devinez quoi ? Vous êtes invité à renseigner les mêmes paramètres.
La différence avec le modèle, c'est que vous n'avez pas eu à saisir d'informations.
Toutes les informations figuraient dans le code. Vous pensez peut-être « Parfait, mais
que se passe-t-il si je veux utiliser des noms différents chaque fois ? ». Comme avec un
script, vous pouvez attribuer dynamiquement des noms à l'aide de paramètres et de
variables :
¡ Les paramètres sont des valeurs que vous êtes invité à renseigner. Ils sont souvent
utilisés pour les informations d'identification utilisateur, le nom de la machine
virtuelle et l'étiquette de nom DNS.
¡ Les variables peuvent se voir « préattribuer » une valeur, mais elles sont également
adaptées chaque fois que vous déployez le modèle, tout comme la taille de la
machine virtuelle ou le nom du réseau virtuel.

Tester
Pour voir un modèle Resource Manager complet, accédez au référentiel GitHub à
l'adresse http://mng.bz/QyWv.

6.2.2 Création de plusieurs instances d'un type de ressource

Lorsque vous créez vos modèles, essayez d'anticiper les futurs besoins en évolution de
vos applications. Il se peut que vous n'ayez besoin que d'une seule machine virtuelle
lorsque vous déployez votre application pour la première fois, mais si la demande pour
votre application augmente, il vous faudra peut-être créer des instances
supplémentaires.
Dans le cadre d'un déploiement par script traditionnel, vous créez une boucle for
ou while pour créer plusieurs instances d'un type de ressource. Cette fonctionnalité est
intégrée à Resource Manager ! Comme la plupart des langages de programmation et de
script, Resource Manager propose plus de 50 types de fonctions. Les fonctions Resource
Manager courantes sont notamment length, equals, or et trim. Vous contrôlez le
nombre d'instances à créer à l'aide de la fonction copy.
Lorsque vous utilisez la fonction copy, Resource Manager crée le nombre de
ressources que vous spécifiez. Chaque fois que Resource Manager répète l'opération de
création, une valeur numérique est mise à votre disposition pour vous permettre de
nommer les ressources de manière séquentielle. Vous accédez à cette valeur à l'aide de
la fonction copyIndex(). L’exemple de la liste 6 a créé une adresse IP publique unique.
L’exemple de la liste  6.2 utilise le même type de fournisseurs de ressources
Microsoft.Network/publicIPAddresses, mais crée deux adresses IP publiques. Vous
utilisez copy pour définir combien d'adresses vous souhaitez créer et copyIndex() pour
nommer les adresses de façon séquentielle.

Liste 6.2  Création de plusieurs adresses IP publiques à l'aide de la fonction copy

{
    "apiVersion": "2019-04-01",
    "type": "Microsoft.Network/publicIPAddresses",
    "name": "[concat(‘publicip’, copyIndex())]",
 Modèles Azure Resource Manager 85

    "copy": {
     "count": 2
    }
    "location": "eastus",
    "properties": {
     "publicIPAllocationMethod": "dynamic",
    }
},

Vous utilisez également la fonction concat pour concaténer le nom de l'adresse  IP

publique et la valeur numérique de chaque instance que vous créez. Une fois ce
modèle déployé, vos deux adresses  IP publiques sont nommées publicip0 et
publicip1. Ces noms ne sont n'est pas forcément très descriptif, mais cet exemple
simple montre comment vous pouvez utiliser une convention de numérotation lorsque
vous créez plusieurs ressources à l'aide de la fonction copy.

6.2.3 Outils permettant de créer vos propres modèles

Je vous dois la vérité  : les modèles Resource Manager sont vraiment super, et je ne
peux que vous les recommander pour créer et déployer vos applications dans Azure,
mais il n'en reste pas moins que vous devez les écrire. Différents outils sont à votre
disposition pour vous simplifier la tâche, et des centaines d'exemples de modèles sont
disponibles auprès de Microsoft et de tiers. En fait, l'une des meilleures façons
d'apprendre à créer et à utiliser des modèles consiste à examiner les modèles de
démarrage rapide proposés par Microsoft dans son référentiel d'exemples à l'adresse
https://github.com/Azure/azure-quickstart-templates.
Si vous êtes motivé pour commencer à écrire vos propres modèles, il existe deux outils
principaux que je vous recommande. Le premier est Visual Studio Code, un éditeur
multiplateforme, open source et gratuit (https://code.visualstudio.com). Outre des
fonctionnalités intégrées comme le contrôle de code source et l'intégration GitHub, il
propose également des extensions permettant de créer automatiquement les
différentes sections, ou encore des fournisseurs, qui offrent les ressources nécessaires
pour créer un modèle, comme illustré à la figure 6.8. Si vous téléchargez et installez VS
Code, sélectionnez View (Afficher) >Extensions, puis recherchez Azure.

Figure 6.8  De nombreuses extensions sont disponibles dans Visual Studio Code pour optimiser et simplifier la
création et l'utilisation des modèles Azure Resource Manager.
86 Chapitre 6  Azure Resource Manager

Figure 6.9  Visual Studio vous permet de créer graphiquement des modèles et d'explorer les ressources JSON.

Une méthode plus « graphique » pour créer des modèles Azure Resource Manager
consiste à utiliser la version complète de l'éditeur Visual Studio, comme illustré à la
figure 6.9. Il existe des versions pour Windows et macOS, mais vous avez besoin d'une
licence distincte pour utiliser l'éditeur. Une édition Community est disponible, mais à
utiliser avec prudence si vous créez des modèles dans votre entreprise : une version
avec une licence est généralement nécessaire. Consultez vos experts en matière de
licences, car Visual Studio est destiné aux développeurs d'applications.
Vous pouvez, bien sûr, utiliser un éditeur de texte de base. L'une des raisons pour
lesquelles les modèles Azure Resource Manager sont écrits en JSON, c'est que cela
élimine la nécessité de recourir à des outils spéciaux. Travailler avec JSON implique
une courbe d'apprentissage, c'est pourquoi je vous recommande d'explorer les modèles
de démarrage rapide disponibles dans le référentiel d'exemples Azure. Attention à
l'indentation, aux virgules de fin et à l'utilisation des parenthèses, crochets et accolades !

Allô la Terre, en forme ?

Des outils tiers et d'autres solutions sont à votre disposition pour utiliser les modèles
dans Azure. Hashicorp propose de nombreux outils et solutions open source dédiés au
cloud computing, notamment Terraform. Terraform vous permet de définir toutes les
ressources que vous souhaitez créer de la même façon que vous créez un modèle Azure
Resource Manager natif. Vous pouvez également définir des dépendances et utiliser des
variables. La différence est que, techniquement, Terraform est un fournisseur multi-
systèmes. Les mêmes structures et la même approche en matière de modèles peuvent
être utilisées dans Azure, Google Cloud, AWS et vSphere, par exemple. La différence
réside dans les solutions de provisionnement que vous utilisez pour chaque ressource.
S'agit-il vraiment d'une approche « un modèle pour un fournisseur » ? Non, pas du tout.
Terraform est également une application qui analyse votre modèle, puis qui communique
avec le fournisseur cloud approprié, par exemple Azure. Vous ne disposez d'aucune
fonctionnalité d'édition, et encore moins d'outils graphiques, pour créer votre modèle.
Vous choisissez un éditeur et écrivez le modèle à la main. Encore une fois, la meilleure
façon de vous familiariser avec Terraform consiste à consulter sa documentation et
à explorer ses exemples de modèles.
 Laboratoire : déploiement de ressources Azure à partir d'un modèle 87

Si j'aborde cette question, c'est en référence au concept de choix dans Azure. Si vous
trouvez que les modèles Azure Resource Manager écrits en JSON sont un peu trop
complexes, essayez un produit comme Terraform. Ne renoncez pas aux déploiements
Resource Manager basés sur des modèles. Pour obtenir des déploiements reproductibles
et cohérents à grande échelle, les modèles restent la meilleure approche, c'est pourquoi je
vous conseille de trouver l'approche basée sur des modèles qui vous convient.

6.2.4 Stockage et utilisation des modèles

Donc, le principe des modèles Azure Resource Manager vous intéresse, et vous avez
installé Visual Studio ou Visual Studio Code pour écrire vos propres modèles.
Comment stocker et déployer ces modèles ? Dans l'exercice pratique proposé en fin de
chapitre, vous déployez un modèle à partir du référentiel d'exemples Azure sur
GitHub. Il s'agit d'un référentiel public, et vous n'avez peut-être pas envie de rendre
vos modèles d'application disponibles au monde entier.
Il existe deux  solutions courantes pour stocker les modèles Resource Manager
en privé :
¡ Utiliser un référentiel privé ou un partage de fichiers réseau dans votre entreprise.
¡ Utiliser Azure Storage pour stocker de manière centralisée et sécuriser des
modèles en vue de leur déploiement.
Il n'existe pas de bonne ou mauvaise méthode pour stocker et déployer des modèles.
Vous êtes libre d'utiliser les processus et outils déjà en place. L'avantage du référentiel,
c'est que vous disposez généralement d'un certain contrôle sur les versions, ce qui vous
permet de garantir la cohérence des déploiements et de consulter l'historique de vos
modèles en cas de besoin. La seule contrainte, c'est que lorsque vous déployez le
modèle, vous devez fournir les informations d'identification appropriées pour accéder
à l'emplacement partagé. Ce processus d'authentification peut varier : vous pouvez par
exemple inclure un nom d'utilisateur ou un jeton d'accès dans l'URL vers un modèle
situé dans un référentiel, ou encore fournir un jeton de signature d'accès partagé
(SAS) si vous utilisez Azure Storage.
Les référentiels publics comme GitHub peuvent également être de bonnes solutions
pour apprendre et partager. Je vous conseille de stocker vos modèles de production en
privé, mais si vous créez un modèle qui se prête à des expérimentations ou au test de
nouvelles fonctionnalités, le fait de le partager sur GitHub vous permet d'apporter
votre contribution à la communauté informatique et d'aider d'autres utilisateurs qui
souhaitent réaliser les mêmes déploiements que vous. Et lorsque vous commencez à
créer vos propres modèles, n'oubliez pas de vérifier quels modèles existent déjà pour
ne pas avoir à partir de zéro et à réinventer la roue à chaque fois !

6.3 Laboratoire : déploiement de ressources Azure à partir d'un modèle

C'est bien beau de faire de la théorie sur les modèles et approches de déploiement,
mais vous allez (je l'espère !) commencer à en voir les avantages et l'efficacité lorsque
vous utiliserez des modèles pour de bon :

1 Accédez aux modèles de démarrage rapide sur GitHub (https://github.com/

Azure/azure-quickstart-templates) et trouvez-en un qui vous intéresse. Un bon
point de départ est une machine virtuelle Linux ou Windows simple.
88 Chapitre 6  Azure Resource Manager

2 Les exemples GitHub contiennent des boutons permettant de déployer

directement dans Azure. Une fois que vous avez trouvé un modèle qui vous
convient, sélectionnez Deploy to Azure (Déployer sur Azure), comme illustré à la
figure  6.10, puis suivez les étapes indiquées sur le portail. Ce processus est le
même que celui de la création d'une machine virtuelle, mais il n'y a que quelques
invites à suivre pour renseigner les paramètres requis. Toutes les autres ressources
sont créées à votre place, et vous pouvez en faire abstraction.
3 La dernière étape pour déployer votre modèle consiste à accepter le contrat de
licence affiché, puis à sélectionner Purchase (Achat). Vous créez des ressources
Azure lorsque vous déployez un modèle, ce qui signifie qu'en cliquant sur
Purchase (Achat), vous indiquez que vous acceptez de payer les coûts de ces
ressources Azure.
Un modèle de base, comme une machine virtuelle Linux ou Windows simple,
coûte environ le même prix que les autres machines virtuelles que vous avez
créées jusqu'à présent. Veillez à supprimer le groupe de ressources une fois que
votre déploiement est terminé, exactement comme ce que vous faites
après n'importe quel autre exercice.

Figure 6.10  Chaque modèle Resource Manager situé dans le référentiel d'exemples GitHub est associé à un bouton
Deploy to Azure (Déployer sur Azure). Si vous cliquez sur ce bouton, le portail Azure se charge et le modèle est chargé.
Vous êtes invité à renseigner certains paramètres de base, et le reste du déploiement est traité par le modèle.
 Laboratoire : déploiement de ressources Azure à partir d'un modèle 89

Utilisation de paramètres dans les modèles

Comme nous l'avons mentionné dans la section 6.2.1, vous pouvez utiliser des
paramètres et des variables dans vos modèles. Rappelez-vous, les paramètres sont des
valeurs que vous êtes invité à renseigner, et les variables sont des valeurs dynamiques
qui peuvent être appliquées à tous les niveaux d'un modèle. Les valeurs que vous êtes
invité à renseigner (paramètres) varient d'un modèle à l'autre. Ainsi, en fonction du
modèle de démarrage rapide que vous sélectionnez, vous pouvez être invité à renseigner
une ou deux valeurs, ou vous pouvez avoir à en fournir sept ou huit.
Quand vous concevez vos modèles, essayez de prévoir si vous et les autres utilisateurs
voudrez les réutiliser lorsque vous déploierez des applications. Vous pouvez fournir une
valeur par défaut et restreindre les valeurs autorisées. Soyez toutefois vigilant avec ces
valeurs par défaut et autorisées, car vous risquez sinon de trop contraindre les
utilisateurs et de les obliger à créer leurs propres modèles. Dans la mesure du possible,
essayez de créer des modèles de base réutilisables et offrant suffisamment de flexibilité.

4 Une fois votre modèle déployé, retournez sur GitHub et examinez le fichier
azure-deploy.json. Ce fichier est le modèle Azure Resource Manager que vous
avez utilisé pour créer et déployer l'exemple. Essayez de voir si vous comprenez
les différents types de ressources et les différentes configurations qui ont été
appliqués. Vous aurez moins de mal à comprendre le format JSON quand vous
serez amené à travailler avec davantage de types de ressources et de modèles !
Faites-moi confiance !
 Haute disponibilité
et redondance
7
J’ai perdu le compte du nombre de fois où quelque chose en informatique m’a
laissé tomber. J’ai eu une panne de disque dur sur un ordinateur portable la veille
d’une conférence, une alimentation électrique fumante sur un serveur de
messagerie et une défaillance d’interfaces réseau sur un routeur principal. Et mieux
vaut ne pas me lancer sur le sujet des mises à jour de systèmes d’exploitation, de
pilotes, ou de microprogrammes ! Je suis sûr que tous ceux qui travaillent dans le
domaine de l’informatique aimeraient partager des histoires d’horreur sur des
situations auxquelles ils ont dû faire face : généralement des problèmes qui se sont
produits au milieu de la nuit ou à un moment critique pour l’entreprise. Est-ce
qu’une bonne panne arrivant au bon moment, peut réellement exister ?
En informatique, si vous anticipez les problèmes, vous apprenez à planifier
et  à  concevoir des applications qui en tiennent compte. Dans ce chapitre,
vous  apprendrez à utiliser les fonctionnalités de haute disponibilité et de
redondance  d’Azure pour minimiser les perturbations causées par les
mises à jour de maintenance et les pannes. Ce chapitre jette les bases des deux ou
trois chapitres à venir, tandis que vous commencez à passer d’une application qui
s’exécute sur une application Web ou une VM unique, à une application qui peut
évoluer et être distribuée à l’échelle mondiale.

7.1 Le besoin de redondance

Si vous voulez que les clients vous confient leur important commerce de pizza, ils
doivent pouvoir accéder aux applications que vous fournissez dès qu’ils en ont
besoin. La plupart des clients ne chercheront pas des « heures d’ouverture » sur un
site Web, surtout si vous travaillez dans un environnement international où les
clients peuvent venir du monde entier. Quand ils ont faim, ils veulent manger !
La figure  7.1 illustre un exemple basique d’application qui s’exécute sur une
seule machine virtuelle. Malheureusement, cette application crée un point de défail-
lance unique. Si cette VM n’est pas disponible, l’application n’est pas disponible.
À cause de cela, le client sera mécontent et affamé.

90
 Le besoin de redondance 91

Accès client Accès client

à l’application à l’application

VM VM
unique unique Figure 7.1  Si votre application s’exécute sur une seule
machine virtuelle, toute panne survenant sur cette VM
rend l’application inaccessible. Cela pourrait conduire
vos clients à aller faire des affaires ailleurs ou, au
Réponse de Application non minimum, à être insatisfaits du service que vous
l’application retournée accessible fournissez.

Lorsque vous conduisez une voiture, vous disposez normalement d'une roue de
secours en cas de crevaison. Si vous utilisez un ordinateur portable ou une tablette, il y
a de fortes probabilités que vous branchiez l’appareil à un chargeur au cas où la
batterie s’épuiserait en cours de session. À la maison ou dans votre appartement, avez-
vous des ampoules de rechange au cas où ? Ou encore une lampe de poche ou des
bougies en cas de panne de courant ?
La plupart des gens aiment avoir une certaine forme de redondance ou de plan de
secours, dans la vie quo tidienne, mais aussi et surtout, en informatique. Si vous êtes
paré pour remplacer une roue ou une ampoule sur le champ, vous pouvez gérer les
pannes et les échecs moyennant une interruption minimale. Si vous concevez et
construisez vos applications dans une optique de redondance, vous fournissez à vos
clients un niveau élevé de disponibilité qui réduit ou même masque les interruptions
que l’application rencontre. Tous les datacenters Azure sont conçus pour la haute
disponibilité. Unités d’alimentation de secours, connexions réseau multiples ou encore
baies de stockage avec disques de rechange, sont quelques exemples, parmi d'autres, de
concepts essentiels de redondance qu’Azure fournit et gère pour vous. Toute la
redondance fournie par Azure pourrait s'avérer inutile si vous exécutez votre
application sur une seule machine virtuelle. Pour vous donner de la souplesse et du
contrôle sur la façon de rendre votre application hautement disponible, deux
fonctionnalités principales pour les charges de travail IaaS sont disponibles :
¡ Zones de disponibilité  : vous permettent de distribuer des VM sur des segments
physiquement isolés d’une région Azure pour optimiser davantage la redondance de
votre application. Les zones peuvent également fournir une haute disponibilité aux
ressources réseau telles que les adresses IP publiques et les équilibreurs de charge.
¡ Groupes à haute disponibilité : vous permettent de regrouper logiquement les VM
pour les distribuer dans un datacenter Azure unique et ainsi minimiser les
interruptions liées à des pannes ou des mises à jour de maintenance.
Pour la plupart des déploiements de nouvelles applications dans Azure, je vous suggère
de prévoir d’utiliser des zones de disponibilité. Cette approche offre de la souplesse
dans la façon de distribuer votre application. De plus, elle fournit de la redondance
aux ressources réseau qui occupent souvent une place centrale dans la façon dont les
clients accèdent finalement aux VM sous-jacentes. Pour voir comment chacune de ces
approches fonctionne, abordons-les plus en détail.
92 Chapitre 7  Haute disponibilitéet redondance

7.2 Redondance des infrastructures avec zones de disponibilité

Les zones de disponibilité sont des datacenters physiquement distincts exploitant des
ressources essentielles indépendantes, telles que l’alimentation et la connectivité réseau.
Chaque région Azure prenant en charge des zones de disponibilité en fournit trois. Vous
créez vos ressources dans et parmi ces zones. La figure 7.2 illustre la manière dont les
ressources Azure peuvent être réparties entre les zones de disponibilité.

Europe de l’Ouest
Adresse IP publique

Équilibreur de charge

Zone de disponibilité 1 Zone de disponibilité 2 Zone de disponibilité 3

VM 1 VM 2 VM 3

Figure 7.2  Une région Azure peut contenir plusieurs zones de disponibilité : des
datacenters physiquement isolés qui utilisent une alimentation, un réseau et un système
de refroidissement indépendants. Les ressources réseau virtuelles Azure telles que les
adresses IP publiques et les équilibreurs de charge peuvent couvrir toutes les zones
d’une région pour fournir une redondance qui va au-delà des seules VM.

Grâce aux zones de disponibilité, vos applications peuvent tolérer que l’intégralité
d’un datacenter Azure soit déconnecté. Bien sûr, il faudrait un événement majeur
pour que cela arrive, mais ce n’est pas impossible !
Pour les déploiements d’applications d'envergure, vous pouvez créer plusieurs
machines virtuelles dans chaque zone de disponibilité. Plusieurs machines virtuelles
dans une zone de disponibilité sont automatiquement distribuées sur le matériel
disponible au sein de cette zone. Vous n'avez rien à configurer, ni à contrôler. Même si
une mise à jour de maintenance ou une panne d’équipement à l’intérieur d’une zone
devait avoir un impact sur toutes les VM qui s’exécutent dans cette zone, n’oubliez pas
que les zones sont physiquement isolées les unes des autres : les VM présentes dans une
autre zone continueraient à fonctionner.
Si vous êtes né sous une mauvaise étoile, est-ce que toutes les VM réparties dans les
différentes zones pourraient toutes subir des mises à jour de maintenance en même temps ?
Oui, mais c’est improbable. Les zones d’une région ont des cycles de mise à jour décalés.
Les mises à jour sont effectuées dans une zone ; une fois qu’elles sont terminées, les mises à
jour sont effectuées dans la zone suivante. Les zones de disponibilité fournissent un haut
niveau d’abstraction et de redondance ; vous devez donc examiner votre application sur
l’ensemble du déploiement, et pas seulement là où se situent les VM d’une zone.
L’inclusion des ressources réseau virtuelles dans les zones de disponibilité
est  beaucoup plus importante que ce qu’on pourrait penser à première vue.
La figure 7.3 illustre ce qui se passerait si le datacenter
 Redondance des infrastructures avec zones de disponibilité 93

Europe de l’Ouest

Zone de disponibilité 1 Zone de disponibilité 2 Zone de disponibilité 3

Adresse IP publique

Équilibreur de charge VM 2 VM 3

VM 1

Figure 7.3  Lorsque les ressources réseau sont associées à une seule zone ou à un seul datacenter
Azure, une panne dans cette installation rend l’intégralité de l’application inaccessible par le client.
Peu importe si les autres VM continuent de fonctionner dans d’autres zones. Sans la connectivité
réseau pour distribuer le trafic de vos clients, l’application entière est indisponible.

devenait indisponible pour les ressources réseau, telles qu’une adresse IP publique
ou un équilibreur de charge, qui s’exécutent dans les zones de disponibilité.
Je reviendrai plus en détail sur les équilibreurs de charge au chapitre 8, mais pour
l’instant, tout ce que vous devez comprendre, c’est que l’équilibreur de charge distribue
le trafic sur toutes les machines virtuelles disponibles qui lui sont associées. Les VM
signalent leur état d’intégrité à intervalles définis et l’équilibreur de charge arrête de
distribuer le trafic à une VM qui signale qu’elle n’est pas disponible. Avec un équilibreur
de charge qui fonctionne dans les zones de disponibilité, une panne dans un datacenter
Azure rend ces VM indisponibles  ; elles ne font donc plus partie de la rotation
d’équilibrage de charge.
Une adresse IP publique qui couvre les zones de disponibilité fournit un point
d’entrée unique aux clients pour atteindre votre équilibreur de charge, puis être
distribuée vers une machine virtuelle disponible. Dans un déploiement d’application
où cette adresse IP publique réside dans un seul datacenter Azure, si ce datacenter
rencontre un problème, aucun client ne peut accéder à l’adresse IP publique. Le client
ne peut plus utiliser votre application, même si des VM sont disponibles pour répondre
aux demandes des clients.
Les ressources qui peuvent utiliser des zones de disponibilité incluent à la fois des
services de zone et des services redondants interzone :
¡ Les services de zone sont notamment destinés aux machines virtuelles, à une adresse
IP publique ou à un équilibreur de charge. Toute la ressource s’exécute dans une
zone donnée et peut fonctionner seule en cas d'indisponibilité d'une autre zone.
¡ Les services redondants interzone sont destinés aux ressources capables de se
répliquer automatiquement entre les zones, telles que le stockage redondant
interzone et les bases de données SQL. Toute la ressource n’est pas exécutée dans
une zone donnée, ses données sont distribuées entre les zones, de
sorte qu'elle continue à être disponible si une zone rencontre un problème.
94 Chapitre 7  Haute disponibilitéet redondance

La prise en charge de la zone de disponibilité est disponible pour plus de 20 services

Azure sur plus d'une dizaine de régions. Le nombre de services et de régions qui
s’intègrent aux zones de disponibilité ne cesse de croître. Toutefois, compte tenu des
limitations des régions, il se peut que la prise en charge des zones de disponibilité ne
soit pas proposée à certaines ressources de base, telles que les machines virtuelles.
Dans ces cas, vous pouvez utiliser un autre type de redondance de machine virtuelle
dans n’importe quelle région, sujet que nous étudierons dans la section 7.2.1 : Groupes
à haute disponibilité.

7.2.1 Création de ressources réseau dans une zone de disponibilité

Pour commencer à découvrir une partie de cette disponibilité et de cette redondance,
nous allons créer des ressources communes, telles qu’une adresse IP publique et un
équilibreur de charge, puis des machines virtuelles. Vous pourrez ainsi constater que la
configuration requise pour tirer parti des zones de disponibilité est minime dans
Azure. Même s'il s’agit d’exemples simples, ils sont le pivot essentiel de la plupart des
environnements d’application que vous déployez.
Les adresses IP publiques et les équilibreurs de charges peuvent être créés sur l’un
des deux niveaux disponibles : De base et Standard. La principale différence réside
dans le fait que le niveau standard permet à la ressource réseau d’utiliser des zones de
disponibilité. Par défaut, un équilibreur de charge ou une adresse IP publique standard
présente automatiquement une redondance interzone. Aucune configuration
complémentaire n’est nécessaire. La plateforme Azure stocke de manière centralisée
les métadonnées de la ressource dans la région que vous spécifiez et s’assure que la
ressource continue à fonctionner si une zone devient indisponible.
Pour le moment, ne vous préoccupez pas trop de ce qui se passe concernant
l’équilibreur de charge et les ressources réseau. Rappelez-vous ce que j’ai évoqué au
début  : ces deux ou trois  prochains chapitres s’appuient les uns sur les autres. Au
chapitre  8, nous allons nous plonger dans les équilibreurs de charge et tout cela
devrait commencer à avoir plus de sens.

Tester
Pour créer des ressources réseau qui soient redondantes entre les zones de disponibil-
ité, procédez comme suit :

1 Sélectionnez l'icône Cloud Shell, située dans la partie supérieure du tableau de

bord du portail Azure.
2 Créez un groupe de ressources, par exemple azuremolchapter7az :
az group create --name azuremolchapter7az --location westeurope

3 Créez une adresse IP publique standard dans votre groupe de ressources. Par
défaut, une adresse IP publique de base serait créée et affectée uniquement à une
seule zone. Le paramètre --sku standard indique à Azure qu’il doit créer une
ressource interzones redondante :
az network public-ip create \
--resource-group azuremolchapter7az \
--name azpublicip \
--sku standard
 Redondance des infrastructures avec zones de disponibilité 95

4 Créez un équilibreur de charge qui couvre les zones de disponibilité. Là encore,

un équilibreur de charge de base serait créé par défaut et affecté à une seule
zone, ce qui ne correspond pas à la conception avec haute disponibilité que vous
voulez pour vos applications. Indiquez une référence (SKU) standard pour créer
un équilibreur de charge redondant interzone, comme suit :
az network lb create \
--resource-group azuremolchapter7az \
--name azloadbalancer \
--public-ip-address azpublicip \
--sku standard

7.2.2 Création d'une machine virtuelle dans une zone de disponibilité

Pour créer une VM dans une zone de disponibilité, vous spécifiez la zone dans laquelle
la machine virtuelle doit être exécutée. Dans l’idéal, pour déployer de nombreuses
VM, vous créez et utilisez un modèle. Le modèle définit et distribue les zones pour
chaque VM. Au fur et à mesure que la demande client pour votre pizzeria en ligne
augmente, vous pouvez également mettre à jour le modèle avec le nombre de VM que
vous voulez alors, puis redéployer le modèle. Les nouvelles VM sont distribuées
automatiquement entre les zones. De plus, il n’est pas nécessaire d’effectuer un suivi
manuel des zones dans lesquelles les VM s’exécutent. Dans l’exercice pratique de fin
de chapitre, vous utiliserez un modèle pour créer et distribuer automatiquement
plusieurs VM. Afin de voir le processus logique pour spécifier une zone pour une VM,
nous allons créer une VM et spécifier manuellement la zone.

Tester
Pour créer une VM dans une zone de disponibilité, procédez comme suit :

1 Dans le portail Azure, sélectionnez l’icône Cloud Shell en haut du tableau de bord.

2 Créez une machine virtuelle avec la commande az vm create que vous avez
utilisée dans les chapitres précédents. Utilisez le paramètre --zone pour spécifier
la zone 1, 2 ou 3 dans laquelle la VM doit s’exécuter. Dans l’exemple suivant, une
VM nommée zonedvm est créée en zone 3 :
az vm create \
--resource-group azuremolchapter7az \
--name zonedvm \
--image ubuntults \
--size Standard_B1ms \
--admin-username azuremol \
--generate-ssh-keys \
--zone 3

Cela prend quelques minutes pour créer une machine virtuelle. Une fois le processus
terminé, la sortie de commande indique la zone dans laquelle s’exécute la VM. Vous
pouvez également vérifier cette information à l'aide de la commande az vm show :
az vm show \
--resource-group azuremolchapter7az \
--name zonedvm \
--query zones
96 Chapitre 7  Haute disponibilitéet redondance

REMARQUE  Les exemples des exercices «  Essayez dès maintenant  » sont

simples, mais sont conçus pour vous montrer que les zones nécessitent peu de
configuration. Vous n’avez pas intégré la VM et l’équilibreur de charge
redondant interzone, mais au chapitre  8, vous allez construire un
environnement d’application, réparti entre les zones de disponibilité, plus
exploitable. L’objectif ici est de vous montrer que la plateforme Azure gère la
redondance et la distribution des ressources, afin que vous puissiez vous
concentrer sur l’application en elle-même.

7.3 Redondance des machines virtuelles avec des groupes

à haute disponibilité
Les zones de disponibilité sont idéales pour concevoir la redondance sur un ensemble
plus large de ressources qui composent vos applications et charges de travail. Je vous
recommande, dans la mesure du possible, de les utiliser pour de nouvelles charges de
travail. Parfois, il est toutefois inutile de rendre toutes les ressources redondantes
interzone. Il se peut également que vous créiez des machines virtuelles dans une région
Azure qui ne disposent pas encore de la prise en charge des zones de disponibilité.
Si vous voulez simplement assurer une redondance pour les machines virtuelles, les
groupes à haute disponibilité sont la solution. Ils ont fait leurs preuves, sont fiables et
disponibles dans toutes les régions. Les groupes à haute disponibilité contiennent un
groupe logique de VM qui indique à la plateforme Azure que le
matériel sous-jacent sur lequel les VM fonctionnent doit être soigneusement
sélectionné. Si vous créez deux VM qui s’exécutent sur le même serveur physique et
que le serveur a une défaillance, ces deux machines virtuelles tombent en panne. Il est
très improbable que ces deux VM soient sur le même serveur, puisque un datacenter
Azure contient potentiellement plusieurs dizaines de milliers de serveurs physiques,
voire plus, mais c’est possible ! Il peut ne pas s’agir d’une défaillance, mais d’une mise à
jour de maintenance qui entraîne une courte indisponibilité du serveur physique.
Que faire si vos machines virtuelles fonctionnent dans la même baie et sont associées
aux mêmes dispositifs de stockage et de mise en réseau ? Vous êtes à nouveau confronté
au point de défaillance unique discuté au début du chapitre.
Les groupes à haute disponibilité permettent à la plateforme Azure de créer vos
machines virtuelles dans des groupes logiques appelés domaines d’erreur et domaines de mise
à jour. Ces domaines logiques permettent à la plateforme Azure de comprendre les limites
physiques des groupes matériels pour s’assurer que vos VM sont réparties uniformément
entre eux. Si un composant matériel a un problème, seules quelques VM de votre groupe
à haute disponibilité sont affectées. Ou si des mises à jour de maintenance doivent être
appliquées au matériel physique, cela affecte seulement quelques-unes de vos VM. La
relation du matériel physique avec les domaines logiques d’erreur et de mise à jour à
l’intérieur d’un groupe à haute disponibilité est illustrée à la figure 7.4.
Les zones de disponibilité effectuent le même type de distribution en coulisses, mais
elle est réalisée de façon transparente, sans être exposée. La configuration est minime,
même avec les groupes à haute disponibilité. Il est toutefois utile de comprendre ce qui
se passe dans les coulisses.

7.3.1 Domaines d’erreur

Un domaine d’erreur est un groupe logique de matériels dans un datacenter d’Azure.
Il  contient du matériel qui partage l’équipement d’alimentation électrique ou de
réseau. Vous ne contrôlez pas ce que sont ces domaines d’erreur et il n’y a rien que
vous puissiez configurer au niveau de la VM. La plateforme Azure repère dans quels
domaines d’erreurs vos VM sont placées et répartit les nouvelles
 Redondance des machines virtuelles avec des groupes à haute disponibilité 97

Groupe à haute disponibilité

Baie de serveurs Baie de serveurs Domaine d’erreur Domaine d’erreur
Domaine de Domaine de
Serveur physique Serveur physique mise à jour mise à jour
Machine Machine Machine Machine
virtuelle virtuelle virtuelle virtuelle

Domaine de Domaine de
Serveur physique Serveur physique mise à jour mise à jour
Machine Machine Machine Machine
virtuelle virtuelle virtuelle virtuelle

Figure 7.4  Dans un datacenter Azure, le matériel est logiquement divisé en domaines de mise à jour et en
domaines d’erreur. Ces domaines logiques permettent à la plateforme Azure de comprendre comment distribuer
vos VM sur le matériel sous-jacent pour répondre à vos exigences de redondance. Il s’agit d’un exemple basique :
un domaine de mise à jour contient probablement plus d’un serveur physique.

VM entre ces domaines d’erreur afin que vous disposiez toujours de machines virtuelles
disponibles si l’alimentation ou un commutateur réseau tombe en panne.
Les VM qui utilisent des disques gérés (rappelez-vous que, toutes vos VM devraient
utiliser des disques gérés  !) respectent également la distribution et les limites des
domaines d’erreurs logiques. La plateforme Azure attribue logiquement des clusters de
stockage aux domaines d’erreur afin de s’assurer que lorsque vos VM sont réparties entre
les groupes matériels, les disques gérés sont également distribués sur le matériel de
stockage. Il n’y aurait aucun intérêt à la redondance des VM sur le matériel serveur si tous
les disques gérés pouvaient potentiellement se retrouver dans un seul cluster de stockage !
Et oui, les disques gérés peuvent également être utilisés avec des zones de disponibilité.

7.3.2 Domaines de mise à jour

Les domaines d’erreur protègent des pannes matérielles en créant un groupe logique
de matériels, tandis que les domaines de mises à jour offrent une protection dans le
cadre des entretiens de routine. Pour fournir cette protection, un domaine d’erreur
est lui-même divisé logiquement en domaines de mise à jour. Encore une fois, il n’y a
rien que vous puissiez configurer ici. La plateforme Azure se sert des domaines de mise
à jour pour comprendre comment elle doit répartir les VM dans votre groupe à haute
disponibilité.
Les ingénieurs Azure effectuent (principalement de manière automatisée) la
maintenance et installent des mises à jour sur l’ensemble du matériel physique d’un
domaine de mise à jour, puis effectuent la même maintenance sur tout le matériel du
domaine de mise à jour suivant. Ce travail de maintenance est échelonné sur les
domaines de mise à jour, pour s’assurer que les machines virtuelles d’un groupe à haute
disponibilité ne fonctionnent pas toutes en même temps sur le matériel qui subit la
maintenance. C’est le même type de processus que celui que nous avons examiné avec
les zones de disponibilité. La distribution de vos ressources est réalisée de manière à
empêcher un scénario dans lequel tout le matériel sous-jacent dédié à vos ressources est
mis à jour simultanément.
98 Chapitre 7  Haute disponibilitéet redondance

Il n’y a pas de relation entre les domaines répartis dans plusieurs groupes à haute
disponibilité. Les ressources physiques qui composent les domaines d’erreur et de mise
à jour dans un groupe à haute disponibilité peuvent ne pas être les mêmes pour un
deuxième groupe à haute disponibilité. Cette sensibilisation veut dire que si vous créez
plusieurs groupes à haute disponibilité et que vous répartissez vos VM entre ces
derniers, le domaine d’erreur  1, par exemple, ne contient pas toujours le même
matériel physique.

7.3.3 Distribution des machines virtuelles dans un groupe à haute disponibilité

Avançons étape par étape et voyons comment les VM sont distribués dans les domaines
logiques d’erreur et de mise à jour qui constituent un groupe à haute disponibilité.
De cette façon, vous avez plusieurs machines virtuelles qui peuvent faire fonctionner
votre pizzeria, et les clients ne seront pas affamés !

Tester
Pour voir les groupes à haute disponibilité à l’œuvre, procédez comme suit afin
de déployer un modèle Ressource Manager :

1 Ouvrez un navigateur Web et accédez à un modèle Ressource Manager dans le

référentiel d’exemplesGitHub sur https://github.com/fouldsy/azure-mol-
samples-2nd-ed/tree/master/07/availability-set, puis sélectionnez le bouton
Déployer sur Azure. Vous utilisez un modèle dans cet exercice afin de pouvoir
déployer rapidement des machines virtuelles. Cela vous permet d’explorer la
façon dont ces VM sont distribuées dans le groupe à haute disponibilité.
Le portail Azure s’ouvre et vous invite à entrer quelques paramètres.
2 Choisissez de créer un groupe de ressources, puis fournissez un nom,
azuremolchapter7, par exemple. Sélectionnez une région, puis fournissez
les données de votre clé SSH (vous pouvez l’obtenir dans ce Cloud Shell avec
cat ~/.ssh/id_rsa.pub).
Le modèle crée un groupe à haute disponibilité qui contient trois VM. Ces VM
sont distribuées dans les domaines logiques d’erreur et de mise à jour. En vous
servant des connaissances acquises sur Resource Manager au chapitre  6, ce
modèle utilise la fonction copyIndex() pour créer plusieurs machines virtuelles
et cartes réseau.
3 Pour reconnaître que vous souhaitez créer les ressources précisées dans le
modèle, cochez la case «  J’accepte les termes et conditions mentionnés
ci-dessus », puis sélectionnez Achat.
Cela prend quelques minutes pour créer les trois  VM dans le groupe à haute
disponibilité. Laissez le déploiement se poursuivre sur le portail pendant que vous lisez
le reste de cette section.
Lorsque le modèle commence à se déployer, un groupe à haute disponibilité est
créé. Les domaines de mise à jour et d’erreur sont assignés selon le nombre demandé.
Les propriétés suivantes ont été définies dans le modèle d’exemple :
“properties”: {
  “platformFaultDomainCount”: “2”,
  “platformUpdateDomainCount”: “5”,
  “managed”: “true”
}
 Redondance des machines virtuelles avec des groupes à haute disponibilité 99

Ces propriétés permettent de créer un groupe à haute disponibilité comportant

deux  domaines d’erreur et cinq  domaines de mise à jour (comme illustré à la
figure 7.5) et indiquent que les VM doivent utiliser des disques gérés, et donc honorer
la distribution du disque en conséquence. La région que vous sélectionnez pour
le groupe à haute disponibilité détermine le nombre maximal de domaines d’erreur
et  de mise à jour. Les régions prennent en charge deux ou trois domaines d’erreur,
et jusqu’à 20 domaines de mise à jour.

Groupe à haute disponibilité

Domaine d’erreur 0 Domaine d’erreur 1

Domaine de Domaine de
mise à jour 0 mise à jour 1

Domaine de Domaine de
mise à jour 2 mise à jour 3

Domaine de
mise à jour 4

Figure 7.5  Le groupe à haute disponibilité que votre modèle d’exemple

déploie contient deux domaines d’erreur et cinq domaines de mise à jour.
Le système de numérotation a le zéro pour base. Les domaines de mise à jour
sont créés de manière séquentielle dans les domaines d’erreur.

Lorsque vous créez davantage de VM dans un groupe à haute disponibilité, vous devez
étudier le nombre de domaines de mise à jour à utiliser. Par exemple, s'il
y a cinq domaines de mise à jour cela signifie que jusqu’à 20 % de vos VM peuvent être
indisponibles pour cause de maintenance :
¡ Admettons que vous ayez dix VM dans votre groupe à haute disponibilité. Deux
de ces VM peuvent subir une maintenance en même temps. Si vous voulez qu’une
seule machine virtuelle à la fois puisse subir une maintenance, vous devez créer
dix domaines de mise à jour. Plus vous créez de domaines de mise à jour, plus la
période pendant laquelle votre application est potentiellement en état de
maintenance est longue.
¡ Continuons avec l’exemple précédent de 10 machines virtuelles sur 10 domaines
de mise à jour. Vos applications sont susceptibles d'être perturbées tant que tous
les 10 domaines de mise à jour n'ont pas terminé leur cycle de maintenance. Si
vous n’avez que 5 domaines de mise à jour, ce délai de maintenance est réduit.
Une période de maintenance plus longue n'est pas nécessairement une mauvaise
chose. Vous devez plutôt déterminer votre tolérance aux exécutions potentielles
à une capacité inférieure.
Il est important de se rappeler que ces domaines de mise à jour et les cycles de
maintenance sont effectués par la plateforme Azure elle-même. Vous devez également
tenir compte de vos propres besoins en matière de mise à jour et de vos fenêtres de
maintenance.
100 Chapitre 7  Haute disponibilitéet redondance

Lorsque la première VM est créée, la plateforme Azure cherche à voir où se trouve la

première position de déploiement disponible. Il s’agit du domaine d’erreur 0 et du
domaine de mise à jour 0, comme illustré à la figure 7.6.
Lorsque la deuxième VM est créée, la plateforme Azure cherche à voir où se trouve
la position de déploiement disponible suivante. Il s’agit maintenant du domaine
d’erreur 1 et du domaine de mise à jour 1, comme illustré à la figure 7.7.

Groupe à haute disponibilité Groupe à haute disponibilité

Domaine d’erreur 0 Domaine d’erreur 0 Domaine d’erreur 1

Domaine de Domaine de Domaine de
mise à jour 0 mise à jour 0 mise à jour 1

VM 0 VM 0 VM 1

Figure 7.6  La première VM est créée Figure 7.7  Avec une seconde VM créée, les VM sont maintenant
dans le domaine d’erreur 0 et le réparties uniformément entre les domaines d’erreur et de mise à
domaine de mise à jour 0. jour. C’est ce qui est souvent considéré comme la quantité de
redondance minimale pour protéger vos applications.

Votre modèle crée trois VM, alors que se passe-t-il ensuite selon vous ? La plateforme
Azure cherche de nouveau à voir où se trouve la position de déploiement disponible
suivante. Vous n’avez créé que deux domaines d’erreur, de sorte que la VM est créée
de nouveau dans le domaine d’erreur 0. Mais la VM est créée dans un domaine de mise
à jour différent de la première VM. La troisième VM est créée dans le domaine de mise
à jour 2, comme illustré à la figure 7.8.

Groupe à haute disponibilité

Domaine d’erreur 0 Domaine d’erreur 1
Domaine de Domaine de
mise à jour 0 mise à jour 1 Figure 7.8  La troisième VM est
créée dans le domaine d’erreur 0,
VM 0 VM 1 mais dans le domaine de mise
à jour 2. Bien que les machines
virtuelles 0 et 2 partagent
Domaine de potentiellement le même risque
mise à jour 2 de  défaillance matérielle, elles se
trouvent dans différents domaines
VM 2 de mise à jour et ne subiront donc
pas de maintenances régulières
en même temps.
Les VM  0 et  2 se trouvant
dans le même domaine
 Redondance des machines virtuelles avec des groupes à haute disponibilité 101

d’erreur, une défaillance matérielle pourrait donc potentiellement avoir un impact sur
les deux machines. Mais l’entretien de routine n’affecte qu’une seule de ces VM à la
fois, car elles sont réparties dans plusieurs domaines de mise à jour. Si vous continuez
et créez plus de VM, la plateforme Azure va continuer à les distribuer dans des
domaines d’erreur et de mise à jour différents. Lorsque les cinq domaines de mise à
jour sont utilisés, la sixième VM est créée dans le domaine de mise à jour 0, et le cycle
se poursuit.

7.3.4 Affichage de la distribution des machines virtuelles dans un groupe à haute

disponibilité
Maintenant que vous comprenez en théorie la répartition des VM dans les domaines
d’erreur et de mise à jour dans un groupe à haute disponibilité, vérifions ce qui est
arrivé au modèle Ressource Manager que vous avez déployé.

Tester
Pour voir comment vos VM sont distribuées dans un groupe à haute disponibilité, procé-
dez comme suit :

1 Recherchez et sélectionnez Groupe de ressources dans la barre de navigation,

dans la partie gauche du portail Azure.
2 Choisissez le groupe de ressources que vous avez créé pour votre déploiement de
modèle, azuremolchapter7 par exemple.
3 Sélectionnez votre groupe à haute disponibilité dans la liste des ressources,
azuremolavailabilityset par exemple.
La fenêtre Vue d’ensemble affiche une liste des machines virtuelles et des
domaines d’erreur et de mise à jour qui leurs sont associés, comme illustré à la
figure 7.9.

Figure 7.9  Le groupe à haute disponibilité répertorie les VM qu’il contient et affiche

pour chaque VM le domaine d’erreur et le domaine de mise à jour. Ce tableau vous
permet de visualiser comment les VM sont réparties dans les domaines logiques.

Si vous êtes particulièrement attentif, vous avez peut-être remarqué que les VM ne
correspondent pas parfaitement avec l’ordre des domaines d’erreur et de mise à jour
attendu. Y a-t-il un bogue  ? Probablement pas. Si vous examinez l’exemple de la
figure 7.9 et que vous le comparez à ce que vous avez appris des concepts précédents,
vous vous attendez à ce que les VM soient distribuées comme illustré au tableau 7.1.
102 Chapitre 7  Haute disponibilitéet redondance

Tableau 7.1  Machines virtuelles dans un ensemble de disponibilité créées et distribuées

séquentiellement sur l’ensemble des domaines

Nom Domaine d’erreur Domaine de mise à jour

vm0 0 0

vm1 1 1

vm2 0 2

Alors, qu’est-ce qui a mal tourné ? Rien. Repensez à la façon dont Resource Manager
crée des ressources à partir d’un modèle. La plateforme Azure n’attend pas que la
première VM soit créée avant que la seconde puisse l’être. Les trois VM sont créées en
même temps. Ainsi, il peut y avoir quelques fractions de seconde de différence durant
lesquelles une VM est associée en premier à un groupe à haute disponibilité. Peu
importe l’ordre, puisque vous ne contrôlez pas ce que les domaines d’erreur et de mise
à jour sous-jacents représentent. Tout dépend de la plateforme Azure. Vous avez
uniquement besoin de vérifier que vos VM sont distribuées, pas où elles le sont.

J'aime que tout soit en ordre...

Si la façon dont les VM sont générées en série vous dérange et que vous devez distribuer
les VM de façon bien ordonnée, vous pouvez paramétrer Resource Manager pour qu’il
crée les VM en série, plutôt qu’en parallèle. Dans ce mode, les VM sont créées l’une
après l’autre, le temps de déploiement est donc augmenté. Pour activer ce
comportement en série, utilisez «  mode  »  : «  Serial  » dans vos modèles sous
la fonction copyIndex(). Cela devrait distribuer les VM d’une manière
séquentielle et logique.

7.4 Exercice pratique : déploiement de machines virtuelles

hautement disponibles à partir d’un modèle
Cet exercice pratique combine et renforce ce que vous avez appris au chapitre  6 sur
Azure Resource Manager et les modèles, avec les zones de disponibilité. Prenez le temps
d’examiner le modèle de démarrage rapide donné en exemple dans cet exercice pour
voir comment vous pouvez utiliser la logique et les fonctions pour distribuer plusieurs
VM entre les zones. Ne vous contentez pas de déployer le modèle et de passer à la suite :
regardez comment le modèle s’appuie sur les fonctionnalités introduites au chapitre 6 !

Qu’est-ce qu’un quota ?

Dans Azure, les quotas par défaut de votre abonnement vous empêchent de déployer
accidentellement des ressources et de les oublier, ce qui vous coûterait beaucoup
d’argent. Généralement ces quotas varient selon les types de ressource et
d’abonnement et sont appliqués au niveau de la région. Une liste complète des quotas
est consultable sur http://mng.bz/ddcx.
Lorsque vous allez commencer à créer plusieurs VM dans les prochains chapitres, vous
pourrez être confronté à des problèmes de quota. Le fait d'avoir omis de supprimer les
ressources des chapitres et exercices précédents peut également être à l'origine de
problèmes. Les quotas constituent un système efficace qui vous tient informé de l’usage
que vous faites des ressources. Les messages d’erreur peuvent ne pas être clairs, mais
si vous voyez un message d’erreur du type :
Exercice pratique : déploiement de machines virtuelles hautement disponibles à partir d’un modèle 103

L’opération entraîne le dépassement des limites de quota.

Maximum autorisé : 4, Actuellement utilisé : 4, Supplément demandé : 2.

il est souhaitable de demander une augmentation de vos quotas Il n’y a rien

de compliqué n'i d’exclusif à Azure. Vous pouvez afficher votre quota actuel pour une
région donnée au moyen de la commande suivante :
az vm list-usage --location eastus

Si cet exercice vous pose des difficultés, supprimez les deux  premiers groupes
de ressources créés dans ce chapitre, de type : azuremolchapter7 et
azuremolchapter7az. Si vos quotas par défaut sont faibles, les quatre VM
de ces groupes de ressources peuvent vous empêcher de réussir cet exercice.
Pour demander une augmentation de vos quotas pour une région, suivez les étapes
décrites à la page http://mng.bz/Xq2f.

Examinons et déployons un modèle qui inclut plusieurs VM dans les zones

de disponibilité.

1 Dans un navigateur Web, ouvrez le fichier JSON disponible à l'adresse https://

github.com/Azure/azure-quick‑start-templates/blob/master/201-multi-vm-lb-
zones/azuredeploy.json, et recherchez le texte suivant :
Microsoft.Compute/virtualMachines

La section VM ressemble à ce que vous avez utilisé au chapitre 6, mais notez la

valeur de propriété de zones. Cette section combine plusieurs fonctions
différentes, disponibles dans les modèles, pour sélectionner la zone 1, 2 ou 3,
pendant la création de la VM. De cette façon, vous n’avez
pas besoin de suivre manuellement dans quelle zone s’exécute chaque VM ni la
manière dont vous devez ensuite déployer des VM supplémentaires.
2 Dans votre navigateur Web, recherchez chacun des éléments suivants pour
afficher les sections concernant l’adresse IP publique et l’équilibreur de charge :
Microsoft.Network/publicIPAddresses
Microsoft.Network/loadBalancers

Les deux ressources utilisent la référence (SKU) standard, qui fournit par défaut
la redondance de zone. Aucune configuration supplémentaire n’est nécessaire
pour accomplir cette tâche ! Voyons ce qui se passe !
3 Dans votre navigateur Web, ouvrez le modèle de démarrage rapide disponible
à  l'adresse http://mng.bz/O69a, puis sélectionnez le bouton Déployer
dans Azure.
4 Créez ou sélectionnez un groupe de ressources, puis fournissez un nom
d’utilisateur et un mot de passe aux VM.
5 Entrez un nom DNS unique, comme azuremol.
104 Chapitre 7  Haute disponibilitéet redondance

6 Choisissez de créer des machines virtuelles Windows ou Linux. Les machines

virtuelles Windows prennent un peu plus de temps à créer.
7 Indiquez le nombre de VM à créer, par exemple 3.
8 Cochez la case pour accepter les conditions générales du déploiement
du modèle, puis sélectionnez Achat, comme illustré à la figure 7.10.

Figure 7.10  Pour déployer le modèle de zone de disponibilité dans le portail Azure, indiquez
un groupe de ressources, un nom d’utilisateur et un mot de passe, puis le type de système
d’exploitation et le nombre de VM que vous souhaitez créer. Le modèle utilise des boucles,
copyIndex(), dependsOn, des variables et des paramètres comme nous l’avons vu au
chapitre 6.
Exercice pratique : déploiement de machines virtuelles hautement disponibles à partir d’un modèle 105

Une fois les VM créées, utilisez le portail Azure ou la commande az vm show

pour voir comment les VM ont été distribuées entre les zones. Si vous êtes curieux
de savoir ce que le reste du modèle fait avec les ressources de réseau, le chapitre 8
vous permet de découvrir les équilibreurs de charge dans les moindres détails !

Nettoyage de l’allée nº3

Vous rappelez-vous quand, au début du livre, je vous ai dit de vous assurer de tout
nettoyer après votre passage pour minimiser l’impact sur vos crédits Azure gratuits ? Je
vous conseille vivement de supprimer les groupes de ressources que vous avez créés au
cours de ce chapitre. Lors des deux prochains chapitres, vous continuez à créer
de multiples machines virtuelles et instances d’application Web, alors assurez-vous
de garder les coûts et les quotas sous contrôle.
Chaque fois que vous vous connectez au portail Azure, vous devriez recevoir une
notification contextuelle qui vous permet de connaître l’état de vos crédits Azure. Si vous
voyez que votre crédit disponible se réduit d’un montant important de jour en jour,
cherchez les groupes de ressources que vous avez peut-être oublié de supprimer !
 Applications
d’équilibrage de charge
8
Une composante importante des applications hautement disponibles est la méthode
utilisée pour distribuer le trafic entre toutes vos machines virtuelles. Dans le
chapitre 7, vous avez appris ce qui différencie les groupes à haute disponibilité des
zones de disponibilité, et comment vous pouvez créer plusieurs machines virtuelles
dans des datacenters ou régions Azure pour fournir une redondance d'application.
Même si toutes ces machines virtuelles sont hautement disponibles et distribuées,
cela ne sert à rien si une seule de ces machines reçoit tout le trafic client.
Les équilibreurs de charge sont des ressources réseau qui reçoivent le
trafic d'application entrant provenant de vos clients, examinent le trafic pour
appliquer des filtres et des règles d'équilibrage de charge, puis distribuent les
requêtes sur un pool de machines virtuelles qui exécutent votre application. Dans
Azure, différentes méthodes sont à votre disposition pour équilibrer la charge du
trafic, par exemple si vous devez effectuer un déchargement SSL sur des applications
volumineuses qui utilisent le trafic réseau crypté. Dans ce chapitre, vous découvrirez
les différents composants des équilibreurs de charge, et vous apprendrez à configurer
des règles et filtres de trafic ainsi qu'à distribuer le trafic vers des machines virtuelles.
Vous utiliserez les composants à haute disponibilité étudiés dans le chapitre 8, et
vous vous préparerez pour le chapitre 9, qui aborde la façon dont vous pouvez faire
évoluer les ressources.

8.1 Composants de l'équilibreur de charge Azure

Les équilibreurs de charge disponibles dans Azure peuvent fonctionner à
deux niveaux : la couche 4, où seul le trafic réseau est examiné et distribué (il s'agit
en fait de la couche transport), et la couche 7, où les données d'application du trafic
réseau sont connues, permettant ainsi de déterminer la distribution des données.
Ces deux  niveaux des équilibreurs de charge fonctionnent de la même façon,
comme illustré à la figure 8.1.

106
 Composants de l'équilibreur de charge Azure 107

Internet
Équilibreur
de charge

Adresse IP publique
Pool IP front-end

Sonde d’intégrité
Sonde pour vérifier health.html
sur les VM back-end
Règles d’équilibrage de charge
Autoriser les entrées sur port TCP 80 ->
port TCP 80 sur pool back-end

Pool IP back-end
Carte Carte Carte
réseau réseau réseau
virtuelle virtuelle virtuelle

Machine Machine Machine

virtuelle virtuelle virtuelle

Figure 8.1  Le trafic provenant d'Internet pénètre dans l'équilibreur de charge via une adresse IP publique
qui est associée à un pool IP front-end. Le trafic est traité par des règles d'équilibrage de charge qui
déterminent comment et où il doit être transmis. Les sondes d'intégrité associées aux règles garantissent
que le trafic est uniquement distribué uniquement sur des nœuds sains. Un pool back-end de cartes
réseau virtuelles connectées aux machines virtuelles reçoit ensuite le trafic distribué par les règles
d'équilibrage de charge.

Les principaux composants d'un équilibreur de charge sont les suivants :

¡ Pool  IP front-end  : point d'entrée dans l'équilibreur de charge. Pour autoriser
l'accès à partir d'Internet, une adresse IP publique peut être associée au pool IP
front-end. Il est possible d'associer des adresses IP privées pour les équilibreurs de
charge internes.
¡ Sondes d'intégrité : surveillent l'état des machines virtuelles associées. Pour garantir
que le trafic est distribué uniquement sur des machines virtuelles saines et
réactives, des contrôles sont réalisés de façon régulière pour vérifier qu'une
machine virtuelle répond correctement au trafic.
¡ Règles d'équilibrage de charge  : distribuent le trafic vers les machines virtuelles.
Chaque paquet entrant est comparé aux règles, qui définissent les protocoles et
ports entrants, puis distribué sur un ensemble de machine virtuelles associées. Si
aucune règle ne correspond au trafic entrant, le trafic est refusé.
¡ Règles NAT (Network Address Translation)  : permettent d'acheminer le trafic
directement vers des machines virtuelles spécifiqu. Par exemple, si vous souhaitez
fournir un accès distant via SSH ou RDP, vous pouvez définir des règles NAT pour
transférer le trafic d'un port externe vers une seule machine virtuelle.
¡ Pool IP back-end : l'emplacement où les machines virtuelles qui exécutent votre
application sont associées. Les règles d'équilibrage de charge sont associées aux
pools back-end. Vous pouvez créer différents pools back-end pour différentes
parties de vos applications.
108 Chapitre 8  Applications d’équilibrage de charge

Azure Application Gateway : équilibrage de charge avancé

Les équilibreurs de charge Azure peuvent fonctionner au niveau de la couche réseau ou
de la couche application. Ce chapitre se concentre sur l'équilibreur de charge standard
Azure, qui fonctionne au niveau de la couche réseau (couche 4 ou protocole de transport).
Au niveau de cette couche, le trafic est examiné et distribué, mais l'équilibreur de charge
ne dispose d'aucun contexte sur le trafic ou les applications que vous exécutez.
Azure Application Gateway est un équilibreur de charge qui fonctionne au niveau de la
couche application (couche 7). Application Gateway obtient des informations sur
l'application qui s'exécute sur la machine virtuelle et peut utiliser des méthodes plus
perfectionnées pour gérer les flux de trafic. L'un des principaux avantages d'Application
Gateway est la possibilité de gérer le trafic Web HTTPS crypté.
Lorsque vous équilibrez la charge de sites Web avec des certificats SSL, vous pouvez
décharger le processus qui vérifie et déchiffre le trafic en provenance des serveurs Web.
Sur les sites Web avec un trafic SSL important, le processus permettant de vérifier et
déchiffrer le trafic peut consommer une grande partie du temps de calcul sur les
machines virtuelles ou les applications Web. Application Gateway peut vérifier et
déchiffrer le trafic, transmettre la requête Web aux serveurs Web, puis rechiffrer le
trafic reçu des serveurs Web et le renvoyer au client.
Application Gateway offre d'autres fonctionnalités d'équilibrage de charge plus avancées,
comme la possibilité de distribuer le trafic sur n'importe quel point de terminaison IP plutôt
que seulement sur une machine virtuelle Azure. Ces règles de distribution avancées
peuvent vous être utiles lorsque vous créez des applications qui n'utilisent pas que des
machines virtuelles. Les mêmes concepts clés que ceux qui régissent un équilibreur de
charge standard s'appliquent, et c'est ce que nous allons voir dans ce chapitre pour vous
aider à comprendre comment tout cela fonctionne dans Azure.

8.1.1 Création d'un pool IP front-end

Dans les chapitres précédents, vous avez créé des machines virtuelles auxquelles une
adresse IP avait été directement affectée. Vous avez utilisé cette adresse IP publique pour
accéder ensuite à la machine virtuelle avec une connexion à distance telle que SSH ou
RDP, ou utilisé un navigateur Web pour accéder à un site Web exécuté sur la machine
virtuelle. Lorsque vous utilisez un équilibreur de charge, vous ne vous connectez plus
directement aux machines virtuelles. Au lieu de cela, pour autoriser le trafic à atteindre
votre équilibreur de charge et à être distribué sur vos machines virtuelles, une ou plusieurs
adresses IP doivent être affectées à l'interface externe d'un équilibreur de charge.
Les équilibreurs de charge peuvent fonctionner dans deux modes :
¡ Équilibreur de charge Internet : équilibreur avec une ou plusieurs adresses IP publiques
connectées au pool  IP front-end. Un équilibreur de charge Internet reçoit
directement le trafic provenant d'Internet et le distribue vers les machines
virtuelles back-end. Un exemple courant de ce cas de figure est celui des serveurs
Web front-end auxquels les clients accèdent directement sur Internet.
¡ Équilibreur de charge Interne : équilibreur avec une ou plusieurs adresses IP privées
connectées au pool IP front-end. Un équilibreur de charge interne fonctionne
dans un réseau virtuel Azure, comme dans le cas des machines virtuelles de base
de données back-end. En général, vous n'exposez pas les bases de données back-
end ou les couches application au monde extérieur. Au lieu de cela, des serveurs
Web front-end se connectent à un équilibreur de charge interne, lequel distribue
le trafic sans aucun accès public direct. La figure  8.2 montre comment un
équilibreur de charge interne peut distribuer le trafic sur les machines virtuelles
back-end qui se trouvent derrière un équilibreur de charge public et les machines
virtuelles Web front-end.
 Composants de l'équilibreur de charge Azure 109

VM VM
front-end back-end

Équilibreur Équilibrage
VM VM
Internet de charge de charge
front-end back-end
Internet interne

VM VM
front-end back-end

Figure 8.2  Un équilibreur de charge Internet peut être utilisé pour distribuer le trafic vers les
machines virtuelles front-end exécutant votre site Web, qui se connectent ensuite à un équilibreur
de charge interne pour distribuer le trafic vers des machines virtuelles, à un niveau base de données.
L'équilibreur de charge interne n'est pas public et n'est accessible qu'aux machines virtuelles
front-end se trouvant dans le réseau virtuel Azure.

Le mode dans lequel fonctionne votre équilibreur de charge n'a aucune incidence sur
le comportement du pool IP front-end. Vous affectez une ou plusieurs adresses IP qui
sont utilisées en cas de demande d'accès à l'équilibreur de charge. Les adresses IPv4 et
IPv6 peuvent être configurées pour le pool IP front-end. Vous pouvez ainsi configurer
des communications IPv6 de bout en bout entre les clients et vos machines virtuelles
lorsque le trafic entre et sort de l'équilibreur de charge.

Tester
Pour comprendre comment les composants de l'équilibreur de charge fonctionnent
ensemble, procédez comme suit pour créer un équilibreur de charge et un pool IP
front-end :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell en haut du tableau
de bord.
2 Créez un groupe de ressources à l'aide de la commande az group create.
Spécifiez un nom de groupe de ressources, comme par exemple
azuremolchapter8, ainsi qu'un emplacement :
az group create --name azuremolchapter8 --location westeurope

Si vous continuez à vous appuyer sur le chapitre 7 et souhaitez utiliser des zones
de visibilité, veillez à sélectionner la région appropriée pour vous assurer que la
prise en charge de la zone de disponibilité est disponible.
3 Créez une adresse IP à l'aide de la commande az network public-ip create.
Dans le chapitre 7, vous avez appris que les zones de disponibilité offrent une
redondance aux ressources réseau. Je vous propose donc de créer une adresse IP
publique standard, redondante interzone et d'indiquer un nom, par exemple
publicip :
az network public-ip create \
--resource-group azuremolchapter8 \
--name publicip \
--sku standard
110 Chapitre 8  Applications d’équilibrage de charge

Pour créer une adresse IP publique IPv6, vous pouvez ajouter --version IPv6 à la
commande précédente. Pour ces exercices, vous pouvez utiliser des adresses IPv4.
4 Créez l'équilibreur de charge et affectez l'adresse  IP publique au
pool  IP front-end. Pour ajouter l'adresse  IP publique, spécifiez le paramètre
--public-ip-address. Si vous souhaitez créer un équilibreur de charge interne,
utilisez plutôt le paramètre --private-ip-address.
Comme avec l'adresse IP publique, créez un équilibreur de charge standard,
redondant interzone, qui fonctionne dans les zones de disponibilité :
az network lb create \
--resource-group azuremolchapter8 \
--name loadbalancer \
--public-ip-address publicip \
--frontend-ip-name frontendpool \
--backend-pool-name backendpool \
--sku standard

Nous verrons un peu plus en détail ce qu'est le pool back-end dans quelques pages.

8.1.2 Création et configuration de sondes d'intégrité

Si l'une des machines virtuelles qui exécutent votre application rencontre un
problème, à votre avis, l'équilibreur de charge doit-il continuer à distribuer le trafic
vers cette machine virtuelle ? Un client qui tenterait d'accéder à votre pizzéria en ligne
pourrait alors être redirigé vers cette machine virtuelle, ce qui l'empêcherait de
commander quoi que ce soit ! Un équilibreur de charge surveille l'état des machines
virtuelles et peut supprimer celles qui rencontrent des problèmes. L'équilibreur de
charge continue à surveiller l'intégrité, et il ajoute à nouveau la machine virtuelle au
pool à des fins de distribution du trafic lorsqu'il est indiqué que celle-ci répond à
nouveau correctement.
Une sonde d'intégrité peut fonctionner dans deux modes :
¡ Basé sur les ports : l'équilibreur de charge recherche une réponse de la machine
virtuelle sur un port et un protocole spécifiques, comme par exemple le port
TCP  80. Tant que la machine virtuelle répond à la sonde d'intégrité sur
le port TCP 80, elle reste dans la distribution du trafic de l'équilibreur de charge.
Dans le cas contraire, la machine virtuelle est supprimée de la distribution du trafic
de l'équilibreur de charge, comme illustré à la figure 8.3. Ce mode ne garantit pas
que la machine virtuelle fournit le trafic comme attendu, mais uniquement que le
service de connectivité réseau et de destination renvoie une réponse.
¡ Basé sur les chemins d'accès HTTP : une page personnalisée, par exemple health.
html, est écrite et placée sur chaque machine virtuelle. Ce contrôle d'intégrité
personnalisé peut être utilisé pour vérifier l'accès à un magasin
d'images ou une connexion de base de données. Dans ce mode, la machine
virtuelle reste dans la distribution du trafic de l'équilibreur de charge uniquement
si la page de contrôle de l'intégrité renvoie une réponse HTTP code 200, comme
illustré à la figure 8.4. Avec une sonde d'intégrité basée sur les ports, le serveur
Web réel peut s'exécuter mais n'a pas de connexion de base de données. Avec une
page de contrôle d'intégrité personnalisée, l'équilibreur de charge peut vérifier
que la machine virtuelle est en mesure de fournir un trafic réel au client.
 Composants de l'équilibreur de charge Azure 111

Vérifie la réponse sur

Équilibreur le port TCP 80
de charge Machine
Internet
Sonde d’intégrité virtuelle
Suppression de la distribution
de l’équilibreur de charge en
l’absence de réponse

Figure 8.3  Une sonde d'intégrité d'équilibreur de charge basée sur les ports recherche une réponse
de la machine virtuelle sur un port et un protocole définis. Si la réponse de la machine virtuelle n'est
pas conforme à un seuil donné, la machine virtuelle est supprimée de la distribution du trafic de
l'équilibreur de charge. Lorsque la machine virtuelle commence de nouveau à répondre correctement,
la sonde d'intégrité le détecte et ajoute à nouveau la machine virtuelle à la distribution du trafic de
l'équilibreur de charge.

Vérifie la réponse HTTP Machine virtuelle

Équilibreur code 200 (OK) de health.html
de charge
Internet Serveur web
Sonde
d’intégrité Health. html
Suppression de la distribution
de l’équilibreur de charge
faute de renvoyer un message
HTTP 200 (OK)

Figure 8.4  Une machine virtuelle qui exécute un serveur Web et dispose d'une page health.
html personnalisée reste dans la distribution du trafic de l'équilibreur de charge, à condition
que la sonde d'intégrité reçoive une réponse HTTP code 200 (OK). Si le processus du serveur
Web rencontre un problème et ne peut pas renvoyer les pages demandées, elles sont supprimées
de la distribution du trafic de l'équilibreur de charge. Ce processus offre ainsi un contrôle
plus approfondi de l'état du serveur Web qu'avec les sondes d'intégrité basées sur les ports.

La création de la page de contrôle d'intégrité demande du travail supplémentaire,

mais cela vaut le coup car l'expérience client en est améliorée. La page de contrôle
d'intégrité ne doit pas nécessairement être complexe. Il peut s'agir d'une page HTML
de base permettant de vérifier que le serveur Web lui-même peut fournir des pages.
Sans la page de contrôle d'intégrité, si le processus du serveur Web rencontrait un
problème, la machine virtuelle serait toujours disponible sur le port TCP 80, de sorte
que la sonde d'intégrité basée sur les ports croirait que la machine virtuelle est saine.
Une sonde d'intégrité basée sur les chemins d'accès HTTP requiert que le serveur Web
renvoie correctement une réponse HTTP. Si le processus du serveur Web se bloque ou
échoue, aucune réponse HTTP n'est envoyée, de sorte que la machine virtuelle est
supprimée de la distribution du trafic de l'équilibreur de charge.
Deux paramètres sont également à votre disposition pour configurer la fréquence
à laquelle la sonde d'intégrité contrôle la machine ainsi que la réponse attendue :
¡ Intervalle : définit la fréquence à laquelle la sonde d'intégrité contrôle l'état de la
machine virtuelle. Par défaut, la sonde d'intégrité contrôle l'état toutes les
15 secondes.
¡ Seuil : définit le nombre d'échecs de réponse consécutifs que la sonde d'intégrité
reçoit avant que la machine virtuelle ne soit supprimée de la distribution du trafic
de l'équilibreur de charge. Par défaut, la sonde d'intégrité tolère deux échecs
consécutifs avant que la machine virtuelle ne soit supprimée de la distribution du
trafic de l'équilibreur de charge.
112 Chapitre 8  Applications d’équilibrage de charge

Tester
Pour créer une sonde d'intégrité pour votre équilibreur de charge, comme illustré dans la
figure 8.4, procédez comme suit.

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell en haut du tableau
de bord.
2 Indiquez un nom pour la sonde d'intégrité, comme par exemple healthprobe.
Pour configurer la sonde d'intégrité pour un serveur Web, spécifiez le port 80
pour HTTP, puis définissez une page de contrôle d'intégrité personnalisée
nommée health.html. Dans la section  8.2, vous vous entraînerez à créer cette
page de contrôle d'intégrité sur vos machines virtuelles. Pour montrer comment
configurer les valeurs d'intervalle et de seuil de la sonde d'intégrité, définissez un
intervalle de 10 secondes et un seuil de trois échecs consécutifs :
az network lb probe create \
--resource-group azuremolchapter8 \
--lb-name loadbalancer \
--name healthprobe \
--protocol http \
--port 80 \
--path health.html \
--interval 10 \
--threshold 3

Une fois que la sonde d'intégrité est créée, comment faites-vous pour contrôler l'état
de vos machines virtuelles  ? Les sondes d'intégrité sont associées à des règles
d'équilibrage de charge. La même sonde d'intégrité peut être utilisée avec plusieurs
règles d'équilibrage de charge. Souvenez-vous du chapitre  5, dans lequel vous avez
créé des groupes de sécurité réseau (network security group ou NSG) et des règles. Ces
NSG peuvent être associés à plusieurs machines virtuelles ou à plusieurs sous-réseaux
virtuels. Une relation un-à-plusieurs similaire s'applique aux sondes d'intégrité.
Voyons maintenant comment faire fonctionner votre sonde d'intégrité et créer des
règles d'équilibrage de charge.
8.1.3 Définition de la distribution du trafic avec des règles d'équilibrage de charge
Lorsque le trafic est dirigé via l'équilibreur de charge vers les machines virtuelles back-
end, vous pouvez définir quelles conditions doivent être remplies pour que l'utilisateur
soit dirigé vers la même machine virtuelle. Vous souhaiterez peut-être que l'utilisateur
conserve une connexion à la même machine virtuelle pendant la durée d'une seule
session, ou lui permette de revenir et de conserver son affinité de machine virtuelle en
fonction de l'adresse IP source. La figure 8.5 illustre un exemple du mode d'affinité de
session par défaut.
En mode d'affinité de session, le flux de trafic est traité par un hachage à 5 tuples qui
utilise l'adresse  IP source, le port source, l'adresse  IP de destination, le port de
destination et le type de protocole. En gros, pour chaque requête envoyée par un
utilisateur à votre serveur Web sur le port TCP 80, cet utilisateur est dirigé vers la même
machine virtuelle back-end pendant toute la durée de cette session.
Que se passe-t-il si le client ferme sa session de navigateur ? La prochaine fois qu'il se
connectera, une nouvelle session sera démarrée. Étant donné que l'équilibreur de
charge distribue le trafic entre toutes les machines virtuelles saines dans le pool IP back-
end, il est possible que l'utilisateur se connecte à nouveau à la même machine virtuelle ;
mais plus le pool IP back-end contient de machines virtuelles, plus l'utilisateur a de
chances de se connecter à une autre machine virtuelle.
 Composants de l'équilibreur de charge Azure 113

Équilibreur de charge

Pool back-end

Règle de l’équilibreur
de charge VM 1
Session 1
Mode d’affinité de
session (par défaut)
Session 1 Hachage à 5 tuples
• IP source
Internet Session 2 • Port source VM 2
• IP destination
• Port de destination
• Type de protocole
Session 2
VM 3

Figure 8.5  Dans le mode d'affinité de session, l'utilisateur se connecte à la même machine virtuelle
back-end uniquement pour la durée de sa session.

En tant que propriétaire et développeur de l'application, il peut que vous souhaitiez

que l'utilisateur se connecte à la même machine virtuelle que la fois précédente quand
il démarre une autre session. Par exemple, si votre application gère les transferts de
fichiers ou utilise UDP plutôt que TCP, vous souhaiterez probablement que la même
machine virtuelle continue à traiter ses requêtes. Dans ces cas de figure, vous pouvez
configurer les règles d'équilibrage de charge pour l'affinité IP source. La figure  8.6
illustre un exemple de mode d'affinité IP source.

Équilibreur de charge
Pool back-end

Règle de l’équilibreur
de charge Session 1 VM 1
Mode d’affinité IP source
Session 2
Session 1 Hachage à 2 tuples Hachage à 3 tuples
• IP source • IP source
Internet Session 2 VM 2
• IP destination • IP destination
• Protocole

VM 3

Figure 8.6  Lorsque vous configurez les règles d'équilibrage de charge pour utiliser le mode d'affinité IP
source, l'utilisateur peut fermer, puis démarrer une nouvelle session tout en continuant à se connecter à
la même machine virtuelle back-end. Le mode d'affinité IP source peut utiliser un hachage à 2 tuples qui
utilise l'adresse IP source et de destination, ou un hachage à 3 tuples qui utilise également le protocole.
114 Chapitre 8  Applications d’équilibrage de charge

Tester
Pour créer une règle d'équilibrage de charge qui utilise une sonde d'intégrité, procédez
comme suit :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell en haut du tableau
de bord.
2 Pour créer une règle d'équilibrage de charge, spécifiez un nom pour la règle,
comme par exemple httprule.
3 Indiquez le port externe sur lequel le trafic est reçu et le port interne sur lequel
le trafic doit être distribué. Dans cet exemple simple, le trafic est reçu sur le
port 80, puis distribué sur le port 80 :
az network lb rule create \
--resource-group azuremolchapter8 \
--lb-name loadbalancer \
--name httprule \
--protocol tcp \
--frontend-port 80 \
--backend-port 80 \
--frontend-ip-name frontendpool \
--backend-pool-name backendpool \
--probe-name healthprobe
Si vous exécutez plusieurs sites Web sur une machine virtuelle qui répond sur différents
ports, vous pouvez utiliser une règle donnée pour diriger le trafic vers un site Web
spécifique de la machine virtuelle.
8.1.4 Routage du trafic direct à l'aide de règles de traduction d'adresses réseau
Les règles d'équilibrage de charge distribuent le
trafic entre les pools back-end de machines
Internet virtuelles, vous n'avez donc aucune garantie de
pouvoir vous connecter à une machine virtuelle
donnée à des fins de maintenance ou de gestion.
Comment pouvez-vous vous connecter à une
Équilibreur de charge
machine virtuelle spécifique située derrière un
Règles NAT (Network Address Translation) équilibreur de charge  ? La configuration de
Trafic direct : port TCP 5000 externe ->
l'équilibreur de charge comporte une dernière
port TCP 22 interne partie que nous allons maintenant examiner : les
règles de traduction d'adresse réseau (NAT). Ces
règles vous permettent de contrôler le flux d'un
trafic spécifique pour le diriger vers une seule
Groupe de sécurité réseau machine virtuelle. La figure 8.7 montre comment
les règles NAT acheminent un trafic spécifique
Groupe de sécurité réseau vers des machines virtuelles individuelles.
Autoriser le port TCP 22
externe-> port TCP 22 interne
Figure 8.7  Le trafic dans l'équilibreur de charge est traité par les
règles NAT. Si un protocole et un port correspondent à une règle, le
trafic est ensuite transmis à la machine virtuelle back-end définie.
Aucune sonde d'intégrité n'est associée, l'équilibreur de charge ne
vérifie donc pas si la machine virtuelle est en mesure de répondre avant
Machine de transférer le trafic. Le trafic quitte l'équilibreur de charge et est
ensuite traité par les règles NSG. Si le trafic est autorisé, il est
virtuelle transmis à la machine virtuelle.
 Composants de l'équilibreur de charge Azure 115

Les règles NAT fonctionnent avec des règles NSG. La machine virtuelle ne peut
recevoir le trafic que s'il existe une règle NSG qui autorise le même trafic que la règle
NAT de l'équilibreur de charge.
Pourquoi créer des règles NAT ? Imaginons que vous souhaitiez utiliser SSH ou RDP
pour vous connecter à une machine virtuelle spécifique (et que vous n'utilisiez pas
Azure bastion, que j’ai mentionné au chapitre 2) ou utiliser des outils de gestion pour
vous connecter à un serveur de base de données back-end. Si l'équilibreur de charge
distribue le trafic entre les machines virtuelles back-end, il vous faudra essayer encore et
encore de vous connecter, sans aucune garantie de pouvoir vous connecter à la machine
virtuelle souhaitée.

Priorité à la sécurité
Des thèmes de sécurité seront abordés dans la partie 3 de ce livre, mais vous devez
toujours garder la question de la sécurité à l'esprit lorsque vous créez et exécutez des
applications dans Azure. La sécurité ne doit pas être une question secondaire, que l'on
remet à plus tard. Avec l'essor du cloud computing et des machines virtuelles et
applications Web « jetables », il devient facile d'oublier certaines pratiques de sécurité de
base. En particulier si vous travaillez dans Azure dans le cadre d'un abonnement
d'entreprise, assurez-vous que les ressources que vous créez n'offrent pas,
involontairement, un moyen pour les pirates d'accéder à votre infrastructure.
Quelles pratiques faut-il éviter ? En fait, des choses que vous avez déjà faites dans le
cadre de ce livre ! Les ports de gestion à distance pour SSH et RDP ne doivent pas être
ouverts à l'Internet public comme vous avez pu le faire, ou à tout le moins, vous devez
restreindre l'accès à une plage d'adresses IP spécifiques.
La bonne pratique consiste à utiliser un service géré tel qu’Azure bastion ou
à créer manuellement une VM sécurisée compatible avec la gestion à distance. Selon
les besoins, vous connectez l'hôte Azure Bastion à cette machine virtuelle sécurisée,
puis vous vous connectez sur le réseau virtuel Azure à des machines virtuelles
supplémentaires. Vous avez utilisé cette approche simple de machine virtuelle jumpbox
au chapitre 5. Elle permet de limiter la surface d'attaque et réduit la nécessité de recourir
à des règles NSG et des règles NAT d'équilibrage de charge. Le chapitre 16 présente
Azure Security Center et explique comment vous pouvez formuler des requêtes en
dynamique et ouvrir des ports de gestion à distance pour une période de temps
spécifique, ce qui constitue la meilleure solution.
Même si vous travaillez dans le cadre d'un abonnement Azure privé sans aucun lien avec
d'autres abonnements Azure (éducatifs ou professionnels), essayez de limiter la
connectivité à distance fournie.

Tester
Pour créer une règle NAT d'équilibrage de charge, procédez comme suit :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell en haut du tableau
de bord.
2 Pour créer une règle NAT d'équilibrage de charge, définissez un nom, comme
par exemple natrulessh, ainsi que le pool IP front-end à utiliser. La règle NAT
examine le trafic sur un protocole et un port donnés, par exemple le port
TCP 50001. S'il y a correspondance avec la règle, le trafic est transféré vers le
port 22 back-end :
116 Chapitre 8  Applications d’équilibrage de charge

az network lb inbound-nat-rule create \

--resource-group azuremolchapter8 \
--lb-name loadbalancer \
--name natrulessh \
--protocol tcp \
--frontend-port 50001 \
--backend-port 22 \
--frontend-ip-name frontendpool

À ce stade, vous avez créé un équilibreur de charge de base. Examinez comment les
différents composants de l'équilibreur de charge ont été regroupés :
az network lb show \
--resource-group azuremolchapter8 \
--name loadbalancer

Une adresse  IP publique a été affectée au pool  IP front-end, et vous avez créé une
sonde d'intégrité afin de contrôler l'état sur une page de contrôle d'intégrité
personnalisée pour un serveur Web. Une règle d'équilibrage de charge a été créée
pour distribuer le trafic Web provenant de vos clients vers un pool back-end, et elle
utilise la sonde d'intégrité. Vous avez également une règle NAT d'équilibrage de charge
qui autorise le trafic SSH. Il n'y a cependant pas encore de machine virtuelle pour
recevoir ce trafic. Pour ne pas faire attendre plus longtemps les clients de votre pizzeria,
je vous propose de créer des machines virtuelles capables d'exécuter votre application
Web et auxquelles l'équilibreur de charge peut distribuer le trafic !

8.1.5 Affectation de groupes de machines virtuelles à des pools back-end

La dernière partie de la configuration de l'équilibreur de charge consiste à définir des
pools back-end qui contiennent une ou plusieurs machines virtuelles. Ces pools back-
end contiennent des machines virtuelles qui exécutent les mêmes composants
d'application, ce qui permet à l'équilibreur de charge de distribuer le trafic vers un
pool back-end spécifique en ayant la certitude que n'importe laquelle des machines
virtuelles que contient ce pool pourra répondre correctement à la requête du client.
La figure 8.8 décrit en détail comment les pools back-end regroupent logiquement les
machines virtuelles qui exécutent les mêmes applications.

Équilibreur de charge
Pool back-end : Machines virtuelles
de couche applicative

VM 1 VM 2 VM 3

Pool IP Règles d’équili-

Internet brage de charge
front-end
Pool back-end : machines virtuelles
Sondes multimédias
d’intégrité
VM 1 VM 2 VM 3

Figure 8.8  Il est possible de créer un ou plusieurs pools back-end dans un équilibreur de charge.
Chaque pool back-end contient une ou plusieurs machines virtuelles qui exécutent le même composant
d'application. Dans cet exemple, un pool back-end contient les machines virtuelles qui exécutent la
couche application Web, et l'autre pool back-end contient les machines virtuelles qui fournissent les
contenus multimédias, comme par exemple les images et la vidéo.
 Composants de l'équilibreur de charge Azure 117

Vous créez et utilisez un équilibreur de charge avec des machines virtuelles, mais tout
se passe au niveau du réseau virtuel. Le pool  IP front-end utilise des adresses  IP
publiques ou privées. La sonde d'intégrité examine les réponses au niveau d'un port
ou d'un protocole donné. Même en cas d'utilisation d'une sonde HTTP, l'équilibreur
de charge recherche une réponse positive du réseau. Les règles d'équilibrage de
charge mettent l'accent sur la méthode utilisée pour distribuer le trafic à partir d'un
port externe du pool front-end vers un port du pool back-end.
Lorsque vous affectez des machines virtuelles au pool back-end qui reçoit le trafic
distribué par l'équilibreur de charge, c'est la carte réseau virtuelle qui se connecte à
l'équilibreur de charge. Il arrive que les machines virtuelles se connectent à la carte réseau
virtuelle. Si vous repensez au chapitre 5, cette séparation entre les machines virtuelles et
la carte réseau virtuelle est logique en termes de gestion des ressources. Les règles NSG
contrôlent le trafic autorisé à circuler vers la machine virtuelle, mais elles sont appliquées
à un sous-réseau virtuel ou à une carte réseau virtuelle, et non à la machine virtuelle.
Quelles sont les implications sur la façon dont vous configurez les pools IP back-end?
Vous devez créer vos autres ressources réseau virtuelles avant de pouvoir connecter une
machine virtuelle à l'équilibreur de charge. La procédure de création des ressources
réseau devrait vous rappeler ce que vous avez déjà appris dans un précédent chapitre,
alors voyons maintenant ce que vous avez retenu !

Réseau virtuel

Sous-réseau

Groupe de sécurité réseau

Autoriser le port TCP 80 (HTTP)
Autoriser le port TCP 22 (SSH)
Figure 8.9  Pour préparer
Carte réseau Carte réseau le réseau virtuel, dans cet
virtuelle 1 virtuelle 2 exercice, vous créerez un
réseau, un sous-réseau et
des cartes réseau virtuelles
protégés par un NSG. Les
règles associées au NSG
autorisent le trafic HTTP
et SSH.

Tester
Pour créer les ressources réseau supplémentaires comme illustré à la figure  8.9,
procédez comme suit :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell en haut du tableau
de bord.
2 Créez un réseau virtuel et un sous-réseau :
az network vnet create \
--resource-group azuremolchapter8 \
--name vnetmol \
--address-prefixes 10.0.0.0/16 \
118 Chapitre 8  Applications d’équilibrage de charge

--subnet-name subnetmol \
--subnet-prefix 10.0.1.0/24

Dans la pratique, il y a de fortes chances pour que ces ressources réseau existent
déjà. Les noms et plages d'adresses IP sont également les mêmes que ceux que
vous avez utilisés au chapitre  5. Étant donné que vous devez supprimer les
ressources Azure à la fin de chaque chapitre, cette réutilisation des plages
d'adresses  IP ne devrait pas poser problème. N'oubliez pas simplement que,
généralement, vous n'avez pas à créer un réseau virtuel et un sous-réseau chaque
fois que vous créez un équilibreur de charge. Vous pouvez plutôt utiliser les
ressources réseau virtuelles existantes.
3 Créez un NSG :
az network nsg create \
--resource-group azuremolchapter8 \
--name webnsg

4 Créez une règle NSG qui autorise le trafic provenant du port TCP 80 à atteindre
vos machines virtuelles. Cette règle est nécessaire pour que les machines
virtuelles de serveur Web puissent recevoir le trafic client et y répondre :
az network nsg rule create \
--resource-group azuremolchapter8 \
--nsg-name webnsg \
--name allowhttp \
--priority 100 \
--protocol tcp \
--destination-port-range 80 \
--access allow

5 Ajoutez une autre règle afin d'autoriser le trafic SSH pour la gestion à distance.
Cette règle NSG fonctionne avec la règle NAT d'équilibrage de charge créée
dans la section 8.1.4 pour l'une de vos machines virtuelles :
az network nsg rule create \
--resource-group azuremolchapter8 \
--nsg-name webnsg \
--name allowssh \
--priority 101 \
--protocol tcp \
--destination-port-range 22 \
--access allow

6 Associez le NSG au sous-réseau créé à l'étape 2. Les règles NSG sont appliquées à
toutes les machines virtuelles qui se connectent à ce sous-réseau :
az network vnet subnet update \
--resource-group azuremolchapter8 \
--vnet-name vnetmol \
--name subnetmol \
--network-security-group webnsg
7 Étant donné que l'équilibreur de charge fonctionne avec des cartes réseau
virtuelles, créez deux  cartes réseau virtuelles et connectez-les au sous-réseau
virtuel. Spécifiez également le nom de l'équilibreur de charge
et le pool d'adresses back-end auquel se connectent les cartes réseau virtuelles.
La règle NAT d'équilibrage de charge n'est associée qu'à la première carte réseau
virtuelle qui est créée :
 Création et configuration de machines virtuelles avec l'équilibreur de charge 119

az network nic create \

--resource-group azuremolchapter8 \
--name webnic1 \
--vnet-name vnetmol \
--subnet subnetmol \
--lb-name loadbalancer \
--lb-address-pools backendpool \
--lb-inbound-nat-rules natrulessh

8 Procédez de la même façon pour créer la deuxième carte réseau, mais sans la
règle NAT d'équilibrage de charge :
az network nic create \
--resource-group azuremolchapter8 \
--name webnic2 \
--vnet-name vnetmol \
--subnet subnetmol \
--lb-name loadbalancer \
--lb-address-pools backendpool

8.2 Création et configuration de machines virtuelles avec

l'équilibreur de charge
Faisons maintenant une pause pour examiner ce que vous avez créé jusqu'à présent. La
figure 8.10 montre, dans les grandes lignes, à quoi ressemblent vos ressources réseau et
votre équilibreur de charge. Notez à quel point ces ressources sont intégrées. L'équilibreur
de charge ne peut pas exister par lui-même. Pour permettre  la  distribution du trafic,

Internet
Équilibreur
de charge

Adresse IP publique
Pool IP front-end

Sonde d’intégrité
Sonde pour vérifier health.html
sur les VM back-end
Règles d’équilibrage de charge
Autoriser les entrées sur port TCP 80 ->
port TCP 80 sur pool back-end

Backend IP pool Figure 8.10  Aucune machine

virtuelle n'a été créée ici : la
Carte réseau Carte réseau
configuration de l'équilibreur de
Carte réseau
virtuelle virtuelle virtuelle charge implique des ressources
réseau virtuelles. Il existe une
Groupe de sécurité réseau
relation étroite entre l'équilibreur
Sous-réseau virtuel de charge et les ressources
Réseau virtuel réseau virtuelles.
120 Chapitre 8  Applications d’équilibrage de charge

les cartes réseau virtuelles doivent être connectées à l'équilibreur de charge. Ces cartes
réseau virtuelles ont besoin d'un réseau virtuel et d'un sous-réseau, et elles doivent
idéalement être protégées par un NSG. Les machines virtuelles qui exécutent ensuite
votre application n'ont presque rien à voir avec les étapes à suivre pour créer et
configurer l'équilibreur de charge !
Vous avez créé de nombreuses ressources réseau et configuré plusieurs parties de
l'équilibreur de charge. L'adresse IP publique et l'équilibreur de charge ont été créés
dans une zone de disponibilité en tant que ressources redondantes interzone, je vous
propose donc de créer deux  machines virtuelles dans des zones différentes pour
multiplier les chances que les zones de disponibilité améliorent la haute disponibilité
de vos applications.
Si vous utilisez des groupes à haute disponibilité plutôt que des zones de disponibilité,
c'est à ce stade que vous créez un groupe à haute disponibilité et y ajoutez vos machines
virtuelles. La plateforme Azure distribue ensuite les machines virtuelles entre les domaines
d'erreur et de mise à jour. Puisque vous souhaitez optimiser l'utilisation des fonctionnalités
de haute disponibilité d'Azure pour votre pizzeria, utilisez des zones de disponibilité.

Tester
Pour créer les machines virtuelles et les associer à l'équilibreur de charge, procédez
comme suit :

1 Créez la première machine virtuelle, puis affectez-la à une zone de disponibilité

à l'aide de la commande --zone 1 :
az vm create \
--resource-group azuremolchapter8 \
--name webvm1 \
--image ubuntults \
--size Standard_B1ms \
--admin-username azuremol \
--generate-ssh-keys \
--zone 1 \
--nics webnic1

2 Créez la deuxième machine virtuelle, puis affectez-la à la zone de disponibilité 2

et associez la deuxième carte réseau virtuelle que vous avez créée plus tôt, à l'aide
de la commande --nics webnic2 :
az vm create \
--resource-group azuremolchapter8 \
--name webvm2 \
--image ubuntults \
--size Standard_B1ms \
--admin-username azuremol \
--generate-ssh-keys \
--zone 2 \
--nics webnic2

Pour observer l'équilibreur de charge en action, vous devez installer un serveur Web
de base, comme vous l'avez fait au chapitre 2. Vous pouvez également tester la règle
NAT d'équilibrage de charge. Est-ce que vous commencez maintenant à voir en quoi
tous ces composants dans Azure sont liés et interdépendants ?
 Création et configuration de machines virtuelles avec l'équilibreur de charge 121

Tester
Au chapitre 5, nous avons abordé le sujet de l'agent SSH. L'agent SSH vous permet de
transférer une clé SSH d'une machine virtuelle à la suivante. Seule la machine virtuelle 1
est associée à une règle NAT d'équilibrage de charge, vous devez donc utiliser l'agent
pour vous connecter à la machine virtuelle 2. Pour installer un serveur Web sur vos
machines virtuelles, procédez comme suit :

1 Démarrez l'agent SSH, puis ajoutez votre clé SSH afin de pouvoir vous connecter
aux deux machines virtuelles :
eval $(ssh-agent) && ssh-add

2 Obtenez l'adresse IP publique associée au pool IP front-end de l'équilibreur de

charge. Cette méthode est la seule qui permet d'acheminer le trafic via les
machines virtuelles :
az network public-ip show \
--resource-group azuremolchapter8 \
--name publicip \
--query ipAddress \
--output tsv

3 Vous êtes maintenant prêt à vous connecter en SSH à la machine virtuelle  1.

Spécifiez l'adresse IP publique de l'équilibreur de charge (remplacez <your-ip-
address> dans la commande suivante) et le port utilisé avec la règle NAT
d'équilibrage de charge, par exemple 50001. Le paramètre -A - utilise l'agent
SSH pour franchir vos clés SSH :
ssh -A azuremol@<your-ip-address> -p 50001

Au chapitre 2, vous avez utilisé apt-get pour installer la totalité de la pile LAMP
qui contenait le serveur Web Apache. Voyons quelque chose d'un peu différent
du serveur Web Apache, avec le serveur Web autonome mais puissant NGINX.
Sur une machine virtuelle Windows, c'est généralement là que vous installez IIS.
Pour installer le serveur Web NGINX , exécutez la commande suivante :
sudo apt update && sudo apt install -y nginx

4 Le référentiel d'exemples GitHub que vous avez utilisé dans les chapitres
précédents contient une page Web HTML de base et une page de contrôle
d'intégrité pour la sonde d'intégrité de l'équilibreur de charge. Clonez ces
exemples sur la machine virtuelle :
git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

5 Copiez les exemples de page HTML et de page de contrôle d'intégrité dans le

répertoire du serveur Web :
sudo cp azure-mol-samples-2nd-ed/08/webvm1/* /var/www/html/

6 Le moment est venu de vous connecter à la deuxième machine virtuelle et

d'installer le serveur Web NGINX, ainsi que l’exemple de code. Souvenez-vous
de l'agent SSH. Vous devriez être en mesure de vous connecter en SSH de la
machine virtuelle 1 vers la machine virtuelle 2 via l'adresse IP privée interne :
ssh 10.0.1.5
122 Chapitre 8  Applications d’équilibrage de charge

7 Installez le serveur Web NGINX :

sudo apt update && sudo apt install -y nginx

8 Clonez les exemples GitHub sur la machine virtuelle :

git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

9 Copiez les exemples de page HTML et de page de contrôle d'intégrité dans le

répertoire du serveur Web :
sudo cp azure-mol-samples-2nd-ed/08/webvm2/* /var/www/html/

Ouvrez un navigateur Web, puis connectez-vous à l'adresse  IP publique de votre

équilibreur de charge. La page Web de base se charge et indique que votre pizzeria
compte maintenant des machines virtuelles redondantes s'exécutant derrière un
équilibreur de charge dans les zones de disponibilité, comme illustré à la figure 8.11. Il
se peut que vous deviez forcer l'actualisation de votre navigateur Web pour vérifier que
la machine virtuelle  1 et la machine virtuelle  2 répondent quand l'équilibreur de
charge distribue le trafic entre elles.

Figure 8.11  Lorsque vous ouvrez l'adresse IP publique de l'équilibreur de charge dans un navigateur
Web, le trafic est distribué sur l'une des machines virtuelles qui exécutent votre site Web de base.
La sonde d'intégrité de l'équilibreur de charge utilise la page health.html pour confirmer les réponses
du serveur Web avec un code HTTP 200 (OK). Si c'est le cas, la machine virtuelle devient ensuite
disponible dans le cadre de la distribution du trafic de l'équilibreur de charge.

8.3 Exercice pratique : consultation de modèles de déploiements existants

Ce chapitre revient sur ce que vous avez appris dans plusieurs chapitres précédents. Vous
avez créé des ressources réseau, comme au chapitre 5. Vous avez rendu l'équilibreur de
charge et les machines virtuelles hautement disponibles à l'aide des zones de disponibilité,
comme au chapitre  7. Et vous avez installé un serveur Web et déployé des fichiers
d'exemple, comme au chapitre 2. Votre pizzeria a bien changé depuis le début de ce livre,
où elle consistait en une simple page Web déployée sur une seule machine virtuelle !
Pour revenir sur un autre thème abordé dans un chapitre précédent, dans cet
exercice pratique, je vais vous demander d'explorer toutes les ressources qui constituent
l'équilibreur de charge. Pour ce faire, vous examinez le modèle Resource Manager,
comme vous l'avez appris au chapitre 6. L'objectif de cet exercice pratique est de voir
comment, avec un seul modèle, vous pouvez créer et configurer la même chose qu'avec
de nombreuses pages d'instructions et plusieurs commandes CLI. Et croyez-moi, avec
PowerShell, cela demanderait encore plus de commandes ! Procédez comme suit :
 Exercice pratique : consultation de modèles de déploiements existants 123

1 Ouvrez le portail Azure.

2 Accédez à l'option Groupe de ressources et sélectionnez-la dans la barre de
navigation à gauche du portail.
3 Choisissez votre groupe de ressources, par exemple azuremolchapter8.
4 Sélectionnez Exporter le modèle dans la barre du côté gauche de l'écran, comme
illustré à la figure 8.12.
5 Pour afficher la partie pertinente du modèle, sélectionnez chacune des
ressources répertoriées dans la liste. Prenez quelques minutes pour explorer ce
modèle. Comme vous pouvez le voir, l'ensemble des ressources et composants
que vous avez configurés dans la CLI Azure sont présents.

Figure 8.12  Sur le portail Azure, sélectionnez le groupe de ressources de votre équilibreur de charge et
affichez le modèle Resource Manager.

L'utilisation d'un modèle simplifie considérablement le déploiement d'un

environnement d'application hautement disponible, redondant et à charge équilibrée.
Vous pouvez modifier le nom, les règles et le mode de distribution de l'équilibreur de
charge, et laisser le modèle déployer et configurer la totalité de l'environnement
d'application à votre place.
N'oubliez pas de supprimer ce groupe de ressources pour tirer le meilleur parti de
vos crédits Azure gratuits !
 Des applications évolutives

9
Dans les deux chapitres précédents, nous avons vu comment créer des applications
hautement disponibles et utiliser des équilibreurs de charge pour distribuer le trafic
vers plusieurs machines virtuelles exécutant votre application. Mais comment
pouvez-vous exécuter et gérer efficacement plusieurs machines virtuelles, et
exécuter le bon nombre d'instances de VM lorsque vos clients en ont le plus besoin ?
Lorsque la demande clients augmente, vous souhaitez augmenter automatiquement
l'échelle de votre application pour faire face à cette demande. Et lorsque la demande
diminue, par exemple au milieu de la nuit, lorsque la plupart des personnes sans
jeunes enfants dorment, vous souhaitez réduire l'échelle de l'application pour
économiser un peu d'argent.
Dans Azure, vous pouvez automatiquement dimensionner vos ressources IaaS
comme il convient à l'aide de VMSS (Virtual Machine Scale Sets, ou groupes de
machines virtuelles identiques). Ces VMSS exécutent des machines virtuelles
identiques, généralement distribuées derrière un équilibreur de charge ou une
passerelle d'application. Vous définissez des règles de mise à l'échelle automatique
qui augmentent ou diminuent le nombre d'instances de VM en fonction de la
demande clients. L'équilibreur de charge ou la passerelle d'application se charge de
distribuer automatiquement le trafic vers les nouvelles instances de machine
virtuelle, ce qui vous permet de vous concentrer sur la façon de mieux bâtir et
exécuter vos applications. Les groupes VMSS vous donnent les moyens de contrôler
vos ressources IaaS avec certains des avantages du PaaS en termes d'élasticité. Les
applications Web, que nous n'avons pas beaucoup couvertes dans les deux derniers
chapitres, reviennent désormais en force dans ce chapitre, avec leur propre capacité
à évoluer en fonction de la demande.
Dans ce chapitre, nous allons voir comment concevoir et créer des applications à
même de se mettre à l'échelle automatiquement. Nous verrons en quoi cette capacité
d'adaptation à la demande vous aide à exécuter des applications efficaces, et
explorerons différentes manières de mettre une application à l'échelle compte tenu
de différentes métriques.

124
 Pourquoi créer des applications évolutives, fiables ? 125

9.1 Pourquoi créer des applications évolutives, fiables ?

Quel est l'intérêt de créer des applications qui se mettent à l'échelle  ? Une telle
application est en mesure de s'adapter à la demande clients lorsque la charge de travail
augmente, même lorsque vous êtes au cinéma le week-end. Pas de facture pour un tas
de ressources supplémentaires que vous n'utilisez pas, et plus de plantage de votre
application du fait du manque de ressources disponibles, ce qui est sans doute pire
encore. Le schéma idéal pour les applications et les ressources dont elles ont besoin est
rarement statique. Généralement, la demande de l'application fluctue tout au long de
la journée et de la nuit, ainsi qu'entre les jours de la semaine et le weekend.
La mise à l'échelle des ressources peut s'effectuer de deux manières différentes,
comme le montre la figure 9.1 : verticalement ou horizontalement. Les VMSS et les
applications Web peuvent évoluer verticalement ou horizontalement.

vCPU Mise à l’échelle vCPU vCPU

verticale
vRAM vRAM vRAM vRAM vRAM
Augmentation des
vRAM vRAM ressources affectées vRAM vRAM vRAM

vCPU Mise à l’échelle vCPU vCPU

horizontale
vRAM vRAM vRAM vRAM vRAM vRAM
Augmentation du
vRAM vRAM nombre d’instances vRAM vRAM vRAM vRAM

Figure 9.1  L'application peut s'adapter à la hausse comme à la baisse de la demande de manière

verticale ou horizontale. La méthode à utiliser dépend de la façon dont l'application est conçue pour
gérer la mise à l'échelle. Une mise à l'échelle verticale ajuste les ressources affectées à la machine
virtuelle ou à l'application Web, notamment le nombre de cœurs d'UC ou la quantité de mémoire dont
elle dispose. Cette méthode de mise à l'échelle de l'application fonctionne bien dès lors que l'application
n'exécute qu'une seule instance. Une mise à l'échelle horizontale modifie le nombre d'instances qui
exécutent votre application et contribue à accroître sa disponibilité et sa résilience.

L'évolutivité de l'application est un facteur important pour sa haute disponibilité. Aux

chapitres  7 et 8, nous avons passé un certain temps sur le sujet des groupes à haute
disponibilité et des zones de disponibilité, et nous avons vu comment configurer des
équilibreurs de charge. Les deux chapitres soulignaient la nécessité d’exécuter plusieurs
machines virtuelles. Lorsque l'application peut se mettre à l'échelle automatiquement,
sa disponibilité s'accroît également avec la distribution de ces machines virtuelles sur des
groupes à haute disponibilité ou des zones de disponibilité. Tout cela est une bonne
chose. La puissance d’Azure réside dans le fait que vous n'avez pas besoin de vous soucier
de la façon d'ajouter d'autres instances d'application, de les répartir sur le matériel de
votre datacenter ou même de différents datacenters, puis de mettre à jour les ressources
réseau pour distribuer le trafic aux nouvelles instances d'application.

9.1.1 Mise à l'échelle des machines virtuelles verticalement

La première façon de faire pour mettre les ressources à l'échelle n'a rien d'original, et c'est
sans doute ainsi que vous avez habituellement procédé vous-même le cas échéant. Si votre
application se met à fonctionner lentement à mesure que le nombre de clients qui
l'utilisent augmente, que faites-vous classiquement ? Vous augmentez la quantité de CvPU
ou de mémoire, non ? Vous montez en puissance la ressource en réponse à la demande.
126 Chapitre 9  Des applications évolutives

L’une des utilisations les plus courantes de la mise à l'échelle verticale concerne les
serveurs de base de données. Les bases de données sont notoirement gourmandes en
ressources de calcul, plus encore que ne le sont de vos pizzas les clients de votre pizzeria !
Les serveurs de base de données consomment souvent toutes les ressources fournies à
une VM, même s'ils ne les utilisent pas immédiatement. Dans ces conditions, il peut
s'avérer difficile de suivre la demande réelle sur le système et de savoir quand une mise
à l'échelle verticale s'impose pour fournir plus de ressources. La figure 9.2 illustre la
manière dont la mise à l'échelle verticale répond typiquement à une augmentation des
besoins en ressources d'un serveur de base de données.

Augmentaon de la puissance
vCPU vCPU de traitement (vCPU) vCPU vCPU vCPU vCPU
vCPU vCPU vCPU vCPU vCPU vCPU
Augmentaon de la
vRAM vRAM mémoire (vRAM) vRAM vRAM vRAM vRAM
vRAM vRAM vRAM vRAM vRAM vRAM
vRAM vRAM vRAM

Figure 9.2  À mesure qu'une base de données prend de l'embonpoint, elle a besoin de plus de
ressources pour stocker et traiter les données en mémoire. Pour une mise à l'échelle verticale dans
ce scénario, vous ajoutez plus d'UC et de mémoire.

Vous pouvez avoir besoin d'une mise à l'échelle sur d'autres paramètres que la capacité
UC et la mémoire. Prenons le cas d'un site Web qui sert beaucoup d'images ou de
vidéos. Il se peut qu'il n'y ait pas beaucoup de besoins de traitement, mais la demande
en bande passante peut être élevée. Pour augmenter la bande passante disponible,
vous pouvez augmenter le nombre de cartes réseau sur votre machine virtuelle. Et si
vous avez besoin de stocker plus d'images et de vidéos, vous ajoutez du stockage. Vous
pouvez ajouter ou supprimer des ressources telles que des cartes réseau virtuelles et du
stockage alors même que la machine virtuelle s'exécute.
Redimensionnement des machines virtuelles
Dans Azure, vous pouvez augmenter la taille d'une VM (montée en puissance) si vous
avez besoin de plus de ressources de calcul pour votre application. Au chapitre 2, vous
avez créé une machine virtuelle de base Sa taille était probablement du type Standard_
D2s_v3. Ce nom ne vous renseigne pas beaucoup sur les ressources de calcul affectées
à la machine virtuelle pour déterminer s'il est souhaitable d'augmenter la capacité UC
ou la mémoire à sa disposition. Pour réaliser une mise à l'échelle verticale, vous devez
savoir quelles sont vos options.

Tester
Suivez les instructions fournies pour déterminer la taille et les ressources de calcul des
machines virtuelles disponibles :

1 Ouvrez le portail Azure dans un navigateur Web, puis ouvrez Cloud Shell.

2 Entrez la commande CLI Azure suivante pour déterminer la taille des VM dis-
ponibles et les ressources de calcul qu'elles fournissent :
az vm list-sizes --location eastus --output table
 Pourquoi créer des applications évolutives, fiables ? 127

La sortie de az vm list-sizes varie d'une région à l'autre et évolue à mesure qu'Azure

adapte ses familles de machines virtuelles. Voici un exemple condensé de sortie
générée par la commande, montrant la quantité de mémoire (MemoryInMb) et le nom-
bre de cœurs (NumberOfCores) à disposition de chaque mémoire virtuelle :
MaxDataDiskCount MemoryInMb Nom NumberOfCores

4 8192 Standard_D2s_v3 2
8 16384 Standard_D4s_v3 4
16 32768 Standard_D8s_v3 8
32 65536 Standard_D16s_v3 16
8 4096 Standard_F2s_v2 2
16 8192 Standard_F4s_v2 4
32 16384 Standard_F8s_v2 8
2 2048 Standard_B1ms 1
2 1024 Standard_B1s 1
4 8192 Standard_B2ms 2
4 4096 Standard_B2s 2

Ainsi, votre VM Standard_D2s_v3 vous fournit deux cœurs d'UC et 8 Go de mémoire. C'est
plus que suffisant pour une machine virtuelle de base qui exécute un serveur Web.
Supposons que les prises de commande de votre pizzeria en ligne se mettent à exploser, et
que vous souhaitiez réaliser une mise à l'échelle verticale. Il vous suffit d'utiliser az vm
resize pour choisir une autre taille. Vous spécifiez la taille de machine virtuelle qui offre
le nombre de cœurs d'UC et la quantité de mémoire dont votre application a besoin.
La capacité UC et la mémoire supplémentaires n'apparaissent pas pour autant
comme par magie sur votre machine virtuelle. Ce comportement peut à cet égard être
un peu différent de celui que vous observez avec Hyper-V ou VMware dans un contexte
de ressources sur site. Dans des limites raisonnables, vous pouvez ajouter ou supprimer
des ressources de calcul de base dans un environnement sur site sans interrompre
l'exécution de la VM. Dans Azure, un redémarrage de la machine virtuelle est
généralement nécessaire lorsque vous la redimensionnez pour enregistrer les nouvelles
ressources de calcul et déclencher les règles de facturation appropriées. Lorsque vous
souhaitez mettre en œuvre une mise à l'échelle verticale, prévoyez un certain temps
d'arrêt pour le redémarrage de la machine virtuelle.
Mise à l’échelle à un niveau inférieur
Et si vous avez une VM qui dispose de plus de ressources qu'il ne lui en faut  ? Ce
scénario est souvent plus courant que celui d'une machine virtuelle qui n'en a pas
assez. Les propriétaires d'application choisissent parfois une taille de VM sensiblement
supérieure à ce dont ils ont besoin, pour s'assurer du bon fonctionnement de leur
application. Toutes ces ressources gaspillées coûtent de l'argent, et leur coût passe
facilement inaperçu jusqu'à ce que la facture arrive à la fin du mois.
La mise à l'échelle des ressources est possible dans les deux sens. Nous avons
beaucoup parlé de la montée en puissance des ressources, mais les mêmes principes
s'appliquent pour leur descente en puissance. Il est important d’identifier les tailles de
machine virtuelle utilisées et le poids de la demande des applications sur ces ressources.
Vous pouvez ensuite au besoin utiliser la commande az vm resize pour choisir une
taille de machine virtuelle avec moins de cœurs et de mémoire. Ici aussi, comme pour
toute opération de redimensionnement, un redémarrage de la VM est nécessaire.
9.1.2 Mise à l'échelle des applications Web verticalement
Les applications Web peuvent être mises à l'échelle verticalement pour adaptation aux
besoins en ressources de la même manière que les machines virtuelles. Lorsque vous
avez créé une application Web au chapitre 3, la taille Standard S1 par défaut vous a
128 Chapitre 9  Des applications évolutives

fourni un cœur d'UC et 1,75 Go de RAM. Chaque niveau et chaque taille d'application
Web fournit une quantité définie de ressources, dont des cœurs d'UC, de la mémoire
et des emplacements de préproduction. Le principe reste le même si la taille ou
l'allocation de ressources par défaut change, ou que vous choisissez une taille
d'application Web différente.
Si, après avoir créé votre application Web, vous vous apercevez que l'application
requiert plus de ressources que ce que prévoit le plan de service, vous pouvez changer
de niveau, comme illustré à la figure 9.3. Cette possibilité vous est également offerte si
vous constatez un trop-plein de ressources par rapport à ce dont vous avez besoin.
En procédant manuellement de cette façon, vous pouvez ainsi mettre verticalement
à l'échelle votre application Web en fonction des besoins.

Figure 9.3  Pour mettre manuellement à l'échelle une application Web verticalement, vous modifiez le
niveau de tarification (taille) du plan de service d'application sous-jacent. Le plan de service
d'application définit la quantité de ressources affectées à votre application Web. Si votre application
nécessite une quantité de stockage, un nombre d'UC ou des emplacements de déploiement différents,
vous pouvez changer de niveau pour adapter les ressources affectées à la demande de l'application.

9.1.3 Mise à l'échelle des ressources horizontalement

Une autre approche utilisable pour suivre la demande est celle de la mise à l'échelle
horizontale. En procédant par mise à l'échelle verticale, vous augmentez la quantité
d'UC et la quantité de mémoire attribuées à une même ressource, telle qu'une machine
virtuelle. En procédant par mise à l'échelle horizontale, c'est en revanche le nombre
de machines virtuelles que vous augmentez, comme illustré à la figure 9.4.
L'approche de la mise à l'échelle horizontale exige de la part de l'application qu'elle
soit consciente de cette possibilité et à même de traiter les données sans conflits. Cette
approche est particulièrement pertinente pour les applications Web dans la mesure où
l'application est généralement en mesure de traiter les données par elle-même.
Lorsque vous créez des applications complexes, vous pouvez subdiviser votre
application en composants individuels de plus petite taille. Si vous repensez aux files
d'attente de stockage Azure évoquées au chapitre  4, vous
 Les VMSS (Virtual Machine Scale Sets), ou groupes de machines virtuelles identiques 129

Une mise à l’échelle

vCPU vCPU vCPU vCPU
horizontale augmente
le nombre de VM qui
vRAM vRAM exécutent votre vRAM vRAM vRAM vRAM vRAM vRAM
applicaon.
vRAM vRAM vRAM vRAM vRAM vRAM vRAM vRAM

Figure 9.4  Pour faire face à une augmentation de la demande de votre application, vous pouvez augmenter
le nombre de VM qui exécutent l'application en distribuant la charge sur plusieurs machines virtuelles plutôt
que sur des machines virtuelles à instance unique de plus en plus volumineuses. La charge est ainsi répartie
sur plusieurs machines virtuelles, plutôt que de se concentrer sur une instance unique de machine virtuelle
de plus en plus gonflée.

vous pouvez avoir un composant d'application destiné à recevoir les commandes Web
front-end, et un autre chargé de traiter ces commandes et de les transmettre à la
pizzeria. L'utilisation de files de messages est une approche de la conception et de
l'écriture d'applications à même de fonctionner dans un environnement à évolutivité
horizontale. Cette approche vous permet également de mettre à l'échelle chaque
composant d’application séparément et d'utiliser différentes tailles de VM ou
d'application Web pour optimiser l'efficacité et réduire votre facture mensuelle.
Historiquement, on faisait de la mise à l'échelle verticale car il était plus facile de
déverser des ressources de calcul supplémentaires sur une application en espérant que
cela fasse son bonheur. La mise en place d'un cluster de ressources et la mise à l'échelle
d'une application à l'horizontale étaient souvent complexes dans le monde physique.
Avec le cloud computing et la virtualisation, les problématiques liées à la mise à l'échelle
horizontale ont été à ce point minimisées que vous pouvez souvent mettre une application
à l'échelle plus rapidement à l'horizontale qu'à la verticale, et sans temps d'arrêt.
Rappelez-vous de la commande az vm resize plus tôt dans ce chapitre. Que se
passe-t-il à l'issue de l'opération de redimensionnement de la machine virtuelle ? La VM
redémarre. S'il s'agit de la seule instance de votre application, personne ne peut plus y
accéder jusqu'à ce qu'elle soit de nouveau en ligne. Dans le cas d'une mise à l'échelle
horizontale, il n'y a pas de temps d'arrêt lorsque vous ajoutez des instances de VM ; une
fois les nouvelles machines virtuelles fin prêtes, elles prennent automatiquement en
charge une partie des demandes de l'application. Les sondes d'intégrité de l'équilibreur
évoquées (évoquées chapitre 8) détectent automatiquement la présence dans le pool
back-end de toute nouvelle machine virtuelle prête à participer au traitement des
demandes des clients, laquelle se voit dès lors distribuer du trafic.
Azure a été conçu pour vous offrir le maximum de souplesse et de choix en matière
d'évolutivité. Si vous concevez un nouvel environnement applicatif, je vous suggère
l'approche de la mise à l'échelle horizontale. Les VM ont une extension sympa dans
Azure qui peut vous être utile en la matière : les VMSS (ou Virtual Machine Scale Sets).

9.2 Les VMSS (Virtual Machine Scale Sets), ou groupes de machines

virtuelles identiques
Les machines virtuelles sont l'une des charges de travail les plus courantes dans Azure,
et ce pour une bonne raison. La courbe d'apprentissage pour créer et exécuter une
machine virtuelle est douce, car la plupart de ce que vous connaissez déjà est
directement transposable dans Azure. Les serveurs Web sont l'une des charges de
travail les plus courantes pour une machine virtuelle, ce qui là aussi est intéressant
puisque vous n'avez pas à acquérir de nouvelles compétences pour transposer vos
connaissances de la façon d'exécuter Apache, IIS ou NGINX dans le contexte d'une
machine virtuelle Azure.
130 Chapitre 9  Des applications évolutives

Et si vous pouviez disposer d'un cluster de machines virtuelles exécutant votre

serveur Web  ? Comment géreriez-vous cela dans votre environnement habituel sur
site ? De nombreuses solutions de cluster sont possibles pour une telle implémentation.
Et en ce qui concerne les mises à jour de vos serveurs physiques ou de vos machines
virtuelles  ? Comment procéderiez-vous  ? Et pour augmenter ou réduire
automatiquement le nombre d'instances dans votre cluster ? Auriez-vous besoin d'un
autre outil ? La figure 9.5 illustre le principe d'un VMSS.

VMSS

Zone de disponibilité 1

VM 1

Zone de disponibilité 2
Équilibreur
Internet de charge VM 2

Zone de disponibilité 2

VM 3

Figure 9.5  Un VMSS est un groupe logique de machines virtuelles. Les VM sont identiques et peuvent
être gérées, mises à jour et mises à l'échelle de manière centralisée. Vous pouvez définir des métriques
qui augmentent ou diminuent automatiquement le nombre de machines virtuelles présentes dans le
groupe VMSS en fonction de la charge de votre application.

Un VMSS simplifie l'exécution et la gestion de plusieurs machines virtuelles aux fins

de la mise en œuvre d'une application hautement disponible et à charge équilibrée.
Vous indiquez à Azure quelle taille de machine virtuelle vous souhaitez utiliser, vous
spécifiez une image de base pour la machine virtuelle, et vous précisez le nombre
d'instances à mettre en œuvre. Vous pouvez ensuite établir des seuils de capacité UC
ou de mémoire pour augmenter ou diminuer automatiquement le nombre d'instances
en fonction de la charge de l'application, ou planifier cet ajustement au vu des pics
d'utilisation client. Les VMSS tirent profit à la fois du modèle IaaS des machines
virtuelles et des avantages qu'offre le PaaS en termes de mise à l'échelle, de redondance,
d'automatisation et de gestion centralisée des ressources.

Un VMSS pour une seule machine virtuelle ?

Pour les applications que vous créez sur des machines virtuelles, le mieux est d'utiliser
un VMSS, même si vous n'avez besoin que d'une seule machine virtuelle. Pourquoi ? Un
VMSS est extensible à tout moment et il crée automatiquement les connexions voulues
à un équilibreur de charge ou à une passerelle d'application. Si la demande se met
à augmenter soudainement au bout de deux mois sur votre application, le VMSS pourra
créer une ou deux instances de VM supplémentaires.
Pour étendre une machine virtuelle ordinaire, autonome, vous devrez ajouter la machine
virtuelle à un équilibreur de charge ; et si vous n'avez pas initialement placé la machine
virtuelle dans un groupe à haute disponibilité ou une zone de disponibilité, il vous faudra alors
planifier la façon de rendre vos VM hautement disponibles. En créant un VMSS dès le départ,
même si vous n'avez besoin que d'une seule machine virtuelle, vous assurez la pérennité de
votre application en minimisant le travail supplémentaire nécessaire par la suite.
 Les VMSS (Virtual Machine Scale Sets), ou groupes de machines virtuelles identiques 131

9.2.1 Création d’un VMSS

Bien qu'un VMSS simplifie la création et l'exécution d'applications hautement
disponibles, il implique la création et la configuration de quelques composants
additionnels. Ceci étant dit, deux commandes seulement sont nécessaires pour le
déploiement d'un VMSS avec la CLI Azure.

Tester
Pour créer un VMSS avec la CLI Azure, procédez comme indiqué ci-après :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell en haut du tableau
de bord.
2 Créez un groupe de ressources à l'aide de la commande az group create, en
spécifiant un nom de groupe de ressources, par exemple azuremolchapter9, et
un emplacement :
az group create --name azuremolchapter9 --location westeurope

Les groupes VMSS peuvent utiliser des zones de disponibilité ; assurez-vous par
conséquent de sélectionner une région où le support est disponible.
3 Pour créer un VMSS, spécifiez le nombre d'instances de machine virtuelle
souhaitées et indiquez la façon dont ces instances doivent gérer les mises à jour
de leur configuration. Lorsque vous apportez une modification aux machines
virtuelles, par exemple pour l'installation d'une application ou l'implémentation
d'une mise à jour du système d'exploitation invité, elles peuvent se mettre à jour
automatiquement dès qu'elles détectent la modification. Ou vous pouvez définir
la stratégie de mise à niveau sur manual pour vous laisser le choix du meilleur
moment pour l'application des mises à jour. Les autres paramètres sont les
mêmes que pour la création d'une machine virtuelle unique et devraient vous
être familiers :
az vmss create \
--resource-group azuremolchapter9 \
--name scalesetmol \
--image UbuntuLTS \
--admin-username azuremol \
--generate-ssh-keys \
--instance-count 2 \
--vm-sku Standard_B1ms \
--upgrade-policy-mode automatic \
--lb-sku standard \
--zones 1 2 3

C'est tout ! Vous avez créé plusieurs machines virtuelles dans une zone de disponibil-
ité, avec capacité de mise à l'échelle. Et maintenant, voici la surprise que vous réserve
ce VMSS que vous venez de créer avec la CLI Azure. Vous vous souvenez du chapitre 8
sur les équilibreurs de charge, de toutes ces commandes CLI que vous avez dû utiliser
et de ce que nous avons vu sur les modèles pour simplifier la création d'un équilibreur
de charge ? Avec cette commande az  vmss  create, la bonne nouvelle est que vous
avez automatiquement créé et configuré un équilibreur de charge !
132 Chapitre 9  Des applications évolutives

N'oubliez pas vos limites de quota

Nous avons évoqué les quotas au chapitre 7, mais il me semble opportun d'y revenir au
cas où vous feriez face à des problèmes. Dans Azure, les quotas par défaut sur votre
abonnement vous empêchent de déployer accidentellement des ressources et de les
oublier, ce qui vous coûterait de l'argent ! La liste de ces quotas est consultable sur
http://mng.bz/ddcx.
Lorsque vous créez plusieurs VM, vous pouvez rencontrer des problèmes de quotas.
Le fait d'avoir omis de supprimer les ressources des chapitres et exercices précédents
peut également être à l'origine de problèmes. Si vous voyez un message d'erreur du type
L’opération entraîne le dépassement des limites de quota.
Maximum autorisé : 4, Actuellement utilisé : 4, Supplément demandé : 2.

il est souhaitable de demander une augmentation de vos quotas Vous pouvez

afficher votre quota actuel pour une région donnée au moyen de la commande suivante :
az vm list-usage --location westeurope

Pour demander une augmentation de vos quotas pour une région, suivez les étapes
décrites à la page http://mng.bz/Xq2f.

La CLI Azure vous permet de créer un VMSS en un minimum de temps. Un équilibreur

de charge a été créé et configuré, une adresse IP publique a été attribuée et les instances
de machine virtuelle du VMSS ont été ajoutées au pool d'adresses IP back-end.

Tester
Vérifiez les ressources créées avec votre VMSS, comme indiqué dans les prochaines
com mandes.

Pour voir les ressources qui ont été créées avec votre VMSS, exécutez la commande
suivante :
az resource list \
--resource-group azuremolchapter9 \
--output table

La sortie est du type de celle présentée ci-dessous. La colonne Type vous apporte la
confirmation qu'un réseau virtuel, une adresse IP publique et un équilibreur de charge
ont été créés :
Nom
Groupe de ressources Type

mol azuremolchapter9 Microsoft.Compute/virtualMachineScaleSets

molLB azuremolchapter9 Microsoft.Network/loadBalancers
molLBIP azuremolchapter9 Microsoft.Network/publicIPAddresses
molVNET azuremolchapter9 Microsoft.Network/virtualNetworks

Qu'est-ce que toute cette magie signifie au juste ? Lorsque vous créez un VMSS avec la
CLI Azure, un équilibreur de charge à redondance interzone et une adresse IP publique
sont automatiquement créés sans que vous n'ayez rien à faire. Les machines virtuelles
sont créées et ajoutées à un pool d'adresses IP back-end sur l'équilibreur de charge. Des
règles NAT sont créées qui vous permettent de vous connecter aux instances de machine
 Les VMSS (Virtual Machine Scale Sets), ou groupes de machines virtuelles identiques 133

virtuelle. La seule chose qui manque, ce sont les règles de l'équilibreur de charge, car
celles-ci varient en fonction des applications que vous souhaitez exécuter. Lorsque vous
ajoutez ou supprimez des machines virtuelles dans le VMSS, la configuration de
l'équilibreur de charge se met automatiquement à jour pour permettre la distribution
du trafic vers les nouvelles instances. Cette magie ne se limite pas à la CLI Azure : si vous
utilisez Azure PowerShell ou le portail Azure, ces ressources réseau de prise en charge
sont automatiquement créées et connectées pour opérer de concert.

Tester
Votre VMSS a été créé avec deux instances. Vous pouvez mettre manuellement
à l'échelle le nombre d'instances de VM de votre VMSS. Lorsque vous effectuez une telle
mise à l'échelle, l'équilibreur de charge met automatiquement à jour la configuration du
pool d'adresses IP back-end. Définissez le paramètre --new-capacity du
VMSS sur quatre instances comme suit :
az vmss scale \
--resource-group azuremolchapter9 \
--name scalesetmol \
--new-capacity 4

9.2.2 Création de règles de mise à l'échelle automatique

Lorsque vous avez créé votre groupe VMSS, vous déployez un nombre fixe d'instances.
L'une des fonctionnalités les plus intéressantes des VMSS réside dans leur capacité à
augmenter ou diminuer automatiquement le nombre d'instances de machine virtuelle
qu'ils exécutent.
Comme l'illustre la figure 9.6, lorsque la charge de l'application s'accroît, le VMSS
peut augmenter automatiquement son nombre d'instances exécutées. Pensez à une
application professionnelle type dans votre environnement. Au début de la journée de
travail, les utilisateurs se mettent à accéder à l'application, ce qui entraîne un
accroissement de la charge qui pèse sur les ressources des instances de VM du VMSS.
Pour assurer à l'application des performances optimales, le VMSS augmente alors
automatiquement son nombre d'instances de machine virtuelle. Et l'équilibreur de
charge se met automatiquement à distribuer du trafic aux nouvelles instances. Plus tard
dans la journée, lorsque les utilisateurs rentrent chez eux, la demande sur l'application
décroît. Les instances de machine virtuelle utilisent moins de ressources, de sorte que
le VMSS supprime alors automatiquement certaines de ces instances pour minimiser
les ressources inutiles et diminuer les coûts.

VMSS
VMSS VMSS
VM 1 VM 2 VM 3
VM 1 VM 2 VM 3 Augmentation Diminution VM 1 VM 2
de la charge de la charge
VM 4 VM 5
Mise à l’échelle automatique
Mise à l’échelle automatique par diminution du nombre
par augmentation du nombre d’instances de VM
d’instances de VM

Figure 9.6  Les VMSS peuvent se mettre automatiquement à l'échelle en augmentant ou en diminuant leur nombre
d'instances. Au moyen de règles que vous définissez, vous surveillez certaines métriques qui déclenchent au moment
opportun une augmentation ou une diminution des instances de VM exécutées. Le nombre d'instances de machine
virtuelle s'ajuste de la sorte au niveau de la demande sur votre application. Vous assurez ainsi des performances et
une disponibilité optimales de votre application, tout en éliminant les coûts inutiles lorsque la charge diminue.
134 Chapitre 9  Des applications évolutives

Vous pouvez baser les règles applicables à votre VMSS sur différentes métriques. Vous
pouvez utiliser les métriques de l'hôte pour suivre la consommation des ressources de
base, configurer la collecte de métriques au niveau de la machine virtuelle invitée pour
l'analyse de compteurs de performance spécifiques pour l'application, ou utiliser
Azure Application Insights pour surveiller en profondeur le code de l'application.
Vous pouvez également utiliser la planification pour imposer la présence dans le
VMSS d'un nombre spécifique d'instances de machine virtuelle sur des fenêtres de
temps données. Dans l’exemple d’une application professionnelle commune pour
laquelle la demande est plus élevée pendant les heures de travail qu'en soirée, vous
pouvez définir un nombre fixe plus élevé d’instances à exécuter pendant les heures
d’ouverture et définir un nombre fixe d'exécution d'instances le soir.
Avec des règles de mise à l'échelle automatique basées sur des métriques, les
performances seront scrutées sur un intervalle de temps défini, par exemple 5 minutes,
et quelques minutes pourront encore être nécessaires pour lancer les nouvelles instances
de machine virtuelle et les configurer pour utilisation par l'application. Avec une
planification fixe pour l'ajustement automatique du nombre d'instances de machine
virtuelle dans votre VMSS, les ressources supplémentaires entreront en scène à l'heure
dite, et l'équilibreur de charge leur distribuera le trafic sur toute la plage de temps définie.
L'utilisation d'une planification nécessite une base de référence concernant la demande
type sur l'application et ne tient pas compte des augmentations et des baisses de demande
ici ou là sur le compte commercial ou le cycle de vente. Vous pouvez donc vous retrouver
avec plus de ressources que vous n'en avez besoin à certains moments, et donc payer parfois
plus que nécessaire. Et il peut aussi y avoir des moments où la charge de l'application est
trop forte pour le nombre d'instances de VM que le VMSS est en mesure de mobiliser.

Tester
Pour créer des règles de mise à l'échelle automatique pour un VMSS, procédez comme
indiqué ci-après :

1 Recherchez et sélectionnez Groupe de ressources dans la barre de navigation,

dans la partie gauche du portail Azure.
2 Choisissez le groupe de ressources que vous avez créé pour votre déploiement de
modèle, dans notre cas azuremolchapter9.
3 Sélectionnez votre VMSS dans la liste des ressources, dans notre cas scalesetmol.
4 Sous Paramètres à gauche de la fenêtre du VMSS, choisissez Mise à l'échelle.
Vous pouvez effectuer une mise à l’échelle manuelle ou créer vos propres règles
de mise à l’échelle personnalisée.
5 Choisissez de créer des règles de mise à l’échelle personnalisée.
6 Spécifiez un nom, tel que autoscale, puis définissez un nombre d'instances
minimal, maximal et par défaut. Pour cet exercice, fixez le minimum à  2, le
maximum à 10, et le nombre par défaut à 2.
7 Choisissez Ajouter une règle, puis passez en revue les paramètres de règle
disponibles, présentés à la figure 9.7.
Le paramétrage par défaut surveille la consommation moyenne de la capacité
UC. La règle se déclenche lorsque la charge dépasse les 70 % sur une période de
10 minutes. Une instance de machine virtuelle est ajoutée dans le groupe VMSS,
et un délai de 5 minutes s'écoule avant que la surveillance ne reprenne et que la
règle suivante ne puisse être déclenchée.
Les VMSS (Virtual Machine Scale Sets), ou groupes de machines virtuelles identiques 135

Figure 9.7  Lorsque vous ajoutez une règle de mise à l'échelle automatique,

vous définissez le comportement exact requis pour que la règle se déclenche.

Ce délai de temporisation (« refroidissement ») donne aux nouvelles instances de

VM le temps de se déployer et de commencer à recevoir du trafic de la part de
l'équilibreur de charge, de manière à ce que la charge globale de l'application
dans le VMSS puisse diminuer. Sans ce délai de refroidissement, les règles
pourraient déclencher l'ajout d'une nouvelle instance de machine virtuelle avant
même que la première instance ajoutée n'ait eu le temps de recevoir du trafic.
136 Chapitre 9  Des applications évolutives

8 Pour créer la règle, cliquez sur Ajouter.

9 Choisissez d’ajouter une autre règle. Cette fois, configurez la règle pour que le
nombre d'instances soit diminué d'une unité lorsque la charge UC moyenne est
inférieure à 30 % sur une période de 5 minutes.
10 Dans la fenêtre illustrée à la figure 9.8, vérifiez vos règles, puis cliquez Enregistrer.

Figure 9.8  Vous devez à présent avoir une règle qui augmente le nombre d'instances d'une unité
lorsque la charge UC moyenne dépasse les 70 % et une autre règle qui diminue ce nombre d'une unité
lorsque la charge UC moyenne se situe sous les 30 %.

Vous pouvez également configurer des règles de mise à l'échelle automatique avec la
CLI  Azure, Azure  PowerShell ou dans des modèles. Le portail offre une interface
commode pour la consultation des règles et la visualisation des
options disponibles pour chaque paramètre. Pour les règles complexes, les modèles vous
permettent de créer des VMSS avec le même jeu de règles de manière reproductible.

9.3 Mise à l'échelle d'une application Web

Si vous avez trouvé génial ce que nous avons vu sur les applications Web au chapitre 3
et sur les tables et les files d'attente d'Azur au chapitre 4, ces trois derniers chapitres
qui ont été chargés sur les machines virtuelles IaaS vous ont peut-être laissés perplexes.
Le cloud n'était-il pas censé être plus simple que cela  ? Pour les composants PaaS
comme les applications Web, c'est tout à fait le cas !
 Mise à l'échelle d'une application Web 137

Je ne voudrais surtout pas que les prochaines pages vous donnent le sentiment que je
passe un peu vite sur la façon d'apporter aux applications Web la même haute
disponibilité ainsi que les mêmes capacités de mise à l'échelle. Le fait est que tout est
beaucoup plus simple les concernant  ! Le choix entre IaaS et PaaS s'inscrit dans la
recherche d'un équilibre entre flexibilité et facilité de gestion. Une grande partie de la
redondance sous-jacente est abstraite dans les services PaaS tels que les applications
Web. Inutile donc de consacrer toute une section à la haute disponibilité et une autre
encore aux équilibreurs de charge.
Le choix de l'IaaS pour générer et exécuter vos propres VM ou VMSS avec des
équilibreurs de charge et des zones de disponibilité peut tenir à un besoin ou une
restriction de l'entreprise. Les développeurs, les ingénieurs d'exploitation ou les outils
et workflows peuvent ne pas être prêts à faire avec des applications Web. Ceci étant dit,
je vous encourage vivement à considérer cette option pour le déploiement de vos
nouvelles applications. L'utilisation de composants PaaS, tels que des applications Web,
vous permet de vous concentrer davantage sur vos applications et vos clients en évitant
de perdre du temps sur l'infrastructure et l'administration.

Tester
Pour créer une application Web avec la CLI Azure, procédez comme indiqué ci-après :

1 Au chapitre 3, vous avez créé une application Web sur le portail Azure. Comme
pour la plupart des ressources, il est souvent plus rapide et plus facile d'utiliser la
CLI Azure. Ouvrez Cloud Shell dans le portail Azure.
2 Créez un plan de service d'application de taille Standard S1. Cette taille vous per-
met d'ajouter jusqu’à 10  instances de votre application Web pour sa mise à
l'échelle automatique :
az appservice plan create \
--name appservicemol \
--resource-group azuremolchapter9 \
--sku s1

3 Créez une application Web utilisant un référentiel Git local pour le déploiement,
comme vous l'avez fait au chapitre 3 :
az webapp create \
--name webappmol \
--resource-group azuremolchapter9 \
--plan appservicemol \
--deployment-local-git

Tous les concepts et scénarios évoqués à la section  9.2.2 autour des règles et
planifications de mise à l'échelle automatique pour les VMSS s'appliquent aux
applications Web. Les scénarios les plus courants de mise à l'échelle automatique d'une
application Web sont les suivants :
¡ Augmentation ou diminution automatique du nombre d'instances de
l'application Web compte tenu de métriques de performance, pour adaptation
à la demande sur l'application tout au long de la journée de travail.
¡ Planification déclenchant automatiquement une augmentation du nombre
d'instances de l'application Web au début de la journée de travail, puis une
diminution du nombre d'instances à la fin de la journée.
138 Chapitre 9  Des applications évolutives

Dans le cas de notre pizzeria, l'application Web peut voir sa charge de trafic augmenter
plus tard dans la journée et tout au long de la soirée , le jeu de règles de mise à l'échelle
automatique est donc bien sûr à adapter en fonction de la situation. Encore une fois,
vous devez étudier les performances de votre application pour comprendre son
fonctionnement en conditions normales d'utilisation et pour déterminer la métrique
de performance la plus pertinente pour le déclenchement d'une augmentation ou
d'une réduction de son nombre d'instances. Et même dans le cas d'une mise à l'échelle
automatique basée sur une planification, un suivi s'impose pour déterminer quand
surviennent les pics de demande sur votre application et créer les règles appropriées
pour soutenir ce modèle d'utilisation.

Tester
Pour créer des règles de mise à l'échelle automatique pour une application Web, procé-
dez comme indiqué ci-après :

1 Recherchez et sélectionnez Groupe de ressources dans la barre de navigation,

dans la partie gauche du portail Azure.
2 Choisissez le groupe de ressources que vous avez créé pour votre application
Web, dans notre cas azuremolchapter9.
3 Sélectionnez votre application Web dans la liste des ressources, dans notre cas
webappmol.
4 Sous Paramètres à gauche de la fenêtre de l'application Web, choisissez Monter
en charge (plan de service d'application).
5 Encore une fois, choisissez de configurer des règles de mise à l'échelle
automatique personnalisées, et pas seulement une mise à l’échelle manuelle de
l’application Web.
6 Spécifiez un nom, tel que autoscalewebapp, puis définissez un nombre
d'instances minimal, maximal et par défaut. Pour cet exercice, fixez le minimum
à 2, le maximum à 5, et le nombre par défaut à 2.
7 Choisissez d'ajouter une règle, puis passez en revue les paramètres de règle
disponibles. Cette fenêtre est identique à celle des règles de mise à l'échelle
automatique qui s'ouvre pour les VMSS. Le paramétrage par défaut surveille
la consommation moyenne de la capacité UC et entraîne le déclenchement de
l'action prévue lorsque la charge dépasse les 70 % sur une période de 10 minutes.
Une instance de l'application Web est ajoutée, et un délai de 5 minutes s'écoule avant
que la surveillance ne reprenne et que la règle suivante ne puisse être déclenchée.
8 Choisissez d’ajouter une autre règle. Cette fois, configurez la règle pour que le
nombre d'instances soit diminué d'une unité lorsque la charge UC moyenne est
inférieure à 30 % sur une période de 5 minutes.
9 Examinez, puis enregistrez vos règles.
Lorsque vos règles de mise à l'échelle automatique déclenchent une augmentation ou
une diminution du nombre d'instances de votre application Web, la plate-forme Azure
met à jour la distribution du trafic compte tenu des instances disponibles. Même si
aucun équilibreur de charge n'est exposé, comme avec des VMSS, le trafic est toujours
distribué automatiquement sur les instances de l’application Web à mesure que votre
environnement s'étend ou se réduit. Le fonctionnement est similaire, mais il est cette
fois totalement transparent pour vous. C'est là l'un des avantages de l'approche PaaS, qui
vous soulage de cet aspect !
 Exercice pratique : installation d'une application sur un VMSS ou une application Web 139

Autant les VMSS que les applications Web vous permettent de créer des règles qui
dimensionnent automatiquement le nombre d'instances qui exécutent vos applications.
Avec plusieurs instances pour exécuter votre application, vous augmentez également la
disponibilité sa disponibilité. Les VMSS sont un bon terrain d’entente pour les développeurs
et les décisionnaires, qui souhaitent ou ont besoin d'un côté de créer des applications sur
des machines virtuelles et cherchent d'un autre côté le bénéfice de fonctionnalités de type
PaaS pour la mise à l'échelle automatique et la reconfiguration du flux de trafic client.
Dans le chapitre 11, nous allons examiner Azure Traffic Manager, qui complète ces
déploiements haute disponibilité. À l’heure actuelle, vous n’êtes pas encore prêt à passer
à la production car il vous manque plusieurs VMSS redondants ou instances d’applications
Web parmi lesquels le trafic est automatiquement réparti. Nous y viendrons bientôt.

9.4 Exercice pratique : installation d'une application sur un

VMSS ou une application Web
Nous avons vu beaucoup de choses dans ce chapitre ; je vous propose donc maintenant
un petit exercice final avec le choix de l'appliquer à un VMSS ou à une application
Web. Ou, si vous souhaitez prolonger votre pause déjeuner, faites donc les deux !

9.4.1 Les VMSS (Virtual Machine Scale Sets), ou groupes de machines

virtuelles identiques
Vous avez plusieurs instances de VM dans votre VMSS, mais elles ne font pas grand-
chose pour le moment. Pour une vue d'ensemble des différentes façons d'installer des
applications sur les instances de machine virtuelle d'un VMSS, accédez à la page
http://mng.bz/9Ocx. Dans la pratique, vous utiliseriez l'une de ces méthodes de
déploiement automatisé , pour l'heure, vous allez installer manuellement un serveur
Web sur vos instances de VM, comme vous l'avez fait au chapitre 8 :
1 Vous vous souvenez des règles NAT d'équilibrage de charge ? Par défaut, chaque
instance de machine virtuelle d'un VMSS possède une règle NAT qui permet de
s'y connecter directement en SSH. Les ports ne sont pas définis sur le port TCP
standard 22. Affichez la liste des instances de VM d'un VMSS avec leur numéro
de port au moyen de la commande suivante :
az vmss list-instance-connection-info \
--resource-group azuremolchapter9 \
--name scalesetmol

2 Pour vous connecter à un port spécifique en SSH, utilisez le paramètre -p comme

suit (fournissez votre propre adresse IP publique et les numéros de port
appropriés dans votre cas) :
ssh azuremol@40.114.3.147 -p 50003

3 Installez un serveur Web NGINX de base sur chaque instance de machine virtuelle
avec apt install. Repensez à la façon dont vous avez procédé au chapitre 8.
4 Pour voir le VMSS en action, ouvrez l'adresse IP publique de l'équilibreur de
charge du VMSS dans un navigateur Web.
5 Si vous rencontrez des problèmes, veillez à ce que l’équilibreur de charge crée
correctement une règle d’équilibrage de charge pour le port TCP 80 et qu'il est
associé à une sonde d'intégrité pour chaque port TCP 80 ou votre propre sonde
d'intégrité HTTP personnalisée qui vérifie /health.html sur la VM.
140 Chapitre 9  Des applications évolutives

9.4.2 Applications Web

Pour déployer votre application sur une application Web exécutant plusieurs instances,
nous allons procéder comme nous l'avons vu au chapitre 3 pour une application Web
unique. Vous allez faire un push de l'application vers le référentiel Git local pour
l'application Web et, grâce à la puissance du PaaS, la plate-forme Azure déploiera cette
base de code unique sur les différentes instances de l'application Web :

1 Initialisez un référentiel Git dans azure-mol-samples-2nd-ed/09, puis ajoutez et

validez les fichiers d'exemple comme vous l'avez fait au chapitre 3 :
cd azure-mol-samples-2nd-ed/09
git init && git add . && git commit -m “Pizza”

2 Votre application Web dispose d'un référentiel Git local. Ajoutez un lien distant
pour votre application Web de la même manière que vous l'avez fait au
chapitre 3 :
git remote add webappmolscale <your-git-clone-url>

3 Faites un push de cet exemple vers votre application Web. Vous validez ainsi cette
seule base de code, mais votre application est ensuite distribuée sur les différentes
instances de l'application Web :
git push webappmolscale master
 10
Les bases de données
mondiales avec Cosmos DB

Les données. Impossible de s'en passer. Presque toutes les applications que vous
développez et exécutez, créent, traitent ou récupèrent des données. En général, ces
données sont stockées dans une base de données structurée telles que MySQL,
Microsoft SQL ou PostgreSQL. Ces vastes bases de données structurées présentent
de multiples avantages : elles sont réputées et déjà bien établies, bénéficient d'une
importante documentation et de nombreux tutoriels, et sont accessibles depuis la
plupart des principaux langages de programmation.
Un grand pouvoir impliquant de grandes responsabilités, de nombreux frais
d'infrastructure et un gros travail de gestion accompagnent généralement ces bases
de données structurées traditionnelles. Cela ne signifie pas que vous ne devriez pas
les utiliser, loin de là. Mais lorsqu'il s'agit d'applications exécutées à l'échelle
mondiale, ça n'est pas une mince affaire que de créer également des clusters de
serveurs de base de données qui répliquent vos données et acheminent
intelligemment les clients vers votre instance la plus proche.
C'est là qu'Azure Cosmos DB devient votre allié. Vous n'avez pas besoin de vous
soucier de la façon de répliquer vos données, d'assurer la cohérence et de distribuer
les demandes des clients. À la place, vous ajoutez des données dans l'un des nombreux
modèles à votre disposition, puis vous choisissez où vous souhaitez que vos données
soient disponibles. Dans ce chapitre, vous allez découvrir les modèles de bases de
données non structurées dans Cosmos DB, apprendre à créer et à configurer votre
base de données en vue d'une distribution mondiale, et à développer des applications
Web qui utilisent votre instance Cosmos DB hautement évolutive et redondante.

10.1 Qu'est-ce que Cosmos DB ?

Au chapitre  4, nous avons commencé à découvrir les bases de données non
structurées avec les tables de stockage Azure. L'exemple utilisé était basique, mais
les concepts constituent les fondements de Cosmos DB. Tout d'abord, prenons un
peu de recul et déterminons ce que l'on entend par bases de données structurées et
non structurées.

141
142 Chapitre 10  Les bases de données mondiales avec Cosmos DB

10.1.1 Les bases de données structurées (SQL)

Les bases de données structurées représentent une approche plus traditionnelle en
matière de stockage des données. Une structure, ou schéma, d'une base de données
définit la façon dont sont présentées les données. Les données sont stockées dans des
tables : chaque ligne correspond à un élément ainsi qu'à un ensemble fixe de valeurs
qui lui est attribué. Reprenons l'exemple de notre pizzeria. Dans la table qui stocke les
différentes sortes de pizza, chaque ligne pourrait indiquer le nom de la pizza, sa taille
et son prix. Une base de données SQL basique est illustrée dans la figure 10.1.

Base de données structurée

Table Figure 10.1  Dans une base

id nompizza taille coût de données structurée, les
données sont stockées dans
1 Pepperoni 16” 18 USD les lignes et les colonnes d'une
2 Végétarienne 16” 15 USD table. Chaque ligne contient un
3 Hawaïenne 16” 12 USD nombre fixe de colonnes qui
représentent le schéma de la
base de données.

Dans les bases de données structurées, chaque serveur doit généralement contenir la
base de données complète afin que les requêtes et la récupération des données
fonctionnent. Les données, qui proviennent de différentes tables, sont jointes dans des
requêtes selon des critères définis par le développeur dans le cadre de la requête
structurée. C'est de là que vient le terme Langage de requête structurée ou SQL (Structured
Query Language). À mesure que les bases de données gagnent en taille et en complexité,
les serveurs qui exécutent la base de données doivent être suffisamment importants
pour stocker ces données en mémoire. Avec des ensembles de données très importants,
cela s'avère difficile et coûteux. Étant donné qu'elles nécessitent une structure, il est
également compliqué d'ajouter des propriétés et de modifier la structure a posteriori.

10.1.2 Les bases de données non structurées (NoSQL)

Base de données Dans les bases de données NoSQL, les données non structurées ne
non structurée sont pas stockées dans des tables faites de lignes et de colonnes.
Elles sont stockées dans des tableaux dynamiques qui vous
{ permettent d'ajouter de nouvelles propriétés pour un élément,
"coût": "18", selon vos besoins. Un des principaux avantages de cette approche
"description": "Pepperoni" est qu'elle offre la possibilité d'ajouter rapidement une nouvelle
} sorte de pizza ou une garniture spécifique sans avoir à modifier la
{
structure sous-jacente de la base de données. Dans une base de
"coût": "15",
"description": "Végétarienne",
données structurée, vous devriez ajouter une nouvelle colonne à
"gluten": "non" une des tables, puis mettre à jour l'application afin de gérer la
} colonne supplémentaire. Dans les bases de données NoSQL, vous
{ ajoutez une propriété supplémentaire à une entrée donnée depuis
"coût": "12", votre code ; reportez-vous à la figure 10.2.
"description": "Hawaïenne",
"garniture": "jambon, ananas"
Figure 10.2  Dans une base de données non structurée, les données sont
} stockées sans mappages fixes de colonnes à la ligne d'une table. Vous pouvez par
exemple ajouter des garnitures à une seule pizza, sans devoir mettre à jour le
schéma complet et autres dossiers.
 Qu'est-ce que Cosmos DB ? 143

Les bases de données NoSQL proposent également différents modèles de bases de

données. Ces modèles fournissent une indication sur la façon dont sont stockées et
récupérées les données au sein de la base. Le modèle que vous devez utiliser dépend de
la taille et du format de vos données, et de la façon dont vous souhaitez les présenter
dans votre application. Ces modèles incluent les documents, les graphiques et les
tableaux. Ne vous tracassez pas trop avec les modèles pour l'instant. Différents modèles
conviennent mieux à différents ensembles de données non structurées, selon la manière
dont vous voulez mettre en relation et interroger les données. Le point à retenir est que
les bases de données non structurées NoSQL reposent sur un concept différent
concernant le stockage et la récupération des données, ce qui peut réellement devenir
un avantage lorsque vous développez et exécutez des applications cloud dans Azure.

10.1.3 Mise à l'échelle de bases de données

Vous souvenez-vous lorsque j'ai déclaré que pour une base de données structurée, la base
complète doit exister sur chaque serveur ? Lorsque vous commencez à travailler avec de
très grosses bases de données, vous avez besoin de serveurs toujours plus importants pour
les exécuter. Il est possible que vous ne travailliez jamais avec des bases de données qui
atteignent une taille de plusieurs milliers de gigaoctets (voire de téraoctets), mais les
bases de données NoSQL évoluent et s'adaptent différemment des bases de données
SQL. La différence réside dans le fait que les bases de données NoSQL évoluent
généralement de façon horizontale plutôt que verticale.
La mise à l'échelle verticale d'une machine virtuelle est limitée par la mémoire et l'UC.
Lorsque vous atteignez la limite en matière de débit de stockage et de bande passante
réseau, vous commencez à rencontrer des problèmes de performances dans d'autres parties
de la pile de calculs. Sans compter le mal que cela fera à votre portefeuille (ou celui de votre
patron) quand vous recevrez la facture de machines virtuelles aussi volumineuses. Comme
rappel du chapitre 9, la figure 10 illustre la mise à l'échelle verticale.3 Imaginez à présent un
cluster de machines virtuelles de base de données aussi volumineuses, car vous souhaitez
que votre application soit résiliente et redondante, n'est-ce pas ?
Au contraire, une mise à l'échelle horizontale vous permet d'exécuter vos machines
virtuelles de base de données en utilisant moins de ressources et à un prix plus bas. Pour
ce faire, les bases de données NoSQL répartissent les données entre les nœuds de base de
données et acheminent les requêtes depuis votre application jusqu'au nœud approprié.
Les autres nœuds du cluster n'ont pas besoin de savoir où est stocké le reste des données,

Augmentaon de la puissance
vCPU vCPU de traitement (vCPU) vCPU vCPU vCPU vCPU

vCPU vCPU vCPU vCPU vCPU vCPU

Augmentaon de
vRAM vRAM la mémoire (vRAM) vRAM vRAM vRAM vRAM

vRAM vRAM vRAM vRAM vRAM vRAM

vRAM vRAM vRAM

Figure 10.3  Les bases de données structurées évoluent généralement de manière verticale. À mesure
que la base de données s'agrandit, vous augmentez la capacité de stockage, de mémoire et de puissance
d’UC sur le serveur.
144 Chapitre 10  Les bases de données mondiales avec Cosmos DB

ils doivent seulement répondre à leurs propres requêtes. Selon les besoins, vous pouvez
ajouter rapidement des nœuds à un cluster pour répondre à une demande client.
Par conséquent, dans une base de données NoSQL, il n'est pas nécessaire que la base
tienne entièrement dans la mémoire d'un hôte. Seule une partie de la base, que l'on appelle
une partition, doit être stockée et traitée. Si votre application traite une quantité importante
de données structurées, une base de données NoSQL pourrait affecter les performances, car
les différents hôtes sont interrogés pour leurs informations, qui sont ensuite retournées au
client. Si vous devez traiter une grande quantité de données non structurées, les bases
de données NoSQL permettront certainement d'améliorer les performances, voire d'offrir
des avantages en termes de gestion et d'efficacité. La figure 10.4 illustre un exemple de mise
à l'échelle horizontale de base de données non structurée dans les hôtes.

Fraconnement de la base
vCPU vCPU de données pour monter vCPU vCPU vCPU vCPU

vCPU vCPU en charge et équilibrer les vCPU vCPU vCPU vCPU

demandes de traitement

vRAM vRAM vRAM vRAM vRAM vRAM

vRAM vRAM vRAM vRAM vRAM vRAM

vRAM vRAM vRAM

Paron de base Paron de base
de données de données

Figure 10.4  Les bases de données non structurées NoSQL procèdent par mise à l'échelle horizontale.
À mesure que la base s'agrandit, celle-ci est fragmentée en segments de données qui sont ensuite
distribués sur les serveurs de base de données.

10.1.4 Mise en place avec Cosmos DB

Qu'est-ce que Cosmos DB ? Il s'agit d'une plateforme de base de données disponible
mondialement et offrant des fonctionnalités de mise à l'échelle automatique, vous
permettant d'utiliser diverses formes de bases de données NoSQL. Comme avec certains
services tels que Web Apps, Cosmos DB vous épargne une bonne partie de la charge de
gestion. Lorsque vous créez une application Web, vous n'avez pas besoin de configurer
l'équilibrage de charge ou le clustering. En effet, vous devez seulement choisir vos
régions, configurer la mise à l'échelle automatique, puis charger le code de votre
application. La réplication et la distribution du trafic de l'application Web sont gérées de
manière hautement disponible par la plateforme Azure. Avec Cosmos DB, vous n'avez
pas à vous soucier de la taille de la base de données dont vous avez besoin,de la quantité
de mémoire à assigner, ni de la façon de répliquer des données à des fins de redondance.
Vous choisissez la quantité de débit dont vous pourriez avoir besoin et les régions dans
lesquelles stocker vos données, puis vous commencez à ajouter vos données.
Tout au long de ce chapitre, nous allons utiliser un modèle SQL pour Cosmos DB,
tandis que les données seront stockées au format JSON NoSQL. Ces concepts vous sont
peut-être inconnus, mais tâchez de rester avec moi. Il est possible d'utiliser d'autres
modèles tels que Mongo, Cassandra, Gremlin et Table. Ceux-ci partagent la même
fonctionnalité : choisissez votre modèle, vos régions et ajoutez vos données. Voici toute
la puissance de Cosmos DB.
 Création d'un compte Cosmos DB et d'une base de données 145

10.2 Création d'un compte Cosmos DB et d'une base de données

Observons à présent Cosmos DB et les bases de données non structurées à l'œuvre, et
ce de plusieurs façons. La première méthode consiste à créer un compte depuis le
portail Azure, puis à sélectionner et créer un modèle de base de données. Vous ajoutez
ensuite les données dans la base afin que votre application puisse l'interroger.
Autrement, vous pouvez utiliser Azure  CLI, Azure PowerShell ou des kits de
développement logiciel (SDK) spécifiques au langage pour coder la base de données.
Nous allons passer par le portail Azure afin que vous puissiez créer et interroger
visuellement les données.

10.2.1 Création et alimentation d'une base de données Cosmos DB

Au chapitre 4, vous avez créé votre première base de données NoSQL avec une table
de stockage Azure. Nous allons utiliser Cosmos DB pour créer une base de données
similaire, qui proposera cette fois toutes les options de géo-redondance et de
réplication afin de s'assurer que votre boutique en ligne permette aux clients de
commander des pizzas, sans générer de temps d'arrêt. Créons tout d'abord un compte
Cosmos DB ainsi qu'une base de données de documents, puis ajoutons des entrées de
données pour trois différentes sortes de pizzas, comme illustré à la figure 10.5.

Pizza au Pizza Pizza Figure 10.5  Dans cette

pepperoni végétarienne hawaïenne section, vous créerez un
groupe de ressources et
un compte Cosmos DB.
Base de données de documents Cosmos DB Une base de données
de documents est ensuite
créée dans ce compte,
puis vous ajouterez
Compte Cosmos DB
trois entrées afin de
proposer une carte de
Groupe de ressources Azure base pour votre pizzéria.

Tester
Pour voir Cosmos DB à l'œuvre, créez un compte à l'aide du portail Azure :

1 Ouvrez le portail Azure et sélectionnez Créer une ressource, dans le coin

supérieur gauche du tableau de bord.
2 Recherchez et sélectionnez Azure Cosmos DB, puis choisissez Créer.
3 Choisissez de créer un groupe de ressources, tel que azuremolchapter10,
et entrez un nom unique pour votre compte Cosmos DB, tel que azuremol.
146 Chapitre 10  Les bases de données mondiales avec Cosmos DB

4 Le type de modèle que vous pouvez utiliser pour votre base de données est
désigné sous le nom d'API. Pour cet exemple, choisissez Core (SQL) dans le
menu déroulant.
5 Dans le champ Emplacement, sélectionnez Est des États-Unis. Cosmos  DB est
disponible dans toutes les régions Azure. Cependant, pour cet exemple, il est
nécessaire de choisir l'Est des États-Unis pour l'application Web que vous allez
déployer dans l'exercice pratique en fin de chapitre.
6 Laissez l’option de géoredondance désactivée, ainsi que n’importe quel
autre fonction, notamment les régions multi-écriture. La section 10.2.2 explique
plus en détail comment répliquer votre base de données à l'échelle mondiale.

Sécuriser le trafic avec les points de terminaison de service

Vous avez la possibilité de connecter votre Cosmos DB à un réseau virtuel Azure avec un
point de terminaison de service. Nous ne discuterons pas de cette option maintenant,
même si elle est intéressante pour sécuriser votre instance en autorisant l’accès à la
base de données uniquement à partir d’un réseau virtuel défini.
Si vous créez des applications middleware qui utilisent Cosmos DB, ou des applications
uniquement en interne, vous pouvez utiliser un point de terminaison de service de réseau
virtuel pour réduire l’accès à partir d’un réseau virtuel spécifique, pas sur Internet et avec un
point de terminaison public. Un nombre croissant de services Azure prennent en charge ces
types de points de terminaison, et il s’agit d’un autre exemple d'options vous permettant de
sécuriser votre environnement pour répondre aux besoins de votre entreprise.

7 Lorsque vous êtes prêt, examinez et créez votre compte Cosmos DB. La création
du compte prend quelques minutes.

Pour l'instant, votre base de données est vide. Voyons voir comment stocker des
données de base pour le menu de votre pizzéria. Cosmos DB regroupe les données
d’une base de données dans un conteneur. Il ne s'agit pas du même type de conteneur
sur lequel reposent Docker, Kubernetes et les applications natives du Cloud. Cette
confusion de nommage ne nous aide pas, mais tâchez de restez avec moi.
Dans les bases de données Cosmos DB qui
utilisent le modèle de document, les données
sont regroupées logiquement en conteneurs
appelés collections. D’autres modèles d’API ont
Pizza au Pizza Pizza un nom légèrement différent pour l’entité de
pepperoni végétarienne hawaïenne conteneur, comme graph pour l'API Gremlin.
Ces collections stockent des éléments de
données connexes pour notre API SQL,
Collection pouvant être rapidement indexés et
interrogés, comme illustré à la figure 10.6. Les
collections ne sont pas entièrement
Base de données de documents Cosmos DB
différentes de la façon dont vous organisez
une base de données SQL en tables, mais elles
Figure 10.6  Une base de données Cosmos DB qui utilise offrent davantage de flexibilité quant à la
le modèle de document stocke les données dans des distribution des données pour la performance
collections. Ces collections vous permettent de grouper ou la redondance.
des données pour une indexation et une interrogation plus
rapides.
 Création d'un compte Cosmos DB et d'une base de données 147

Étant donné que Cosmos  DB est conçu pour traiter de très grandes quantités de
données et de débit, vous pouvez choisir comment dimensionner et contrôler le flux
et le coût de ces données. Le débit est mesuré en unités de requête par seconde
(RU/s), une unité de requête équivalant à 1 Ko de données de document. En résumé,
vous déterminez la quantité de bande passante souhaitée pour votre base de données.
Si vous ne l'aviez pas déjà deviné, plus vous désirez de bande passante (RU/s), plus cela
vous coûtera cher. Cosmos DB vous indique la quantité de données exploitées ainsi
que le débit utilisé par votre application. Vous n'avez généralement pas à vous soucier
du dimensionnement. En ce qui concerne votre pizzéria, ne voyons pas trop grand !

Tester
Pour créer une collection et alimenter des entrées dans la base, procédez comme suit :

1 Recherchez et sélectionnez Groupe de ressources dans la barre de navigation,

dans la partie gauche du portail Azure.
2 Choisissez le groupe de ressources dans lequel vous avez créé votre base
de données Cosmos DB, tel que azuremolchapter10.
3 Sélectionnez votre compte Cosmos DB dans la liste des ressources, puis choisissez
la Page de présentation.
4 Choisissez d'ajouter un conteneur.
5 Étant donné qu'il s'agit de votre première base de données, choisissez Créer
nouveau, puis saisissez un nom tel que pizzadb.
6 Laissez le débit défini sur la valeur par défaut.
7 Pour l’ID de conteneur, saisissez pizzas. Un conteneur logique est alors créé et
vous pouvez l'utiliser pour stocker les éléments du menu de votre pizzéria.
8 Saisissez une clé de partition /description pour vous assurer que les types de
pizza sont uniformément distribués.
La clé de partition identifie la façon dont les données peuvent être fractionnées
dans la base de données. Ce n’est pas vraiment nécessaire dans un petit exemple
de base de données comme celle-ci, même s'il s'agit d'une bonne pratique à
mesure que votre application évolue.
9 Ne choisissez pas d'ajouter une clé unique. Les clés permettent de définir le
conteneur encore plus logiquement, par exemple grâce à des sous-sections de
nourriture que peuvent commander les clients. La collection la plus vaste
correspond à votre carte, mais dans des bases de données bien plus grandes, peut-
être souhaitez-vous des clés de partition pour les pizzas, les boissons et les desserts.
10 Pour créer la base de données et la collection, sélectionnez OK.
Vous disposez à présent d'un compte Cosmos  DB, d'une base de données, et d'une
collection, mais Cosmos DB ne contient toujours pas vos pizzas. Vous pouvez importer
des données ou écrire du code qui entre des données. Créons manuellement
trois pizzas afin de découvrir sur le portail Azure certains des outils graphiques intégrés
pour la navigation, l'interrogation et la manipulation des données dans votre base
Cosmos DB.
148 Chapitre 10  Les bases de données mondiales avec Cosmos DB

Tester
Pour les créer, ajoutez des entrées dans la base de données, procédez comme suit,
comme illustré à la figure 10.7 :

1 Dans votre compte Cosmos  DB, naviguez jusqu'au menu situé dans la partie
gauche de la fenêtre Vue d'ensemble et choisissez Explorateur de données.

Figure 10.7  Avec l'Explorateur de données du portail Azure, vous pouvez parcourir vos
collections afin d'interroger ou de créer de nouveaux documents. Cet outil graphique vous
permet de gérer rapidement votre base de données depuis un navigateur Web.

2 Commencez par développer la base de données pizzadb, puis la collection

pizzas.
3 Ajoutez un nouvel élément pour insérer des pizzas dans la base de données. Les
données sont ajoutées au format JSON.
4 Dans la zone de texte, remplacez le texte existant par les données suivantes pour
ajouter une pizza au pepperoni classique à la carte :
{
  "description": "Pepperoni",
  "cost": "18"
}

5 Pour ajouter les données à la base, sélectionnez Enregistrer.

 Création d'un compte Cosmos DB et d'une base de données 149

6 Ajoutez une nouvelle pizza à votre carte. Cette fois-ci, ajoutez une propriété pour
indiquer que la pâte de cette pizza ne contient pas de gluten. Vous n'avez pas
besoin de toucher à la base de données sous-jacente ; contentez-vous d'ajouter
une nouvelle propriété à vos données. Pour ajouter un nouvel élément, entrez
les données suivantes et sélectionnez Enregistrer :
{
  "description": "Veggie",
  "cost": "15",
  "gluten": "free"
}

7 Ajoutez une dernière sorte de pizza. Ajoutez cette fois une propriété gérant les
garnitures de la pizza. Pour ajouter un nouvel élément, entrez les données
suivantes et sélectionnez Enregistrer :
{
  "description": "Hawaiian",
  "cost": "12",
   "toppings": "ham, pineapple"
}

Ces trois entrées illustrent toute la puissance d'une base de données NoSQL. Vous avez
ajouté des propriétés aux entrées sans avoir à modifier le schéma de la base. Deux propriétés
différentes ont permis d'indiquer que la pâte de la pizza végétarienne est sans gluten et
quelle est la garniture de la pizza Hawaïenne. Cosmos  DB accepte ces propriétés
supplémentaires, et ces données sont à présent disponibles pour vos applications.
Certaines propriétés JSON supplémentaires sont ajoutées pour des éléments comme
id, _rid et _self. Nous ne nous intéresserons pas à ces propriétés pour l’instant.
Cosmos DB utilise ces propriétés pour suivre et identifier les données. Vous ne devez
pas les modifier, ni les supprimer manuellement.

10.2.2 Ajout d'une redondance mondiale à une base de données Cosmos DB

Vous disposez à présent d'une base de données Cosmos DB qui stocke une carte de pizzas
classique dans la région Est des États-Unis. Cependant, votre pizzéria s'apprête à ouvrir
des franchises dans le monde entier ! Vous souhaitez répliquer les données de vos pizzas
vers des régions Azure dans différentes zones, à proximité de votre nouvelle clientèle.
Pourquoi procéder de cette manière ? Si tous vous clients lisent et écrivent des don-
nées depuis la base de données dans une région, cela représente beaucoup de trafic
potentiel traversant les câbles sous-marins et circulant à travers le monde. Afin d'offrir
à vos clients la meilleure expérience à faible latence, vous pouvez répliquer vos données
vers les régions Azure dans le monde entier, et les clients peuvent ainsi se connecter au
réplica le plus proche, comme illustré à la figure 10.8.
Les modèles de cohérence et les garanties sont intégrés dans la plateforme
Cosmos DB pour gérer la cohérence et la réplication des données à votre place. Vous
déterminez une ou plusieurs régions comme emplacement d'écriture principal.
Les exemples de cet ouvrage utilisent un point d'écriture unique, mais vous pouvez
vous servir de la prise en charge multimaître pour écrire des données au point
de terminaison le plus proche, qui seront ensuite propagées
150 Chapitre 10  Les bases de données mondiales avec Cosmos DB

Cosmos DB Los Angeles,

(Europe du Nord) États-Unis

Cosmos DB (Ouest Melbourne,

des États-Unis) Australie
Cosmos DB (Est
des États-Unis)
Cosmos DB
Paris, France
Région d'écriture (Asie de l'Est)
principale

Données répliquées
Cosmos DB (Sud-Est Kuala Lumpur,
vers plusieurs régions de l'Australie) Malaisie

Les clients interrogent et

Garanties de lisent Cosmos DB depuis
cohérence pour les la région la plus proche
données Cosmos DB

Figure 10.8  Les données sont répliquées d'une instance principale Cosmos DB vers plusieurs
régions Azure à travers le monde. Les applications Web peuvent ensuite être dirigées pour
lecture depuis la région de laquelle elles sont les plus proches, puis les clients sont acheminés
dynamiquement vers l'emplacement le plus proche, afin de minimiser la période de latence et
d'améliorer les temps de réponse.

de manière asynchrone vers d'autres régions. Les données sont également répliquées
rapidement vers les régions de lecture de votre choix. Vous pouvez contrôler l'ordre de
basculement, afin de désigner les régions de lecture puis, avec votre application,
déterminer automatiquement ou manuellement les régions depuis lesquelles lire.
Vous pouvez définir un modèle de cohérence (qui s'apparente en réalité davantage
à un aspect conceptuel plutôt qu'opérationnel) qui définit la rapidité de la réplication
des écritures dans plusieurs régions. Les modèles de cohérence vont de fort, qui attend
que les écritures répliquées soient confirmées par des réplicas et qui garantit donc que
les lectures sont cohérentes, àéventuel, qui est un modèle plus souple. Le modèle
éventuel garantit que toutes les données sont répliquées, mais il peut exister un léger
retard lorsque les lectures des réplicas retournent des valeurs différentes, jusqu'à ce
qu'elles soient toutes synchronisées.
Il existe un équilibre entre une distribution géographique plus limitée, comme avec
le modèle de cohérence fort, et une réplication géographique plus large avec le modèle
de cohérence éventuel, en n'oubliant pas le léger retard lors de la réplication des données.
Il faut également prendre en compte les coûts de traitement et de bande passante,
selon la cohérence et la rapidité souhaités en matière de réplication des données. La
plateforme Azure gère la réplication sous-jacente des données depuis votre point
d'écriture ; vous n'avez pas besoin de créer vos applications pour répliquer les données
ou de déterminer la meilleure façon de lire les données depuis des points de
terminaison répliqués.
 Création d'un compte Cosmos DB et d'une base de données 151

À l'échelle mondiale, vous pourriez avoir plusieurs machines virtuelles ou

applications Web, telles que celles que vous avez créées aux chapitres précédents, mais
dans différentes régions à travers le monde. Ces applications se connectent à une
instance locale Cosmos DB afin d'interroger et de lire l'ensemble de leurs données.
Grâce à certaines fonctionnalités Azure intéressantes en termes de trafic réseau que
nous aborderons au chapitre 11, les utilisateurs peuvent être acheminés automatiquement
vers l'une de ces instances locales d'application Web, qui utilisent également une
instance locale Cosmos DB. En cas de maintenance ou de pannes régionales, l'ensemble
de la plateforme achemine le client vers l'instance suivante la plus proche.
Dans l'univers des bases de données structurées classiques, où vous gérez vos
machines virtuelles, l'installation des bases de données et la configuration des clusters,
une telle configuration demande une planification rigoureuse et est compliquée à
mettre en place. Avec Cosmos DB, il suffit de trois clics. Honnêtement !

Tester
Pour répliquer vos données Cosmos DB à l'échelle mondiale, procédez comme suit :

1 Recherchez et sélectionnez Groupe de ressources dans la barre de navigation,

dans la partie gauche du portail Azure.
2 Choisissez le groupe de ressources dans lequel vous avez créé votre base de don-
nées Cosmos DB, tel que azuremolchapter10.
3 Dans la liste des ressources, sélectionnez votre compte Cosmos DB. Ces deux clics
ne rentrent pas dans le compte, commencez à compter à partir d'ici !
4 Sélectionnez l’option de menu à gauche pour répliquer les données à l’échelle
mondiale. La carte qui répertorie toutes les régions Azure disponibles, indique
que votre base de données est actuellement disponible dans la région Est des
États-Unis (figure 10.9).

Figure 10.9  Sélectionnez une région Azure pour répliquer votre base de données Cosmos DB, puis
choisissez Enregistrer. Voici toutes les étapes nécessaires pour distribuer mondialement vos données.
152 Chapitre 10  Les bases de données mondiales avec Cosmos DB

5 Choisissez Europe de l'Ouest, puis sélectionnez Enregistrer. En théorie, vous

pouvez sélectionner la région Azure de votre choix, mais pour l'exercice pratique
en fin de chapitre, il est nécessaire que les données soient répliquées vers
l'Europe de l'Ouest. Cela prend quelques instants de répliquer les données dans
la région choisie et de les mettre en ligne afin qu'elles puissent être utilisées par
vos applications.
C'est bon, vous pouvez compter le nombre de clics ! Trois, n'est-ce pas ? Sur un élan de
générosité, comptabilisons les deux  premiers clics servant à sélectionner le groupe de
ressources et le compte Cosmos DB. Ainsi, en seulement cinq clics et quelques secondes,
vous avez créé un réplica d'instance de votre base de données, qui permet à vos applications
d'accéder aux données de la région dont elles sont les plus proches. Un cluster MySQL
classique vous permet-il de faire ça  ? Si vous arrivez à effectuer cette  opération aussi
rapidement en dehors de Cosmos DB, n'hésitez pas à me tweeter (@fouldsy) !
Maintenant que votre base de données est distribuée mondialement, est-il nécessaire
de modifier beaucoup votre code afin de déterminer à quelle région Cosmos DB se
connecter  ? Comment pouvez-vous maintenir toutes ces différentes versions de vos
applications selon la région Azure dans laquelle elles sont exécutées ? Rien de plus
simple : laissez la plateforme Azure gérer ça pour vous !

10.3 Accès aux données distribuées mondialement

La plupart du temps, la plateforme Azure détermine l'emplacement le plus adapté
pour vos applications. Une application doit généralement lire et écrire des données.
Vous pouvez déterminer les stratégies de basculement pour votre base de données Cos-
mos DB, qui contrôle l'emplacement d'écriture principal. Cet emplacement d'écriture
agit comme le hub central, pour s'assurer que les données sont systématiquement
répliquées dans les différentes régions. Cependant, votre application Web peut
généralement lire depuis plusieurs régions disponibles afin d'accélérer les requêtes et
de retourner les données au client. Tout cela est géré par les appels REST.
Voyons ce qui se passe depuis la CLI Azure lorsque vous demandez des informations
sur une base de données Cosmos DB. Ce processus s'apparente à la connexion d'une
application à une base de données, sans que vous puissiez aller trop loin dans le code.

Tester
Utilisez la commande az cosmosdb show pour accéder à des informations concernant
votre emplacement de lecture et d'écriture :

1 Ouvrez le portail Azure dans un navigateur Web, puis ouvrez Cloud Shell.

2 Utilisez la commande az cosmosdb show pour afficher les emplacements de lec-
ture et d'écriture de votre base de données Cosmos DB.
Entrez le nom du groupe de ressources et celui de la base de données que vous
avez créés dans les exercices « Essayez dès maintenant » précédents. Dans l'exem-
ple suivant, le groupe de ressources est azuremolchapter10 et le nom de la base
de données Cosmos DB est azuremol :
az cosmosdb show \
--resource-group azuremolchapter10 \
--name azuremol
 Accès aux données distribuées mondialement 153

Le résultat retourné par cette commande étant assez conséquent, examinons les
deux parties principales : les emplacements de lecture et les emplacements d'écriture.
Voici un exemple de résultat pour la section readLocations :
"readLocations": [
  {
   "documentEndpoint":"https://azuremol-eastus.documents.azure.com:443/",
   "failoverPriority": 0,
   "id": "azuremol-eastus",
   "isZoneRedundant": "false",
   "locationName": "East US",
   "provisioningState": "Succeeded"
  },
  {
   "documentEndpoint":
   ➥"https://azuremol-westeurope.documents.azure.com:443/",
   "failoverPriority": 1,
   "id": "azuremol-westeurope",
   "isZoneRedundant": "false",
   "locationName": "West Europe",
   "provisioningState": "Succeeded"
   }
],

Lorsque votre application établit une connexion à une base de données Cosmos DB,
vous pouvez spécifier une stratégie de connexion. Si les bases de données ne sont pas
votre fort, pensez à une connexion Open Database Connectivity (ODBC) classique
que vous pouvez créer sur une machine Windows. La chaîne de connexion définit
généralement un nom d’hôte, un nom de base de données, un port et des informations
d'identification. Il en va de même pour Cosmos  DB. Vous pouvez vous connecter à
Cosmos  DB depuis plusieurs langages, y compris .NET, Python, Node.js et Java. Les
langages peuvent varier, mais tous les SDK partagent un paramètre identique  : la
détection des points de terminaison. Deux des propriétés principales de la stratégie de
connexion sont importantes :
¡ Détection automatique des points de terminaison—Le SDK lit tous les points de terminaison
disponibles depuis Cosmos  DB et utilise l'ordre de basculement indiqué. Cette
approche garantit que votre application respecte toujours l'ordre que vous spécifiez
au niveau de la base de données. Peut-être souhaitez-vous que toutes les lectures
passent par l'Est des États-Unis et utilisent uniquement Europe de l’Ouest en cas de
maintenance dans l'emplacement principal.
¡ Emplacements de point de terminaison préférés— Vous spécifiez les emplacements que
vous souhaitez utiliser. Cela peut être utile, par exemple, lorsque vous déployez
votre application vers l'Europe de l'Ouest et souhaitez vous assurer que vous utilisez
le point de terminaison correspondant. Vous perdez un peu en souplesse lors de
l'ajout ou de la suppression de points de terminaison. Vous vous assurez cependant
que votre point de terminaison par défaut est proche de votre application, sans
avoir besoin de déterminer cela à l'aide d'un routage réseau plus avancé.
En règle générale, le SDK de Cosmos  DB prend en charge cette tâche pour votre
application. Celle-ci ne modifie pas la façon dont elle gère la connexion à la base de
données : elle sait seulement qu'il existe plusieurs emplacements auxquels elle peut se
connecter. Mais c'est le SDK qui se charge de la connexion et qui utilise cette
reconnaissance de l'emplacement.
154 Chapitre 10  Les bases de données mondiales avec Cosmos DB

La figure  10.10 illustre une approche simplifiée de l'utilisation de cette

reconnaissance de l'emplacement entre votre application et le SDK. Encore une fois,
quel que soit le langage utilisé, l'approche reste identique. La figure prend l'exemple
du SDK Python car certains des exemples ont été écrits dans ce langage. Cet exemple
part également du principe que vous utilisez des emplacements de point de terminaison
automatiques.

Azure
2. Demande des emplacements de Cosmos DB
point de terminaison automatiques

1. Demande de connexion 3. Connexion et

emplacements renvoyés

Application 4. Connexion renvoyée SDK Python

web Cosmos DB
5. Demande de données
6. Demande des données depuis
8. Données renvoyées le point de terminaison principal

Azure Cosmos
7. Données envoyées depuis le point DB (lecture
de terminaison de lecture principal principale)

Figure 10.10  Le flux de requêtes via un SDK Cosmos DB, lorsqu'une application utilise la

reconnaissance de l'emplacement pour interroger Cosmos DB

Les étapes illustrées à la figure 10.10 sont les suivantes :

1 Votre application doit établir une connexion à une base de données Cosmos DB.
Dans la stratégie de connexion, vous activez la détection automatique des points
de terminaison. L'application se sert du SDK Cosmos  DB pour établir une
connexion à la base de données.
2 Le SDK Cosmos  DB effectue une demande de connexion et indique qu'il
souhaite utiliser les emplacements de point de terminaison automatiques.
3 Une connexion est renvoyée selon les informations d'identification et la base de
données demandée.
4 Le SDK renvoie un objet de connexion que l'application peut utiliser.
Les informations d’emplacement sont extraites de l'application.
5 L'application demande des données de la base Cosmos  DB. Le SDK est de
nouveau utilisé pour interroger et obtenir les données.
6 Le SDK utilise la liste des points de terminaison disponibles et effectue la demande
auprès du premier point de terminaison disponible. Il utilise ensuite le point de
terminaison de connexion pour interroger les données. Si le point de terminaison
principal n'est pas disponible, en cas de maintenance par exemple, l'emplacement
du point de terminaison suivant est automatiquement utilisé.
7 Cosmos DB renvoie les données depuis l'emplacement du point de terminaison.
8 Le SDK transmet les données depuis Cosmos DB à l'application pour les analyser
et les afficher au besoin.
 Accès aux données distribuées mondialement 155

Nous devons encore aborder les clés d'accès avant d'en avoir terminé avec Cosmos DB.
Ces clés vous permettent de contrôler qui peut accéder aux données ainsi que les
autorisations qui leurs sont accordées. Les clés peuvent être régénérées, et tout comme
pour les mots de passe, il est recommandé de mettre en place une stratégie
afin d'effectuer régulièrement ce processus de régénération. Afin d'accéder aux
données distribuées dans Cosmos DB, vous devez préalablement obtenir vos clés. Le
portail Azure permet d'afficher l'ensemble des clés et des chaînes de connexion de
votre base de données.

Tester
Pour afficher les clés de votre compte Cosmos DB, procédez comme suit :

1 Recherchez et sélectionnez Groupe de ressources dans la barre de navigation,

dans la partie gauche du portail Azure.
2 Choisissez le groupe de ressources dans lequel vous avez créé votre base de don-
nées Cosmos DB, tel que azuremolchapter10.
3 Dans la liste des ressources, sélectionnez votre compte Cosmos DB.
4 Sélectionnez clés à gauche de l'écran.
5 Prenez note de l'URI et de la clé primaire (figure 10.11). Ces valeurs vous seront
utiles pour l'exercice pratique en fin de chapitre.

Figure 10.11  La section Clés de votre compte Cosmos DB répertorie les informations de connexion ainsi
que les clés d'accès. Lorsque vous développez et exécutez des applications, comme c'est le cas pour
l'exercice pratique en fin de chapitre, ces informations sont nécessaires.
Dans Cosmos DB, afin de distribuer vos données et de permettre à vos applications de
lire et d'écrire depuis les emplacements les plus appropriés, de nombreuses opérations
156 Chapitre 10  Les bases de données mondiales avec Cosmos DB

sont menées en arrière-plan. Mais là est tout l'intérêt. En étant informé des possibilités
offertes par le service Cosmos DB, cela facilite la conception et la planification de votre
application, ainsi que la résolution des problèmes si les applications ne permettent pas
au SDK d’effectuer des opérations de lecture et d’écriture selon les besoins. Ne vous
préoccupez pas du pourquoi du comment. Concentrez-vous uniquement sur vos
applications, et comptez sur les services Azure tels que Cosmos DB pour vous fournir les
fonctionnalités et avantages cloud qui vous permettent d'opérer à l'échelle mondiale.

10.4 Exercice pratique : déploiement d'une application Web qui utilise

Cosmos DB
À la section  10.2.2, vous avez distribué mondialement votre base de données
Cosmos  DB. Nous avons ensuite abordé l'aspect théorique de la façon dont les
applications Web peuvent lire depuis différents emplacements à travers le monde.
Vous avez sûrement envie de passer à la partie pratique et ça tombe bien car c'est ce
que nous allons faire. Dans cet exercice pratique, l’application Web de base créée dans
les chapitres précédents est utilisée, mais cette fois, la carte de pizzas provient des
éléments que vous avez ajoutés à la base de données Cosmos DB dans un exercice
précédent « Testez dès maintenant » :

1 Créez une application Web dans le portail Azure.

2 Étant donné que la pizzeria n’est plus une page HTML basique, choisissez Node
LTS pour le temps d’exécution qui s’exécute sur Linux.
3 Lorsque l’application Web est prête, créez une source de déploiement
(référentiel Git local). Les étapes sont identiques à celles que vous avez pu suivre
lorsque vous en avez créé une aux chapitres précédents (au chapitre  3 par
exemple). N'hésitez pas à revenir sur ces exercices en cas de doute.
4 Ouvrez Cloud Shell. Dans les chapitres précédents, vous avez obtenu une copie
des échantillons Azure sur GitHub. Si vous ne l’avez pas fait, procurez-vous une
copie à l’adresse :
git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

5 Passez au répertoire contenant l'exemple d'application Web Cosmos DB :

cd ~/azure-mol-samples-2nd-ed/10/cosmosdbwebapp

6 Pour afficher vos clés Cosmos DB, modifiez le fichier de configuration avec la clé
d'accès et l'URI de la base de données que vous avez copiées dans l'exercice
« Essayez dès maintenant » précédent :
nano config.js

7 Écrivez le fichier en appuyant sur Ctrl-O, puis quittez en appuyant sur Ctrl-X.
8 Ajoutez et validez vos modifications dans Git avec la commande suivante :
git init && git add . && git commit -m "Pizza"
 Exercice pratique : déploiement d'une application Web qui utilise Cosmos DB 157

9 Créez un lien vers le nouveau référentiel Git dans votre emplacement de test
avec git remote add azure, suivi de votre URL de déploiement Git.
10 Utilisez la commande git push azure master pour pousser vos modifications
sur votre application Web.
11 Sélectionnez l'URL de votre application Web à partir de la fenêtre Vue d'ensem-
ble du portail Azure.
12 Ouvrez l'URL dans un navigateur Web pour consulter votre pizzéria, à présent
gérée par Cosmos DB, comme illustré à la figure 10.12.

Figure 10.12  L'application Web Azure de base affiche votre carte des pizzas succincte,
en se basant sur les données de la base Cosmos DB. La pizzeria des chapitres précédents
est affichée, mais la liste des pizzas et leurs prix sont désormais optimisés par Cosmos
DB. Le site reste néanmoins basique, l’objectif étant d'observer le service en action et de
comprendre comment commencer à créer vos propres applications.
 11
Gestion du trafic réseau et
du routage

La résolution DNS (service de noms de domaine) est au cœur de presque toutes les
connexions numériques que vous effectuez. C’est comme ça que vous naviguez sur le
Web, recevez des e-mails, regardez Netflix et appelez avec Skype. DNS est le mécanisme
qui convertit un nom, comme manning.com par exemple, en adresse IP. Quand je
veux apprendre de nouvelles choses, je n’ai pas besoin de me rappeler 35.166.24.88 :
je rentre simplement manning.com dans un navigateur Web et je parcoure quelques
livres  ! Les périphériques réseau acheminent le trafic en fonction des adresses IP,
donc vous avez besoin d’une approche qui aide ceux d’entre nous qui ont une
mauvaise mémoire à faire des choses comme acheter des livres ou des pizzas en ligne.
Au cours des derniers chapitres, nous avons passé beaucoup de temps à apprendre
comment créer des applications évolutives, hautement disponibles et distribuées dans le
monde entier. Une des dernières pièces manquantes est de savoir comment orienter les
clients du monde entier vers l’instance d’application la plus appropriée, généralement
celle qui est la plus proche d’eux. Azure Traffic Manager facilite le routage automatique
des clients vers vos instances d’application en fonction de la performance ou de
l’emplacement géographique. Dans ce chapitre, nous abordons la façon dont vous
pouvez créer et gérer des zones DNS dans Azure, puis comment utiliser Traffic Manager
pour orienter les clients avec des requêtes DNS, comme illustré à la figure 11.1.

11.1 Qu’est-ce qu’Azure DNS ?

Vous n’avez pas besoin de comprendre en profondeur comment le DNS fonctionne
pour suivre ce chapitre jusqu’au bout et utiliser Azure DNS. La figure 11.2 donne
un aperçu général de la façon dont un utilisateur interroge un service DNS pour
obtenir l’adresse IP d’une application Web. Un grand nombre de sous-étapes
pourraient se produire aux étapes 1 et 2, donc s’il vous reste un peu de temps de
pause déjeuner à la fin de ce chapitre, n’hésitez pas à vous intéresser à la façon dont
les requêtes et la récursivité DNS fonctionnent.

158
 Qu’est-ce qu’Azure DNS ? 159

Client
Londres

Internet

Client acheminé vers

Azure Traffic l'instance d'application
Manager la plus appropriée en
Requêtes DNS pour localiser
fonction des réponses
la cible appropriée en fonction
DNS de Traffic Manager
de l'emplacement du client
et de la méthode de routage

Régions Azure
Zone Azure DNS
azuremol.com Région Est Région Europe
des États-Unis de l'Ouest

eastus.azuremol.com westeurope.azuremol.com
VM Web 1 VM Web 2
53.17.91.8 102.42.9.67
A 53.17.91.8 A 102.42.9.67

Figure 11.1  Dans ce chapitre, nous examinerons comment vous pouvez créer des zones DNS dans Azure DNS.
Pour minimiser la latence et améliorer les temps de réponse, Traffic Manager peut ensuite être utilisé pour
formuler des requêtes DNS et orienter les clients vers l’instance d’application la plus proche d’eux.

Azure DNS fonctionne de la même manière que toutes les solutions DNS existantes
que vous pouvez utiliser ou que vous connaissez peut-être. Votre zone et vos
enregistrements sont stockés dans Azure et les serveurs de noms qui répondent aux
requêtes DNS sont répartis à l’échelle mondiale dans les datacenters Azure.

Client

1. Requêtes DNS pour 3. Connexion à l'adresse IP

www.azuremol.com 2. Enregistrement d'hôte
retourné : 53.17.91.8
Infrastructure Azure
Application web
Azure DNS
Figure 11.2  Ce flux
publique de l'application
dans Azure simplifié de trafic DNS
montre comment un
utilisateur envoie une
requête DNS pour www.
azuremol.com à un serveur
DNS, reçoit une réponse
53.17.91.8
qui contient l’adresse IP
associée, puis peut se
connecter à
l’application Web.
160 Chapitre 11  Gestion du trafic réseau et du routage

Azure DNS prend en charge tous les types d’enregistrements que vous attendez de la
part d'une offre de service DNS standard. Les enregistrements IPv4 et IPv6 peuvent
tous deux être créés. Les types d’enregistrement sont les suivants :
¡ A : enregistrements d’hôte IPv4, pour diriger les clients vers vos applications et services
¡ AAAA  : enregistrements d’hôte IPv6 , pour les entreprises dans le coup qui
utilisent IPv6 pour diriger les clients vers leurs applications et services
¡ CNAME : nom canonique ou alias, enregistrements, permettant de fournir un
nom court plus facile à utiliser que le nom d’hôte complet d’un serveur
¡ MX : enregistrements MX (Mail Exchange) pour acheminer le trafic de courrier
électronique vers vos serveurs ou votre fournis seur de messagerie
¡ NS  : enregistrements du serveur de noms, qui incluent les enregistrements
générés automatiquement pour les serveurs de noms Azure
¡ PTR : enregistrements du pointeur, pour les requêtes DNS inversées afin de faire
correspondre les adresses IP aux nom s d’hôtes
¡ SOA : enregistrements de sources de noms , qui incluent les
enregistrements générés automatiquement pour les serveurs de noms Azure
¡ SRV : enregistrements du service, pour permettre de révéler les services réseau,
utilisés par exemple en matière d'identité
¡ TXT  : enregistrements de chaînes de texte, notamment pour le SPF (Sender
Protection Framework) ou le DKIM (DomainKeys Identified Mail)
Dans une configuration DNS typique, vous configurez plusieurs serveurs DNS. Même
avec la distribution géographique de ces serveurs à des fins de redondance, les clients
peuvent interroger un serveur de nom de l’autre côté du monde. Ces millisecondes
nécessaires pour interroger, résoudre, puis solliciter une réponse pour l'application
Web peuvent s’additionner lorsque vous avez beaucoup de clients qui veulent
commander des pizzas.
Une zone Azure DNS est répliquée à l’échelle mondiale parmi les datacenters Azure.
Le réseau Anycast garantit que lorsqu’un client effectue une requête DNS vers votre
domaine, le serveur de nom disponible le plus proche réponde à sa demande. Comment
le routage anycast fait-il cela ? En général, une seule adresse IP est communiquée dans
plusieurs régions à la fois. Plutôt que d'utiliser une simple requête DNS qui résout une
adresse IP unique n’existant qu’à un seul emplacement, le routage anycast permet à
l’infrastructure réseau de déterminer intelligemment l’emplacement d’une requête et
d’acheminer le client vers la région déclarée la plus proche. Ce routage permet à vos
clients de se connecter à votre application Web plus rapidement et offre une meilleure
expérience client dans l’ensemble.
Vous n’avez pas besoin d’être un expert en réseau pour bien comprendre comment
cela fonctionne : Azure le gère pour vous ! Lorsque vous combinez Azure DNS avec
Azure Traffic Manager (section 11.2), non seulement vous renvoyez des requêtes DNS à
partir des serveurs de noms les plus proches, mais vous connectez également les clients
à l’instance d’application la plus proche. Faites que ces millisecondes comptent !

11.2 Délégation d’un domaine réel à Azure DNS

Lorsque vous enregistrez un domaine réel, votre fournisseur vous fournit une interface
de gestion et des outils pour gérer ce domaine. Pour permettre aux clients d’accéder à
vos services et d’utiliser les enregistrements ainsi que la zone Azure DNS, vous déléguez
 Délégation d’un domaine réel à Azure DNS 161

l’autorité de votre domaine aux serveurs de noms Azure. Grâce à cette délégation
toutes les requêtes DNS sont immédiatement dirigées vers ces serveurs de noms Azure,
comme illustré à la figure 11.3. Azure ne vous permet pas actuellement d’acheter et
d’enregistrer des domaines dans la plateforme. Vous devez donc acheter le nom de
domaine via un registrar externe, puis pointer les enregistrements NS sur les serveurs
de noms Azure.
Fournisseur configuré avec
des serveurs de noms Azure
pour déléguer votre
domaine à Azure DNS
ns1.azure-dns.com.
Fournisseur de
nom de domaine
Zone DNS
NS ns1.azure-dns.com.
Client NS ns2.azure-dns.net.
Requête DNS Le fournisseur Enregistrement d'hôte
pour votre NS ns3.azure-dns.org.
transmet toutes
domaine NS ns4.azure-dns.info. les requêtes www A 53.17.91.8
à Azure DNS

Figure 11.3  Pour déléguer votre domaine à Azure, configurez votre fournisseur de domaine actuel avec
les adresses de serveur de nom Azure. Lorsqu’un client effectue une requête DNS pour votre domaine,
les requêtes sont envoyées directement aux serveurs de noms Azure de votre zone.

Pourquoi déléguer votre DNS à Azure ? Pour simplifier la gestion et les opérations.
Qu’il s’agisse de créer des services supplémentaires, d’ajuster la configuration de
l’équilibreur de charge ou d’améliorer les temps de réponse avec un DNS répliqué
dans le monde entier, l’interface de gestion unique fournie par Azure permet
d’effectuer ces tâches. Lorsque vos zones DNS sont hébergées dans Azure, vous pouvez
également installer certaines des fonctionnalités de sécurité de Ressource  Manager
décrites dans le chapitre 6. Ces fonctionnalités comprennent, par exemple, le contrôle
d’accès en fonction du rôle (RBAC) pour limiter et auditer l’accès aux zones DNS,
ainsi que les verrous de ressources pour empêcher la suppression accidentelle, voire
malveillante, d'une zone.
La plupart des bureaux d’enregistrement de domaines fournissent des interfaces et
des contrôles plutôt basiques pour gérer les zones et les enregistrements DNS. Pour
réduire la surcharge de gestion et améliorer la sécurité, Azure  DNS vous permet
d’utiliser la CLI Azure, Azure PowerShell ou les API REST pour ajouter ou modifier des
enregistrements. Les équipes opérationnelles peuvent utiliser les mêmes outils et
workflows pour intégrer de nouveaux services. Si des problèmes apparaissent, il est
souvent plus facile de les dépanner lorsque vous pouvez vérifier que le DNS fonctionne
comme prévu sans qu’un fournisseur DNS tiers constitue une variable supplémentaire.
Donc, si vous êtes convaincu qu’il est logique de déléguer votre domaine à
Azure DNS, vers quel serveur de nom Azure devez-vous faire pointer votre domaine ? Si
vous créez une zone Azure DNS, les serveurs de noms sont répertoriés dans le portail,
comme illustré à la figure 11.4. Vous pouvez également accéder à ces adresses de serveur
de nom avec la CLI Azure ou Azure PowerShell.
Il n’y a pas d’exercice «  Essayez dès maintenant  » pour ces dernières pages car,
à  moins que vous n’achetiez et configuriez un domaine réel, vous ne pourrez
pas tester la méthode pour acheminer le trafic
162 Chapitre 11  Gestion du trafic réseau et du routage

Figure 11.4  Vous pouvez afficher les serveurs de nom Azure pour votre zone DNS dans le portail Azure,
la CLI Azure ou Azure PowerShell.

réel. Vous pouvez créer une zone Azure DNS sans domaine réel, mais aucun trafic ne
peut y être acheminé. Dans la réalité, vous mettez à jour les enregistrements NS avec
votre fournisseur actuel pour pointer toutes les requêtes concernant votre domaine
vers les serveurs de nom Azure. Cela peut prendre de 24 à 48  heures (mais
généralement beaucoup moins) pour que la délégation de votre domaine se propage
dans toute la hiérarchie DNS mondiale. Il convient donc de l’anticiper  : ce
comportement peut causer de brèves interruptions pour les clients qui accèdent à
votre application.

11.3 Routage mondial et résolution avec Traffic Manager

Dans les chapitres précédents, vous avez appris des informations sur les applications
hautement disponibles distribuées dans le monde entier. Le but ultime est d’avoir
plusieurs instances de machine virtuelle ou d’application Web, dans différentes régions
ou différents continents, qui se connectent à une instance Cosmos  DB près d’elles.
Mais comment faire pour que vos clients se connectent à la machine virtuelle ou
l’application Web, exécutant votre application, la plus proche ?
Azure Traffic Manager est un service réseau qui fonctionne comme une destination
centrale pour vos clients. Nous allons utiliser l’exemple d’une application Web disponible
à l’adresse www.azuremol.com. La figure 11.5 offre une vue d’ensemble de la façon dont
Traffic Manager achemine les utilisateurs vers l’application disponible la plus proche.
2. Résout l'adresse en azuremol.
1. Le client émet une requête trafficmanager.net 3. Interroge Traffic
pour www.azuremol.com Manager pour le point
de terminaison 4. Traffic Manager examine la
Traffic stratégie de routage, retourne
Client DNS Manager un point de terminaison
6. Résout
5. Point de terminaison
eastus.cloudapp.net
retourné sous forme
en 53.17.91.8
eastus.cloudapp.net
7. Le client se connecte
à une application Web

VM Web est
des États-Unis
53.17.91.8

Figure 11.5  Un client envoie une requête DNS à un service DNS pour www.azuremol.com. Le service DNS transmet
la requête à Traffic Manager, qui renvoie un point de terminaison selon la méthode de routage en cours d’utilisation.
Le point de terminaison est résolu en adresse IP, que le client utilise pour se connecter à l’application Web.
 Routage mondial et résolution avec Traffic Manager 163

Traffic Manager ne joue pas le rôle d’un équilibreur de charge tel que vous l’avez vu au
chapitre 8. Comme l’illustre la figure 11.5, Traffic Manager achemine le trafic vers une
adresse IP publique. Examinons le flux de trafic d’un peu plus près :
1 L’utilisateur effectue une requête DNS pour www.azuremol.com. Son serveur DNS
contacte les serveurs de noms pour azuremol.com (qui pourraient être des serveurs
de noms Azure si vous utilisez Azure DNS !) et demande l’enregistrement pour www.
2 L’hôte www se résout en un enregistrement CNAME qui pointe vers azuremol.
trafficmanager.net.
3 Le service DNS transmet la requête DNS aux serveurs de noms Azure pour
trafficmanager.net.
4 Traffic Manager examine ensuite la demande et détermine un point de
terminaison vers lequel diriger l’utilisateur. L’intégrité et le statut du point de
terminaison sont examinés, comme avec les équilibreurs de charge Azure. La
méthode de routage Traffic  Manager est également vérifiée. Les méthodes de
routage que Traffic Manager peut utiliser sont les suivantes :
¡ Priority (Prioritaire) : contrôle l’ordre d’accès aux points de terminaison
¡ Weighted (Pondéré) : distribue le trafic dans les points de terminaison selon une
métrique de poids qui lui a été assignée
¡ Performance (Performances) : routage basé sur la latence des utilisateurs jusqu’au
point de terminaison afin que l’utilisateur bénéficie du temps de réponse
le plus rapide possible
¡ Geographic (Géographique)  : associe les points de terminaison à une région
géographique et dirige vers eux les utilisateurs en fonction de leur emplacement
5 Le point de terminaison eastus.cloudapp.net est retourné par Traffic Manager
au service DNS.
6 Le service DNS recherche l’enregistrement DNS pour eastus.cloudapp.net et
retourne le résultat de la requête au client.
7 Grâce à l’adresse IP du point de terminaison qu’il a demandé, le client contacte
directement l’application Web. À ce stade, le trafic pourrait atteindre l’adresse IP
publique d’un équilibreur de charge Azure plutôt que d’une machine virtuelle
directement.
Comme vous pouvez le voir, la fonction de Traffic Manager est de déterminer un point
de terminaison pour une application donnée afin d’y diriger les clients. Il existe
quelques contrôles d’intégrité qui surveillent l’état des points de terminaison,
s’apparentant aux sondes d’intégrité des équilibreurs de charge que vous avez étudiés
au chapitre 8. Et vous pouvez définir un mécanisme de routage de trafic prioritaire ou
pondéré pour répartir les utilisateurs sur un ensemble de points de terminaison
disponibles, à nouveau, de façon semblable à un équilibreur de charge. Traffic Manager
dirige généralement le trafic vers un équilibreur de charge ou une passerelle
Application Gateway d’Azure, ou vers un déploiement d’application Web.

Azure Front Door

Traffic Manager, qui fait l'objet de cette section, est idéal pour distribuer et acheminer le
trafic dans le monde entier. Il fonctionne avec n’importe quel type de point de
terminaison Internet, et pas seulement les ressources dans Azure. Le trafic est basé sur
DNS et ne dépend pas de l’application proprement dite.
Si vous avez besoin de distribuer le trafic au niveau de l’application et de la possibilité
d’effectuer un déchargement TLS/SSL ou d'acheminer les requêtes selon HTTP/HTTPS,
Azure Front Door est la solution qu'il vous faut. Traffic Manager
164 Chapitre 11  Gestion du trafic réseau et du routage

(suite)
et Front Door offrent le même type de service et des options de configuration similaires.
Toutefois, Front Door est spécifiquement conçu pour fonctionner au niveau de la couche
d’application. Front Door comporte également des astuces de performances
intéressantes, telles que le fractionnement TCP pour diviser les connexions en petits
segments et réduire la latence.
Au chapitre 8, nous avons examiné les équilibreurs de charge et mentionné Application
Gateway, qui fonctionne au niveau de la couche d’application et se propose des fonctions
comme le déchargement TLS. Ce chapitre se concentre sur les équilibreurs de charge et
vous explique leurs concepts fondamentaux, sur lesquels repose Application Gateway. Il
en est de même ici. Nous nous concentrons sur Traffic Manager dans ce chapitre, même
si bon nombre des mêmes concepts et options de configuration, tels que les options de
routage, sont également disponibles pour Azure Front Door. Comme pour la plupart des
éléments d’Azure, ce qu’il faut utiliser dans chaque service est piloté par les applications
que vous exécutez et leurs besoins.

11.3.1 Création de profils sur Traffic Manager

Traffic Manager utilise des profils pour déterminer la méthode de routage à utiliser et
les points de terminaison associés pour une demande donnée. Pour poursuivre sur le
thème d’une application distribuée dans le monde entier abordé aux chapitres
précédents, vous cherchez à ce que vos utilisateurs se servent de l’application Web la
plus proche d’eux. Si vous considérez à nouveau les méthodes de routage, deux façons
vous permettent de le faire :
¡ Routage basé sur les performances : le client est acheminé vers le point de terminaison
avec la latence la plus faible, par rapport à la source de la requête. Cette méthode
de routage apporte une certaine intelligence et permet toujours à Traffic Manager
de diriger le client vers un point de terminaison disponible.
¡ Routage géographique : le client est toujours acheminé vers un point de terminaison
donné, en fonction de la source de sa demande. Par exemple, si le client est aux
États-Unis, il est toujours dirigé vers l’est américain. Cette méthode de routage vous
oblige à définir des régions géographiques à associer à chaque point de terminaison.
Lorsque vous utilisez le routage géographique, vous contrôlez un peu plus les points
de terminaison que les clients utilisent. Il peut y avoir des raisons réglementaires qui
imposent que les clients d’un État dans une région donnée utilisent toujours des points
de terminaison dans la même région. Les exercices utilisent des points de terminaison
géographiques pour montrer un exemple plus concret, car il y a une astuce pour le
routage géographique  : vous devez spécifier un profil enfant, et non un point de
terminaison directement.
Le ciel ne vous tombera pas sur la tête si vous utilisez la méthode de routage
géographique avec des points de terminaison, mais la pratique recommandée consiste
à utiliser un autre profil Traffic  Manager pour transmettre le trafic vers le point de
terminaison final. Pourquoi ? Les régions ne peuvent être associées qu’à un seul profil
Traffic  Manager. Dans les chapitres précédents sur la haute disponibilité, vous avez
toujours cherché à vous assurer d’avoir de la redondance. Si vous associez une région à
un point de terminaison donné et que vous utilisez le routage géographique, vous
n’avez alors aucune option de basculement si ce point de terminaison rencontre un
problème ou si vous effectuez une maintenance.
 Routage mondial et résolution avec Traffic Manager 165

Au lieu de cela, les profils enfants imbriqués vous permettent de définir une priorité
qui dirige toujours le trafic vers un point de terminaison intègre. Si le point de terminaison
n’est pas intègre, le trafic passe à un autre point de terminaison.int. La figure 11.6 montre
que le trafic bascule vers une autre région, même si vous pouvez également créer plusieurs
instances d’application Web dans la région Ouest des États-Unis et utiliser une méthode
de routage pondérée sur le profil enfant. Lorsque vous commencez à augmenter le
nombre d’instances de votre environnement d’application, prenez le temps de réfléchir
à la meilleure façon de fournir une haute disponibilité aux points de terminaison derrière
Traffic Manager. Pour ces exemples, vous créerez un basculement entre les régions pour
voir clairement les différences de comportement.

Profil avec la
méthode de routage
géographique

Est des États-Unis Europe de l’Ouest

Profil enfant avec Profil enfant avec
la méthode de la méthode de
routage prioritaire routage prioritaire

Application Web Application Web Application Web Application Web

Est des États-Unis Europe de l’Ouest Est des États-Unis Europe de l’Ouest
priorité 1 priorité 100 priorité 100 priorité 1

Figure 11.6  Un profil Traffic Manager parent configuré avec la méthode de routage géographique doit
utiliser des profils enfants qui contiennent plusieurs points de terminaison. Ces points de terminaison
enfants peuvent ensuite utiliser le routage prioritaire pour toujours diriger le trafic vers le point de
terminaison préféré. Par exemple, le profil enfant « Est des États-Unis » envoie toujours le trafic vers le
point de terminaison situé dans la région Est des États-Unis, à condition que le point de terminaison soit
intègre. Si le point de terminaison n’est pas intègre, le trafic est ensuite dirigé vers la région Europe de
l’Ouest. Sans ce profil enfant, les clients de l’Est des États-Unis ne pourraient pas basculer vers un autre
point de terminaison et ne pourraient pas accéder à votre application Web.

Tester
Pour créer les profils Traffic Manager pour votre application distribuée, procédez comme suit.
Le reste des exercices utilisent les régions de l’Est des États-Unis et de l’Europe de
l’Ouest. Si vous ne vivez pas dans l’une de ces régions, choisissez une autre région plus
appropriée. N’oubliez tout simplement pas d’être cohérent tout au long des exercices !
L’exercice pratique de fin de chapitre montre comment tout cela s’imbrique et fonctionne
ensemble, mais vous ne serez pas correctement dirigé vers vos applications Web si
vous vivez en dehors de l’Amérique du Nord ou de l’Europe et que vous ne changez pas
les régions en conséquence.

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell en haut du tableau
de bord.
2 Créez un groupe de ressources, en spécifiant un nom de groupe de ressources,
par exemple azuremolchapter11, et un emplacement, par exemple eastus :
166 Chapitre 11  Gestion du trafic réseau et du routage

az group create --name azuremolchapter11 --location eastus

3 Créez le profil Traffic Manager parent. Choisissez d’utiliser la méthode

de routage géographique, puis spécifiez un nom, par exemple azuremol.
Le paramètre de nom DNS vous indique qu’il doit être unique, fournissez
donc un nom unique. Le domaine suivant crée le nom d’hôte
azuremol.trafficmanager.net, que vous allez utiliser pour configurer les applica-
tions Web dans l’exercice pratique à la fin du chapitre :
az network traffic-manager profile create \
--resource-group azuremolchapter11 \
--name azuremol \
--routing-method geographic \
--unique-dns-name azuremol

4 Créez l’un des profils Traffic Manager enfants. Cette fois, utilisez la méthode de
routage prioritaire et le nom eastus, et spécifiez un autre nom DNS unique, par
exemple azuremoleastus :
az network traffic-manager profile create \
--resource-group azuremolchapter11 \
--name eastus \
--routing-method priority \
--unique-dns-name azuremoleastus

5 Créez un autre profil Traffic Manager enfant avec le nom westeurope et un autre

nom DNS unique, par exemple azuremolwesteurope :
az network traffic-manager profile create \
--resource-group azuremolchapter11 \
--name westeurope \
--routing-method priority \
--unique-dns-name azuremolwesteurope

6 Vous avez créé à plusieurs reprises une application Web maintenant, utilisez
donc utiliser la CLI pour créer rapidement deux plans de service d’application
et une application Web dans chaque plan. L’une de ces applications Web est  dans
l’Est des États-Unis, l’autre en Europe de l’Ouest. Dans l’exercice pratique de fin
de chapitre, vous téléchargerez des exemples de pages Web dans ces applications
Web, donc pour l’instant il vous suffit de créer les sites vides et les tenir prêts
à  utiliser un référentiel Git local.
Créez l’application Web dans l’Est des États-Unis comme suit :
az appservice plan create \
--resource-group azuremolchapter11 \
--name appserviceeastus \
--location eastus \
--sku S1
az webapp create \
--resource-group azuremolchapter11 \
--name azuremoleastus \
--plan appserviceeastus \
--deployment-local-git
 Routage mondial et résolution avec Traffic Manager 167

7 Créez une deuxième application Web dans la région Europe de l’Ouest :

az appservice plan create \
--resource-group azuremolchapter11 \
--name appservicewesteurope \
--location westeurope \
--sku S1
az webapp create \
--resource-group azuremolchapter11 \
--name azuremolwesteurope \
--plan appservicewesteurope \
--deployment-local-git

11.3.2 Distribution du trafic vers l’instance la plus proche à l’échelle mondiale

Vous avez créé les points de terminaison et les profils Traffic  Manager, mais aucun
trafic ne peut circuler. Si les clients étaient dirigés vers les profils, il n’y aurait aucune
association avec vos points de terminaison. Le diagramme de la figure  11.7 illustre
comment vous devez associer un point de terminaison à des profils.

Profil avec la
méthode de routage
géographique

Est des États-Unis Europe de l’Ouest

Profil enfant avec la Profil enfant avec
méthode de routage la méthode de
prioritaire routage prioritaire

Application Web Application Web Application Web Application Web

Asie de l’Est Europe de Asie de l’Est Europe de
Priorité 1 l’Ouest Priorité 100 l’Ouest
Priorité 100 Priorité 1

Figure 11.7  Dans cette section, vous associerez vos points de terminaison aux profils Traffic Manager
et définirez la priorité du trafic à distribuer.

Les premières associations que vous effectuez concernent vos points de terminaison
d’application Web. N’oubliez pas que pour une haute disponibilité, vous souhaitez que
les deux applications Web soient disponibles pour chaque profil Traffic Manager. Vous
utilisez une méthode de routage prioritaire pour diriger tout le trafic vers l’application
Web principale pour chaque profil. Si cette application Web n’est pas disponible, le
trafic peut basculer vers le point de terminaison de l’application Web secondaire.
Lorsque vous avez créé les profils Traffic Manager dans la section 11.3.1, quelques
valeurs par défaut ont été utilisées pour les options de contrôle d’intégrité et de
surveillance de point de terminaison. Voyons de plus près quelles sont ces options :
¡ Durée de vie (TTL) du DNS  : 30  secondes  : définit la durée pendant laquelle les
réponses DNS de Traffic Manager peuvent être mises en cache. Une durée de vie
courte garantit que le trafic client est acheminé correctement lorsque des mises à
jour de la configuration de Traffic Manager sont effectuées.
168 Chapitre 11  Gestion du trafic réseau et du routage

¡ Protocole : HTTP : pour la surveillance des points terminaux, vous pouvez également
choisir le protocole HTTPS ou une vérification TCP de base. Comme pour les
équilibreurs de charge, le HTTP ou le HTTPS garantissent qu’une réponse
HTTP 200 OK est retournée par chaque point de terminaison.
¡ Port : 80 : le port à vérifier sur chaque point de terminaison.
¡ Chemin d’accès : / : par défaut, vérifie la racine du point de terminaison, mais vous
pouvez également configurer une page personnalisée, comme la page de contrôle
de l’intégrité utilisée par les équilibreurs de charge.
¡ Intervalle de sondage : 30 secondes : fréquence de contrôle de l’intégrité des points
de terminaison. La valeur peut être de 10 ou de 30 secondes. Pour effectuer une
détection rapide toutes les 10 secondes, des frais supplémentaires sont appliqués
par point de terminaison.
¡ Nombre d’échecs tolérés : 3 : nombre d'occurrences d'échec d'un point de terminaison
à un contrôle d’intégralité avant que le point de terminaison ne soit marqué
comme non disponible.
¡ Délai d’expiration de la sonde : 10 secondes : durée qui s’écoule avant qu’une sonde
ne soit marquée comme étant en échec et que le point de terminaison ne fasse de
nouveau l'objet d'une détection.
Vous n’avez pas besoin de modifier l’une de ces options par défaut. Lorsque vous
construisez vos propres environnements d’application dans le monde réel, vous pouvez
réduire le nombre de défaillances à tolérer ou l’intervalle de détection pour les charges
de travail stratégiques. Ces modifications garantiraient que tous les problèmes
d’intégrité soient détectés rapidement et que le trafic soit acheminé plus tôt vers un
point de terminaison différent.

Tester
Pour associer des points de terminaison à des profils et mettre fin au routage
géographique, procédez comme suit :

1 Sur le portail Azure, accédez à votre groupe de ressources et sélectionnez-le.

Pour cet exercice, sélectionnez le profil Traffic Manager que vous avez créé pour
l’Est des États-Unis.
2 Choisissez les points de terminaison dans la barre de navigation à gauche du
profil, puis sélectionnez Ajouter.
3 Créez un point de terminaison Azure, puis saisissez un nom, par exemple eastus.
4 Il existe différents types de ressources cibles, et c'est App Service qu'il faut utiliser.
Sélectionnez votre application Web pour la ressource cible, sous une forme de
type azuremoleastus, dans la région Est des États-Unis.
5 Laissez la priorité définie sur 1, acceptez les autres valeurs par défaut, puis
sélectionnez OK.
6 Répétez le processus pour ajouter un autre point de terminaison. Cette fois,
nommez le point de terminaison westeurope, sélectionnez votre application
Web dans la région Europe de l’Ouest comme ressource cible et
définissez une priorité de 100.
Votre profil Traffic  Manager répertorie maintenant deux points de
terminaison  : un pour l’application Web dans l’Est des États-Unis et un pour
l’application Web en Europe de l’Ouest, comme illustré à la figure  11.8.
Ce routage des points de terminaison basé sur les priorités dirige toujours le trafic
vers l’application Web dans l’Est des États-Unis lorsque cette ressource est intègre.
Si cette ressource n’est pas disponible, il y a redondance pour basculer vers
l’application Web en Europe de l’Ouest.
 Routage mondial et résolution avec Traffic Manager 169

Figure 11.8  Deux points de terminaison sont répertoriés pour le profil Traffic Manager. Le point de terminaison
pour l’Est des États-Unis a la priorité inférieure, de sorte qu’il reçoit toujours le trafic lorsqu’il est intègre. La
redondance est assurée avec le point de terminaison de l’Europe de l’Ouest, qui n’est utilisé que lorsque le point de
terminaison dans l’Est des États-Unis n’est pas disponible.

7 Revenez à votre groupe de ressources et sélectionnez le profil Traffic Manager

pour l’Europe de l’Ouest.
8 Choisissez d’ajouter des points de terminaison.
9 Répétez les étapes pour ajouter deux points de terminaison et configurez-les
comme suit :
¡ Nom : westeurope
Ressource cible : application Web en Europe de l’ouest
Priorité : 1
¡ Nom : eastus
Ressource cible : application Web dans l’Est des États-Unis
Priorité : 100
Votre profil Traffic Manager répertorie maintenant deux points de terminaison : un
pour l’application Web en l’Europe de l’Ouest et un pour l’application Web dans l’Est
des États-Unis, comme illustré à la figure 11.9. Vous avez fourni la même redondance
que dans le profil Traffic Manager précédent, avec cette fois l'ensemble du trafic dirigé
vers l’Europe de l’Ouest quand le point de terminaison est intègre et à l’Est des
États-Unis quand il ne l'est pas.

Figure 11.9  La même configuration des points de terminaison que dans le précédent profil Traffic Manager, mais
cette fois l’emplacement des applications Web est inversé. Ces profils enfants peuvent être utilisés pour
acheminer les clients vers l’application Web soit dans l’Est des États-Unis, soit en Europe de l’Ouest, mais vous
avez maintenant une redondance pour basculer vers un autre point de terminaison quand le point de terminaison
principal dans la région n’est pas disponible.
170 Chapitre 11  Gestion du trafic réseau et du routage

Plus qu’une seule étape, je vous le promets ! Rappelez-vous que c’est une bonne
pratique pour la haute disponibilité que d'utiliser Traffic Manager pour la distribution
d’applications à l’échelle mondiale. Dans la réalité, votre environnement n’est
peut-être pas aussi complexe. Examinons à nouveau le diagramme pour voir les profils
enfants et les associations avec les applications Web régionales que vous devez créer,
comme illustré à la figure 11.10.

Profil avec la
méthode de routage
géographique

Est des États-Unis Europe de l’Ouest

Profil enfant avec la Profil enfant avec la
méthode de routage méthode de routage
prioritaire prioritaire

Application Web Application Web Application Web Application Web

Est des États-Unis Europe de l’Ouest Est des États-Unis Europe de l’Ouest
priorité 1 priorité 100 priorité 100 priorité 1

Figure 11.10  Les profils Traffic Manager enfants pour l’Est des États-Unis et l’Europe de l’Ouest
ont été créés, avec les applications Web régionales et les priorités configurées selon les besoins.
Vous devez maintenant associer les profils enfants au profil parent.

Pour diriger le trafic en fonction de la géographie, vous définissez une région, telle
que l’Amérique du Nord, et un profil imbriqué, par exemple eastus. Tous les clients
dans la région de l’Amérique du Nord sont dirigés vers ce profil enfant. Vous avez
configuré les priorités sur cet enfant de manière à ce que l’application Web située dans
la région Est des États-Unis desserve toujours le trafic. Mais vous avez fourni une option
redondante pour basculer vers l’application Web en Europe de l’Ouest si besoin.
L’inverse se produit pour les clients en Europe de l’Ouest. Un autre point de
terminaison pour le profil Traffic  Manager parent peut être ajouté, cette fois avec
l’Europe comme région à associer au point de terminaison, puis le profil imbriqué
westeurope. L'ensemble du trafic européen est acheminé vers ce profil et l’application
Web en Europe de l’Ouest dessert toujours l’application Web. En cas de problème, le
trafic peut basculer vers l’Est des États-Unis.
Si vous êtes soumis à des mandats de souveraineté politiques ou de données tels que
le trafic ne peut pas basculer vers une autre région, vous devrez peut-être ajuster la
façon dont les points de terminaison et les profils Traffic Manager sont configurés. Vous
pouvez, par exemple, créer plusieurs applications Web en Europe de l’Ouest, comme
 Routage mondial et résolution avec Traffic Manager 171

vous l’avez vu au chapitre 9. De cette façon, plusieurs instances de l’application Web

peuvent desservir les clients. Ou, si votre application s’exécute sur des machines
virtuelles, utilisez un VMSS derrière un équilibreur de charge pour profiler une
redondance similaire.

Tester
C’est là que votre propre emplacement régional importe ! Si vous vivez en dehors de l’un
des groupements régionaux indiqués dans les profils Traffic Manager, assurez-vous que
vous sélectionnez votre propre région, faute de ne pouvoir accéder à l’application Web
dans l’exercice pratique de fin de chapitre.
Pour associer les profils enfants au profil parent, procédez comme suit :

1 Sur le portail Azure, accédez à votre groupe de ressources et sélectionnez-le.

2 Sélectionnez le profil Traffic Manager parent. Dans les exemples précédents, il
s’appelait azuremol.
3 Choisissez les points de terminaison dans la barre de navigation à gauche du
profil, puis sélectionnez Ajouter.
4 Créez un point de terminaison qui utilise le premier profil enfant. Définissez le
point de terminaison imbriqué en tant que type et indiquez un nom, par exemple
eastus. Sélectionnez le profil Traffic Manager que vous avez créé pour l’Est des
États-Unis en tant que ressource cible.
5 Sous Regroupement régional, choisissez Amérique du Nord/Amérique centrale/
Caraïbes dans le menu déroulant, puis sélectionnez OK.
6 Répétez les étapes pour ajouter un autre point de terminaison. Cette fois,
nommez le point de terminaison « westeurope », définissez la ressource cible sur
le profil Traffic Manager enfant pour l’Europe de l’Ouest, puis choisissez Europe
dans le menu déroulant du regroupement régional.
Vos points de terminaison pour le profil parent répertorient maintenant les
deux profils enfants, dont chacun présente un point de terminaison associé à la
région géographique appropriée, comme illustré à la figure 11.11.

Figure 11.11  Profils enfants imbriqués avec des régions géographiques associées. Ce profil Traffic Manager
parent dirige l'ensemble du trafic d’Europe vers l’application Web dans la région Europe de l’Ouest, avec une
redondance pour utiliser l’Est des États-Unis en cas de problème. L’inverse est vrai pour les clients d’Amérique du
Nord, d’Amérique centrale et des Caraïbes.
172 Chapitre 11  Gestion du trafic réseau et du routage

Les applications Web sont actuellement configurées pour accepter

uniquement le trafic sur leur domaine par défaut, qui se présente sous la forme
webappname.azurewebsites.net. Lorsque Traffic Manager dirige les clients vers ces
instances de l’application Web, le trafic semble provenir du domaine du profil
parent, par exemple azuremol.trafficmanager.net. Les applications Web ne
reconnaissant pas ce domaine, l’application Web ne se charge donc pas.
7 Ajoutez le domaine du profil Traffic  Manager parent aux deux instances de
l’application Web que vous avez créées dans les étapes 4 à 6. Si nécessaire, vous
pouvez trouver le nom de domaine dans la page de Présentation du profil
Traffic Manager parent :
az webapp config hostname add \
--resource-group azuremolchapter11 \
--webapp-name azuremoleastus \
--hostname azuremol.trafficmanager.net
az webapp config hostname add \
--resource-group azuremolchapter11 \
--webapp-name azuremolwesteurope \
--hostname azuremol.trafficmanager.net

Lorsque vous ouvrez l’adresse de votre profil Traffic  Manager parent, telle que
https://azuremol.trafficmanager.net, you can’t tell which endpoint you access, as both
web apps run the same default web page. Dans l’exercice pratique de fin de chapitre,
vous téléchargez une page Web basique dans chaque application Web pour les
différencier !
Arrêtons-nous un instant pour examiner ce que vous avez créé à travers ces exercices.
C’est important, car les clients peuvent désormais utiliser toutes les fonctionnalités de
haute disponibilité et de redondance des chapitres précédents, avec le routage
automatique du trafic qui les dirige vers l’instance la plus proche de votre application
Web. Dans ce chapitre, vous avez créé les éléments suivants :
¡ Une application Web dans la région Est des États-Unis et une autre dans Europe
de l’Ouest
¡ Les profils Traffic Manager qui utilisent le routage géographique pour diriger tous les
clients en Amérique du Nord et centrale vers l’application Web dans l’Est des
États-Unis, et tous les clients en Europe vers l’application Web de l’Europe de l’Ouest.
¡ Des stratégies Traffic  Manager enfants avec routage prioritaire, pour basculer
vers la région alternative et l’utiliser, au cas où l’application Web principale de la
région n’est pas disponible
En termes de haute disponibilité :
¡ Si vous combinez cette configuration avec des applications Web qui
se dimensionnent automatiquement, vous avez alors une foule de redondance.
¡ Si vous combinez ces applications Web avec Cosmos  DB, toute votre
application est maintenant automatiquement dimensionnée et distribuée dans le
monde entier. De plus vos clients accèdent toujours aux ressources proches d’eux
pour la latence la plus faible en matière de temps de réponse et
de meilleures performances.
¡ Même si vous êtes bloqué avec des machines virtuelles, vous pouvez utiliser des
VMMS avec des équilibreurs de charge pour fournir le même environnement
hautement disponible et distribué partout dans le monde.
 Routage mondial et résolution avec Traffic Manager 173

Et oui, vous pouvez remplacer Traffic Manager par Front Door si vous avez besoin
d’utiliser des fonctions avancées de gestion du trafic au niveau de l’application.
Je sais que les derniers chapitres contiennent beaucoup de nouvelles informations,
et que chaque chapitre a monopolisé une bonne partie de votre pause déjeuner tous les
jours  ! Mais regardez ce que vous avez accompli depuis la semaine dernière. Vous
pouvez maintenant créer une application Web avec des
machines virtuelles en IaaS ou des applications Web en PaaS, la rendre hautement
disponible et à charge équilibrée, et la laisser se dimensionner automatiquement
(figure  11.12). Vous pouvez utiliser un back-end Cosmos  DB distribué à l’échelle
mondiale pour vos besoins de base de données, et vous pouvez acheminer
automatiquement les clients vers l’instance régionale la plus proche de votre
application, le tout avec un DNS hébergé dans Azure.

Client

Internet

Azure Traffic
Azure DNS
Manager

Solution PaaS Azure Solution IaaS Azure

Est des États-Unis Europe de l’Ouest Est des États-Unis 2 Europe de l’Ouest
Mise à l’échelle Zones de disponibilité Zones de disponibilité
Mise à l’échelle
automatique automatique ou Équilibreur de charge Équilibreur de charge
de l’app Web de l’app Web
VMSS VMSS

Cosmos DB

Figure 11.12 Après avoir lu ces derniers chapitres, vous devez pouvoir comprendre comment créer dans Azure des
applications hautement disponibles, IaaS ou PaaS. Les solutions IaaS peuvent utiliser des zones de disponibilité,
des équilibreurs de charge et des VMSS. Les solutions PaaS peuvent utiliser le dimensionnement automatique des
applications Web et Cosmos DB. Traffic Manager et Azure DNS peuvent acheminer automatiquement les clients
vers l’instance d’application la plus appropriée, en fonction de leur emplacement géographique.

L’exercice pratique de fin de chapitre télécharge quelques sites Web de base dans vos
applications Web, juste pour démontrer que Traffic  Manager fonctionne et que le
point de terminaison approprié dessert votre trafic. Si vous avez le temps, n’hésitez pas
à terminer l’exercice ; sinon, félicitez-vous et allez faire une sieste. Je ne le dirai pas à
votre patron !
174 Chapitre 11  Gestion du trafic réseau et du routage

Nous avons encore un chapitre dans cette deuxième section du livre ; il parle de la
façon de s’assurer que vos applications restent intègres  : comment surveiller et
dépanner vos applications et l’infrastructure.

11.4 Exercice pratique : Déploiement d’application Web

pour voir Traffic Manager à l’œuvre
Voilà encore un chapitre dans lequel nous avons abordé beaucoup de choses. Cet
exercice devrait donc vous permettre de continuer à renforcer vos compétences Azure
liées aux applications Web. Dans le référentiel GitHub contenant les échantillons
d’Azur il y a deux pages Web basiques pour une application de pizzeria en ligne. Le
titre de chaque page Web indique l’emplacement de l’application Web. Téléchargez
ces pages Web dans l’instance d’application Web appropriée pour voir votre flux
Traffic Manager à l’œuvre :

1 Si nécessaire, clonez le référentiel d’exemples GitHub dans votre Cloud  Shell

comme suit :
git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

2 Commencez par la page Web eastus, puis répétez les étapes suivantes dans le
répertoire westeurope :
cd ~/azure-mol-samples-2nd-ed/11/eastus

3 Initialisez le référentiel Git et ajoutez la page Web basique :

git init && git add . && git commit -m "Pizza"

4 Dans le portail Azure, la fenêtre Vue d'ensemble de votre application  Web a

répertorié l'URL du clone Git. Copiez cette l’URL, puis définissez-la comme
destination pour votre exemple de site HTML dans Cloud Shell à l’aide de la
commande suivante :
git remote add eastus <your-git-clone-url>

5 Transférez par push l'exemple de site HTML vers votre application Web :

git push eastus master

6 Répétez ces étapes pour le répertoire azure-mol-samples-2nd-ed/11/westeurope.

7 Une fois que vous avez terminé, ouvrez votre navigateur Web
au nom de domaine de votre profil Traffic Manager parent, par
exemple https://azuremol.trafficmanager.net, to see the traffic flow.
 12
Surveillance et dépannage

Dans les chapitres précédents, vous avez appris à rendre vos applications hautement
disponibles et à acheminer les clients du monde entier vers des instances de
votre application distribuées mondialement. Un des objectifs consistait à minimiser
la quantité d'interactions avec votre infrastructure d'applications et à laisser la
plateforme Azure gérer l'état d'intégrité et les performances à votre place. Il est
parfois encore nécessaire de se retrousser les manches et d'examiner les diagnostics
ou les mesures de performances. Dans ce chapitre, vous allez apprendre à examiner
les diagnostics de démarrage pour une machine virtuelle, à surveiller les mesures de
performances et à résoudre les problèmes de connectivité avec Network Watcher.

12.1 Diagnostics de démarrage des machines virtuelles

Avec les applications Web, vous n'avez qu'à déployer votre code et laisser la
plateforme Azure gérer le reste. Dans le chapitre 3, nous avons passé en revue les
principes de base du dépannage et du diagnostic des problèmes
avec les déploiements d'applications Web. Vous avez appris à consulter les
événements d'application en temps réel pour surveiller les performances. Lorsque
vous travaillez avec des machines virtuelles dans le cloud, il est souvent compliqué
de résoudre un problème quand il vous est impossible de voir physiquement l'écran
de l'ordinateur de la même façon que vous pouvez obtenir des diagnostics de
l'application Web.
Le manque de connectivité représente l'un des problèmes les plus rencontrés
avec les machines virtuelles. Si vous ne pouvez pas vous connecter en SSH ou RDP à
une machine virtuelle, comment pouvez-vous résoudre les problèmes  ? Une des
premières étapes consiste à vérifier si la machine virtuelle fonctionne correctement.
Pour cela, Azure fournit des diagnostics de démarrage des machines virtuelles, dont
des journaux de démarrage ainsi qu'une capture d'écran de la console.

175
176 Chapitre 12  Surveillance et dépannage

Accès interactif à la console de démarrage

Pour certaines situations de dépannage particulières, vous pouvez également
accéder à une console série en direct pour les machines virtuelles dans Azure.
Cette console série permet d'ouvrir des sessions interactives et de résoudre
les problèmes de démarrage. Vous pouvez reconfigurer votre machine virtuelle afin de
corriger les échecs de démarrage ou les problèmes de configuration de services
et d'applications qui l'empêchent de démarrer correctement.
Ce chapitre n'aborde pas les situations spécifiques d'utilisation de la console série, mais
il s'agit d'une ressource utile qui vous permet de vous asseoir virtuellement face à l'écran
d'une machine virtuelle lorsque celle-ci démarre. Vous devez également activer les
diagnostics de démarrage, ces exercices constituent donc des prérequis pour la
console série.

Tester
Pour créer une machine virtuelle et activer les diagnostics de démarrage, procédez
comme suit :

1 Dans le coin supérieur gauche du portail Azure, sélectionnez Créer une

ressource.
2 Recherchez et sélectionnez une image de machine virtuelle Windows Server
2019 Datacenter.
3 Créez un groupe de ressources, ici azuremolchapter12, puis sélectionnez
la région Azure la plus proche de vous.
4 Sélectionnez une taille de machine virtuelle, telle que DS1_v2.
5 Saisissez un nom d’utilisateur pour la machine virtuelle, telle que azuremol,
et   un mot de passe. Le mot de passe doit obligatoirement comporter un
minimum de 12 caractères et doit contenir 3 des éléments suivants : un caractère
minuscule, un caractère majuscule, un nombre et un caractère spécial.
6 Acceptez toutes les options de redondance ou de règles de port entrants.
7 Acceptez les valeurs par défaut des disques et de la mise en réseau. Aucune
modification n'est nécessaire. Ces paramètres doivent vous être familiers maintenant.
Vous n'avez peut-être pas encore vu la section Gestion. L'option diagnostics de
démarrage est activée par défaut, et un compte de stockage est créé, comme
illustré à la figure 12.1.
8 Pour l'instant, n'activez pas l'option diagnostics du système d'exploitation invité.
9 Examinez les paramètres de configuration de la machine virtuelle, puis
sélectionnez Créer.
Étant donné que la création et la configuration de la machine virtuelle prend quelques
minutes, nous allons continuer à examiner les diagnostics de démarrage.
Si vous rencontrez un problème alors que les diagnostics de démarrage
sont  désactivés, il est probable que vous ne puissiez pas démarrer la machine virtuelle
afin d'activer les diagnostics. Il s'agit là du scénario classique de la poule et de l'œuf,
n'est-ce pas  ? Voilà pourquoi les diagnostics de démarrage sont automatiquement
activés pour les machines virtuelles créées dans le portail Azure. Vous devez cependant
activer les diagnostics de démarrage pour Azure PowerShell, la CLI Azure ainsi que
pour les SDK
 Diagnostics de démarrage des machines virtuelles 177

Figure 12.1  Les diagnostics de démarrage sont activés par défaut lorsque vous créez une
machine virtuelle dans le portail Azure. Un compte de stockage est créé, dans lequel sont
stockés les diagnostics de démarrage. Vous examinerez et activerez les diagnostics du système
d'exploitation invité dans un prochain exercice, ne les activez donc pas pour l'instant. Pour une
utilisation en production, je vous conseille d'activer à la fois les diagnostics de démarrage et les
diagnostics du système d'exploitation invité, et cela pour chaque machine virtuelle créée.

spécifiques au langage. Je vous recommande vivement d'activer les diagnostics de

démarrage dès la création de vos machines virtuelles. Prenez l’habitude d’utiliser les
modèles Azure Resource Manager (chapitre 6) ou vos propres scripts de la CLI Azure
ou PowerShell qui activent les diagnostics de démarrage pendant le déploiement.
Il est nécessaire de créer un compte de stockage pour les journaux de démarrage et
les captures d'écran de la console, mais le stockage de ces données vous reviendra
certainement à moins d'un centime par mois, à moins que votre machine virtuelle soit
très active et génère de nombreuses données. La première fois que vous rencontrerez
un problème avec une machine virtuelle et que vous aurez besoin d'accéder aux
diagnostics de démarrage, vous ne regretterez pas d'avoir dépensé cet argent ! Vous
pouvez également utiliser ce compte de stockage pour conserver des journaux et des
mesures de performances supplémentaires au niveau de la machine virtuelle, que nous
étudierons plus en détail dans la section 12.2. Au risque de me répéter, les coûts de
stockage doivent être infimes. Même si l'environnement de votre machine virtuelle
s'agrandit, cet investissement peut se révéler très utile lorsqu'il s'agit
d'intervenir rapidement quand un problème survient.

Tester
Pour consulter les diagnostics de démarrage pour votre machine virtuelle, procédez
comme suit :

1 Sur le portail Azure, depuis le menu situé à gauche, sélectionnez Machines

virtuelles.
2 Choisissez la machine virtuelle que vous avez créée dans l'exercice précédent.
3 Dans la section Support + résolution des problèmes du menu de la machine
virtuelle, choisissez diagnostics de démarrage. Les diagnostics de démarrage et
l'état de la machine virtuelle s'affichent, comme illustré à la figure  12.2. Le
rapport d’intégrité indique si un problème survient au démarrage de la machine
virtuelle, et vous permet d'en déterminer la cause racine.
178 Chapitre 12  Surveillance et dépannage

Figure 12.2  Les diagnostics de démarrage pour un rapport sur l'état d'intégrité et du démarrage
d'une machine virtuelle. Si des erreurs s'affichent, vous devriez être en mesure de les résoudre et d'en
déterminer la cause racine. Vous pouvez également télécharger les journaux depuis le portail pour les
analyser sur votre ordinateur local.

12.2 Mesures de performances et alertes

Une des premières étapes dans la résolution de problèmes consiste à réaliser un
examen des performances. Quelle est la quantité de mémoire disponible, d'UC
consommée et d'activité du disque ?
Lorsque vous développez et testez vos applications dans Azure, je vous conseille
d'enregistrer régulièrement des niveaux de référence des performances. Ils vous
donneront une idée des performances de votre application selon différentes charges.
Pourquoi est-ce important ? Dans trois mois, comment pourrez-vous déterminer si vous
rencontrez des problèmes de performances, si vous ne disposez d'aucunes données
auxquelles comparer les performances actuelles ?
Lorsque vous avez appris à réaliser une mise à l'échelle automatique des applications
au chapitre  9, vous avez utilisé des mesures de performances de base, telles que
l’utilisation de l’UC, afin d'indiquer à la plateforme Azure à quel moment augmenter
ou diminuer le nombre d'instances de votre application. Ces métriques de base vous
donnent seulement un léger aperçu des performances de la machine virtuelle. Pour
obtenir des métriques plus détaillées, vous devez examiner les performances de la
machine virtuelle. Pour ce faire, il faut que vous installiez l’extension Azure Diagnostics.
12.2.1 Consultation des mesures de performances avec l'extension de diagnostic
de machine virtuelle
Azure propose de nombreuses extensions faciles à installer et qui vous permettent
d'ajouter des fonctionnalités à vos machines virtuelles. Ces extensions installent un
petit agent ou un runtime d'application dans la machine virtuelle, qui renvoie ensuite
généralement des informations à la plateforme Azure ou à des solutions tierces. Les
extensions de machine virtuelle peuvent automatiquement configurer et installer des
composants et exécuter des scripts sur vos machines virtuelles.
 Mesures de performances et alertes 179

L'extension de diagnostic de machine virtuelle est couramment utilisée pour

transmettre des mesures de performances depuis l'intérieur de la machine virtuelle
vers un compte de stockage. Ces mesures de performances peuvent ensuite être
analysées dans le portail Azure, ou téléchargées et utilisées dans une solution de
surveillance existante. Vous pouvez utiliser l'extension de diagnostic afin de mieux
comprendre les performances de l'UC et de la consommation de mémoire de la
machine virtuelle, ce qui vous permet généralement d'obtenir un aperçu plus précis et
plus détaillé que l'hôte.

Automatisation et extensions de machine virtuelle

Le chapitre 18 porte sur Azure Automation, qui vous permet d'effectuer certaines tâches
sur vos machines virtuelles de façon planifiée et automatisée. Une des
puissantes fonctionnalités d'Azure Automation est d'agir comme un serveur pull
DSC (configuration d'état souhaité) PowerShell. Le service DSC PowerShell détermine un
état donné de la façon dont doit être configuré un système, les packages à installer, les
fichiers et autorisations, etc. Vous créez des définitions pour la configuration de votre
choix, puis vous les appliquez à des machines virtuelles ou à des serveurs physiques.
Vous pouvez ensuite faire un rapport sur ces stratégies et en assurer la conformité.
L'extension DSC PowerShell Azure est utilisée pour appliquer des configurations DSC,
par exemple à partir d'un serveur pull Azure Automation.
L'extension de script personnalisé Azure fait partie des extensions permettant
d'appliquer des configurations et d'exécuter des scripts sur des machines virtuelles.
Avec l'extension de script personnalisé, vous définissez un ensemble simple de
commandes ou pointez sur un ou plusieurs scripts externes, tels que ceux hébergés
dans Azure Storage ou GitHub. Ces scripts sont capables d'exécuter des tâches de
configuration et d'installation complexes et garantissent que toutes les machines
virtuelles déployées sont configurées de manière cohérente.
L'extension DSC PowerShell Azure et l'extension de script personnalisé sont
couramment utilisées avec des VMSS. Vous appliquez l'une de ces extensions au groupe
VMSS, puis lorsque les instances de machine virtuelle sont créées au sein du groupe,
celles-ci sont automatiquement configurées pour exécuter votre application. Ces extensions
visent à minimiser la configuration manuelle requise des machines virtuelles, car il s'agit d'un
processus pouvant être source d'erreurs et nécessitant une intervention humaine.
Il existe d'autres façons d'automatiser la configuration des machines virtuelles, notamment
les outils Puppet et Chef, qui disposent tous deux d'extensions de machine virtuelle Azure.
Si vous utilisez déjà un outil de gestion de configuration, vérifiez auprès du fournisseur si
celui-ci est compatible pour une utilisation dans Azure. Il y a de grandes chances qu'une
extension de machine virtuelle soit disponible pour vous faciliter la vie.

Tester
Pour activer l'extension de diagnostic de machine virtuelle, procédez comme suit :

1 Sur le portail Azure, depuis le menu situé à gauche, sélectionnez Machines virtuelles.
2 Choisissez la machine virtuelle que vous avez créée dans un exercice précédent.
3 Dans la section Surveillance du menu de la machine virtuelle, choisissez
Paramètres de diagnostic.
4 Pour Activer la supervision d'invités, sélectionnez le bouton.
180 Chapitre 12  Surveillance et dépannage

L'activation de la supervision d'invités prend quelques minutes. Voici comment

procède Azure dans l'envers du décor :
¡ Il installe l'extension de diagnostic de machine virtuelle
¡ Il configure l'extension pour diffuser des métriques de niveau invité pour les
domaines suivants :
– Disque logique
– Mémoire
– Interface réseau
– Processus
– Processeur
– Système
– Il permet aux journaux d'application, de sécurité et de système d'être transmis
à Azure Storage
Une fois l'extension de diagnostic installée, vous pouvez limiter la collecte des données
en sélectionnant uniquement certains compteurs de performance à signaler. Par
exemple, peut-être souhaiterez-vous uniquement collecter l'utilisation de la mémoire
ou activer la collecte de métriques Microsoft SQL Server. Les métriques sont collectées
par défaut toutes les 60 secondes. Vous pouvez ajuster ce taux d'échantillonnage selon
vos besoins pour vos applications et votre infrastructure.
L'extension de diagnostic de machine virtuelle peut également diffuser des fichiers
journaux depuis votre machine virtuelle. Cela vous permet de centraliser les journaux
d'applications, de sécurité et de système à des fins d'analyse ou d'alerte, comme illustré à
la figure 12.3. Par défaut, les journaux d'applications et de système qui génèrent des alertes
Critique, Erreur ou Avertissement sont journalisés, ainsi que des événements de sécurité
pour l'échec d'audit. Vous pouvez modifier les niveaux de journalisation à enregistrer, et
pouvez également activer la collecte de journaux depuis IIS, les journaux d'application et le
suivi d'événements Windows (ETW). Dans le cadre de la planification et du déploiement de
votre application, déterminez les journaux que vous souhaitez collecter.
Rien n'est unique aux machines virtuelles Windows. Ainsi, vous pouvez utiliser
l'extension de diagnostic de la même manière sur des machines virtuelles Linux, afin
d'obtenir des mesures de performances et de diffuser des journaux.
En général, lorsqu'un problème survient, la seule façon d'analyser ce qui s'est
produit consiste à examiner les vidages sur incident. Les canaux de support requièrent
souvent ces vidages, si vous souhaitez déterminer la cause racine d'un problème. Tout
comme avec les diagnostics de démarrage, il est impossible d'activer rétroactivement les
vidages sur incident afin de déterminer la raison d'un problème. À vous de décider si
vous avez besoin de surveiller certains processus et d'être proactif sur la configuration
des vidages sur incident. Vous pouvez par exemple surveiller le processus IIS et
enregistrer un vidage sur incident complet sur Azure Storage en cas d'échec du processus.
Voici quelques autres domaines que vous pouvez configurer pour les métriques invitées :
¡ Les récepteurs vous permettent de configurer l'extension de diagnostic de machine
virtuelle pour envoyer certains événements à Azure Application Insights. Grâce à
Application Insights, vous gagnez en visibilité sur les performances de votre code.
¡ Agent vous permet de spécifier un quota de stockage pour l'ensemble de vos
métriques. (5 Go étant la valeur par défaut). Vous pouvez également activer la
collecte de journaux pour l'agent lui-même, ou bien le désinstaller.
 Mesures de performances et alertes 181

Figure 12.3  Vous pouvez configurer les événements et les niveaux de journalisation pour différents
composants de la machine virtuelle. Cette fonction vous permet de centraliser les journaux de vos
machines virtuelles pour les analyser et générer des alertes. Vous pouvez consulter et recevoir des
notifications lorsque vos machines virtuelles Azure rencontrent un problème, sans avoir à installer des
systèmes de surveillance complexes, généralement très coûteux.

Tester
Pour consulter les métriques de niveau invité, procédez comme suit :

1 Sur le portail Azure, depuis le menu situé à gauche, sélectionnez Machines virtuelles.
2 Choisissez la machine virtuelle que vous avez créée dans un exercice précédent.
3 Dans la section Surveillance du menu de la machine virtuelle, choisissez Mesures.
Comparées aux métriques basées sur l'hôte étudiées au chapitre  9, de nombreuses
métriques supplémentaires sont à présent disponibles. Explorez certains des
paramètres d’hôte et d’invité de la machine virtuelle disponibles, et identifiez les
applications pour lesquelles vous souhaitez surveiller des métriques spécifiques.

12.2.2 Création d'alertes pour les conditions de performances

Une fois que votre machine virtuelle est configurée pour afficher les mesures de
performances de niveau invité, comment êtes-vous tenu au courant en cas de
problème ? Vous n'avez certainement pas envie d'observer passivement les graphiques
des performances en temps réel en attendant qu'il se passe quelque chose ! Si c'est
votre truc, je ne vous en empêcherais pas. Il existe cependant une méthode bien plus
efficace : les alertes métriques.
182 Chapitre 12  Surveillance et dépannage

Les alertes métriques vous permettent de sélectionner une ressource, une métrique et
un seuil, puis de définir qui notifier et de quelle manière, une fois le seuil atteint. Les
alertes ne fonctionnement pas uniquement sur les machines virtuelles. Vous pouvez
par exemple définir des alertes sur des adresses IP publiques afin de détecter les paquets
DDoS (déni de service distribué) entrants et de vous avertir lorsqu'un certain seuil est
atteint, et que cela pourrait s'avérer être une attaque.
Lorsqu'une alerte est générée, vous pouvez choisir d'envoyer une notification par e-mail
aux propriétaires, aux contributeurs et aux lecteurs. Ces adresses e-mail et utilisateurs sont
obtenus selon les stratégies RBAC appliquées. Dans des structures plus importantes, les
alertes sont susceptibles d'envoyer des notifications par e-mail à un grand groupe de
personnes, alors soyez prudent ! Une autre option consiste à préciser les adresses e-mail : il
peut s'agir des propriétaires d'application ou d'ingénieurs d'infrastructures spécifiques, ou
bien d'une liste ou d'un groupe de distribution destiné aux parties directement impliquées.
Il existe certaines autres options utiles relatives aux mesures à prendre lorsqu'une
alerte est déclenchée :
¡ Exécuter une procédure opérationnelle. Dans le chapitre  18, nous nous intéresserons à
Azure Automation. Le service d'automatisation vous permet de créer et d'utiliser des
procédures opérationnelles qui exécutent des scripts. Ces scripts peuvent réaliser une
mesure corrective de base sur la machine virtuelle, telle que relancer un processus,
voire la redémarrer. Ils peuvent également exécuter des cmdlets de commande Azure
PowerShell pour activer les fonctionnalités d'Azure Network Watcher, tels que les
captures de paquets, que nous allons aborder dans la suite de ce chapitre.
¡ Exécuter une application logique. Les applications logiques Azure vous permettent
de générer des workflows qui exécutent du code sans serveur. Vous pouvez écrire
des informations sur un système de tickets de support ou passer un appel
téléphonique automatisé à un ingénieur de service. Au chapitre  21, nous
découvrirons le monde merveilleux de l'informatique sans serveur avec Azure
Logic Apps et Azure Functions.
Dans l'exercice pratique en fin de chapitre, vous devrez configurer des alertes pour
votre machine virtuelle. Azure est cependant capable de bien plus que de seulement
faciliter le dépannage et la surveillance de vos machines virtuelles. Un autre élément
peut parfois être responsable des problèmes : le réseau.

12.3 Azure Network Watcher

Les mesures de performances de machine virtuelle et les diagnostics de démarrage
constituent d'excellents moyens de surveiller vos applications IaaS Azure. Les journaux
d'applications Web et App Insights vous permettent de vous tenir au courant des
performances de vos applications PaaS. Le trafic réseau s'avère généralement moins
attrayant, mais il est plus probable que ce soit la cause des problèmes de connectivité
d'application rencontrés par vos clients ou par vous-même.
Au chapitre 5, j'ai plaisanté sur le fait que l'équipe réseau est toujours pointée du
doigt lorsque l'équipe des opérations ne parvient pas à identifier la cause d'un
problème. C'est là que nous allons nous faire de nouveau des amis, ou du moins obtenir
une preuve solide que le réseau est notre grand coupable ! Azure Network Watcher est
l'une de ces fonctionnalités qui réconcilie les équipes. Avec Network Watcher, vous
pouvez assurer la surveillance et le dépannage à l'aide de fonctionnalités telles que
celles mentionnées ci-dessous :
¡ Capture de paquets réseau
¡ Validation du flux IP pour des NSG
¡ Génération de topologie réseau
 Azure Network Watcher 183

L'aspect intéressant de ces fonctionnalités est qu'elles placent la responsabilité sur

différentes équipes quant à la résolution des problèmes. Si vous créez des machines
virtuelles et que vous n'arrivez pas à les connecter, vérifiez la connectivité réseau. En
tant que développeur, si votre application rencontre des soucis de connexion à un
niveau de base de données backend, vous pouvez examiner les règles NSG à la
recherche d'un éventuel problème. Pour une analyse plus approfondie, les ingénieurs
réseau peuvent quant à eux capturer des paquets afin d'examiner le flux de
communication complet entre les hôtes.

Dépannage réseau supplémentaire

Network Watcher est complémentaire aux journaux de diagnostic et métriques
mentionnés précédemment dans ce chapitre. Les ressources réseau, telles que les
équilibreurs de charge et les passerelles d'application, peuvent également générer des
journaux de diagnostic. Ces journaux fonctionnent de la même manière que les journaux
d'applications et de système depuis une machine virtuelle ou une application Web. Les
journaux sont collectés dans le portail Azure pour que vous puissiez détecter la présence
d'erreurs dans la configuration ou les communications entre les hôtes et les applications.
DNS et Traffic Manager disposent également d'une zone de Dépannage sur
le portail Azure. Le portail vous présente certaines erreurs courantes que vous pouvez
rencontrer, dispense des conseils de configuration, et propose des liens vers des
documents supplémentaires. Si rien ne fonctionne, vous pouvez toujours ouvrir une
demande de support avec le support Azure.
Bien qu'il s'avère plus facile de créer des déploiements d'applications volumineux avec
des modèles Azure Resource Manager ou avec des scripts Azure CLI ou PowerShell, le
portail Azure est doté de nombreux outils et fonctionnalités pouvant se révéler utiles
lorsque quelque chose ne fonctionne pas comme prévu. Quelques secondes de votre
temps passées à examiner le résultat des outils Network Watcher peuvent vous
permettre d'identifier un problème et de le résoudre rapidement, tout particulièrement
avec les configurations réseau et les stratégies de sécurité complexes. Tous ces outils
facilitent l'amélioration de l'état d'intégrité général et de l'expérience de vos applications
pour vos clients.

Quelles sont les situations dans lesquelles vous pourriez avoir besoin de Network
Watcher et quelles fonctionnalités de dépannage offre-t-il  ? Attardons-nous sur
quelques problèmes courants et voyons de quelle manière Network Watcher pourrait
vous être utile.

12.3.1 Vérification des flux IP

Voici un problème fréquent : les clients n'arrivent pas à se connecter à votre application.
L'application fonctionne correctement lorsque vous vous y connectez depuis le bureau,
mais les clients ne peuvent pas y accéder via l'Internet public. Pourquoi ?

VPN et ExpressRoute
Les réseaux privés virtuels Azure (VPN) offrent des communications sécurisées entre les
infrastructures locales et les datacenters Azure. Azure ExpressRoute, souvent utilisé
dans les grandes structures, fournit des connexions privées à grande vitesse dédiées
depuis les infrastructures aux datacenters Azure.
Ces deux connexions sont assez complexes à mettre en place, et nous ne pourrons pas
en aborder tous les aspects en l'espace d'une pause déjeuner. En outre, vous n'avez
besoin de les installer et de les configurer qu'une seule fois. C'est l'équipe réseau qui est
généralement en charge de leur configuration, et il est possible que vous ne vous rendiez
même pas compte que vous accédez à Azure via une connexion privée.
184 Chapitre 12  Surveillance et dépannage

Tous les tests de votre application fonctionnent correctement. Vous pouvez accéder
à  l'application via un navigateur Web, passer des commandes et recevoir des
notifications par e-mail. Lorsque vos clients essaient ensuite de passer une commande,
l'application ne se charge pas.
En quoi Network Watcher peut-il être utile ? Avec la vérification des flux IP. Network
Watcher simule le flux de trafic vers votre destination et vous indique si le trafic atteint
votre machine virtuelle.

Tester
Pour activer Network Watcher et vérifier les flux IP, procédez comme suit :

1 Sur le portail Azure, sélectionnez Toutes les ressources dans la partie supérieure
gauche du menu de navigation.
2 Filtrez et sélectionnez Network Watcher dans la liste des services disponibles.
Activez Network Watcher dans les régions que vous souhaitez surveiller. Lorsque
vous activez Network Watcher dans une région, Azure utilise des contrôles
d’accès en fonction du rôle pour les différentes ressources et le trafic réseau.
3 Développez la liste des régions pour votre compte. Il se peut que certaines régions
soient déjà activées. Si la région dans laquelle votre machine virtuelle a été
déployée n’est pas activée, sélectionnez le région, puis activez Network Watcher.
4 Lorsque Network Watcher est activé dans une région (cela prend une minute ou
deux), sélectionnez Vérification du flux IP dans la catégorie Outils de diagnostic
réseau, dans la partie gauche de la fenêtre Network Watcher.
5 Sélectionnez votre groupe de ressources, tel que azuremolchapter12 et votre
machine virtuelle, molvm par exemple. Par défaut, le Protocole est défini sur
TCP et la Direction sur Entrante. L'adresse IP locale de la carte réseau virtuelle
est également remplie.
6 Pour le Port local, entrez le port 80. Si vous avez accepté les valeurs par défaut lorsque
vous avez créé la machine virtuelle dans l'exercice précédent, vous n'avez pas ouvert
le port 80, c'est donc un bon exemple de ce qui se produit lorsque le trafic est refusé.
7 Pour l'Adresse IP distante, entrez 8.8.8.8. Cette adresse peut vous sembler
familière : c'est un serveur DNS ouvert fourni par Google. Vous ne faites rien
avec ce serveur ; vous avez juste besoin de fournir à Network Watcher une adresse
IP externe pour simuler le flux de trafic. Vous pouvez également vous rendre sur
https://whatsmyip.com et entrer votre réelle adresse IP publique.
8 Définissez le Port distant sur le port 80, puis sélectionnez Vérifier.
Le résultat de la vérification de flux IP devrait être Accès refusé. Network Watcher vous
indique gentiment la règle à l'origine de l'échec du flux de trafic  : la règle
DefaultInboundDenyAll. Vous savez qu'il existe une règle de sécurité réseau qui
bloque le trafic, mais où est-elle appliquée ? Au sous-réseau, à la carte réseau virtuelle
ou bien au groupe de sécurité des applications ? Une autre fonctionnalité Network
Watcher vous permet de le découvrir !

12.3.2 Affichage des règles NSG effectives

Les règles NSG peuvent être appliquées à une seule carte réseau virtuelle, au niveau du
sous-réseau ou à un groupe de machines virtuelles au sein d'un groupe de sécurité
d'application. Les règles se combinent, ce qui vous permet de déterminer un ensemble
 Azure Network Watcher 185

commun de règles sur un sous-réseau entier, puis d'être plus précis pour les groupes
de sécurité d'application (tels que «  Autoriser le port TCP  80 sur tous les serveurs
Web ») ou pour une machine virtuelle spécifique.
Voici quelques exemples courants de la façon dont les règles NSG peuvent être
appliquées :
¡ Au niveau du sous-réseau : autoriser le port TCP 5986 pour la gestion à distance
sécurisée depuis le sous-réseau de gestion 10.1.10.20/24.
¡ Au niveau du groupe de sécurité des applications : autoriser le port TCP 80 pour le
trafic HTTP vers les applications Web et appliquer le groupe de sécurité des
applications à toutes les machines virtuelles d'application Web.
¡ Au niveau de la carte réseau virtuelle : autoriser le port TCP 3389 pour les accès au
bureau à distance depuis le sous-réseau de gestion 10.1.10.20/24.
Il s'agit de règles de base, et elles autorisent explicitement certains trafics. Si aucune
règle d'autorisation ne correspond à un paquet réseau, les règles DenyAll par défaut
sont appliquées pour rejeter le trafic.
Lors du test de l'application mentionnée dans l'exemple, vous avez peut-être
configuré cette règle HTTP pour autoriser uniquement le trafic depuis l'un de vos sous-
réseaux locaux. À présent, les clients ne peuvent pas se connecter via l'Internet public.

Tester
Pour savoir où est appliquée une règle NSG, procédez comme suit :

1 Dans Network Watcher, sélectionnez Règles de sécurité effectives sur la gauche.

2 Sélectionnez votre groupe de ressources, tel que azuremolchapter12 et votre
machine virtuelle, molvm par exemple. L'affichage des règles effectives prend
quelques secondes, comme illustré à la figure 12.4.

Figure 12.4  Lorsque vous sélectionnez une machine virtuelle, Network Watcher examine la façon dont sont
appliquées l'ensemble des règles NSG ainsi que leur ordre de priorité, et indique quelles règles effectives sont
actuellement appliquées. Vous pouvez ensuite explorer rapidement le sous-réseau, la carte réseau virtuelle et
les règles par défaut pour rechercher et modifier l'emplacement d'application d'une règle donnée.
186 Chapitre 12  Surveillance et dépannage

Les règles par défaut de la machine virtuelle que vous avez créée précédemment ne
sont certes pas passionnantes. Vous pouvez cependant naviguer dans le sous-réseau,
l'interface réseau et les règles effectives par défaut pour obtenir un aperçu de la façon
dont les règles sont combinées et de la manière dont vous pouvez identifier où elles
sont appliquées, si vous avez besoin de modifier l'emplacement.

12.3.3 Capture de paquets réseau

Imaginons que vous avez mis à jour vos règles de sécurité réseau pour permettre à vos
clients d'accéder à votre application via l'Internet public, mais un client signale toutefois
un comportement inhabituel. Il arrive que l'application Web ne se charge pas, ou que
certaines images ne s'affichent pas. Leur connexion semble expirer régulièrement.
Les problèmes intermittents sont souvent les plus complexes à résoudre, notamment
lorsque vous disposez d'un accès limité (ou pas d'accès du tout) à l'ordinateur qui
rencontre ce problème. Une approche de dépannage courante consiste à capturer les
paquets réseau, puis à les examiner à la recherche de tout signe de problèmes, tels que
les erreurs de transmission réseau, les paquets incorrects ou les problèmes de protocole
et de communication.
Avec les captures de paquets réseau, vous obtenez le flux de données brut entre deux
ou plusieurs hôtes. L'analyse de capture réseau, c'est tout un art, et il est réservé aux
plus téméraires  ! Certains outils tiers spécifiques tels que Wireshark de Riverbed,
Fiddler de Telerik et Microsoft

Figure 12.5  Une capture de paquets réseau consultée dans l'analyseur de messages de Microsoft.
Chaque paquet individuel est disponible pour examen. Vous pouvez regrouper et filtrer par protocole de
communication ou par hôte client. Cette étendue de données réseau vous permet d'examiner les paquets
qui circulent réellement entre les nœuds, afin de dépanner l'emplacement d'une erreur. Un ancien collègue
m'a un jour déclaré que « les paquets ne mentent jamais ». Il suffit de savoir les déchiffrer.
 Azure Network Watcher 187

Message Analyzer vous propose de consulter et de filtrer graphiquement les paquets

réseau, en les regroupant généralement par communications ou protocoles. La
figure 12.5 illustre un aperçu d'une capture de paquets réseau.
Pour autoriser Network Watcher à capturer des paquets vers et depuis vos machines
virtuelles, installez en premier lieu l'extension de machine virtuelle Network Watcher.
Comme vous l'avez vu dans la section  12.3.2, les extensions de machine virtuelle
permettent à la plateforme Azure d'accéder à une machine virtuelle, afin d'y effectuer
diverses tâches de gestion. Dans le cas de l'extension Network Watcher, le trafic réseau
est examiné vers et depuis la machine virtuelle.

Tester
Pour installer l'extension de machine virtuelle Network Watcher et capturer les paquets
réseau, procédez comme suit :

1 Sur le portail Azure, sélectionnez Machines virtuelles dans la partie gauche du

menu, puis choisissez votre machine virtuelle (molvm, par exemple).
2 Dans la catégorie Paramètres, située dans la partie gauche de la fenêtre de la
machine virtuelle, sélectionnez Extensions.
3 Choisissez Ajouter une extension.
4 Dans la liste des extensions disponibles, choisissez Agent Network Watcher pour
Windows, puis sélectionnez Créer.
5 Pour confirmer l'installation de l'extension, sélectionnez OK. L'installation de
l'Agent Network Watcher sur votre machine virtuelle prend quelques minutes.
6 Pour revenir au menu Network Watcher dans le portail Azure, sélectionnez
Toutes les ressources dans la partie supérieure du menu de navigation Services
(à gauche dans le portail), puis choisissez Network Watcher.
7 Dans la section Outils de diagnostic réseau, dans la partie gauche de la fenêtre
Network Watcher, sélectionnez Capture de paquets, puis choisissez Ajouter une
nouvelle capture.
8 Sélectionnez votre groupe de ressources, tel que azuremolchapter12 et votre
machine virtuelle, molvm par exemple. Saisissez un nom pour votre capture de
paquets, tel que, molcapture.
Les captures de paquets sont enregistrées par défaut dans Azure Storage. Vous
pouvez également choisir d'enregistrer dans le fichier et spécifier un répertoire
local sur la machine virtuelle source. L'Agent Network Watcher écrit ensuite le
fichier de capture de paquets dans le disque dans la machine virtuelle.
9 S'il n'est pas déjà sélectionné, choisissez le nom du compte de stockage qui
commence par le nom de votre groupe de ressources, tel que
azuremolchapter12diag493. Il s'agit du compte de stockage créé et utilisé par
l'extension de diagnostic de machine virtuelle que vous avez activée précédemment.
10 Vous pouvez définir une taille maximale pour chaque paquet (la valeur par défaut
est de 0 pour l’intégralité du paquet), la taille de fichier maximale pour la session
de capture de paquets (la valeur par défaut est de 1 Go) et la limite de temps pour
la capture de paquets (la valeur par défaut est de 5  heures). Pour capturer
uniquement le trafic depuis des sources ou des ports spécifiques, vous pouvez
également ajouter un filtre afin de réduire l'étendue de vos captures de paquets.
188 Chapitre 12  Surveillance et dépannage

11 Définissez une limite de temps de 60 secondes.

12 Pour démarrer la capture de paquets, sélectionnez OK.
Le démarrage de la capture prend quelques minutes. Une fois la capture en cours, les
données sont transmises vers le compte Azure Storage ou le fichier local sur la machine
virtuelle. La liste des captures est affichée sur la page du portail Network Watcher. Si vous
transférez les journaux vers Azure Storage, vous pouvez envoyer la capture directement
au compte de stockage et télécharger le fichier de capture .cap. Vous pouvez ensuite
ouvrir la capture de paquets dans un programme d'analyse, comme expliqué dans la
section 12.3.3. L'exemple de capture réseau illustré précédemment dans ce chapitre à la
figure 12.5 provient en réalité d'une capture de paquets Azure Network Watcher !

12.4 Exercice pratique : création d'alertes de performances

Avec un peu de chance, les fonctionnalités de diagnostics, de métriques et Network
Watcher pour machine virtuelle évoqués dans ce chapitre vous ont donné un aperçu des
outils Azure mis à votre disposition afin de vous aider à résoudre les problèmes d'application.
Certains éléments, comme les diagnostics de démarrage et l'extension de diagnostic de
machine virtuelle, se révèlent plus pertinents lorsque vous les activez et les configurez au
fur et à mesure que vous déployez des machines virtuelles.
Dans cet exercice, vous allez configurer des alertes métriques afin de découvrir les
éléments pouvant générer une notification et de savoir à quoi ressemble une alerte
lorsque vous en recevez une :
1 Sur le portail Azure, naviguez jusqu'à la machine virtuelle que vous avez créée
dans les exercices précédents.
2 Dans la section Surveillance de la machine virtuelle, sélectionnez Alertes.

3 Choisissez de créer une règle d’alerte, puis ajoutez une condition, lorsque le
pourcentage logiciel est supérieur à une moyenne de 10  % au cours des
5 dernières minutes. Un graphique vous indique les métriques les plus récentes,
ajustez alors le seuil si aucune alerte n'est déclenchée au-delà de 10 %.
4 Ajoutez un groupe d’actions et attribuez-lui un nom et un nom court. Pour cet
exercice, les deux noms doivent être azuremol. Les groupes d’actions vous
permettent de définir des séries d’étapes réutilisables à effectuer lorsqu’une alerte
est générée. Il peut s'agir d'envoyer un e-mail à un groupe d’utilisateurs, ou
d’exécuter un script PowerShell automatisé ou une application Azure Logic App.
5 Explorez les types d’actions disponibles, puis sélectionnez e-mail/SMS/vocale.

6 Choisissez la façon dont vous souhaitez être averti, par exemple par e-mail ou
SMS. Certains frais d'opérateurs téléphoniques peuvent s’appliquer aux
notifications par SMS ou vocales.
7 Une fois le groupe d’actions créé, nommez l’alerte, puis définissez le niveau
de gravité. Ce niveau de gravité est utile si vous avez défini de nombreuses alertes.
Vous pourrez ainsi les trier et hiérarchiser celles qui doivent être résolues en premier.
8 Lorsque vous êtes prêt, créez la règle. L'activation de la règle et des notifications
définies nécessite 10 à 15 minutes.
Cet exemple est basique. Réfléchissez à toutes les alertes et notifications existantes
parmi vos applications et services et à la façon dont vous pouvez utiliser cette fonction
lorsque vous exécutez des charges de travail dans Azure.
 Partie 3

Sécurisation par défaut

D ans un monde en ligne où les applications sont généralement connectées

à Internet 24  h/24, 7  j/7, la menace d'une attaque numérique n'est que trop
réelle. Ces attaques coûtent du temps et de l'argent, et sapent la confiance des
clients. Pour concevoir des applications hautement redondantes et distribuées, il
est crucial de déterminer comment les sécuriser et comment protéger vos
données. Azure intègre plusieurs fonctions qui vous permettent de sécuriser vos
données, dont des outils de chiffrement, de pilotage, de coffre de clés et de
sauvegarde. Dans cette partie du livre, vous apprendrez à sécuriser et protéger
vos applications dès les toutes premières phases.
 13
Sauvegarde, récupération et
réplication

Les prochains chapitres présentent quelques fonctions et services clés d'Azure qui
vous permettent de concevoir la sécurité dans vos applications. C'est probablement
inexact : la sécurité une fonction à ajouter ni une directive à garder à l'esprit. Elle
doit être bâtie de façon intrinsèque au cœur même de votre application, dès les
premières phases de conception. Dans ce chapitre, vous débuterez avec la sécurité
dans Azure en apprenant à sauvegarder et à récupérer vos données. Il ne vous
semble peut-être pas courant d'aborder les sauvegardes lorsque l'on parle de
sécurité. Vous devez appréhender la sécurité comme un ensemble allant au-delà du
chiffrement des données et des certificats Web SSL. Qu'en est-il de la protection de
vos données après une panne, une perte de données ou un piratage ? Le thème de
la sauvegarde et de la réplication constitue d'ailleurs une excellente transition entre
le chapitre sur la haute disponibilité et celui-ci.
Vous pensez peut-être que les sauvegardes sont un travail élémentaire. En tant
qu'ex-administrateur backup, je peux vous dire qu'assurer le bon déroulement des
tâches de sauvegarde et des rotations n'a rien de très amusant ! Cependant, il est
essentiel que les sauvegardes soient réalisées en temps et en heure pour protéger vos
applications et pour que, dans le pire des scénarios, vous puissiez restaurer vos
données rapidement et de façon fiable. Vous pouvez également répliquer vos
VM d'une région Azure à une autre. Cette possibilité repose sur les concepts de
haute disponibilité que nous avons abordés dans le chapitre 7.
Dans ce chapitre, vous apprendrez à sauvegarder et restaurer des VM, puis à
répliquer automatiquement des VM dans Azure. L'ensemble de ces sauvegardes et
de ces points de restauration sont chiffrés afin que vos données soient sécurisées.

13.1 Azure Backup

Par chance, Azure Backup est à la fois un service et un vaste bucket de stockage pour
les sauvegardes à proprement parler. Azure  Backup peut protéger les VM dans
Azure, les VM sur site ou les serveurs physiques, et même les VM hébergés par
d'autres fournisseurs comme Amazon Web  Services (AWS). Les sauvegardes de

191
192 Chapitre 13  Sauvegarde, récupération et réplication

données peuvent être stockées au niveau de baies de stockages sur site ou d'un offre de
récupération Azure. La figure 13.1 illustre la manière à laquelle le service Azure Backup
peut protéger et orchestrer l'ensemble des sauvegardes selon vos besoins.

Serveurs
VM sur site
Azure physiques sur site VM externes (par
(VMware/Hyper-V)
VMs (Windows/Linux) exemple, AWS)

Plusieurs sources de données

peuvent être sauvegardées

Sauvegarde Azure orchestre Azure

les sauvegardes de données
selon chaque stratégie définie.
Backup
Les données de sauvegarde peuvent
être restaurées dans Azure ou dans
un emplacement sur site sécurisé

Coffre Azure Solution

Recovery de stockage
Services sur site

Figure 13.1  Le service d'orchestration central peut prendre en charge la sauvegarde de plusieurs

VM ou serveurs physiques, provenant de divers fournisseurs et de divers sites. Azure Backup réalise
les opérations de sauvegarde des données selon une fréquence ou un calendrier déterminés par des
stratégies définies. Ces sauvegardes peuvent ensuite être stockées dan Azure ou dans une solution
de stockage sur site. Les données sont chiffrées à chaque étape pour plus de sécurité.

Azure  Backup s'occupe avant tout de la planification des sauvegarde et de la

conservation des données, ainsi que de l'orchestration des tâches de sauvegarde et de
restauration. Pour les sauvegardes de VM Azure, aucun composant de serveur n'est
nécessaire. Vous n'avez pas non plus besoin d'installer d'agent manuellement. Toutes
les opérations de sauvegarde et de restauration sont intégrées à la plateforme Azure.
Pour sauvegarder des VM sur site, des serveurs physiques ou des VM hébergées par
d'autres fournisseurs comme AWS, vous installez un petit agent qui assure une
communication bilatérale sécurisée avec Azure. Cette communication sécurisée
garantit que vos données sont chiffrées pendant le transfert.
Pour les données stockées dans Azure, les sauvegardes sont chiffrées à l'aide d'une
clé de chiffrement que vous créez. Vous seul avez accès aux sauvegardes chiffrées. Pour
vous assurer de la sécurité des sauvegardes de données, vous pouvez également
sauvegarder des VM chiffrées (nous en parlerons dans le chapitre 14).
Le flux de trafic réseau nécessaire à la sauvegarde et à la restauration des données ne
vous est pas facturé. Le tarif que vous payez est uniquement basé sur chaque instance
protégée et, dans un deuxième temps, sur la quantité de stockage que vous utilisez dans
Azure. Si vous utilisez un équipement de stockage sur site, le coût lié à Azure Backup est
minime, car vous ne générez aucun coût Azure Backup ou de trafic réseau.
 Azure Backup 193

13.1.1 Stratégies et conservation

Azure Backup utilise un modèle incrémentiel de sauvegarde. Lorsque vous protégez
une instance, la première opération de sauvegarde porte sur l'ensemble des données.
Ensuite, une sauvegarde incrémentielle des données est effectuée à chaque opération.
Chacune de ces sauvegardes est appelée un point de récupération. Le système de
sauvegarde incrémentiel est économique en termes de temps. Il permet
d'optimiser le stockage et l'utilisation de la bande passante réseau. Seules les données
qui ont changé depuis la dernière sauvegarde sont transférées, de manière sécurisée,
vers l'emplacement de destination de la sauvegarde. La figure  13.2 détaille le
fonctionnement du système de sauvegarde incrémentiel.

Sauvegarde
Sauvegarde Sauvegarde incrémentielle
complète incrémentielle

VM
protégée

La première opération
de sauvegarde transfère
toutes les données depuis
la VM vers l'emplacement
de récupération
sélectionné.
La tâche de sauvegarde Les autres tâches de
suivante porte uniquement sur sauvegarde continuent de
les données qui ont changé sauvegarder uniquement les
depuis la dernière opération. données qui ont changé depuis
la dernière opération.

Figure 13.2  Les sauvegardes incrémentielles portent uniquement sur les données qui ont changé depuis
l'opération précédente. La première sauvegarde est toujours une sauvegarde complète. Ensuite, chaque tâche
de sauvegarde porte uniquement sur les données qui ont changé depuis le moment où la tâche précédente a été
effectuée. Vous contrôlez la fréquence des sauvegardes complètes via les stratégies. Cette approche minimise
la quantité de données à transmettre de façon sécurisée sur le réseau et à héberger sur le lieu de stockage de
destination. Azure Backup assure la cohésion entre les différentes sauvegardes incrémentielles pour que,
lorsque vous restaurez les données, celles-ci soient cohérentes et complètes.

Azure Backup vous permet de stocker jusqu'à 9 999 points de restauration pour chaque

instance que vous protégez. Pour vous donner une idée, si vous faites des sauvegardes
quotidiennes, vous pouvez conserver des points de restauration sur plus de 27 ans. Si
vous optez pour des sauvegardes hebdomadaires, vous pouvez les conserver sur
presque 200 ans. Quel que soit le besoin d'audit, cela devrait suffire amplement ! Vous
pouvez conserver vos sauvegardes sur une base quotidienne, hebdomadaire, mensuelle
ou annuelle, ce qui est en phase avec la plupart des stratégies de sauvegarde existantes.
Pour choisir la stratégie de sauvegarde optimale selon votre charge de travail, vous
devez analyser et déterminer votre objectif de point de récupération (RPO) et votre objectif de
délai de récupération (RTO) acceptables.
194 Chapitre 13  Sauvegarde, récupération et réplication

Objectif de point de récupération

Le RPO définit le point que vous pouvez restaurer avec votre dernière sauvegarde. Par
défaut, Azure  Backup réalise une sauvegarde quotidienne. Vous définissez ensuite
dans les stratégies de conservation le nombre de jours, de semaines, de mois ou
d'années pendant lequel vous souhaitez conserver ces points de récupération. Bien
que le RPO soit essentiellement utilisé pour définir la quantité maximale acceptable
de données perdues, vous devez également savoir combien de temps en arrière vous
souhaitez remonter. La figure 13.3 illustre la manière à laquelle la quantité acceptable
de données perdues est définie par le RPO.

Sauvegarde
quo dienne
Perte de données acceptable
VM protégée
Sauvegarde
hebdoma-
daire

1 jour de données 1 semaine de données

perdues au maximum perdues au maximum
Figure 13.3  Le RPO définit la quantité de données que vous pouvez vous permettre de perdre pour
une instance protégée. Plus votre RPO est long, plus la quantité acceptable de données perdues est
importante. Avec un RPO d'un jour, vous pouvez perdre jusqu'à 24 heures de données (selon le délai
écoulé entre la perte de données et la dernière sauvegarde). Avec un RPO d'une semaine, vous
pouvez perdre jusqu'à 7 jours de données.

Les pannes critiques et les pertes de grandes quantités de données se produisent

rarement. En revanche, les incidents mineurs entraînant des pertes ou des écrasements
de données sont plus fréquents. Souvent, ces incidents ne sont pas remarqués
immédiatement, et sont signalés un certain temps après la perte des données. Dans de
telles circonstances, la stratégie de conservation de vos instances protégées devient
particulièrement importante. Si votre stratégie de conservation porte sur une période
courte, vous ne pourrez peut-être pas restaurer vos données au moment souhaité. Vous
devez trouver le juste équilibre qui vous permettra de conserver plusieurs points de
récupération à des coûts de stockage raisonnables.
Le stockage Azure est relativement abordable  : il coûte généralement moins de
0,02 $ par gigaoctet stocké. Pour sauvegarder 100 Go de données VM, cela équivaut à
environ 2 $ par mois (plus les frais associés au service de sauvegarde Azure Backup).
Selon le volume de données qui change, la taille des points de récupération
incrémentaux peut vite grimper. La conservation de points de récupération sur
plusieurs semaines ou plusieurs mois peut coûter plusieurs dizaines de dollars par mois
par instance protégée. Je ne veux pas vous décourager, mais simplement insister sur
l'importance de planifier vos besoins et de soigneusement calculer vos coûts. Le
stockage à 0,02 $ par gigaoctet semble bon marché… jusqu'à ce que vous atteigniez
plusieurs centaines de gigaoctets par instances protégée, avec plusieurs dizaines (voire
plusieurs centaines) d'instances à protéger.
Lorsque j'étais administrateur backup, la capacité de stockage était souvent un
facteur crucial lorsque je devais déterminer le nombre de points de récupération
à conserver. La capacité de stockage a bien souvent donné lieu à des compromis quant
aux RPO. Si vous utilisez Azure Storage plutôt qu'une solution de stockage sur site, vous
n'avez pas à vous préoccuper de la capacité de stockage disponible. Je peux vous
garantir presque à coup sûr qu'il y en a largement assez pour votre carte de crédit !
 Azure Backup 195

Objectif de délai de récupération

Le RTO détermine la rapidité de restauration de vos données. Si vous choisissez de
sauvegarder des VM Azure et de stocker les points de récupération dans une solution
de stockage sur site, la restauration de vos sauvegardes prendra beaucoup plus de
temps que si vous hébergez vos points de récupération dans Azure  Storage. Si vous
sauvegardiez vos VM sur site ou vos serveurs physiques dans Azure Storage, alors ce
serait l'inverse. Le RTO est décrit à la figure 13.4.

Sauvegarde
complète
unique Durée acceptable d'indisponibilité
de l'application
VM protégée

Plusieurs
sauvegardes
incrémentielles
Délai minimal de
Le délai de récupération
récupération des données
s'allonge progressivement
Figure 13.4  Le RTO détermine le délai acceptable pour le processus de restauration des données, délai
au cours duquel l'application ne sera pas disponible. Plus le processus de restauration implique de points
de récupération, plus le RTO est long. De la même manière, plus le stockage de sauvegarde est proche
du point de récupération, plus le RTO est court.

Dans l'un ou l'autre des scénarios, les données de point de récupération doivent être
transférées à partir de l'emplacement de stockage du point de récupération jusqu'à
l'emplacement de restauration. Pour les opérations de restauration volumineuses, qui
nécessitent de transférer plusieurs centaines de gigaoctets, votre bande passe réseau
devient un véritable goulet d'étranglement qui déterminera la vitesse à laquelle vos
applications seront remises en service.
Si vous avez défini des stratégies de conservation longues avec de nombreux points de
récupération incrémentielle successifs, le même phénomène se produit. Pour la
restauration des données, il est possible que plusieurs points de récupérations soient
montés et restaurés. Votre travail consiste à déterminer combien de temps vous souhaitez
pouvoir remonter et sous quel délai vous souhaitez pouvoir restaurer les données.
Le RPO et le RTO diffèrent selon vos applications et les opérations de votre
entreprise. Si vous avez une application qui traite des commandes en temps réel, vous
pouvez difficilement vous permettre des temps d'interruption trop longs. Vous choisirez
donc certainement un RPO et un RTO très courts. Généralement, vos données sont
contenues dans une base de données. Donc, vous concevrez dans la plupart des cas vos
applications de façon qu'elles bénéficient d'une marge de tolérance, plutôt que de
compter sur les points de récupération. Pensez à Cosmos DB : il n'y a rien à sauvegarder,
la plateforme Azure se charge de la réplication et de la protection des données à votre
place. Si vous avez conçu une solution personnalisée sur MySQL ou Microsoft
SQL Server, vous utilisez probablement un type de clustering et de réplication similaire
pour vous assurer que vous disposez de plusieurs copies de la base de données, afin que
vous n'ayez pas à effectuer une restauration depuis une sauvegarde si vous perdez une
instance. Les sauvegardes vous permettent principalement de vous protéger en cas de
panne importante ou de corruption des données.
196 Chapitre 13  Sauvegarde, récupération et réplication

13.1.2 Planification des sauvegardes

Comment contrôlez-vous la fréquence de vos sauvegardes et la conservation de vos
points de récupération  ? Dans Azure  Backup, ces paramètres sont définis dans les
stratégies. Vous établissez ces stratégies en prévoyant les divers scénarios contre lesquels
vous souhaitez vous protéger. Vous pouvez réutiliser vos stratégies sur plusieurs
instances protégées.
Par exemple, vous pouvez définir une stratégie indiquant que vous souhaitez
effectuer une sauvegarde chaque jour à 18  h  30. Vous souhaitez conserver vos
sauvegardes quotidiennes pendant six mois et les alterner de manière à conserver les
sauvegardes hebdomadaires pendant deux ans. À des fins de conformité, vous conservez
les sauvegardes mensuelles pendant cinq  ans. Vous conservez également une
sauvegarde annuelle pendant 10  ans. Ces valeurs de conservation peuvent sembler
excessives, mais pour une application qui comprend des fonctions de communication
et de messagerie, les contraintes de réglementation et de conformité imposent souvent
de conserver des sauvegardes sur de longues durées. Azure Backup est suffisamment
souple pour vous permettre de définir des stratégies adaptées à différentes charges de
travail d'application et de respecter rapidement les contraintes de conformité.

Tester
Toutes vos sauvegardes Azure sont stockées dans un coffre Recovery Services. Pour
créer un coffre et une stratégie de sauvegarde, procédez comme suit :

1 Ouvrez le portail Azure et sélectionnez Créer une ressource, en haut à gauche

du menu.
2 Recherchez et sélectionnez l'option Backup and Site Recovery, puis choisissez Créer.
3 Créez un groupe de ressources, ici azuremolchapter13, puis entrez un nom
pour le coffre, tel que azuremol.
4 Sélectionnez un emplacement, puis examinez et créez le coffre.
5 Une fois le coffre créé, sélectionnez Groupes de ressources dans le menu à
gauche sur le portail, puis choisissez le groupe de ressources que vous avez créé.
6 Sélectionnez votre coffre Recovery Services dans la liste des ressources
disponibles, choisissez Stratégies de sauvegarde dans le menu de gauche, puis
choisissez d'ajouter une stratégie.
7 Sélectionnez le type de stratégie Machine virtuelle Azure, puis attribuez un nom
à votre nouvelle stratégie, par exemple, molpolicy. Par défaut, une sauvegarde
est créée chaque jour.
8 Choisissez le fuseau horaire approprié dans le menu déroulant. Par défaut,
Azure utilise le temps universel coordonné (UTC, Universal Coordinated Time).
Si vous le souhaitez, passez en revue les stratégies de conservation quotidiennes,
hebdomadaires, mensuelles et annuelles, et ajustez-les. La section sur les concepts
des planifications de sauvegarde et de rétention explique comment sélectionner
ces valeurs. Ces valeurs varient généralement lorsque vous créez et appliquez des
stratégies de sauvegarde pour protéger vos instances de machine virtuelle.
9 Lorsque vous êtes prêt, sélectionnez Créer.
 Azure Backup 197

Pour ceux qui aiment se faciliter la vie

Vous pouvez également configurer des sauvegardes de VM lorsque vous créez une VM
dans le portail Azure. Sur la page Paramètres où vous configurez les paramètres du réseau
virtuel ou les options de diagnostic et de dépannage, vous pouvez activer Azure Backup.
Vous pouvez sélectionner un coffre Recovery Services existant ou en créer un, puis créer
ou appliquer une stratégie de sauvegarde. Actuellement, vous ne pouvez pas activer les
sauvegardes lors du déploiement de VM dans la CLI Azure ou Azure PowerShell, mais une
seule commande post-déploiement suffit généralement.
J'aime planifier les sauvegardes, les stratégies de conservation et les calendriers. C'est
pourquoi le coffre Recovery Services et les stratégies sont créées en premier dans ces
exercices. Cependant, si vous le souhaitez, vous pouvez rapidement créer une VM et
activer les sauvegardes en une seule étape sur le portail Azure.

Vous disposez maintenant d'une stratégie de sauvegarde, qui définit également des
stratégies de conservation pour différentes périodes, mais vous n'avez encore rien
à sauvegarder. Nous allons donc créer une VM avec Cloud Shell. Vous pourrez ainsi créer
une sauvegarde, puis, dans un autre exercice plus tard, répliquer les données.

Tester
Pour créer une VM de test pour la sauvegarde et la réplication, procédez comme suit :

1 Sélectionnez l'icône Cloud Shell, située dans la partie supérieure du portail Azure.

2 Créez une machine virtuelle avec la commande az vm create. Indiquez le nom
du groupe de ressources créé dans l'exercice précédent (azuremolchapter13),
puis attribuez un nom à la VM, par exemple, molvm :
az vm create \
--resource-group azuremolchapter13 \
--name molvm \
--image win2019datacenter \
--admin-username azuremol \
--admin-password P@ssw0rdMoL123

La stratégie de sauvegarde est définie, et votre VM de test est prête. Pour voir le
fonctionnement de Azure Backup en pratique, nous allons appliquer votre stratégie de
sauvegarde à la VM.

Tester
Pour sauvegarder une VM selon la stratégie définie, procédez comme suit :

1 Sélectionnez Groupes de ressources dans le menu de gauche sur le portail.

2 Choisissez le groupe de ressources, puis la VM que vous avez créée.
3 Sous Opérations, sélectionnez Sauvegarde.
4 Vérifiez que votre coffre Recovery Services est sélectionné, puis choisissez votre
stratégie de sauvegarde dans le menu déroulant.
198 Chapitre 13  Sauvegarde, récupération et réplication

5 Examinez les options de planification et de conservation, puis activez la

sauvegarde. L'application de la stratégie de sauvegarde prend quelques secondes.
6 Une fois la stratégie activée, retournez aux paramètres de sauvegarde. L’état de la
machine virtuelle indique Avertissement (sauvegarde initiale en attente).
7 Pour créer la première sauvegarde, choisissez le bouton Sauvegarder mainte-
nant, comme illustré à la figure 13.5.

Figure 13.5  Pour créer la première sauvegarde, sélectionnez le bouton Sauvegarder maintenant. Une
fois la sauvegarde terminée, son état est mis à jour. L'heure de la dernière sauvegarde est indiquée, ainsi
que le dernier point de restauration et le point de restauration le plus ancien.

La première opération de sauvegarde peut prendre  15 à 20  minutes au total. Pour

afficher l'état d'avancement de la tâche de sauvegarde, vous pouvez sélectionner l'option
Afficher toutes les tâches. Vous ne trouverez pas d'indicateur sous forme de barre de
progression ni de pourcentage, mais vous pouvez savoir si la tâche est en cours.
C'est tout ce dont vous avez besoin pour sauvegarder vos VM et protéger vos données
dans Azure ! Poursuivez votre lecture pour découvrir comment restaurer les données
en cas de problème.
 Azure Backup 199

13.1.3 Restauration d'une VM

Azure Backup vous permet de restaurer une VM entière ou des fichiers spécifiques.
Au cours de mes années de métier, les opérations de restauration de fichiers ont été les plus fréquentes. Ce type
de tâche de restauration intervient généralement lorsque des fichiers sont supprimés ou
écrasés accidentellement. Les restaurations de fichiers déterminent habituellement les stratégies de
conservation que vous appliquez à vos sauvegardes. Plus les données sont importantes, plus la période de
conservation des sauvegardes devra être longue (au cas où on vous appelle tard le soir pour restaurer un fichier
d'il y a six mois).
Une restauration complète de VM, comme son nom l'indique, restaure l'intégralité de la VM. J'ai rarement
eu besoin de restaurer une VM complète pour rétablir la connexion avec une VM supprimée. La restauration
complète de VM est particulièrement utile si vous souhaitez fournir une VM de test identique à l'original d'un
point de vue fonctionnel. Vous pouvez restaurer une VM, puis tester une mise à niveau logicielle ou autre
procédure de maintenance. Grâce à cette approche, vous pouvez identifier les problèmes potentiels et établir
un plan de gestion pour la véritable VM de production.
Il est également important de tester régulièrement vos sauvegardes. N'attendez pas de vous trouver face à
une situation concrète où la restauration des données est impérative. Vous pouvez faire confiance à Azure
Backup, mais assurez-vous quand même de savoir où et comment restaurer les données si vous en avez besoin.

Restauration de fichiers
Le processus de restauration de fichiers est assez facile dans
Azure Backup. Azure crée un script de récupération que
vous pouvez télécharger et exécuter, ce qui vous offre une
certaine flexibilité quant au mode de restauration des
fichiers et à la destination. Ce script de récupération est
protégé par un mot de passe. Ainsi, vous seul pouvez
exécuter le processus de récupération. Lorsque vous
exécutez le script de récupération, vous êtes invité à entrer
le mot de passe avant de pouvoir continuer. La fenêtre de
téléchargement du script de récupération est illustrée à la
figure 13.6.
Lorsque vous exécutez le script de récupération, votre
point de récupération est connecté en tant que système de
fichiers local sur votre ordinateur. Pour les VM Windows, un
script PowerShell est généré, et un volume local
(par exemple, F:) est connecté. Pour les VM Linux, le point
de récupération est monté en tant que disque de données
(par exemple, /dev/sdc1) dans votre
volume home. Dans les deux cas, le script de récupération
indique clairement où vous pouvez trouver vos fichiers.
Une fois que vous avez terminé de restaurer les fichiers
depuis le coffre de récupération, vous devez retourner sur le
portail Azure et sélectionner l'option Démonter les disques.
Ce processus retire les disques de votre ordinateur local
et les renvoie dans le coffre de récupération, où ils sont de
nouveau disponibles pour utilisation. Si vous devez
restaurer rapidement des fichiers pour une VM de
production et que, dans le feu de l'action, vous oubliez de
démonter les disques, pas de panique  ! Azure dissocie
automatiquement les points de récupération après
12 heures.

Restauration complète de VM
Une restauration complète de VM crée une VM, la connecte
au réseau virtuel et rattache l'ensemble des disques durs
virtuels. Essayons d'effectuer une restauration complète de
VM. Comme il est toujours préférable de tester les mises à
jour de maintenance avant de les déployer réellement, cet
exercice de restauration est une bonne pratique.
Figure 13.6  Lorsque vous effectuez une
restauration de fichiers, vous choisissez un point de
récupération à restaurer. Un script de récupération
est téléchargé sur votre ordinateur. Vous pouvez
exécuter ce script uniquement en saisissant le mot
de passe généré. Le script de récupération monte le
point de récupération en tant que volume local sur
votre ordinateur. Une fois que vous avez restauré les
fichiers dont vous avez besoin, vous démontez les
disques sur votre ordinateur. Ceux-ci sont alors
renvoyés dans le coffre de récupération et
disponibles pour utilisation.
200 Chapitre 13  Sauvegarde, récupération et réplication

Tester
Pour restaurer une VM complète, procédez comme suit :

1 À partir de votre groupe de ressources, sélectionnez la VM que vous avez

sauvegardés lors de l'exercice précédent.
2 Sélectionnez l'option Sauvegarder dans le menu de gauche de la VM. Dans la vue
d'ensemble de la sauvegarde, vous devriez voir qu'un point de récupération a été
créé, comme illustré à la figure  13.7. Sinon, attendez quelques minutes qu'il
apparaisse avant de commencer cet exercice. Vous pouvez aussi vous contenter
de lire le reste de la procédure pour savoir ce que le processus implique.

Figure 13.7  Lorsque la sauvegarde de la VM est terminée, la vue d'ensemble affiche les données
de la dernière sauvegarde et les points de restauration disponibles. Pour démarrer le processus de
restauration, sélectionnez Restaurer la machine virtuelle.

3 Sélectionnez le bouton Restaurer la machine virtuelle, choisissez un point de

restauration dans la liste, puis sélectionnez OK.
4 Choisissez un point de restauration et déterminez comment restaurer la machine
virtuelle. Vous pouvez créer une machine virtuelle ou en remplacer une qui
existe déjà.
L’option par défaut consiste à créer une machine virtuelle. Dans cette
configuration, une machine virtuelle est créée et connectée au réseau virtuel
spécifié, et les disques sont restaurés et connectés.
Vous pouvez également choisir de remplacer une machine virtuelle existante.
Dans ce scénario, les disques sont restaurés à partir de la sauvegarde et associés à
la VM existante. Quel que soit le réseau virtuel ou les autres options de
configuration appliquées à la machine virtuelle, ils sont conservés.
5 Pour cet exercice, vous avez choisi de restaurer une nouvelle machine virtuelle.
Attribuez un nom à la VM restaurée, par exemple, restoredvm, puis passez en
revue les paramètres de réseau virtuel et de stockage. En production, vous
connectez généralement la VM restaurée à un réseau virtuel isolé afin de ne pas
affecter le trafic de production.
6 Sélectionnez OK, puis Restaurer.
 Azure Site Recovery 201

Le processus de connexion au point de restauration et de création de la VM restaurée

avec les disques précédents rattachés prend quelques minutes. À ce stade, vous pouvez
connecter la VM restaurée pour tester des mises à niveau logicielles ou restaurer de
vastes volumes de données, selon vos besoins.
Vous pouvez également sauvegarder une application Web. Cette approche ne
s'applique pas seulement aux VM. Le processus est un peu différent, mais le principe
est le même. Si vous modifiez votre modèle d'application pour passer à une solution PaaS
(par exemple, avec une application Web), ça ne veut pas dire que vous pouvez oublier
le fonctionnement des sauvegardes et de la conservation des données !

13.2 Azure Site Recovery

Lorsque nous avons abordé Cosmos DB, rappelez-vous, vous avez appris qu'un clic sur
un bouton suffisait à répliquer vos données dans une toute autre région Azure pour
des questions de redondance et de tolérance aux pannes. C'est valable pour les VM
entières également  ! Azure Site Recovery est un service puissant. Vous pouvez faire
bien plus que répliquer vos VM dans une autre région. La figure 13.8 illustre la manière
à laquelle Azure Site Recovery orchestre les charges de travail entre les différents
emplacements.

Ressources sur site

Azure VM VM Hyper-V Serveurs

VMs VMware physiques

Plusieurs serveurs virtuels

ou physiques peuvent être
protégés et répliqués avec
Site Recovery. Azure Site Recovery orchestre la
Azure Site réplication des charges de travail
selon les stratégies définies, qui
Recovery déterminent le calendrier et les
emplacements.

Emplacement Les ressources peuvent

Région Azure secondaire être répliquées ou
sur site migrées vers Azure ou
vers un emplacement
sur site secondaire.

Figure 13.8  Azure Site Recovery organise la réplication et la migration des ressources physiques ou
virtuelles vers un emplacement autre. Les emplacements sur site comme Azure peuvent faire office de
points d'origine et de destination pour la protection, la réplication ou la migration.

Il est important de comprendre qu'Azure Site Recovery ne prend pas seulement en

charge les VM Azure. Site Recovery permet de répliquer des VM VMware ou Hyper-V
sur site vers Azure à des fins de récupération d'urgence (DR) ou dans le cadre d'une
migration vers Azure. Vous pouvez utiliser Azure Site Recovery simplement en tant
qu'outil d'orchestration pour répliquer des VM sur site vers un emplacement sur site
secondaire.
202 Chapitre 13  Sauvegarde, récupération et réplication

Tout comme Azure Backup ne fonctionne pas qu'avec Azure, Azure Site Recovery ne
réplique pas que les VM Azure. Azure  Backup et Azure Site Recovery peuvent être
utilisés comme solutions hybrides pour la sauvegarde et la récupération d'urgence. Ces
services Azure peuvent être utilisés pour protéger toutes vos charges de travail, aussi
bien sur site que sur Azure. À des fins de conformité et de validation, vous pouvez
ensuite générer une structure de rapport unique pour vous assurer que toutes les
charges de travail sont effectivement protégées des pertes de données et sécurisées.
Pourquoi utiliser Azure Site Recovery ? Cette solution est principalement utilisée
pour la réplication et la migration.
La réplication vous protège d'une panne totale de la région Azure. Il faudrait qu'un
événement catastrophique se produise pour que toute une région soit coupée, mais
quand vous travaillez dans l'IT, vous savez que tout est possible. Même les ensembles de
disponibilité et les zones de disponibilité dont nous avons parlé au chapitre  7 vous
protègent uniquement des pannes mineures dans une région Azure. Si toute la région
est hors connexion, votre application n'est plus accessible. Avec Site Recovery,
l'ensemble de l'environnement de votre application, y compris les ressources du réseau
virtuel, sont répliquées dans une région Azure secondaire. Un clic sur un bouton suffit
pour mettre en circuit et activer l'emplacement secondaire. Le trafic peut alors être
acheminé vers cet emplacement secondaire, et vos clients ont accès à votre application.
La figure 13.9 illustre de façon simplifiée la manière à laquelle Azure Site Recovery
protège votre environnement.

Environnement de Environnement
production de récupération

Est des États-Unis Ouest des

États-Unis
Ord. virt Azure
Azure Site Recovery
Disques virtuels Disques virtuels
Stratégie de réplication
VM, Configuration et
Réseau virtuel configuration, données répliquées Réseau virtuel
stockage et Coffre Recovery Services
Azure depuis l'environne- Azure
réseau virtuel ment de production
répliqués selon la stratégie
Sous-réseau Sous-réseau
définie

Figure 13.9  Azure Site Recovery réplique la configuration, les données et les réseaux virtuels de
l'environnement de production vers un environnement de récupération. Les VM ne sont créées dans
l'environnement de récupération que si un basculement est initié. Seules les données sont répliquées.

La VM correspond simplement à des métadonnées qui définissent la taille de la VM,

les disques rattachés et les ressources réseau auxquelles la VM se connecte. Ces
métadonnées sont répliquées, ce qui permet de créer rapidement la VM lorsqu'un
basculement est effectué. Les disques virtuels sont répliqués dans l'environnement de
récupération. Lorsqu'une VM de récupération est créée suite à un événement de
basculement, ces disques virtuels sont rattachés.
 Azure Site Recovery 203

Pour une réplication Azure-Azure, il n'y a pas de calendrier de réplication défini. Les
disques sont répliqués quasiment en temps réel. Lorsque des données changent sur les
disques virtuels source, elles sont répliquées dans l'environnement de récupération.
Pour les charges de travail hybrides, lorsque vous protégez des VM VMware ou Hyper-V
sur site, vous définissez des stratégies qui régissent le calendrier de réplication.
Dans le cas d'une réplication Azure-Azure, pourquoi les données sont-elles
répliquées quasiment en temps réel  ? Un cache de compte de stockage est créé à
l'emplacement défini dans l'environnement de production, comme illustré à la
figure  13.10. Les modifications écrites sur les disques virtuels de production sont
immédiatement répliquées dans ce cache de compte de stockage. Le cache de compte
de stockage est ensuite répliqué dans l'environnement de récupération. Ce cache de
compte de stockage fait office de tampon. Ainsi, les éventuels délais de réplication dans
l'emplacement de récupération distant n'affectent pas les performances au niveau de la
charge de travail de production.

Environnement de production Environnement

de récupération
Est des États-Unis
Ouest des
Ord. virt Azure États-Unis
Cache de compte
Disques virtuels
Disques virtuels Les données écrites sur de stockage Données répliquées
les disques de production depuis le cache de
sont immédiatement compte de stockage
répliquées dans le cache vers l'environnement
de compte de stockage. de récupération

Figure 13.10  Les modifications sur les disques virtuels de production sont immédiatement répliquées
dans un cache de compte de stockage. Ce cache de compte de stockage empêche les chutes de
performances au niveau des charges de travail de production, car la réplication des changements dans
l'emplacement de récupération distant est différée. Les changements sont ensuite répliqués depuis le
cache de compte de stockage vers le point de récupération distant de manière à assurer la cohérence
des données.

Le processus de configuration de Site Recovery pour une réplication Azure-Azure est

simple, mais la création de l'ensemble des ressources répliquées nécessaires et la
réplication initiale des données prend un certain temps. Dans l'exercice de fin de
chapitre, vous serez invité à configurer cette réplication Azure -Azure.
Quelle est l'utilité des VM répliquées dans un emplacement secondaire avec Azure
Site Recovery ? Avant tout, croisez les doigts et espérez que vous n'en aurez pas besoin !
Malgré tout, elles pourraient s'avérer utiles dans deux scénarios.
Le premier est évident  : une panne majeure. Si une région Azure se retrouve
complètement inaccessible, par exemple, en cas de sinistre, vous pouvez initier un
basculement de vos ressources. Le basculement indique à Azure Site Recovery de créer
des VM dans l'emplacement de récupération d'après les métadonnées de VM, puis de
rattacher les disques durs virtuels et les connexions réseau. Vous pouvez également
prendre les devants : si une catastrophe naturelle est prévue dans une région Azure,
204 Chapitre 13  Sauvegarde, récupération et réplication

vous pouvez initier un basculement avant que la zone soit sinistrée. Cette approche
vous permet de décider le moment de la mise hors service potentielle entraînée par le
basculement des ressources vers l'emplacement secondaire, généralement en dehors
des heures de travail. Une fois la région Azure principale sécurisée, vous pouvez ensuite
rebasculer vos ressources vers l'emplacement habituel et continuer d'exécuter vos
applications.
Le deuxième scénario dans lequel vous pourriez être amené à initier un basculement est
lorsque vous souhaitez vérifier que le processus fonctionne. Tout comme les sauvegardes, la
réplication et le plan de basculement doivent être testés. Il serait assez gênant (voire très
stressant) de découvrir au moment d'activer un emplacement secondaire qu'il y a un
problème de configuration au niveau des réseaux virtuels, ou que l'une des applications ne
bascule pas correctement. Heureusement, Azure offre une option spécifique pour tester le
basculement. Un réseau virtuel Azure isolé est généralement utilisé dans l'emplacement
secondaire, tandis que les charges de travail de production continuent de
s'exécuter normalement dans l'emplacement principal. Si vous utilisez Azure Site Recovery,
pensez à tester régulièrement le processus de basculement !

13.3 Exercice pratique : configuration d'une VM pour Site Recovery

Vous devez remplir plusieurs conditions avant de configurer une réplication sur site
VMware ou Hyper-V avec Azure Site Recovery. C'est une fonction très utile, à la fois
pour les besoins de récupération d'urgence et pour migrer des VM sur Azure. Mais
vous allez avoir besoin de beaucoup plus de temps que votre pause déjeuner ! Si vous
souhaitez en savoir plus sur ces scénarios, rendez-vous sur http://mng.bz/x71V.
Configurons une réplication Azure-Azure avec la VM de test que vous avez créée et
enregistrée plus tôt :

1 Dans le portail Azure, sélectionnez Groupes de ressources dans le menu de gauche.

2 Sélectionnez le groupe de ressources utilisé dans les exercices précédents, par
exemple, azuremolchapter13.
3 Sélectionnez la VM que vous avez créée dans les exercices précédents, par
exemple, molvm.
4 Sélectionnez Récupération d’urgence dans le menu à gauche de la fenêtre de la VM.
5 Dans les paramètres avancés, examinez les paramètres par défaut utilisés par
Azure Site Recovery pour créer un groupe de ressources et un réseau virtuel à
l’emplacement de destination. Un cache de compte de stockage est créé pour la
réplication à partir des disques virtuels source, ainsi qu'un coffre Recovery
Services et une stratégie pour contrôler le processus de réplication.
6 Vous n'avez rien à changer ici. Notez toutefois que si vous devez utiliser Site
Recovery en production et si vous avez plusieurs VM à protéger, vous devrez
vérifier la correspondance des VM avec les sous-réseaux et réseaux virtuels
répliqués existants. Pour cet exercice, examinez et activez la réplication à l’aide
des valeurs par défaut.
Maintenant, retournez travailler. Sérieusement. La configuration de l'ensemble des
ressources répliquées et la synchronisation initiale des données vont prendre beaucoup
de temps. N'attendez pas, sauf si votre patron accepte que vous preniez une pause
déjeuner vraiment très longue aujourd'hui !
 Exercice pratique : configuration d'une VM pour Site Recovery 205

Vos sauvegardes ne risquent pas d'être supprimées accidentellement

J’espère qu’en tant que bonne pratique, vous avez supprimé les groupes de ressources
et leurs ressources à la fin de chaque chapitre, de manière à conserver vos crédits Azure
gratuits pour les utiliser pour la suite du livre.
Si vous avez des VM protégées par Azure Backup ou Site Recovery, vous ne pouvez pas
supprimer le coffre ou le groupe de ressources Recovery Services de la VM. La
plateforme Azure sait que vous disposez de données actives sauvegardées ou
répliquées, et empêche la suppression de ces ressources.
Pour supprimer des VM protégées, vous devez d'abord désactiver les tâches de
sauvegarde en cours ou les VM répliquées. Vous pouvez alors choisir de conserver les
données protégées ou de les supprimer. Pour les exercices pratiques de ce chapitre,
supprimez les points de restauration. Azure supprime automatiquement ces points de
restauration et vous permet de les restaurer pendant 14 jours, par mesure de sécurité.
Vous n’avez rien à configurer ici, et vous ne pouvez pas supprimer ces points de
restauration de force. Même si je ne le recommande pas, vous pouvez également
désactiv er lafonction de suppression logicielle d’un coffre Recovery Services en
sélectionnant les propriétés du coffre dans le portail Azure.
Heureusement, le reste du groupe de ressources peut être supprimé. Par ailleurs, vous
n’êtes pas facturé pour ces points de restauration supprimés. Lorsque la période de
suppression logicielle de 14 jours est écoulée, le coffre Recovery Services peut être
supprimé normalement. L’objectif ici est de vous protéger contre les suppressions
accidentelles ou malveillantes des points de restauration, tout en vous donnant le temps
de réaliser qu'ils sont réellement nécessaires et de les récupérer.
 14
Chiffrement des données

La sécurité de vos données est importante. Plus précisément, c'est la sécurité des
données de vos clients qui est essentielle. Presque chaque semaine, on apprend
dans les actualités qu'une grande entreprise a été victime d'une violation de
données. Dans la plupart des cas, ces incidents sont dus à un manque de sécurité, à
une mauvaise configuration, ou encore à une simple négligence. À notre ère
numérique, il est bien trop facile pour des utilisateurs malveillants d'automatiser
leurs tentatives d'accès à vos données. Le délai pour récupérer d'un incident de
sécurité à un niveau applicatif n'est rien comparé au temps nécessaire à l'entreprise
pour regagner la confiance de ses clients en cas d'exposition de leurs données.
Avec les fonctionnalités de chiffrement proposées par Azure, vous ne pourrez
plus prétendre que vous n'avez pas le temps ou l'expertise pour sécuriser vos
données. Dans ce chapitre, nous examinons comment chiffrer les données stockées
dans Stockage Azure ou sur des disques gérés, ou encore comment chiffrer
l'intégralité de la machine virtuelle. Des livres entiers ont été écrits sur le chiffrement
des données, et l'objectif de ce chapitre n'est pas de revenir en détail sur les méthodes
et considérations en la matière. Au lieu de cela, vous découvrez comment tirer parti
de certaines fonctions et services clés d'Azure pour sécuriser vos données tout au
long du cycle de vie applicatif.

14.1 Qu'est-ce que le chiffrement des données ?

Lorsque vous effectuez un achat en ligne, vérifiez-vous que la barre d'adresses
comporte une petite icône en forme de cadenas indiquant que le site Web utilise le
protocole HTTPS ? Pourquoi est-il déconseillé d'envoyer vos données bancaires via
une connexion HTTP classique, non sécurisée ? Dans un paquet réseau circulant
entre des appareils, chaque octet de données peut potentiellement être surveillé et
examiné. La figure 14.1 montre comment le fait d'effectuer des achats en ligne sans
connexion HTTPS peut compromettre la sécurité de vos données bancaires.
Les serveurs Web n'ont aucune excuse pour utiliser des connexions non
sécurisées. Chaque application Web que vous créez dans Azure se voit
automatiquement appliquer un certificat SSL générique.

206
 Qu'est-ce que le chiffrement des données ? 207

Les données transmises via une Le serveur Web n'est pas au

connexion HTTP non chiffrée courant que le trafic a été
peuvent être interceptées par intercepté. Il ne peut pas
des utilisateurs malveillants.
Connexion
protéger vos données.
Client Internet au site Web
011
110
101
HTTP

011
110
101

Les utilisateurs malveillants

peuvent accéder à la totalité de
votre trafic réseau et reconstituer
Utilisateur vos informations d'ordre privé,
telles que vos informations de
malveillant carte de crédit et votre adresse
de facturation.

Figure 14.1  Dans cet exemple simple, un utilisateur malveillant pourrait intercepter le trafic réseau envoyé
via une connexion HTTP non chiffrée. Étant donné que vos données ne sont pas chiffrées, cet utilisateur
malveillant pourrait reconstituer les paquets réseau et obtenir vos informations personnelles et financières.
Au contraire, si vous vous connectez au serveur Web via une connexion HTTPS chiffrée, il est impossible
pour un utilisateur malveillant de lire les contenus des paquets réseau et d'accéder aux données.

Un certificat SSL est un composant numérique qui sert à sécuriser le serveur Web et
permet à un navigateur Web de valider la connexion. Il est possible d'utiliser un certificat
SSL générique pour l'intégralité d'un domaine, par exemple *.azurewebsites.net, pour
le domaine par défaut ou pour les applications Web. Lorsque vous avez créé une
application Web au chapitre 3, vous auriez pu ajouter https:// to the web address and
started to use encrypted communications with your web apps. C'est aussi simple que ça !
Les certificats SSL personnalisés sont relativement abordables et faciles à mettre en
œuvre. Grâce à des projets comme Let’s Encrypt (https://letsencrypt.org), vous pouvez
obtenir gratuitement un certificat et configurer automatiquement votre serveur Web
en quelques minutes. Vous pouvez également acheter et utiliser un certificat App
service qui s’intègre directement aux applications Web. Les certificats App Service sont
stockés dans Azure Key Vault, que nous étudierons plus en détail au chapitre 15.
Lorsque vous concevez et créez des applications dans Azure, dans la mesure du possible,
vous devez mettre en œuvre des communications sécurisées. Cette approche permet de
sécuriser les données pendant leur transfert, mais qu'en est-il lorsque ces données sont
écrites sur le disque ? Il existe un processus similaire pour les disques et les machines
virtuelles, qui permet de sécuriser et protéger vos données au repos. La figure 14.2 montre
comment fonctionne le chiffrement des disques et des machines virtuelles.
J'espère que ces exemples simplifiés de chiffrement des données dans Azure vous
encourageront à mettre en œuvre le chiffrement lorsque vous concevez et créez des
applications dans Azure. La plupart des clients s'attendent à ce que leurs données
soient sécurisées, et de nombreuses entreprises sont contraintes par des exigences
réglementaires et de conformité qui rendent obligatoire le chiffrement. Vous ne devez
pas prendre en compte uniquement l'amende potentielle à payer par l'entreprise en
cas de violation des données ou la perte de la confiance des clients. Pensez également
au risque d'exposition des données personnelles et financières de vos clients,
et à l'impact que cela peut avoir
208 Chapitre 14  Chiffrement des données

Les données sont chiffrées

lorsqu'elles sont écrites sur
le disque. Seules vos clés
de chiffrement permettent
d'accéder aux données et
de les déchiffrer.
Disque
géré Azure
Application
Figure 14.2  Lorsque vous chiffrez
vos données, vous seul pouvez
011 Dans le cas des machines virtuelles Azure, déchiffrer le contenu et y accéder.
110
101 Si un utilisateur malveillant parvenait
les données en mémoire et les disques
à accéder à un disque virtuel ou à des
011
temporaires sont également chiffrés.
110 fichiers individuels, il ne serait pas
101 Vous seul pouvez déchiffrer les données
en mesure d'en déchiffrer le contenu.
de la machine virtuelle et y accéder.
Il est possible de combiner les
méthodes de chiffrement : les clients
Blob Fichier peuvent se connecter à votre serveur
Ord. virt Web via HTTPS, vous pouvez forcer
Stockage Stockage Azure le trafic en direction des comptes
Azure Azure de stockage à basculer sur HTTPS,
et vous pouvez chiffrer les données
qui sont écrites sur le disque.

sur leurs vies quotidiennes. Vous n'aimeriez probablement pas que vos propres
données soient ainsi exposées, c'est pourquoi vous devez faire tout votre possible pour
protéger les données de vos clients.

14.2 Chiffrement au repos

Nous l'avons vu, le chiffrement des données est essentiel. Mais comment pouvez-vous
l'utiliser dans Azure ? Continuez simplement à appliquer ce que vous avez déjà appris
dans ce livre ! Je ne sais pas si vous vous en souvenez, mais dès le début de ce livre, j'ai
expliqué que toutes vos machines virtuelles doivent utiliser des disques gérés. De
nombreuses raisons plaident en ce sens, parmi lesquelles la sécurité. Un disque géré
est automatiquement chiffré. Vous n'avez rien à configurer, et il n'y a pas d'impact sur
les performances lorsqu'il est activé. Pas d'exceptions ici : avec les disques gérés, vos
données sont automatiquement chiffrées au repos.
Que signifie exactement chiffrer des données au repos  ? Lorsque vous utilisez des
disques gérés, vos données sont chiffrées lorsqu'elles sont écrites dans le stockage Azure
sous-jacent. Les données situées sur les disques temporaires, ou celles qui se trouvent
dans la mémoire de la machine virtuelle, ne sont pas chiffrées. Ce n'est qu'une fois que
les données du système d'exploitation ou du disque de données sont au repos sur le
disque physique sous-jacent qu'elles sont chiffrées La figure 14.3 montre comment les
données sont chiffrées lorsqu'elles sont écrites sur un disque géré.

Machine virtuelle
Disque
Disque Mémoire géré
temp. virtuelle Les données sont chiffrées
lorsqu'elles sont écrites
sur un disque géré.
Le disque temporaire et les
données en mémoire de la machine
virtuelle ne sont pas chiffrés.

Figure 14.3  Lorsque les données sont écrites sur un disque géré, elles sont chiffrées. Les données situées dans la
mémoire de la machine virtuelle ou sur des disques temporaires locaux de la machine virtuelle ne sont pas chiffrées,
sauf si la totalité de la machine virtuelle est activée pour le chiffrement, une fonctionnalité que nous verrons plus
loin à la section 14.4.2. Le chiffrement automatique des données écrites sur des disques gérés n'entraîne aucune
surcharge de la machine virtuelle. La plateforme Azure effectue l'opération de chiffrement dans le stockage sous-
jacent. La machine virtuelle n'a pas à gérer les processus de chiffrement/déchiffrement.
 Storage Service Encryption 209

Ce chiffrement au repos sur des disques gérés n'a aucun impact en termes de
performances des machines virtuelles. La machine virtuelle n'a pas à effectuer de
traitement supplémentaire pour chiffrer et déchiffrer les données, de sorte que toute
la puissance d'UC disponible peut être utilisée pour exécuter les applications. Dans les
scénarios standard de chiffrement de machine virtuelle, la machine virtuelle utilise
une certaine quantité de puissance de calcul pour traiter et gérer le chiffrement des
données. Avec de chiffrement automatique des disques gérés, le prix à payer est que
seuls le système d'exploitation et les disques de données sont sécurisés. Les autres
données situées dans la mémoire ou sur le disque temporaire de la machine virtuelle
pourraient, potentiellement, être exposées.
Microsoft gère les clés de chiffrement numérique sur la plateforme Azure à l'aide du
chiffrement automatique des disques gérés. Mais là encore il y a un prix à payer, c'est
que si vous pouvez chiffrer automatiquement vos données sans avoir besoin de créer, de
gérer, d'assurer la rotation ou de révoquer des clés, vous devez faire confiance
à Microsoft pour protéger ces clés.

14.3 Storage Service Encryption

Le chiffrement automatique des disques gérés est une excellente fonctionnalité, mais
comment faire si vous utilisez Azure Storage pour le stockage blob ou le stockage de
fichiers ? Azure Storage Service Encryption (SSE) vous permet de chiffrer les données au
niveau du compte de stockage. Les données sont chiffrées lorsqu'elles sont écrites dans
le compte. Là encore, Microsoft gère les clés de chiffrement, ce qui signifie qu'il n'y a pas
de contrainte de gestion ni de configuration à effectuer. La plateforme Azure génère et
gère les clés à votre place. Si vous préférez, vous pouvez créer et utiliser vos propres clés
de chiffrement, avec dans ce cas quelques contraintes de gestion supplémentaires. Tout
comme le chiffrement automatique des disques gérés au repos, le chiffrement du
stockage Azure est automatiquement activé lorsque vous créez un compte.
Que ce soit avec le chiffrement automatique des disques gérés ou le SSE, l'objectif est
de simplifier autant que possible le chiffrement de vos données et de vous permettre de
consacrer plus de temps à concevoir, créer et exécuter vos applications. La figure 14.4
montre comment le SSE protège vos données et peut également forcer des
communications sécurisées pendant le transfert des données.

Compte de
stockage chiffré HTTP
Application
Données
HTTPS
Les données sont chiffrées
lorsqu'elles sont écrites Blob Fichier Seul le trafic utilisant une
dans le stockage blob communication chiffrée, telle
ou de fichiers. que HTTPS, est accepté.

Figure 14.4  Lorsque vous activez le SSE, les objets blob et fichiers Azure sont chiffrés lorsque les données sont écrites
sur le disque. Les tables et files d'attente Azure ne sont pas chiffrées. Pour renforcer la sécurité des données, vous
pouvez forcer toutes les communications associées à un compte Stockage à utiliser des protocoles de communication
sécurisés, comme HTTPS. Cette approche permet de protéger les données pendant leur transfert jusqu'au moment où
elles sont chiffrées sur le disque.

Comment forcer le trafic de stockage à utiliser des transferts sécurisés

En plus d'activer le SSE, vous pouvez forcer l'ensemble de requêtes de stockage et des
transferts à utiliser une méthode de communication sécurisée. Cela force tous les appels
de l'API REST à utiliser HTTPS, et toutes les connexions de fichiers Azure qui n'activent pas
le chiffrement, comme les anciennes versions du protocole SMB, à être supprimées.
210 Chapitre 14  Chiffrement des données

(suite)
Les SDK Azure, comme les exemples Python que nous avons examinés au chapitre 4, peuvent
utiliser des connexions chiffrées. Les documents de référence pour chaque SDK spécifique à un
langage fournissent des conseils sur la façon de mettre en œuvre des communications
sécurisées.

L'utilisation de communications sécurisées doit être intégrée aux applications dès le départ.
L'activation de communications sécurisées sur une application existante peut poser problème si
certains composants n'ont pas été correctement configurés au départ. À tout le moins, vous
devez commencer par tester les communications sécurisées pour une application existante
dans un environnement de développement.

Tester
Pour créer un compte de stockage et activer le chiffrement et les communications sécurisées,
procédez comme suit :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell dans le menu du haut.
2 Créez un groupe de ressources, en spécifiant un nom de groupe de ressources, par
exemple azuremolchapter14, et un emplacement, par exemple eastus :
az group create --name azuremolchapter14 --location eastus

3 Créez un compte de stockage avec az storage account create. Spécifiez un nom unique,

par exemple azuremolstorage, puis indiquez le groupe de ressources que vous
avez créé à l'étape 2. Indiquez un type de compte de stockage, par exemple Standard_LRS
pour le stockage localement redondant. Pour forcer les communications sécurisées,
définissez --https-only.
az storage account create \
--name azuremolstorage \
--resource-group azuremolchapter14 \
--sku standard_lrs \
--https-only true

4 Vérifiez que le compte de stockage est chiffré et activé pour les communications
sécurisées en interrogeant enableHttpsTrafficOnly et les paramètres de chiffrement :
az storage account show \
--name azuremolstorage \
--resource-group azuremolchapter14 \
--query [enableHttpsTrafficOnly,encryption]

La sortie est du type de celle présentée ci-dessous :

[
 true,
 {
  "keySource": "Microsoft.Storage",
 Chiffrement de machine virtuelle 211

  "keyVaultProperties": null,
  "services": {
   "blob": {
    "enabled": true,
    "lastEnabledTime": "2019-09-27T03:33:17.441971+00:00"
   },
   "file": {
    "enabled": true,
    "lastEnabledTime": "2019-09-27T03:33:17.441971+00:00"
   },
   "queue": null,
   "table": null
  }
 }
]

14.4 Chiffrement de machine virtuelle

Le chiffrement automatique des disques gérés Azure garantit un certain niveau de
sécurité des machines virtuelles. Pour une approche globale de la sécurité des données
de machine virtuelle, vous pouvez chiffrer la machine virtuelle elle-même. Ce processus
va plus loin que le chiffrement des disques durs virtuels sous-jacents. Le disque du
système d'exploitation et tous les disques de données associées, ainsi que le disque
temporaire, sont chiffrés. La mémoire de la machine virtuelle est également chiffrée
afin de réduire encore davantage la surface d'attaque. Vous utilisez des clés numériques
pour chiffrer les machines virtuelles.
Le fait de chiffrer la totalité de la machine virtuelle présente l'avantage de vous
permettre de gérer les clés de chiffrement. Ces clés de chiffrement sont stockées en
toute sécurité dans Azure Key Vault, et vous pouvez choisir d'utiliser des clés générées
par le logiciel ou par le matériel. Vous contrôlez ces clés, ce qui vous permet de définir
leur accès et d'utiliser les contrôles d'accès en fonction du rôle et les audits à des fins de
suivi de l'utilisation. Vous pouvez également effectuer la rotation des clés de chiffrement
selon un calendrier défini, de la même façon que vous changez votre mot de passe tous
les 60 ou 90 jours. Ces contrôles et tâches de gestion supplémentaires pour les clés de
chiffrement ajoutent des contraintes de gestion mais vous procurent une
flexibilité optimale pour sécuriser vos données, et ils peuvent être requis à certaines
fins réglementaires. Examinons un peu plus en détail Azure Key Vault.

14.4.1 Stockage des clés de chiffrement dans Azure Key Vault

Nous allons aborder Azure Key Vault dans le chapitre 15, mais je souhaitais d'abord
vous montrer toute la puissance du chiffrement des données et des machines virtuelles.
Pour résumer, Azure Key Vault est un coffre numérique qui vous permet de stocker en
toute sécurité des clés de chiffrement, des certificats SSL et des secrets
tels que des mots de passe. À des fins de redondance, les coffres de clés sont répliqués
dans les régions Azure. Cette réplication protège vos clés et vos secrets, et vous garantit
qu'ils sont toujours disponibles.
Vous seul avez accès à vos coffres de clés. Vous générez des objets et les stockez dans
des coffres de clés, puis vous définissez qui a accès à ces coffres. Microsoft gère le
service Key Vault sous-jacent mais n'a pas accès au contenu des coffres. Cette limite de
sécurité signifie que lorsque vous chiffrez vos données dans Azure, vous seul pouvez les
déchiffrer et y accéder.
212 Chapitre 14  Chiffrement des données

Tester
Pour créer un coffre de clés et une clé de chiffrement, procédez comme suit :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell dans le menu du haut.
2 Créez un coffre de clés à l'aide de la commande az keyvault create. Spécifiez
le groupe de ressources que vous avez créé dans l'exercice précédent, par
exemple azuremolchapter14, puis fournissez un nom unique pour votre coffre
de clés, tel que azuremolkeyvault :
az keyvault create \
--resource-group azuremolchapter14 \
--name azuremolkeyvault \
--enabled-for-disk-encryption

Je vous propose maintenant de vous arrêter pour réfléchir à la raison pour laquelle
vous ajoutez un paramètre pour --enabled-for-disk-encryption. Lorsque vous
chiffrez une machine virtuelle, la plateforme Azure doit être en mesure de la démarrer
et de la déchiffrer pour qu'elle puisse s'exécuter. La plateforme Azure n'est pas
autorisée à accéder à ces données, et Microsoft ne peut pas afficher les clés de
chiffrement et les utiliser pour autre chose que pour démarrer une machine virtuelle.
Lorsque vous activez un coffre de clés pour le chiffrement de disque, vous autorisez
Azure à accéder à ce coffre ainsi qu'à utiliser la clé de chiffrement associée à une
machine virtuelle.
Encore une fois, Microsoft n'a pas accès à ces clés ni à vos données, et peut
uniquement démarrer votre machine virtuelle chiffrée. Vous admettrez qu'il est difficile
de faire grand-chose avec une machine virtuelle chiffrée si elle ne peut pas démarrer.
La figure 14.5 montre comment la plateforme Azure utilise la clé de chiffrement pour
démarrer une machine virtuelle chiffrée.

Plateforme 2. La plateforme Azure demande la clé de

1. La plateforme Azure tente de Azure chiffrement au coffre de clés pour déchiffrer
démarrer une machine virtuelle la machine virtuelle et la démarrer
chiffrée. Elle obtient les informations
de la clé de chiffrement requise. 3. Le coffre de clés est activé
pour le chiffrement de disque
4. La machine et retourne la clé requise
virtuelle est
démarrée
Azure Key Vault
Ord. virt
Azure Clé de chiffrement

Figure 14.5  Lorsqu'un coffre de clés est activé pour le chiffrement de disque, il autorise la plateforme
Azure à demander et utiliser la clé de chiffrement pour démarrer une machine virtuelle chiffrée.

Les clés peuvent être créées et stockées dans un logiciel, mais il est également possible
de les stocker dans des modules de sécurité matérielle (HSM) pour plus de sécurité.
Les clés logicielles sont adaptées à de nombreuses applications, même si l'utilisation de
HSM peut vous être imposée par des exigences de sécurité. Nous reviendrons plus en
détail sur ce point dans le prochain 15.
 Chiffrement de machine virtuelle 213

3 Pour créer une clé, spécifiez le coffre que vous avez créé à l'étape précédente,
par exemple azuremolkeyvault, puis indiquez un nom de clé, tel que
azuremolencryptionkey :
az keyvault key create \
--vault-name azuremolkeyvault \
--name azuremolencryptionkey \
--protection software

14.4.2 Chiffrement d'une machine virtuelle Azure

La clé de chiffrement que vous avez créée dans la section 14.4.1 peut être utilisée pour
chiffrer de nombreuses machines virtuelles, si vous le souhaitez. Cette approche réduit
la contrainte liée à la gestion des clés et, si vous utilisez des VMSS (Virtual Machine
Scale Sets, ou groupes de machines virtuelles identiques), cela vous permet d'ajuster
automatiquement le nombre d'instances de machine virtuelle sans avoir à générer des
clés de chiffrement à chaque fois. Autrement, chaque machine virtuelle dispose de
ses propres clés de chiffrement. Même si cette méthode est plus complexe, elle fournit
une couche de sécurité à vos machines virtuelles. Si vous utilisez par exemple la même
clé de chiffrement pour les machines virtuelles d’application back-end et pour les
machines virtuelles de base de données, un attaquant potentiel qui dispose de cette clé
pourrait accéder aux données des deux ensembles de machines virtuelles. Si différentes
clés sont utilisées, le nombre de machines virtuelles potentiellement compromises est
réduit. Dans l'exercice pratique en fin de chapitre, vous chiffrerez une seule machine
virtuelle, même si le même processus fonctionne aussi avec un VMSS comprenant
plusieurs machines virtuelles, qui utilise uniquement cette clé. Veillez à concevoir et
intégrer des fonctions de sécurité, en particulier lorsque vous travaillez avec des
applications plus volumineuses offrant des fonctionnalités de mise à l'échelle.
Lorsque vous chiffrez une machine virtuelle, une extension de machine virtuelle
Azure est installée. Cette extension contrôle le chiffrement du disque de système
d'exploitation, du disque temporaire, des éventuels disques de données associés et des
données en mémoire, comme illustré à la figure  14.6. Pour les machines virtuelles
Windows, le mécanisme de chiffrement BitLocker est utilisé. Pour les machines
virtuelles Linux, dm-crypt est utilisé pour traiter le chiffrement. L'extension de
machine virtuelle peut ensuite rendre compte de l'état du chiffrement et déchiffrer la
machine virtuelle selon vos besoins.

Lorsque vous chiffrez une machine Ord. virt Azure

virtuelle, l'extension de chiffrement
de disque de machine virtuelle est
Extension de BitLocker /
installée sur cette machine virtuelle.
chiffrement de Processus DM-
Extension
disque de L'extension gère les Crypt
machine virtuelle processus de niveau
système d'exploitation pour
chiffrer/déchiffrer les données.

Figure 14.6  Lorsque vous chiffrez une machine virtuelle, l'extension de chiffrement de disque Azure est installée.
Cette extension gère l'utilisation de BitLocker sur les machines virtuelles Windows ou de dm-crypt sur les machines
virtuelles Linux afin d'effectuer le chiffrement des données sur votre machine virtuelle. Elle est également utilisée
lorsque vous interrogez l'état du chiffrement pour une machine virtuelle.

Étant donné que l'extension de chiffrement de disque de machine virtuelle s'appuie

sur BitLocker ou dm-crypt, il existe des limites à l'utilisation du chiffrement de machine
virtuelle. La plupart des images Azure Marketplace prennent en charge le chiffrement
de disque, même s'il existe des restrictions concernant les tailles de machines virtuelles
214 Chapitre 14  Chiffrement des données

qui prennent en charge le chiffrement ou le chiffrement des partages de fichiers

réseau connectés tels que les fichiers Azure. Pour obtenir les informations les plus
complètes sur les limites prises en charges et les éléments à prendre en compte pour le
chiffrement de machine virtuelle, consultez les documents Azure les plus récents à
l'adresse http://mng.bz/yyvd.
Ce chapitre vous a présenté rapidement les fonctions de sécurité et de chiffrement des
données disponibles dans Azure. Le chiffrement automatique pour les disques gérés et le
SSE ne nécessite pas beaucoup de configuration, rien ne vous empêche donc d'y recourir.

14.5 Exercice pratique : chiffrement d'une machine virtuelle

Pour voir tout cela en pratique, je vous propose de chiffrer une machine virtuelle à
l'aide de la clé de chiffrement que vous avez stockée dans votre coffre de clés :
1 Créer une machine virtuelle. La plupart des images Linux disponibles dans
l'Azure Marketplace prennent en charge le chiffrement, tout comme les images
Windows Server 2008 R2 et versions ultérieures. Pour accélérer et simplifier le
chiffrement, créez une machine virtuelle Ubuntu LTS, comme vous l'avez déjà
fait à plusieurs reprises dans ce livre. Étant donné que la VM nécessite
suffisamment de mémoire pour effectuer l’opération de chiffrement de disque,
indiquez une taille Standard_D2s_v3 :
az vm create \
--resource-group azuremolchapter14 \
--name molvm \
--image ubuntults \
--size Standard_D2s_v3 \
--admin-username azuremol \
--generate-ssh-keys

2 Activez le chiffrement sur la machine virtuelle et indiquez le nom Azure Key

Vault et la clé numérique que vous avez créée dans l'exercice précédent :
az vm encryption enable \
--resource-group azuremolchapter14 \
--name molvm \
--disk-encryption-keyvault azuremolkeyvault \
--key-encryption-key azuremolencryptionkey

Il faut quelques minutes pour installer l'extension de chiffrement de disque de

machine virtuelle Azure et démarrer le processus de chiffrement de la machine
virtuelle.
3 Une fois que le chiffrement a commencé, surveillez sa progression et
préparez-vous à redémarrer la machine virtuelle pour terminer le processus
de chiffrement. Affichez l'état comme suit :
az vm encryption show \
--resource-group azuremolchapter14 \
--name molvm \
--query ‘status’

Voici un exemple de sortie d'une machine virtuelle en cours de chiffrement.

Au  début, le message d’état indique
[
 {
  "code": "ProvisioningState/succeeded",
   "displayStatus": "Provisioning succeeded",
  "level": "Info",
 Exercice pratique : chiffrement d'une machine virtuelle 215

   "message": "OS disk encryption started",

  "time": null
 }
]

Le chiffrement du disque peut prendre un certain temps, je vous suggère donc

d'attendre environ une heure avant de repasser sur cet exercice pratique, sauf si
vous avez envie de prendre une longue pause déjeuner ! Attention, je ne me prends
pas pour votre patron, mais vous allez vite vous ennuyer à force de regarder le
même message d'état.
4 Lorsque l'état du chiffrement est Encryption succeeded for all
volumes, redémarrez la VM :
az vm restart --resource-group azuremolchapter14 --name molvm

Vous pouvez ensuite contrôler à nouveau l'état du chiffrement de la machine

virtuelle à l'aide de az vm encryption show afin de confirmer que l'état de la
machine virtuelle est Encrypted (Chiffrée).

N'oubliez pas de faire le ménage

Les deux derniers exercices pratiques de fin de chapitre n'étaient pas longs à faire, mais
ils ont peut-être mis du temps à se terminer. N'oubliez pas de revenir en arrière et de
supprimer les ressources lorsque vous avez terminé de les utiliser.
Comme nous l’avons vu au chapitre 13, n’oubliez pas de désactiver Azure Backup ou la
protection Site Recovery avant de supprimer le coffre Recovery Services ou le
groupe de ressources (une fois les 14 jours écoulés pour l'expiration des points de
récupération gratuits supprimés). Veillez à revenir en arrière et à supprimer ces
ressources avant qu'elles ne commencent à utiliser trop de vos crédits Azure gratuits.
 15
Sécurisation des informations
avec Azure Key Vault

Presque chaque semaine, on apprend qu'une grande entreprise a été victime d'un
incident de cybersécurité. De la même manière que vous avez utilisé différents
modes d'automatisation pour faire évoluer ou répliquer vos applications et vos
données, les utilisateurs malveillants automatisent leurs propres actions. Il est peu
probable qu'une seule personne tente manuellement de compromettre la sécurité
de vos systèmes. Dès lors, il devient difficile de défendre vos systèmes 24 heures/24,
7 jours/7, 365 jours/an (ou 366 jours, si vous voulez !).
Dans le chapitre 14, nous avons vu comment chiffrer vos données et vos machines
virtuelles. Ce processus constitue un premier pas important, et nous avons aussi vu
rapidement comment créer et utiliser des clés de chiffrement stockées avec le service
Azure Key Vault. La meilleure approche pour stocker des données sécurisées telles
que les clés, secrets et certificats consiste à utiliser un coffre numérique, par exemple
un coffre de clés, qui gère, émet et audite l'utilisation de vos informations
d'identification et données critiques, le tout de façon centralisée. Lorsque vos
applications et services ont besoin d'accéder à différentes ressources, ils peuvent
automatiquement demander, récupérer et utiliser ces clés, secrets et informations
d'identification. Dans ce chapitre, vous découvrirez pourquoi et comment créer un
coffre de clés sécurisé, contrôler l'accès aux secrets et certificats, puis stocker et
récupérer ces derniers.

15.1 Sécurisation des informations dans le cloud

Les applications deviennent de plus en plus complexes et le risque de cyberattaque
s'intensifie, c'est pourquoi la sécurité est aujourd'hui un élément essentiel à prendre
en compte dans la façon dont vous concevez et exécutez vos services. Une méthode
à privilégier consiste à limiter le risque d'accès non autorisé aux données, surtout si
vous exécutez davantage d'applications publiées sur Internet, que ce soit dans le
cloud ou sur site. Cela ne sert à rien d'avoir la meilleure pizzéria au monde si les
clients n'ont pas suffisamment confiance pour confier leurs informations de
paiement ou personnelles.

216
 Sécurisation des informations dans le cloud 217

Une méthode courante pour assurer la sécurité des applications et des services consiste à
utiliser des clés numériques, des secrets et des certificats, comme illustré à la figure 15.1.
Plutôt que de recourir à un nom d'utilisateur et un mot de passe que vous devez, chaque
fois, saisir manuellement (ou pire encore peut-être, qui sont écrits dans un fichier de
configuration non chiffré), vous utilisez un coffre numérique pour stocker ces informations
d'identification et données sécurisées. Lorsqu'une application ou un service fait une
demande d'accès, il lui faut demander la clé ou le secret nécessaire, et une piste d'audit est
également créée afin de suivre toute utilisation incorrecte ou violation de sécurité.

Machines
Applications Services
virtuelles

Les applications et services,

ou encore les ressources
Azure telles que les machines Des éléments tels que des
virtuelles, peuvent afficher, certificats, clés et secrets
créer et mettre à jour des (mots de passe, par
Clé Coffre exemple) peuvent être
éléments stockés dans le
coffre. stockés en toute sécurité
dans le coffre, et il est
possible d'auditer leur
accès.

Certificats Secrets Clés

Figure 15.1  Azure Key Vault constitue une méthode sécurisée pour stocker des informations numériques telles
que des certificats, des clés et des secrets. Ces éléments sécurisés sont alors directement accessibles par vos
applications et services, ou encore par les ressources Azure telles que les machines virtuelles. Avec un minimum
d'interaction humaine, vous pouvez distribuer de manière centralisée des informations d'identification et des
certificats sécurisés dans vos environnements applicatifs.

Lorsqu'ils sont correctement conçus et mis en œuvre, ces coffres numériques sont
presque entièrement automatisés et sécurisés. Les services peuvent demander un
nouveau certificat numérique, qui est alors émis, puis stocké en toute sécurité dans le
coffre, et ils peuvent ensuite utiliser ce certificat pour s'octroyer l'accès à d'autres
composantes d'application. Les serveurs peuvent configurer des logiciels en récupérant
les secrets tels que les mots de passe dans le coffre numérique, puis en installant les
composants d'application, sans que les informations d'identification ne soient stockées
dans un fichier de configuration texte. Un administrateur d'application peut gérer de
manière centralisée l'ensemble des secrets, clés et certificats associés à un service, et les
mettre à jour régulièrement en fonction des besoins.
Azure Key Vault propose toutes ces fonctions de sécurité numérique et vous permet
de contrôler étroitement quels utilisateurs et quelles ressources sont autorisés à accéder
aux données sécurisées. Les coffres de clés peuvent être répliqués de façon sécurisée à
des fins de redondance et d'amélioration des performances des applications, et ils
s'intègrent avec les ressources Azure courantes telles que les machines virtuelles, les
applications Web et les comptes Azure Storage.

15.1.1 Coffres avec protection logicielle et modules de sécurité matérielle

Avant de voir en pratique comment créer et utiliser un coffre de clés, il est important
de comprendre comment vos informations sécurisées sont stockées dans un coffre.
Comme illustré à la figure 15.2, dans un coffre de clés, l'ensemble des clés, secrets et
certificats sont stockés dans un module de sécurité matérielle (HSM). Ces modules
matériels ne sont pas spécifiques à Azure, ils sont utilisés dans tout le secteur et
fournissent un niveau élevé de sécurité pour les données qui y sont stockées.
218 Chapitre 15  Sécurisation des informations avec Azure Key Vault

Azure Key Vault

Tous les certificats, secrets et clés Logiciel -coffre protégé

associés à un coffre de clés sont
stockés dans des modules de
sécurité matérielle, au sein des
datacenters Azure.
Opérations de
Pour les coffres avec protection
chiffrement
logicielle, les opérations de
chiffrement/déchiffrement
sont exécutées au niveau du
logiciel, en dehors du HSM.

Matériel Module (HSM)

de sécurité
Certificats Secrets Clés

Figure 15.2  Azure Key Vault est une ressource logique située dans Azure, mais les certificats, secrets
et clés sont stockés dans un HSM (module de sécurité matérielle). Pour les scénarios de développement
ou de test, il est possible d'utiliser un coffre avec protection logicielle, qui exécute toutes les opérations
de chiffrement, telles que le chiffrement/déchiffrement des données, au niveau du logiciel et non du
matériel sur le HSM. Pour la production, vous devez utiliser un coffre avec protection par HSM, dans
lequel tout le traitement est effectué au niveau du matériel.

Pour le moment, deux  types de coffres de clés sont disponibles  : avec protection
logicielle et avec protection par HSM. Cette différence peut porter à confusion, c'est
pourquoi il convient de l'expliquer avant de commencer :
¡ Un coffre avec protection logicielle stocke les clés, secrets et certificats dans un HSM,
mais toutes les opérations de chiffrement nécessaires pour chiffrer ou déchiffrer
son contenu sont exécutées par la plateforme Azure au niveau du logiciel. Les
coffres avec protection logicielle sont une bonne solution pour les scénarios de
développement et de test, même si vous pouvez décider qu'une méthode un peu
plus sécurisée est nécessaire pour les charges de travail de production.
¡ Un coffre avec protection par HSM stocke les clés, secrets et certificats dans un HSM, et
les opérations nécessaires pour chiffrer ou déchiffrer son contenu sont exécutées
directement au niveau du HSM. Vous pouvez également générer vos propres clés
sécurisées dans un HSM local, puis les importer dans Azure. Cela implique des
outils et processus supplémentaires, mais avec cette méthode, vous êtes certain de
contrôler totalement les clés, et vous êtes sûr qu'elles ne quitteront jamais le HSM.
Pour optimiser la sécurité et l'intégrité de vos données, les
coffres avec protection matérielle constituent l'approche à privilégier pour les
charges de travail de production.
Quel que soit le type de coffre que vous utilisez, il est important de garder à l'esprit que
toutes vos données sont stockées de façon sécurisée sur un HSM conforme à la norme
FPIS (Federal Information Processing Standard) 140–2 de niveau 2 (au minimum), et
que Microsoft ne peut pas accéder à vos clés ni les récupérer. Les coffres protégés par
HSM impliquent un coût supplémentaire, ce qui signifie que comme pour tout ce qui
touche à Azure et au cloud computing, vous devez comparer le coût par rapport au
risque encouru en cas de compromission de vos données.
 Sécurisation des informations dans le cloud 219

15.1.2 Création d'un coffre de clés et d'un secret

Ce principe du coffre numérique est excellent, mais vous vous demandez peut-être
comment exploiter toute la puissance d'Azure Key Vault. Prenons l'exemple d'un
serveur de base qui exécute une base de données telle que MySQL Server, comme
illustré à la figure 15.3.

1. La machine virtuelle 2. Si l'accès au coffre de

fait une demande pour
obtenir le secret auprès
du coffre de clés
Machine
virtuelle Linux
clés et au secret est
autorisé, le secret est
récupéré dans le coffre
Mot de passe de
Clé Coffre base de données

3. Le secret est renvoyé

à la machine virtuelle.

4. Le secret est utilisé pour fournir

un mot de passe sécurisé pour
l'installation de MySQL Server.

Installation de
MySQL Server

Figure 15.3  Dans les prochains exercices, vous allez créer un exemple de secret stocké dans un coffre
de clés qui peut être utilisé comme mot de passe de base de données pour une installation de MySQL
Server. Une machine virtuelle disposant des autorisations nécessaires pour demander le secret auprès
du coffre de clés est créée. Le secret récupéré est ensuite utilisé pour saisir automatiquement des
informations d'identifications sécurisées pendant le processus d'installation de l'application.

L'un des premiers exercices proposés dans ce livre consistait à créer une machine
virtuelle, puis à installer la pile Web LAMP. Un mot de passe MySQL Server vous a
probablement été demandé, ou un mot de passe vide a été utilisé automatiquement.
Maintenant que vous connaissez tout ce qu'il y a à savoir sur les coffres de clés, vous
pouvez récupérer automatiquement un mot de passe dans le coffre et l'utiliser de
façon dynamique pour installer et configurer le serveur.

Tester
Pour créer un coffre de clés et ajouter un secret, procédez comme suit :

1 Ouvrez le portail Azure, lancez Cloud Shell et créez un groupe de ressources, par
exemple azuremolchapter15 :
az group create --name azuremolchapter15 --location eastus

2 Créez un coffre de clés en lui attribuant un nom unique, tel que azuremol,
et activez-le pour le déploiement de façon à pouvoir l'utiliser pour injecter des
clés et certificats :
az keyvault create \
--resource-group azuremolchapter15 \
--name azuremol \
--enable-soft-delete \
--enabled-for-deployment
220 Chapitre 15  Sécurisation des informations avec Azure Key Vault

Par défaut, votre compte utilisateur Azure se voit attribuer des autorisations
complètes sur le coffre de clés. Cela ne pose aucun problème pour ces exercices,
même si comme bonne pratique de sécurité, vous devriez envisager de restreindre
l'accès à votre coffre de clés. Vous pouvez ajouter le paramètre --no-self-perms
pour ignorer l'attribution de l'autorisation à votre compte.
3 Créez un secret, tel que databasepassword, et attribuez une valeur de mot de
passe, par exemple SecureP@ssw0rd. (Original, n'est-ce pas  ?) Ce secret peut
être utilisé pour s'identifier auprès d'un serveur de base de données, que vous
déploierez dans les exercices suivants :
az keyvault secret set \
--name databasepassword \
--vault-name azuremol \
--description "Database password" \
--value "SecureP@ssw0rd"

4 Vous disposez d'autorisations complètes sur le coffre de clés, de sorte que vous
pouvez afficher le contenu de votre secret :
az keyvault secret show \
--name databasepassword \
--vault-name azuremol

Du point de vue de la gestion, vous pouvez également effectuer des opérations

courantes telles que la sauvegarde et la restauration, le téléchargement, la mise à jour
et la suppression d'éléments stockés dans un coffre de clés. Une autre propriété que
vous avez définie lors de la création du coffre de clés est l'activation de la suppression
réversible (paramètre enable-soft-delete). Attention, si vos applications et services ne
peuvent pas récupérer les secrets dont ils ont besoin dans le coffre de clés, vous
pourriez avoir à faire face à une longue interruption de votre application ! Un coffre
de clés peut stocker des métadonnées associées aux secrets pendant jusqu'à 90 jours
après leur suppression, ce qui vous permet de récupérer les données qui ont été
supprimées par erreur ou par malveillance.
5 Pour simuler une erreur ou un comportement malveillant, supprimez la clé que
vous venez de créer :
az keyvault secret delete \
--name databasepassword \
--vault-name azuremol

6 Récupérez le secret de sorte que vous puissiez continuer à utiliser le mot de passe
de base de données avec votre application et vos services :
az keyvault secret recover \
--name databasepassword \
--vault-name azuremol

Si vous souhaitez vraiment supprimer un secret, vous avez également la possibilité de le

« purger ». Cette option permet de supprimer définitivement le secret sans attendre
que la période de récupération par défaut de 90 jours soit expirée.
N'hésitez pas à utiliser à nouveau az keyvault secret show pour afficher les
informations sur votre secret et confirmer que le mot de passe que vous avez stocké est bien
 Identités gérées pour les ressources Azure 221

là après que vous l'ayez supprimé et restauré. Voyons maintenant comment une machine
virtuelle peut accéder à un coffre de clés et utiliser le secret pour installer MySQL Server.

15.2 Identités gérées pour les ressources Azure

Le fait de pouvoir utiliser Azure Key Vault pour stocker des secrets ou des clés est
vraiment utile, mais comment faire pour accéder à ces secrets ? La CLI Azure ou Azure
PowerShell peuvent accéder aux informations stockées dans un coffre de clés, mais il
est souvent plus pratique d'autoriser vos machines virtuelles ou applications à
récupérer directement les secrets ou les clés lorsqu'elles en ont besoin. Pour ce faire,
une méthode consiste à utiliser des identités gérées pour les ressources Azure, comme
illustré à la figure 15.4.

Azure Active
1. Un principal de service (un Directory
type de compte spécial) est
créé dans Azure Active Directory Principal de service

Activation de l'identité
de service géré sur une
machine virtuelle Azure
2. L'identité de service géré
est appliquée à une machine
virtuelle qui accorde l'accès
aux ressources Azure
Instance 3. La machine virtuelle utilise
Instance Metadata Service pour
Metadata faire une demande de jeton
Service d'accès afin de se connecter
à un service ou une ressource
Ord. virt Ressource
Azure 4. Le jeton d'accès est utilisé Azure
pour se connecter à une
ressource, par exemple pour
récupérer le secret dans le
coffre de clés

Figure 15.4  Lorsque vous créez une identité de service géré pour une machine virtuelle, un principal de service
est créé dans Azure Active Directory. Ce principal de service est un type spécial de compte qui peut être utilisé par
les ressources pour s'authentifier. Cette machine virtuelle utilise ensuite le point de terminaison Instance
Metadata Service pour faire des demandes d'accès aux ressources. Le point de terminaison se connecte à Azure
AD pour demander des jetons d'accès lorsque la machine virtuelle doit demander des données provenant d'autres
services. Lorsqu'un jeton d'accès est renvoyé, il peut être utilisé pour demander l'accès à des ressources Azure,
par exemple un coffre de clés.

Une identité gérée vous permet de créer un type spécial de compte qui peut être utilisé
par une ressource Azure, comme une machine virtuelle. Si vous avez utilisé un service
d'annuaire tel que Active Directory, un compte d'ordinateur est souvent utilisé pour
identifier et octroyer l'accès à différentes ressources réseau dont un ordinateur a
besoin. Pour ce type d'authentification, il n'est pas nécessaire de créer et d'utiliser des
comptes utilisateur classiques, ce qui contribue à renforcer la sécurité : vous pouvez
octroyer un ensemble restrictif d'autorisations à un ordinateur uniquement, ce qui
vous évite d'avoir également à vous soucier des autorisations utilisateur et de l'accès
aux dossiers partagés, par exemple.
Une identité gérée est semblable à un compte d'ordinateur, mais elle est stockée
dans Azure Active Directory (Azure AD). L'identité, qui est appelée principal de service,
est propre à chaque machine virtuelle et peut être utilisée pour attribuer des
222 Chapitre 15  Sécurisation des informations avec Azure Key Vault

autorisations à d'autres ressources Azure, par exemple un compte Stockage Azure ou

un coffre de clés. La machine virtuelle dispose d'autorisations pour accéder à ces
ressources, de sorte que vous pouvez scripter des tâches (de la même façon qu'avec
Azure Automation, qui fait l'objet du chapitre  18) qui ne nécessitent aucune
intervention de l'utilisateur, ou encore des invites de nom d'utilisateur et de mot de
passe. Les machines virtuelles s'authentifient, et la plateforme Azure autorise l'accès
aux ressources qui leur sont attribuées.
Vous pouvez créer deux types d’identités gérées :
¡ Attribuées au système  : ce type d’identité gérée est appliqué directement à une
ressource, comme une machine virtuelle, et n’est utilisé que par cette ressource.
Chaque ressource dispose de sa propre identité unique d'accès en cas d'audit ou
de résolution de problèmes. Lorsque la ressource est supprimée, l’identité gérée
est supprimée automatiquement.
¡ Attribuées à l’utilisateur  : une ressource Azure distincte est créée et gérée pour
l’identité gérée spécifiée. Cette identité gérée peut être partagée avec d’autres
ressources pour définir l’accès. Lorsque des ressources qui utilisent l’identité
sont supprimées, l'identité gérée peut toujours être utilisée.
Voyons maintenant comment vous pouvez utiliser une identité gérée attribuée au
système pour demander le secret databasepassword auprès d'un coffre de clés. Une
fois que la machine virtuelle peut récupérer le secret, le mot de passe peut être utilisé
pour installer automatiquement un serveur de base de données MySQL. Avec un
coffre de clés et des MSI, vous pouvez exécuter un certain nombre de commandes
pour récupérer le secret auprès du coffre de clés, exécuter le programme d'installation
de MySQL Server et fournir automatiquement le mot de passe sécurisé.

Azure Instance Metadata Service

Une machine virtuelle dotée d'une identité gérée utilise un point de terminaison REST
via le service de métadonnées d'instance (Instance Metadata Service, IMDS) pour
demander un jeton d'accès auprès d'Azure AD, qu'elle peut ensuite utiliser pour
demander des données auprès d'Azure Key Vault. Mais qu'est-ce que le service de
métadonnées d'instance ?
IMDS est un point de terminaison REST qui est uniquement accessible en interne pour
les machines virtuelles. Le point de terminaison est disponible à l'adresse non
routable 169.254.169.254. Une machine virtuelle peut faire une demande
au point de terminaison IMDS pour récupérer des informations la concernant, telles
que la région Azure ou le nom du groupe de ressources. Cela permet à la machine
virtuelle de comprendre comment et où sur la plateforme Azure elle est en cours
d'exécution. Le point de terminaison IMDS est accessible dans plusieurs
langages, notamment Python, C#, Go, Java et PowerShell.
Pour les événements de maintenance, il est également possible d'interroger le point de
terminaison IMDS afin que la machine virtuelle soit avertie d'un événement de mise à
jour ou de redémarrage en attente. Toutes les tâches préalables à la mise à jour ou au
redémarrage qui sont nécessaires peuvent alors être effectuées. Étant donné que IMDS
est un point de terminaison REST sur une adresse IP non routable, il n'y a pas d'agent ni
d'extension pour la machine virtuelle à installer, ce qui élimine toute préoccupation
relative à la sécurité du réseau ou au routage.
Pour les besoins des identités gérées, le point de terminaison IMDS est utilisé pour
relayer la demande de jeton d'accès à Azure AD. Cette approche fournit aux machines
virtuelles un moyen sécurisé pour faire une demande d'accès sans avoir à communiquer
directement avec AAD.
 Identités gérées pour les ressources Azure 223

Tester
Pour créer une machine virtuelle avec une MSI, procédez comme suit :

1 Créez une machine virtuelle Ubuntu, indiquez un groupe de ressources, par

exemple azuremolchapter15, et attribuez un nom à la machine virtuelle, par
exemple molvm. Un compte utilisateur nommé azuremol est créé, et les clés SSH
que vous avez utilisées dans les chapitres précédents sont ajoutées à la machine
virtuelle :
az vm create \
--resource-group azuremolchapter15 \
--name molvm \
--image ubuntults \
--admin-username azuremol \
--generate-ssh-keys

2 Comme bonne pratique de sécurité, vous ne devez pas autoriser les comptes à
accéder à l'ensemble des ressources de votre abonnement Azure. En particulier
pour les identités gérées, octroyez uniquement le niveau d'autorisation minimum
nécessaire.
Pour cet exercice, définissez l'étendue de l'accès à votre groupe de ressources
uniquement, ici azuremolchapter15. Vous définissez cette étendue en
interrogeant l'identifiant du groupe de ressources à l'aide de la commande
--query id. Cet identifiant est ensuite attribué à une variable nommée scope :
scope=$(az group show --resource-group azuremolchapter15
➥--query id --output tsv)
3 Créez une identité gérée attribuée au système pour la machine virtuelle avec le
rôle de lecteur, de sorte qu'elle puisse uniquement lire les ressources, et pas leur
apporter des modifications. Étendez l'identité au groupe de ressources. La
variable que vous avez créée à l'étape précédente qui contient l'identifiant du
groupe de ressources est fournie :
az vm identity assign \
--resource-group azuremolchapter15 \
--name molvm \
--role reader \
--scope $scope

4 Appliquez les autorisations à Azure Key Vault qui accorde l’accès au principal de
service pour l’identité gérée. Vous pouvez le faire via le portail en accédant à
Stratégies d’accès pour la ressource Key Vault. Vous pouvez également utiliser la
CLI Azure. Utilisons la CLI pour obtenir les informations à l’aide d’un programme.
Tout d'abord, obtenez les informations sur le principal de service Azure AD
pour votre identité de service géré. Appliquez le filtre display-name sur la
machine virtuelle que vous avez créée à l’étape 3, par exemple molvm :
az ad sp list \
--display-name molvm \
--query [].servicePrincipalNames
224 Chapitre 15  Sécurisation des informations avec Azure Key Vault

La sortie est similaire à l'exemple condensé présenté ci-dessous. Ne vous attardez

pas trop sur la signification de ces valeurs. Elles ne vous servent qu'à attribuer les
autorisations initiales. Encore une fois, vous pouvez utiliser le portail Azure pour
ne pas avoir à utiliser la CLI si celle-ci vous semble compliquée.
Notez le premier paramètre servicePrincipalName. Cette valeur est utilisée
pour attribuer des autorisations sur des ressources Azure telles que votre coffre
de clés clé, et vous en aurez besoin à l'étape suivante :
[
 "887e9665-3c7d-4142-b9a3-c3b3346cd2e2",
 "https://identity.azure.net//
  ➥ihxXtwZEiAeNXU8eED2Ki6FXRPkklthh84S60CiqA4="
]

5 Définissez la stratégie d’accès au niveau du coffre de clés de sorte que le principal

de service de votre VM puisse lire les secrets, et entrez votre premier
servicePrincipalName créé à l'étape 4 :
az keyvault set-policy \
--name azuremol \
--secret-permissions get \
--spn 887e9665-3c7d-4142-b9a3-c3b3346cd2e2

Un point à préciser ici  : lorsque l'identité gérée a été créée et que sa portée a été
définie au groupe de ressources, cela ne signifiait pas pour autant que la machine
virtuelle pouvait faire ce qu'elle voulait. Tout d'abord, le seul rôle créé pour l'identité
était les autorisations de lecture sur les ressources. Mais vous deviez toujours attribuer
des autorisations au coffre de clés lui-même. Ces couches de sécurité et ces autorisations
vous permettent de contrôler précisément les ressources exactes auxquelles chaque
identité peut accéder.
Maintenant que vous avez accès à un coffre de clés, je suppose que vous voulez savoir
comment récupérer le secret, n'est-ce pas ?

15.3 Obtention d'un secret à partir d'une machine virtuelle

à l'aide d'une identité de service géré
Vous avez stocké dans un coffre de clés un secret permettant d'accéder à un mot de
passe de données, et vous avez une machine virtuelle avec une identité gérée qui
fournit un accès en lecture seule à ce secret dans le coffre de clés. Et ensuite ? Comment
pouvez-vous récupérer le secret et l'utiliser  ? La figure  15.5 montre comment une
machine virtuelle utilise le service IMDS pour demander l'accès à une ressource, par
exemple un coffre de clés. Voyons maintenant comment procéder pour voir comment
la machine récupère le secret.
Dans la plupart des cas d’utilisation d’Azure Key Vault, les machines virtuelles ne se
connectent pas et ne récupèrent pas les secrets de cette manière. Key Vault révèle toute
son ingéniosité lorsque les applications elles-mêmes, dans le code, parviennent à
récupérer des secrets. Le code de l’application utilise le SDK Azure approprié, tel que
Python, .Net ou Java. Pour éviter les complexités du code qui résume la situation,
l’exercice suivant utilise une machine virtuelle et certaines tâches de ligne de
commande. Au fil de cet exercice, n’oubliez pas que cette magie se produit
généralement dans le code de l'application.
 Obtention d'un secret à partir d'une machine virtuelle à l'aide d'une identité de service géré 225

1. La machine virtuelle fait une demande HTTP au point

de terminaison Instance Metadata Service (IMDS)
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api
version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net'

Instance
Ord. virt
Metadata
Azure
3. Le jeton d'accès est renvoyé Service
depuis Azure Active Directory
5. Le secret stocké dans 2. IMDS transmet la
le coffre de clés pour demande de jeton d'accès de
4. Le jeton d'accès est utilisé par
databasepassword est la machine virtuelle à Azure
la machine virtuelle pour faire une
renvoyé à la machine Active Directory pour la
demande d'accès à la ressource,
virtuelle ressource cible
par exemple au coffre de clés
Azure Active
Azure Key Vault
Directory
secret databasepass- Principal de service
word

Figure 15.5  La machine virtuelle utilise le service IMDS pour demander l'accès à un coffre de clés.
Le point de terminaison communique avec Azure AD pour faire une demande de jeton d'accès. Le jeton
d'accès est renvoyé à la machine virtuelle, ce qui permet ensuite de faire une demande d'accès auprès du
coffre de clés. Si l'accès est accordé par le coffre de clés, le secret pour databasepassword est renvoyé
à la machine virtuelle.

Tester
Pour récupérer et utiliser un secret sur une VM avec une identité gérée, procédez
comme suit :

1 Obtenez l'adresse IP publique de la machine virtuelle que vous avez créée dans
l'exercice précédent, par exemple molvm :
az vm show \
--resource-group azuremolchapter15 \
--name molvm \
--show-details \
--query [publicIps] \
--output tsv

2 Connectez-vous en SSH à votre machine virtuelle, par exemple ssh azuremol@

publicIps.
3 Pour accéder à un coffre de clés, vous avez besoin d'un jeton d'accès. Ce jeton
d'accès est demandé au service IMDS. Il s'agit d'une requête HTTP, et sur une
machine virtuelle Linux, vous pouvez utiliser le programme curl pour exécuter
la requête. Le service IMDS transmet votre demande à AAD :
curl 'http://169.254.169.254/metadata/identity/oauth2/token?
➥api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net'
➥-H Metadata:true
226 Chapitre 15  Sécurisation des informations avec Azure Key Vault

4 La sortie est un peu difficile à lire, car au premier abord, ce n'est qu'un fouillis de
texte. Elle est au format JSON Web Token (JWT). Pour traiter la sortie JSON et la
rendre plus lisible par l'homme, installez un analyseur JSON appelé jq :
sudo apt-get update && sudo apt-get -y install jq

5 Exécutez à nouveau votre requête curl, mais cette fois affichez la sortie avec jq :
curl 'http://169.254.169.254/metadata/identity/oauth2/token?
➥api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net'
➥-H Metadata:true --silent | jq
Ces premières étapes vous permettent de voir comment les requêtes sont exécutées et
à quoi ressemble la sortie, comme illustré à la figure 15.6. Si vous continuez à vous
connecter à la machine virtuelle et que vous demandez manuellement un jeton
d'accès, quel est l'intérêt d'utiliser une identité gérée  ? Vous pourriez simplement
fournir vos propres informations d'identification. Dans le cadre d'une utilisation en
production, vous utiliseriez probablement un script qui s'exécute sur la machine
virtuelle pour faire automatiquement la demande de jeton d'accès, puis pour récupérer
le secret auprès du coffre de clés. Poursuivons, et voyons comment vous pouvez
automatiser ce processus et récupérer le secret.

1. La machine virtuelle fait une demande HTTP au point

de terminaison Instance Metadata Service (IMDS)
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api
version=201802-01&resource=https%3A%2F%2Fvault.azure.net'

Instance
Ord. virt
Metadata
Azure
3. Le jeton d'accès est renvoyé Service
5. Le secret stocké dans depuis Azure Active Directory
2. IMDS transmet la
le coffre de clés pour demande de jeton d'accès
databasepassword est 4. Le jeton d'accès est utilisé par de la machine virtuelle
renvoyé à la machine la machine virtuelle pour faire une à Azure Active Directory
virtuelle demande d'accès à la ressource, pour la ressource cible
par exemple au coffre de clés
Azure Active
Azure Key Vault
Directory
secret database- Principal de service
password

Figure 15.6  Sur ce diagramme, la requête curl couvre les trois premières étapes. La requête curl est
exécutée, le point de terminaison communique avec Azure AD, et un jeton d'accès est émis.

6 Pour simplifier les choses, et si vous devez faire toutes ces opérations dans un
script, vous pouvez utiliser jq pour traiter la réponse de curl, extraire uniquement
le jeton d'accès, et définir celui-ci en tant que variable nommée access_token:
access_token=$(curl
➥'http://169.254.169.254/metadata/identity/oauth2/token?
➥api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net'
➥-H Metadata:true --silent | jq -r '.access_token')
 Obtention d'un secret à partir d'une machine virtuelle à l'aide d'une identité de service géré 227

7 Pour vous aider à comprendre à quoi cela ressemble, affichez la variable

access_token :
echo $access_token

8 C'est maintenant que les choses deviennent amusantes ! Utilisez le jeton d'accès
pour demander votre secret au coffre de clés. Nous allons d'abord le faire
manuellement pour que vous compreniez ce qui se passe.
9 Récupérez le secret avec une autre requête curl, puis formatez la sortie avec jq.
Saisissez le nom de votre coffre de clés au début de https:// address:
curl https://azuremol.vault.azure.net/secrets/databasepassword?
➥api-version=2016-10-01 -H "Authorization: Bearer $access_token"
➥--silent | jq
La sortie est similaire à l'exemple suivant, qui montre la valeur du mot de passe
stocké dans le secret, ainsi que des métadonnées supplémentaires sur le secret
dont vous n'avez pas à vous soucier pour le moment :
{
  "value": "SecureP@ssw0rd!",
  "contentType": "Database password",
 "id":
➥"https://azuremol.vault.azure.net/secrets/databasepassword/
➥87e79e35f57b41fdb882c367b5c1ffb3",
}

Cette requête curl est la deuxième partie du workflow, comme illustré à la

figure 15.7.

1. La machine virtuelle fait une demande HTTP au point

de terminaison Instance Metadata Service (IMDS)

curl 'http://169.254.169.254/metadata/identity/oauth2/token?api
version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net'
Instance
Ord. virt
Metadata
Azure
3. Le jeton d'accès est renvoyé Service
depuis Azure Active Directory
5. Le secret stocké dans 2. IMDS transmet la
le coffre de clés pour 4. Le jeton d'accès est demande de jeton d'accès
databasepassword est utilisé par la machine de la machine virtuelle à
renvoyé à la machine virtuelle pour faire une Azure Active Directory
demande d'accès à la
virtuelle ressource, par exemple
pour la ressource cible
au coffre de clés
Azure Active
Azure Key Vault
Directory
secret Principal de service
databasepassword

Figure 15.7  Cette deuxième requête curl couvre les deux dernières étapes du diagramme. Le jeton d'accès est
utilisé pour demander le secret au coffre de clés. La réponse JSON (qui inclut la valeur du secret) est renvoyée.
228 Chapitre 15  Sécurisation des informations avec Azure Key Vault

10 De la même manière que vous avez utilisé une variable pour stocker le jeton d'ac-
cès, dans un script, vous pouvez également attribuer la valeur du secret à une
variable. Cette fois, utilisez jq pour traiter la réponse, extrayez uniquement la
valeur du secret, puis définissez-la en tant que variable nommée
database_password :
database_password=$(curl
➥https://azuremol.vault.azure.net/secrets/databasepassword?
➥api-version=2016-10-01 -H "Authorization: Bearer $access_token"
➥--silent | jq -r '.value')
11 Encore une fois, pour vous aider à comprendre le processus, affichez le contenu de
la variable database_password :
echo $database_password

J'espère que vous suivez ! Si vous écrivez une application en Python, ASP.NET ou Node.
js, par exemple, le processus sera le même, car vous demandez le jeton d'accès, puis
vous utilisez ce jeton pour demander un secret auprès d'un coffre de clés. Il y a proba-
blement d'autres bibliothèques que vous pourriez utiliser dans votre code au lieu d'ex-
écuter l'utilitaire jq à partir de la ligne de commande.
Un bref rappel : toutes ces étapes peuvent être condensées en deux lignes, comme
illustré dans l'extrait suivant.

Liste 15.1  Demande de jeton d'accès, puis de secret auprès d'un coffre de clés

access_token=$(curl
➥'http://169.254.169.254/metadata/identity/oauth2/token?
➥api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net'
➥-H Metadata:true --silent | jq -r '.access_token')
database_password=$(curl
➥https://azuremol.vault.azure.net/secrets/databasepassword?
➥api-version=2016-10-01 -H "Authorization: Bearer $access_token"
➥-silent | jq -r '.value')

Et ensuite  ? L’identité gérée de votre machine virtuelle peut récupérer un secret à

partir d’un coffre de clés. Découvrons comment utiliser cette identité gérée pour
installer et configurer MySQL Server.
Dans Ubuntu, vous pouvez définir des sélections de configuration pour les
programmes d'installation de package, tels que MySQL Server. Ces sélections de
configuration vous permettent de fournir des valeurs telles que des noms
d'utilisateur et des mots de passe, et de faire en sorte qu'elles soient automatiquement
utilisées au bon moment du processus d'installation. Les invites manuelles de mot de
passe, comme vous en avez peut-être vu au chapitre 2, ont disparu.
12 Définissez les sélections de configuration pour les mots de passe MySQL Server
à l'aide de la variable database_password que vous avez créée à l'étape 10 :
sudo debconf-set-selections <<< "mysql-server mysql-server/root_password
➥password $database_password"
sudo debconf-set-selections <<< "mysql-server mysql-
➥server/root_password_again password $database_password"
 Création et injection de certificats 229

13 Installez MySQL Server. Il n'y a pas d'invites, car le mot de passe est fourni
par les sélections de configuration :
sudo apt-get -y install mysql-server

14 Voyons maintenant si tout cela a fonctionné  ! Affichez la variable database_

password de sorte que vous puissiez voir clairement ce que doit être le mot de passe :
echo $database_password

15 Connectez-vous à MySQL Server. Lorsque vous êtes invité à saisir un mot de

passe, entrez la valeur de database_password, qui correspond à la valeur du
secret stocké dans le coffre de clés :
mysql -u root -p

Vous êtes connecté à MySQL Server, ce qui confirme que le secret stocké dans le
coffre de clés a été utilisé pour créer les informations d'identification SQL Server !
16 Saisissez exit deux fois pour fermer l'invite de commande MySQL Server, puis
fermez votre session SSH sur la machine virtuelle.
Nous venons de voir un exemple de base, et pour que les applications puissent accéder
aux bases de données ou aux tables, par exemple, il vous faudrait tout de même sécuriser
MySQL Server et fournir des informations d'identification supplémentaires. L'avantage
d'utiliser un secret stocké dans un coffre de clés réside dans le fait que vous êtes certain
que tous les mots de passe sont les mêmes. Si vous utilisez des VMSS, par exemple,
chaque instance de machine virtuelle peut automatiquement demander le secret et
installer MySQL Server de façon à être prête à fournir vos données d'application. Ces
mots de passe ne sont jamais définis dans des scripts, et personne n'a besoin de les
visualiser. Vous pouvez même générer des mots de passe de façon aléatoire et assurer
leur rotation de la même façon qu'avec les secrets stockés dans un coffre de clés.
C'est bien beau de stocker des mots de passe dans un coffre de clés, mais est-il possible
d'utiliser un coffre de clés pour stocker des certificats, puis de récupérer ces certificats
automatiquement à partir de vos applications ou machines virtuelles ? Bien sûr !

15.4 Création et injection de certificats

Les certificats numériques constituent une méthode courante pour assurer la sécurité et
l'authentification dans le cadre des services Web et des applications. Les certificats sont
émis par une autorité de certification considérée (je l'espère !) comme de confiance par
les utilisateurs finaux. Le certificat permet aux utilisateurs de vérifier qu'un site Web ou
une application est bien ce qu'il ou elle prétend être. Chaque fois que vous voyez un site
Web avec une adresse de navigateur Web qui commence par https:// and has a padlock
symbol, the traffic is encrypted ant sécurisé par un certificat numérique.
La gestion des certificats numériques peut devenir une tâche majeure. L'un des
problèmes fréquemment rencontrés consiste à savoir comment stocker les certificats et
y accorder l'accès lorsque les services et applications en ont besoin. Dans les exercices
précédents, nous avons vu comment il est possible d'utiliser un coffre de clés pour
partager des secrets et des clés sécurisés avec des services et des applications, mais cela
vaut également pour les certificats. Comme illustré à la figure 15.8, un coffre de clés
peut être utilisé pour demander, émettre et stocker des certificats.
Pour une utilisation en production, vous devez toujours utiliser une autorité de
certification de confiance pour émettre vos certificats. Pour une utilisation en interne,
vous pouvez émettre des certificats auto-signés que vous créez vous-même. Ces
230 Chapitre 15  Sécurisation des informations avec Azure Key Vault

1. Une demande de 2. Une demande de

création de certificat est signature de certificat est
envoyée au coffre de clés envoyée à l'autorité de
certification
Utilisateur,
application ou Key Vault Autorité de
service certification
4. Le certificat est 3. Le certificat
émis par le coffre portant la signature
de clés X.509 est renvoyé au
et stocké dans le
coffre de clés

Figure 15.8  Un utilisateur, une application ou un service peut demander un nouveau certificat auprès
d'un coffre de clés. Une demande de signature de certificat est envoyée par le coffre de clés à une
autorité de certification tierce ou interne. Azure Key Vault peut également être sa propre autorité de
certification afin de générer des certificats auto-signés. L'autorité de certification émet alors un
certificat X.509 signé, qui est stocké dans le coffre de clés. Pour terminer, le coffre de clés retourne
le certificat au demandeur initial.

certificats auto-signés ne sont pas considérés comme de confiance par les autres
services et applications, ce qui signifie qu'ils génèrent souvent un avertissement, mais
ils permettent d'être rapidement opérationnel et de s'assurer que votre code
fonctionne comme prévu avec le trafic chiffré.
Azure Key Vault peut générer des certificats auto-signés à votre place. En catimini,
Azure KeyVault joue le rôle de sa propre autorité de certification pour demander,
émettre et stocker des certificats. Nous allons utiliser cette possibilité pour générer un
certificat auto-signé et voir comment l'injecter dans une machine virtuelle en toute
simplicité. Le certificat est ensuite utilisé pour un serveur Web de base afin de vous
montrer comment activer rapidement SSL pour sécuriser votre trafic Web.

Tester
Pour créer un certificat et l'injecter dans une machine virtuelle, procédez comme suit :

1 Créez un certificat auto-signé dans Azure Key Vault, puis saisissez un nom, par
exemple molcert. Des stratégies sont utilisées pour définir des propriétés telles
que les délais d'expiration, le niveau de chiffrement et le format du certificat.
Vous pouvez créer différentes stratégies pour répondre aux besoins de vos
applications et services. Pour cet exercice, utilisez la stratégie par défaut qui crée
un certificat de 2 048 bits et est valable pendant un an :
az keyvault certificate create \
--vault-name azuremol \
--name molcert \
--policy "$(az keyvault certificate get-default-policy)"

2 Pour voir le certificat en action, créez une autre machine virtuelle, par exemple
molwinvm. Cette fois, créez une machine virtuelle Windows qui utilise Windows
Server 2019. Vous allez faire aimer ce système d'exploitation, en constatant que
ces fonctionnalités Key Vault ne dépendent pas d’un système d’exploitation
spécifique ! Fournissez vos nom d'utilisateur et mot de passe administrateur :
az vm create \
--resource-group azuremolchapter15 \
 Création et injection de certificats 231

--name molwinvm \
--image win2019datacenter \
--admin-username azuremol \
--admin-password P@ssw0rd1234

3 Vous pouvez ajouter automatiquement le certificat à la machine virtuelle,

directement depuis la CLI Azure. Cette application ne dépend pas d'une identité
gérée. La plateforme Azure injecte le certificat à l’aide de l’agent de machine
virtuelle Windows Azure.
Ajoutez votre certificat (ici molcert) à la machine virtuelle que vous avez créée
à l'étape 2 (ici molwinvm) :
az vm secret add \
--resource-group azuremolchapter15 \
--name molwinvm \
--keyvault azuremol \
--certificate molcert

4 Connectez-vous à la machine virtuelle et assurez-vous que le certificat a été

injecté correctement. Pour vous connecter à votre machine virtuelle, commencez
par obtenir son adresse IP publique :
az vm show \
--resource-group azuremolchapter15 \
--name molwinvm \
--show-details \
--query [publicIps] \
--output tsv

Utilisez un client Microsoft Remote Desktop Connection installé en local sur

votre ordinateur pour vous connecter à votre machine virtuelle. Utilisez les
informations d'identification pour vous connecter à localhost\azuremol, et non
les informations d'identification par défaut de votre ordinateur local que votre
client Remote Desktop peut essayer d'utiliser, comme illustré à la figure 15.9.

Figure 15.9 Votre client Remote Desktop

peut essayer d'utiliser les informations
d'identification par défaut de votre
ordinateur local. Pour éviter cela,
sélectionnez Utiliser un autre compte, puis
fournissez les informations d'identification
localhost\azuremol que vous avez spécifiées
lorsque vous avez créé la machine virtuelle.
232 Chapitre 15  Sécurisation des informations avec Azure Key Vault

5 Une fois que vous êtes connecté, cliquez sur le bouton Démarrer de Windows,
puis saisissez mmc et ouvrez la Microsoft Management Console.
6 Sélectionnez Fichier > Ajouter/Supprimer un composant logiciel enfichable,
puis choisissez d'ajouter le composant logiciel enfichable Certificats.
7 Choisissez d'ajouter des certificats pour le compte d'ordinateur, et sélectionnez
Suivant, puis Terminer.
8 Cliquez sur OK pour fermer la fenêtre Ajouter/Supprimer un composant
logiciel enfichable.
9 Développez le dossier Certificats (ordinateur local) > Personnel > Certificats. Le
certificat provenant d'Azure Key Vault que vous avez injecté dans la machine
virtuelle est répertorié, ici CLIGetDefaultPolicy, comme illustré à la figure 15.10.

Figure  15.10  Dans la Microsoft Management Console, ajoutez le composant logiciel enfichable
Certificats sur l'ordinateur local. Développez le dossier Personnel > Certificats pour afficher les certificats
installés. Le certificat injecté à partir de Key Vault est répertorié.

C'est aussi simple que ça ! Créez le certificat dans Key Vault, puis ajoutez le certificat à
la machine virtuelle. Le certificat est placé dans le magasin de certificats local de
l'ordinateur, ce qui permet aux services ou applications d'y accéder. Sur une machine
virtuelle Windows, les certificats sont stockés dans le cache de certificats local, comme
vous pouvez le voir dans cet exercice. Sur les machines virtuelles Linux, les fichiers .prv
et .crt correspondant aux parties privées et publiques des certificats sont stockés dans/
var/lib/waagent/. Vous pouvez déplacer les certificats là où vous le souhaitez pour
votre application ou service.
Les certificats peuvent être utilisés pour l’authentification entre les clients et les
serveurs, ou entre les composants et les services d’application. Un exemple courant
consiste pour un serveur Web à utiliser un certificat SSL, ce que vous allez faire dans
l'exercice pratique de fin de chapitre.

15.5 Exercice pratique : configuration d'un serveur Web sécurisé

Dans le dernier exercice, vous avez injecté un certificat auto-signé provenant d'Azure
Key Vault dans une machine virtuelle Windows. Pour cet exercice pratique, installez et
configurez le serveur Web IIS pour utiliser le certificat, en procédant comme suit :
 Exercice pratique : configuration d'un serveur Web sécurisé 233

1 Ouvrez PowerShell sur votre machine virtuelle Windows et installez le serveur

Web IIS :
Add-WindowsFeature Web-Server -IncludeManagementTools

2 Ouvrez le gestionnaire Internet Information Server (IIS). Pour ce faire, accédez

au menu Tools (Outils) du Gestionnaire de serveur.
3 Pour Default Web Site (Site Web par défaut), choisissez Edit Bindings (Modifier
les liaisons).
4 Ajoutez une liaison HTTPS pour toutes les adresses IP non assignées sur le
port 443.
5 Sélectionnez le certificat auto-signé que vous avez créé et injecté à partir de Key
Vault, généralement appelé CLIGetDefaultPolicy ou un nom approchant.
6 Ouvrez un navigateur Web sur la machine virtuelle, puis saisissez https://
localhost. Étant donné que vous avez généré un certificat auto-signé dans Key
Vault, le navigateur Web ne lui fait pas confiance.
7 Acceptez l'avertissement pour continuer, puis assurez-vous que la liaison HTTPS
fonctionne.
8 De retour dans Azure Cloud Shell ou sur le portail, créez une règle NSG pour la
machine virtuelle sur le port TCP  443. Entrez https://yourpublicipaddress
dans un navigateur Web sur votre ordinateur local. Vos utilisateurs devraient
normalement recevoir un avertissement de ce type concernant un certificat auto-
signé non fiable. Pour la plupart des cas d'utilisation, n'oubliez pas d'utiliser
une autorité de certification interne ou tierce de confiance pour générer des
certificats et les stocker dans un coffre de clés.
 16
Azure Security Center et
mises à jour

Et si Azure était assez intelligent pour surveiller toutes vos ressources d'application
de base et vous alerter des problèmes de sécurité ? Ne serait-ce pas formidable ? Ou,
si votre entreprise dispose déjà de stratégies de sécurité définies (Si vous n'en avez
aucune, arrêtez immédiatement de lire ce document et prenez note pour ne pas
oublier d'en créer.) Dans ce dernier cas, comment assurer la conformité de vos
déploiements Azure  ? Si vous avez déjà passé un audit de sécurité informatique,
vous savez à quel point il peut être merveilleux d'examiner une liste de problèmes
de configuration affectant votre environnement, surtout s'il s'agit d'erreurs de
sécurité de base que vous êtes capables d'éviter !
Avec Azure Security Center, vous disposez d'un emplacement central où consulter
les alertes et les recommandations de sécurité qui vous sont adressées. Vous pouvez
définir vos propres stratégies de sécurité, puis laisser Azure surveiller l'état de vos
ressources pour s'assurer qu'elles sont conformes.
Dans ce chapitre, nous expliquons comment Security Center peut vous alerter
des éventuels problèmes et indiquer la procédure à suivre pour les résoudre,
comment vous pouvez utiliser l'accès Juste à temps aux VM pour contrôler les
connexions à distance et réaliser des audits sur celles-ci, et comment
Update Management veille automatiquement à ce que vos VM restent à jour avec les
derniers correctifs de sécurité.

16.1 Azure Security Center
Tout au long de ce livre, nous avons abordé des sujets liés à la sécurité comme la
création et la configuration de groupes de sécurité réseau (NSG) pour limiter
l'accès à la VM ou la façon de n'autoriser que le trafic chiffré vers les comptes
Stockage Azure. Au-delà des exercices de ce livre, il peut être difficile de savoir par
où commencer dans vos propres déploiements et comment vérifier que vous avez
appliqué toutes les bonnes pratiques de sécurité. C'est dans ce cas
qu'Azure Security Center peut s'avérer très utile : ses capacités d'analyse de votre
environnement permettent de détecter vos éventuels oublis et erreurs.

234
 Azure Security Center 235

Azure Security Center analyse vos ressources, recommande des correctifs et aide à

résoudre les problèmes de sécurité, comme illustré à la figure 16.1. Lorsque l'on dispose
seulement de quelques VM de test et d'un seul réseau virtuel dans son abonnement
Azure, effectuer le suivi des restrictions de sécurité à mettre en place paraît très simple.
Toutefois, si l'environnement comprend des dizaines, des centaines, voire des milliers
de VM, il devient ingérable de surveiller manuellement les configurations de sécurité à
mettre en œuvre sur chaque machine.

Machines Réseaux
virtuels Stockage Applications
virtuelles
Figure 16.1 Azure Security
Center surveille vos
Surveillance ressources Azure et utilise des
Génération d'alertes
des ressources stratégies de sécurité définies
et de conseils de
Azure à la correction pour vous avertir des menaces
recherche de et des vulnérabilités
problèmes de potentielles. La solution
sécurité fournit également des
Azure Security Center recommandations et des
mesures de résolution des
problèmes. Vous pouvez aussi
Fonctionnalités de utiliser l'accès Juste à temps
sécurité dédiées à la VM, surveiller et appliquer
pour compléter les des mises à jour de sécurité,
recommandations et contrôler les applications
de stratégie
placées sur liste blanche dont
Accès Juste à Mise en liste
Update l'exécution sur les VM est
temps à la VM blanche
Management autorisée
d'applications

Security Center peut également vous avertir si des bonnes pratiques générales ne sont
pas mises en œuvre (par exemple, si les diagnostics ne sont pas activés pour une VM).
Vous souvenez-vous de la section du chapitre  12 consacrée au pil
otage et au dépannage des VM ? Vous devez installer et configurer l'agent de diagnos-
tics avant de rencontrer un problème. Si vous soupçonnez une violation de la sécurité,
vous ne serez peut-être pas en mesure d'accéder à la VM et de consulter les journaux.
En revanche, si vous avez configuré l'extension de diagnostic pour diffuser des jour-
naux vers Stockage Azure, vous pourrez obtenir des informations sur ce qui s'est passé,
comprendre l'étendue du problème et, (espérons-le), retracer sa cause.

Tester
Pour commencer à utiliser Azure Security Center, procédez comme suit :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell dans le menu du haut.
2 Créez un groupe de ressources, en spécifiant un nom de groupe de ressources,
par exemple azuremolchapter16, et un emplacement, par exemple eastus :
az group create --name azuremolchapter16 --location eastus

3 Créez une VM Linux de base de sorte que Security Center dispose d'un élément
à surveiller et pour lequel fournir des recommandations :
236 Chapitre 16  Azure Security Center et mises à jour

az vm create \
--resource-group azuremolchapter16 \
--name azuremol \
--image ubuntults \
--admin-username azuremol \
--generate-ssh-keys

4 Une fois la VM déployée, fermez Cloud Shell.

5 Dans le portail Azure, sélectionnez Security  Center dans la liste des services
à gauche. Lors de la première ouverture du tableau de bord, quelques secondes
sont nécessaires pour préparer tous les composants disponibles (reportez-vous
à la figure 16.2).

Figure 16.2  fenêtre Vue d'ensemble d'Azure Security Center fournit une liste de recommandations, d'alertes
et d'événements. Vous pouvez sélectionner un type de ressource de base tel que Calcul ou Mise en réseau pour
afficher une liste d'éléments de sécurité spécifiques à ces ressources.

Security Center examine la façon dont les ressources telles que les VM, les règles de
NSG et le stockage sont déployées. Les bases de référence de sécurité intégrées
permettent d'identifier les problèmes et de fournir des recommandations. Le réseau
virtuel déployé avec vôtre VM génère des avertissements, comme illustré à la figure 16.3.
Vous pouvez (et devriez) mettre en œuvre vos propres stratégies de sécurité qui
indiquent à Azure comment vous souhaitez limiter l'accès ou quelles mesures doivent
être prises pour se conformer aux mandats opérationnels. Lorsque vous créez ou
mettez à jour des ressources, Azure
 Accès Juste à temps 237

Figure 16.3  Le réseau virtuel de

votre machine virtuelle déclenche
déjà des avertissements de
sécurité. Dans cet exemple, il
avertit qu’un groupe de sécurité
réseau doit être associé au
sous-réseau.

Azure recherche en
permanence les écarts par
rapport à ces stratégies et vous avertit des mesures à prendre pour résoudre les
problèmes de sécurité. Même si vous utiliserez les stratégies de sécurité Azure par
défaut dans ce chapitre, pensez à toutes les configurations de sécurité particulières
que vous pourriez appliquer à vos VM et à la façon dont elles peuvent être définies
dans vos propres stratégies personnalisées.
6 Choisissez Calcul et applications dans le menu de gauche dans la fenêtre
Security Center, puis sélectionnez les machines virtuelles et les ordinateurs.
7 Sélectionnez la machine virtuelle que vous avez créée à l'étape 3. Même si vous
venez de créer cette VM et avez utilisé les valeurs par défaut de la CLI Azure,
certains avertissements de sécurité s'affichent dans cet exemple.
Étudiez certaines de ces recommandations. Lorsque vous sélectionnez chaque
recommandation, certaines vous permettent simplement d'en savoir plus, tandis que
d'autres vous guident à travers les mesures correctives. Il ne s’agit pas de règles strictes
et infaillibles, ce sont simplement des recommandations et des bonnes pratiques.
Certaines d'entre elles sont susceptibles de ne pas être logiques dans votre propre
environnement. Elles constituent toutefois un bon point de départ pour savoir
comment procéder pour sécuriser les ressources lorsque vous les créez dans Azure.

16.2 Accès Juste à temps

Dans la section 16.1, vous avez appris que Security Center recommande de limiter le champ
d'application de la connectivité entrante à distance. Vous pouvez limiter le trafic en
fournissant une plage d'adresses IP, mais, idéalement, vous ne devriez ouvrir la connectivité
entrante qu'en cas de besoin. De cette façon, la VM est complètement fermée aux connexions
à distance et n'est accessible que pendant un court laps de temps lorsque cela est
238 Chapitre 16  Azure Security Center et mises à jour

1. L'utilisateur demande 4. Les règles de NSG sont

un accès Juste à temps configurées pour accorder
(JIT) à la VM un accès défini

Utilisateur Azure Security Center Règles de groupe

Azure
6. L'utilisateur peut
accéder à la VM pour
une période de temps
définie
de sécurité réseau
Accès JIT à la VM 5. Les règles de NSG (NSG)
autorisent l'accès pour
une période de temps
définie

2. Les autorisations RBAC 3. Si les autorisations RBAC

sont vérifiées pour l'accès sont octroyées, l'accès JIT
à la ressource de VM est accordé et configuré

Autorisations de
contrôle d'accès en
fonction du rôle
(RBAC)

Figure 6.4  Avec l'accès JIT à la VM, les règles de NSG sont configurées pour refuser les connexions à distance à
une VM. Les autorisations RBAC permettent de vérifier les autorisations des utilisateurs lorsqu'ils demandent
l'accès à une VM. Si l'une de ces demandes est accordée après avoir été auditée, les règles de NSG sont mises à
jour pour autoriser le trafic provenant d'une plage d'adresses IP spécifique pendant une période définie. L'utilisateur
ne peut accéder à la VM que pendant cette période. Une fois qu'elle arrive à expiration, les règles de NSG sont
automatiquement redéfinies sur un état de refus.

nécessaire. Bien entendu, vous devez tout de même limiter ce petit créneau de
connectivité à une plage d'adresses IP spécifique ! C'est dans ces situations que l'accès
Juste à temps (JIT) à la VM s'avère utile, comme illustré à la figure 16.4.
Avec l'accès Juste à temps (JIT), Security  Center ajuste dynamiquement les
restrictions d'accès sur une VM. Lorsqu'il est activé, des règles de NSG bloquant tout
trafic de connexion à distance sont créées. Un utilisateur peut alors demander l'accès à
une VM uniquement lorsque cela est nécessaire. Lorsqu'il est combiné avec des
contrôles d’accès en fonction du rôle (abordées au chapitre  6), Security  Center
détermine si un utilisateur dispose des droits d'accès à une VM lorsqu'il demande une
connexion. Si c'est le cas, Security Center met à jour les règles de NSG pertinentes pour
autoriser le trafic entrant. Ces règles ne sont appliquées que lors d'une période
spécifique. Une fois qu'elle est terminée, les règles sont rétablies et la VM devient à
nouveau fermée aux connexions à distance. Si vous êtes activement connecté à une VM,
vous n’êtes pas déconnecté automatiquement lorsque le délai expire. Vous
pouvez terminer vos travaux de maintenance ou de dépannage et vous déconnecter
lorsque vous êtes prêt. Vous ne serez toutefois pas en mesure d'initier une nouvelle
connexion, à moins que vous ne demandiez à nouveau un accès JIT.

Se laisser envahir
Nous n’avons pas vraiment étudié le pare-feu Azure, mais il s’agit d’une ressource de
réseau virtuel qui est ressemble un peu plus à un pare-feu physique sur site qu’à des
NSG. Si vous recherchez davantage de souplesse et de contrôle du trafic, le pare-feu
Azure constitue une excellente option, même s'il engendre un certain coût.
Sans trop s'attarder sur le pare-feu Azure, je tiens à souligner qu'Azure
Security Center peut également s'intégrer avec le pare-feu Azure, pour ouvrir et
fermer les règles requises. Si vous
 Accès Juste à temps 239

utilisez le pare-feu Azure pour protéger le trafic de machines virtuelles sur les réseaux
virtuels, et pas seulement des NSG, vous pouvez toujours utiliser la gestion automatisée
des règles de l’accès JIT aux machines virtuelles.
Pour en savoir plus sur le pare-feu Azure, consultez les documents à l’adresse
https://docs.microsoft.com/azure/firewall/overview.

Dans quel cas utiliseriez-vous l'accès JIT dans votre pizzeria fictive ? Pensez aux VM qui
exécuteraient votre application Web, votre système de commande ou vos applications
de logique métier. Souhaiteriez-vous qu'elles soient connectées à Internet et
disponibles en accès public permanent ? J'espère que non ! L'accès à distance avec SSH
ou RDP est une option parfaitement valable, mais vous devriez toujours essayer de
minimiser autant que possible sa durée de disponibilité. Même si vous disposez de
règles de NSG qui limitent l'accès à certaines plages d'adresses IP, l'accès JIT apporte
une couche de protection supplémentaire concernant les éléments auxquels les
utilisateurs d'Azure peuvent accéder, puis crée une piste de vérification plus simple à
partir de laquelle Security Center peut fournir des rapports.

Tester
Pour activer l'accès Juste à temps à la VM, procédez comme suit :

1 Ouvrez le portail Azure et sélectionnez Security Center dans le menu à gauche.

2 Sous Défense de cloud avancée, sélectionnez Accès Juste à temps à la VM.
3 Si vous y êtes invité, choisissez l'option permettant d'essayer l'accès Juste à temps
à la VM ou de passer au niveau tarifaire Standard de Security  Center. Cette
période d'essai gratuit dure 60  jours et ne se prolonge pas automatiquement.
Cette offre s'ajoute à votre compte Azure gratuit et ne vous coûte rien.
Sélectionnez l'option permettant d'appliquer le plan Standard, puis attendez
quelques instants pour qu'il s'active. Une fois le plan activé, vous devrez peut-être
fermer et rouvrir le portail Azure avant de pouvoir effectuer les étapes suivantes.
4 Sélectionnez à nouveau Accès Juste à temps à la VM dans la fenêtre
Security Center. Une fois que votre compte de niveau standard est activé, vous
pouvez afficher une liste de VM à utiliser.
5 Sélectionnez votre machine virtuelle, puis choisissez Demander l’accès, comme
illustré à la figure 16.5.

Figure  16.5  Sélectionnez une VM dans les options recommandées, puis choisissez Activer JIT sur 1  machine
virtuelle. La colonne État indique actuellement que cette VM est ouverte à tous les accès à distance, ce qui entraîne
l'apparition du niveau Haut de gravité du problème de sécurité.
240 Chapitre 16  Azure Security Center et mises à jour

Par défaut, l'accès JIT définit des règles qui peuvent ouvrir les ports pour l'accès
distant SSH (port  22), RDP (port  3389) et PowerShell (ports  5985 et  5986)
pendant trois heures.
6 Pour cet exercice, activez SSH à partir de votre propre adresse IP. Suivez la bonne
pratique pour une utilisation en production et entrez une justification pour
suivre les motifs des demandes d'accès. Laissez les valeurs par défaut et choisissez
Ouvrir les ports, comme illustré à la figure 16.6.

Figure  16.6  Lorsque vous activez l'accès JIT, vous pouvez modifier les règles par défaut à
autoriser, les adresses IP sources autorisées ou la durée maximale de demande (en heures). Ces
règles JIT permettent d'exercer un contrôle précis de ce qui est autorisé, afin de ne tolérer que le
strict minimum en matière de connectivité.

7 Avec l'accès JIT, accédez à votre groupe de ressources, puis sélectionnez votre VM.
8 Choisissez Mise en réseau pour afficher la configuration de réseau virtuel
assignée à la VM. La liste des règles de NSG attribuées s'affiche, comme illustré à
la figure 16.7.

Figure 16.7  Les règles JIT sont créées avec la priorité la plus basse. Ces priorités s'assurent que les règles JIT
prévalent sur toutes les règles ultérieures appliquées au niveau du sous-réseau.
 Azure Update Management 241

Les règles JIT s'affichent en haut de la liste, car elles ont la priorité la plus basse. Le
trafic est autorisé vers l’adresse IP de la VM, mais seulement à partir de votre propre
adresse IP. C’est la raison pour laquelle l'accès JIT est configuré. Ce qui peut sembler
étrange dans cet exemple, c'est la présence d'une règle default-allow-ssh qui autorise
tout le trafic. Repensez au chapitre 5, quand nous avons abordé les groupes de sécurité
réseau (NSG). Comprenez-vous ce qui se passe ici ?
L'accès JIT ne s'applique qu'à la VM. Dans la règle JIT, la colonne Destination affiche
l'adresse IP de la VM. Dans l'exemple illustré à la figure 16.7, cette adresse est 10.0.0.4.
Le trafic est autorisé. Mais la règle de NSG véritablement en vigueur est appliquée à
l'ensemble du sous-réseau. La règle default-allow-ssh s'applique au niveau du sous-
réseau et autorise le trafic depuis n’importe quelle source et vers n’importe quelle
destination.
Les règles de NSG sont traitées par ordre croissant de priorité. Comme nous l’avons
vu dans le chapitre 5, une action de refus prend toujours effet, indépendamment de
toutes règles supplémentaires. Même si vous avez modifié cette règle default-allow-ssh
pour refuser le trafic, la règle JIT permettrait toujours d’accéder à la machine virtuelle
spécifique et à partir de l’adresse IP source définie.
Soyez vigilent avec cette superposition de règles NSG. Idéalement, vous devez
supprimer la règle default-allow-sse, puis autoriser l’accès uniquement en cas de besoin
avec l'accès JIT. Dans cette approche, SSH est refusé par la règle DenyAllInbound
finale. Lorsque vous devez vous connecter à une machine virtuelle, utilisez l'accès JIT
pour demander l'accès, qui crée automatiquement une règle pour permettre à SSH
d’être étendu à votre adresse IP pendant une période définie.
La règle de NSG est supprimée automatiquement une fois que la période spécifiée
écoulée. Par défaut, les règles JIT sont appliquées pendant trois heures. Après cette
période, l'état de la VM redevient plus sécurisé, ce qui vous oblige à demander à
nouveau l'accès à cette dernière.
Ce processus JIT contrôle qui peut demander un accès à la VM et se le voir accorder.
Toutefois, le simple fait pour un utilisateur de se voir octroyer l'accès à une VM ne
signifie pas qu'il dispose des autorisations nécessaires pour s'y connecter. La seule
opération effectuée dans Azure est la mise à jour des règles de NSG définies.
Security Center et l'accès JIT ne peuvent pas ajouter, supprimer ou mettre à jour des
informations d'identification d'accès à la VM.
Toutes les requêtes JIT sont également consignées. Dans Security  Center,
sélectionnez l'option Accès Juste à temps à la VM, puis choisissez votre règle. Sur la
droite, sélectionnez l'option de menu …, puis choisissez Journal d'activité. Ce journal
d'activité vous aide à vérifier qui a demandé l'accès à une VM en cas de problème.
L'accès JIT à la VM est une méthode permettant à Security Center et à Azure de
protéger vos VM. Contrôler l'accès aux VM est un élément important de la sécurité.
Mais qu'en est-il des applications, des bibliothèques et des services exécutés sur ces
machines ? C'est dans ce cas que vous devez vous assurer que toutes les dernières mises
à jour de sécurité sont appliquées à vos VM en temps opportun.

16.3 Azure Update Management

Un élément sur lequel Azure Security Center peut créer des rapports est l'état de toutes
les mises à jour de système d'exploitation requises par la VM. Dans votre pizzeria, vous
devriez essayer d'installer les derniers correctifs de sécurité et d'application. Exécuter
des systèmes disposant d'une vulnérabilité ou d'une zone d'attaque connues n'est pas
souhaitable. La sécurité de votre environnement est donc renforcée si vous mettez en
œuvre un moyen d'automatiser les mises à jour de ces systèmes et d'effectuer le suivi de
242 Chapitre 16  Azure Security Center et mises à jour

la conformité. Lorsque vous travaillez avec des applications qui traitent des données
client et des informations de paiement, n'exécutez pas les systèmes sans avoir installé
les derniers correctifs. N'oubliez pas de préparer un environnement de test permet-
tant d'appliquer des correctifs de sécurité de manière sûre et de vérifier qu'ils ne cau-
sent aucun problème avant de les appliquer à des systèmes de production !
Les VM Azure intègrent une fonctionnalité de gestion des mises à jour permettant
de rechercher les mises à jour de système d'exploitation, de signaler leur disponibilité
et de les installer. Ce qui est formidable avec cette solution, c'est qu'elle fonctionne
aussi bien sur Windows que sur Linux. Et ce n'est pas tout : elle est compatible avec
différentes distributions Linux telles qu'Ubuntu, Red  Hat et SUSE. La figure  16.8
montre comment Update  Management surveille la disponibilité des mises à jour
requises et peut les installer.

Azure Monitor

2. Collecte et analyse les

données fournies par l'agent
sur la VM pour déterminer
l'état des mises à jour.

Surveillance de
l’agent de Gestion des mises à jour Azure Automation
machine virtuelle 3. Les runbooks sont
1. L'agent est installé
sur la VM pour exécutés selon un
transmettre des calendrier défini pour
données sur les mises appliquer les mises à
à jour installées. jour requises.

Figure 16.8  Update Management installe un agent de VM qui recueille des informations au sujet des
mises à jour installées sur chaque VM. Ces données sont analysées par Azure Monitor et retransmises à la
plateforme Azure. Il est ensuite possible de planifier l'installation automatique des mises à jour requises à
l'aide des runbooks Azure Automation.

La VM a besoin de quelques minutes pour se préparer et rendre compte de son état de

mise à jour. Nous allons donc configurer votre VM, puis découvrir ce qui se passe en
coulisses.

Tester
Pour configurer votre VM afin d'utiliser Update Management, procédez comme suit :

1 Ouvrez le portail Azure et sélectionnez Groupes de ressources dans le menu à

gauche.
2 Sélectionnez votre groupe de ressources, par exemple azuremolchapter16, puis
sélectionnez votre VM, par exemple azuremol.
3 Sous Opérations, sélectionnez Update Management.
4 Acceptez les options par défaut pour Emplacement ainsi que pour la création
d'un espace de travail Log  Analytics et d'un compte Automation. Nous
examinerons ces composantes dans le reste de cette section.
5 Pour activer la gestion des mises à jour pour la VM, sélectionnez Activer.
 Azure Update Management 243

Vous revenez à la fenêtre Vue d'ensemble d'Update Management, mais il faut

quelques minutes pour configurer la VM et rendre compte de son état. Poursuivez
la lecture et laissez le processus suivre son cours.
Examinons un peu plus en détail le fonctionnement de la solution Update Management.

16.3.1 Services de gestion Azure associés

Si vous avez travaillé avec des technologies Microsoft sur site, vous avez peut-être eu
affaire à la suite System Center. System Center comprend plusieurs composants tels
que Configuration Manager, Operations Manager, Orchestrator et Data Protection
Manager. Ce ne sont pas les seuls, mais ces composants de base permettent de réaliser
les actions suivantes :
¡ Définir les configurations et l'état souhaité
¡ Installer des applications et des mises à jour
¡ Générer des rapports sur l'intégrité et la sécurité
¡ Automatiser les déploiements de services et d'applications volumineux
¡ Sauvegarder et répliquer des données

Puisque les entreprises font désormais appel à des fournisseurs de cloud computing
depuis quelques années, ces composants System Center sur site sont remplacés par des
services Azure capables de travailler dans un environnement hybride. Nous avons
examiné deux composants dans les chapitres précédents, même si vous ne l'avez pas
remarqué :
¡ Azure Backup permet de sauvegarder des VM ou des fichiers individuels, de définir
des stratégies de conservation et de restaurer des données.
¡ Azure Site Recovery vous permet de répliquer des VM dans d'autres régions en cas
de catastrophe naturelle ou de panne prolongée.
Azure Backup et Site Recovery vous ont aidé à protéger vos données dans le chapitre 13.
Maintenant, vous allez utiliser des services supplémentaires avec Update Management :
¡ Les espaces de travail Log Analytics recueillent des informations provenant de divers
agents ou sources, tout en permettant de définir des stratégies et des requêtes
pour vous avertir de différentes situations éventuelles. Ces requêtes et alertes peu-
vent vous aider à suivre l'état des mises à jour d'une VM, ou vous signaler les prob-
lèmes de configuration ou de sécurité.
¡ Azure Monitor détaille et signale les informations basées sur le traitement effectué
dans les espaces de travail Log Analytics. Azure Monitor fournit une méthode
centralisée pour visualiser les alertes, interroger les données des journaux et
générer des notifications sur toutes vos ressources Azure.
¡ Azure  Automation vous permet de créer des runbooks qui exécutent des com-
mandes ou des scripts entiers. Les runbooks peuvent représenter de grands
déploiements complexes et peuvent appeler plusieurs autres Runbooks. Nous
étudierons Azure Automation en détail au chapitre 18.
244 Chapitre 16  Azure Security Center et mises à jour

L’intégration de ces composants est indiquée dans la figure 16.9.

Espace de travail Azure

Log Analytics Automation

Rassembler et analyser Exécuter automatiquement

les journaux provenant les runbooks (plusieurs
de diverses sources pour cibles d'hôte)
fournir des requêtes
et des alertes

Azure

Sauvegarder des données Répliquer des données dans des régions

ou des VM entières en définies en fonction des stratégies
fonction des stratégies de planification et de conservation
de planification
et de conservation
Azure Azure Site
Backup Recovery

Figure 16.9  Plusieurs services Azure s'associent pour fournir des fonctionnalités

de gestion et de configuration dans l'ensemble de l'environnement de votre
application. Les services qui utilisent ces composants ne sont pas limités aux VM
ou aux ressources Azure et peuvent être compatibles avec d'autres fournisseurs de
cloud ou des systèmes sur site lorsqu'ils sont configurés de manière appropriée.

Les espaces de travail Log  Analytics et Azure  Automation sont deux composants
puissants sur lesquels nous pourrions facilement écrire des chapitres entiers. Avec
seulement une poignée de VM à gérer, il est facile de négliger la nécessité de mettre en
place un référentiel centralisé de journaux à des fins d'interrogation et d'alerte, ou un
moyen d'automatiser les configurations et les déploiements sur toutes les VM. Si vous
n'avez pas déjà dressé une liste de composants Azure sur lesquels revenir lorsque vous
aurez terminé de lire ce livre, commencez-en une en y ajoutant ces deux composants !
La chose la plus importante à comprendre concernant Azure est que la solution
comporte plusieurs services et composants qui peuvent souvent interagir entre eux et
se compléter les uns les autres. De la même façon que les VM Azure et les réseaux
virtuels Azure sont des services individuels, les deux services se complètent, voire
dépendent l'un de l'autre. Azure Backup et l'extension Azure  Diagnostics sont
d'excellents composants individuels, mais ils libèrent véritablement leur potentiel si les
espaces de travail Log Analytics et Azure Monitor sont utilisés pour surveiller leur état
et rassembler tous les événements ou avertissements générés. J'espère que vous avez
commencé à identifier certains de ces composants associés et à voir comment les
services Azure sont interdépendants. Maintenant que vous lisez les derniers chapitres
de ce livre qui abordent les options de sécurité et de pilotage, l'objectif est de s'assurer
que les applications que vous exécutez dans Azure sont intègres et stables.
 Azure Update Management 245

Une histoire d'identité

En parlant de services qui se complètent les uns les autres… Il existe une grande (une très
grande) composante d'Azure que nous avons seulement effleurée : Azure Active Directory
(Azure AD). L'identité est au cœur d'Azure. Azure AD fournit certaines des fonctionnalités
de sécurité que nous avons examinées dans le chapitre 6 avec le modèle de déploiement
Azure Resource Manager. La possibilité d'utiliser des contrôles RBAC pour limiter les
actions pouvant être exécutées par certains utilisateurs ou groupes sur une ressource se
rattache à une solution centralisée de gestion des identités. Même la possibilité de se
connecter au portail Azure ou à la CLI Azure est gérée par Azure AD.
Ce livre n'aborde pas Azure AD, car le champ d'application de ses fonctionnalités est
vaste et très différent des services IaaS et PaaS Azure comme les VM, les groupes de
machines virtuelles identiques (VMSS) et les applications Web. Le public des sujets peut
se recouper, mais la plupart des développeurs auraient un objectif différent concernant
les informations qu'ils souhaiteraient obtenir au sujet d'Azure AD par rapport à un
responsable d'applications ou à un informaticien chargé de déployer l'infrastructure.
Selon le type de compte Azure que vous utilisez, les fonctionnalités offertes par Azure AD
peuvent également être limitées. Lorsque vous vous inscrivez pour bénéficier d'un compte
d'essai gratuit Azure, une instance Azure AD par défaut est créée pour vous. Vous êtes le
compte principal dans ce répertoire, et vous disposez des droits d'administrateur complets.
Si vous vous connectez à Azure avec un compte de votre entreprise ou de votre
établissement d'enseignement, il y a de fortes chances pour que vous disposiez de peu ou
d'aucun droit d'administrateur. Donc, même si nous pouvions nous mettre d'accord sur
des sujets à aborder, vous pourriez ne pas être en mesure d'effectuer les exercices
directement. Et je ne recommande vraiment pas d'aller fouiller dans un véritable
environnement Azure AD pour apprendre comment il fonctionne !
Azure AD est un autre de ces services centraux dans Azure qui associe beaucoup
d'autres services et composants. Le cloud computing n'est pas une solution magique qui
vous facilite la tâche ou décompose les silos opérationnels. Vous avez besoin des
compétences nécessaires pour travailler avec différentes équipes et parties prenantes. Tout
au long de ces chapitres, j'espère que vous avez acquis les compétences de base pour ces
services Azure afin de comprendre comment élaborer des applications redondantes à
grande échelle et comment communiquer avec les autres équipes de manière plus efficace
et avec une meilleure connaissance des défis qu'elles peuvent rencontrer.

16.3.2 Consultation et application des mises à jour

Il peut falloir un certain temps à l'agent de VM pour effectuer la première analyse et
rendre compte de l'état des mises à jour appliquées. La liste des composants installés
doit également être comparée avec la liste des mises à jour disponibles pour un système
d'exploitation et une version donnés. Si votre VM n'a pas terminé l'opération et rendu
compte de son état, continuez à lire et revenez à cette étape après quelques minutes.
Quand elle est prête, la vue d'ensemble obtenue est illustrée à la figure 16.10. Soyez
patient, la préparation de l'agent nécessite entre 10 et 15  minutes avant qu'il ne
présente l'état Prêt et vous permette de planifier les mises à jour afin de pouvoir les installer.
Il est très bien d'avoir une liste des mises à jour requises, mais qu'en est-il de leur
installation  ? C'est là qu'intervient Azure  Automation. Lorsque vous avez activé
Update Management, plusieurs runbooks Azure Automation ont été créés afin de gérer
automatiquement le processus d'application des mises à jour requises.
246 Chapitre 16  Azure Security Center et mises à jour

Figure 16.10  Une fois que l'agent de VM a effectué l'analyse de conformité, une liste des mises
à jour disponibles est fournie. Selon le système d'exploitation et la version, Update Management peut
fonctionner conjointement avec l'espace de travail Log Analytics et Azure Monitor pour classer les mises
à jour par ordre d'importance ou fournir des liens vers les pages des mises à jour correctives pertinentes.

Tester
Si vous avez de la chance (ou si vous êtes malchanceux), votre VM peut signaler
qu'aucune mise à jour n'est requise. Les images de VM sont souvent mises à jour dans
Azure. Si vous déployez une VM peu de temps après la création de l'image la plus
récente, toutes les mises à jour requises sont déjà installées. Si c'est le cas, lisez ces
étapes pour savoir ce que vous devez faire lorsque vos VM ont besoin d'être mises à jour.
Pour appliquer les mises à jour requises pour votre VM, procédez comme suit :

1 Dans la section Gestion des mises à jour de votre VM, sélectionnez Planifier le
déploiement de la mise à jour.
2 Attribuez un nom au déploiement de la mise à jour, par exemple
azuremolupdates, puis examinez la classification des mises à jour. Vous pouvez
contrôler quels ensembles de mises à jour sont appliqués. Pour l'instant, laissez
toutes les options telles qu'elles sont définies par défaut.
3 La fonctionnalité Mises à jour à exclure vous permet d'indiquer des mises à jour
spécifiques que vous ne souhaitez pas installer. Si vous savez que votre application
nécessite la version spécifique d'un package ou d'une bibliothèque, vous pouvez
vous assurer qu'aucun package mis à jour causant des dysfonctionnements n'est
installé. Examinez les options disponibles, même si aucune modification n'est
nécessaire dans cet exercice.
 Azure Update Management 247

4 Sélectionnez Paramètres de planification, puis choisissez une date d'application

des mises à jour à partir des options de calendrier et d'heure. Au moins
cinq  minutes doivent séparer l'heure actuelle et l'heure de début que vous
indiquez, pour laisser quelques instants à la plateforme Azure afin de traiter et
de planifier votre runbook dans Azure Automation.
5 Lorsque vous êtes prêt, sélectionnez OK.
6 Si certaines applications et services doivent être interrompus ou arrêtés avant
l'application des mises à jour et redémarrés lorsque celles-ci sont terminées,
sélectionnez Pré-scripts + post-scripts. Des tâches d’automatisation distinctes
peuvent être configurées pour effectuer des actions sur les machines virtuelles
avant et après l’application des mises à jour.
7 Fenêtre de maintenance (minutes) définit la durée maximale d'exécution du
processus de mise à jour avant que la VM ne doive redevenir opérationnelle.
Cette fenêtre empêche l'exécution de processus de mise à jour de lo
ngue durée qui peuvent rendre une VM indisponible pendant plusieurs heures.
Vous pouvez avoir besoin de définir un délai de fenêtre de maintenance plus
court ou plus long selon les contrats de niveau de service des applications qui
s'exécutent sur ces VM, le nombre de mises à jour requises ou la taille de celles-ci.
Acceptez la valeur par défaut, puis sélectionnez Créer.
8 Dans la fenêtre Gestion des mises à jour, sélectionnez Calendriers de
déploiement. Une liste s'affiche et indique les mises à jour dont l'installation est
planifiée à la date et à l'heure que vous avez indiquées, comme illustré à la
figure 10.86.11.

Figure 16.11  La liste des tâches de déploiement planifiées s'affiche. Chaque mise à jour est
automatiquement appliquée à l'heure définie, à moins que vous ne décidiez de supprimer la
tâche y étant associée.

9 En haut de la fenêtre Gestion des mises à jour, sélectionnez Gérer plusieurs

machines. La fenêtre bascule vers le compte Azure Automation qui a été créé
lors de l'activation de la fonctionnalité Update Management pour la VM. Ne vous
posez pas trop de questions au sujet du fonctionnement des runbooks pour
l'instant. Vous n'avez rien à personnaliser, et nous parlerons d'Azure Automation
au chapitre 18.
Notez que vous pouvez choisir Ajouter une machine virtuelle Azure ou Ajouter
une machine non-Azure, comme illustré à la figure 16.12. Cette capacité montre
une approche centralisée de gestion des mises à jour pour l'ensemble de
l'environnement de votre application, et pas seulement pour les VM Azure.
248 Chapitre 16  Azure Security Center et mises à jour

Figure 16.12  Dans votre compte Azure Automation, vous pouvez gérer plusieurs ordinateurs et afficher
leur état ou appliquer des mises à jour. Les VM Azure et les ordinateurs non-Azure peuvent tous être
surveillés et contrôlés par le même compte Azure  Automation. En coulisses, Azure peut s'intégrer à
d'autres fournisseurs pour installer des agents sur des ordinateurs dans un environnement hybride. Cette
intégration permet d'utiliser un tableau de bord et une plateforme de gestion uniques pour répondre à vos
besoins en matière de mise à jour.

10 Revenez à la fenêtre Gestion des mises à jour pour votre machine virtuelle, puis
sélectionnez l’onglet Hist orique. Lorsque le déploiement de votre mise à jour
démarre, son état s'affiche. N’oubliez pas que vous avez planifié l'exécution de la
tâche d'ici quelques minutes, elle ne s'affichera donc pas immédiatement.
11 Sélectionnez la planification pour afficher l’état et la sortie, comme illustré à la
figure 16.13.

Figure 16.13  Vous pouvez surveiller l'état des tâches Azure Automation en cours dans le portail. Pour
examiner ou dépanner des tâches, vous pouvez cliquer sur l'une d'entre elles pour afficher les résultats
et les journaux générés.
 Exercice pratique : activation de l'accès JIT et des mises à jours pour une VM Windows 249

12 Une fois le déploiement de la mise à jour terminé, revenez à votre groupe de

ressources, sélectionnez votre VM, puis choisissez Gestion des mises à jour.
Quelques minutes peuvent être nécessaires à l'agent pour se mettre à jour et
rendre compte de l'application des mises à jour via un espace de travail
Log Analytics. Il devrait alors afficher sur le tableau de bord que la VM est à jour
et qu'aucune mise à jour supplémentaire n'est requise.
Ce chapitre conclut cette présentation éclair de Security  Center et des composants
associés tels que l'accès JIT à la VM et Update Management. L'objectif est que vous ne
vous contentiez plus de simplement réfléchir au déploiement et à l'exécution d'une
VM ou d'une application Web, mais qu'au lieu de cela, vous établissiez un plan pour la
gestion des applications plus générale qui est associée à ces opérations. Le cloud
computing ne fait pas des stratégies de sécurité des précautions superflues. Il est même
sans doute plus important de sécuriser les ressources dans un tel environnement.
Laissez les fonctionnalités Azure comme Security Center vous guider dans les mesures
à prendre, et utilisez les outils intégrés comme Update  Management et
Azure  Automation pour assurer la sécurité permanente de l'intégralité de votre
environnement .

16.4 Exercice pratique : activation de l'accès JIT et des mises à jours

pour une VM Windows
Les différents composants abordés dans ce chapitre ont peut-être eu besoin d'un
certain temps pour s'activer et rendre compte de leur état attendu. Cet exercice
pratique est facultatif. Son objectif est de montrer que ces fonctionnalités ne se limitent
pas à un seul système d'exploitation. Si vous n'avez pas le temps, ou si vous pensez
comprendre comment vous appliquer ces fonctionnalités à une VM Windows, n'hésitez
pas à ignorer cet exercice. Sinon, vous pouvez suivre les étapes suivantes pour vous
entraîner un peu plus à utiliser Security  Center et Update  Management. C'est en
forgeant que l'on devient forgeron, non ?

1 Créez une machine virtuelle Windows  Server de votre choix dans le même
groupe de ressources que celui utilisé dans les exercices précédents, par exemple
azuremolchapter16.
2 Affichez les règles NSG pour la machine virtuelle/sous-réseau et supprimez
toutes les règles par défaut qui autorisent RDP sur le port TCP 3389.
3 Utilisez votre client local Connexion Bureau à distance pour vérifier que les connex-
ions RDP sont bloquées.
4 Demandez l'accès JIT, réexaminez les règles de NSG et confirmez que vous
pouvez maintenant établir une connexion RDP vers votre VM.
5 Activez Update Management sur votre VM Windows. Cette fois, vous devriez pouvoir
utiliser les comptes Azure Automation et l'espace de travail Log Analytics existants.
6 Laissez l'agent de surveillance rendre compte des mises à jour requises, puis
planifiez les mises à jour à appliquer via Azure Automation.
 Partie 4

Les technologies vraiment

intéressantes

P assons maintenant au plus intéressant ! Dans ces derniers chapitres, nous

allons découvrir quelques-unes des technologies à venir que vous pouvez utiliser
dans Azure, telles que l'intelligence artificielle, le Machine Learning, les conte-
neurs, Kubernetes et l'Internet des objets. Même si vous n'utilisez pas encore ces
services, vous y aurez certainement affaire prochainement compte tenu des ten-
dances informatiques actuelles. Ces services certaines des technologies les plus
intéressantes à utiliser. Même si nous abordons ces sujets très rapidement pour
que vous puissiez en prendre connaissance lors de votre pause déjeuner, ils fer-
ont parfaitement l'affaire en guise de conclusion et pour vous donner un aperçu
des possibilités en matière de création dans Azure.
 17
Machine Learning et
intelligence artificielle

J'espère que nous ne connaîtrons pas un avenir tout droit tiré de Terminator ou de
Matrix. Dans ces films, les machines se battent pour prendre le contrôle, et
l'ascension de l'intelligence artificielle (IA) met ainsi presque fin à l'humanité. Une
source d'inquiétude que l'on connaît actuellement dans le monde de l'informatique
est le fait que les principaux acteurs du développement de l'IA soient de grandes
entreprises privées, qui travaillent de façon peu (ou pas) réglementée et sans
surveillance centrale. Attention, je ne veux pas dire que l'IA est un problème ! Les
assistants numériques des smartphones peuvent vous aider à accomplir de
nombreuses tâches quotidiennes. Les systèmes de Machine Learning (ML) mis en
œuvre dans les applications de navigation permettent de contrôler le trajet
quotidien des utilisateurs pour suggérer des itinéraires alternatifs au vu des
conditions de trafic ou météorologiques. Les commandes de chauffage domotiques
permettent d'ajuster automatiquement la température en fonction de la
température extérieure, de l'heure de la journée et de la saison (l'été ou l'hiver).
Dans la dernière partie de ce livre, vous allez découvrir les services Azure proposés en
matière d'apprentissage automatique et d'intelligence artificielle. Dans un seul chapitre.
Lors de votre pause déjeuner. Soyons réalistes : 45 minutes de lecture ne suffiront pas
pour faire de vous un expert en ML ou en IA ! Si vous mangez votre sandwich rapidement,
vous pourrez apprendre suffisamment de choses sur les différents services proposés par
Azure pour comprendre comment intégrer certains de ces services de ML et d'IA dans
vos applications. Pour la plupart, les services Azure de ML et d'IA présupposent une
certaine expérience préalable en matière d'algorithmes de données, de langages de
programmation, de traitement par lots ou de compréhension du langage. Ne vous
attendez donc pas à devenir un expert dans l'heure qui suit !
Dans ce chapitre, nous allons faire une présentation éclair de certains des
services Azure Cognitive Services qui proposent des fonctions de ML et d'IA. Vous allez
apprendre à utiliser ces services pour faire appel à des fonctions de Machine Learning de
base sur des modèles de données, puis vous allez rapidement utiliser le service Azure
Web Apps et Microsoft Bot Framework pour appliquer certains des services d'IA qui peuvent
exécuter un bot de pizzeria permettant aux clients de commander des pizzas.

253
254 Chapitre 17  Machine Learning et intelligence artificielle

17.1 Présentation de l'intelligence artificielle (IA) et du Machine

Learning (ML), ainsi que du lien entre les deux technologies
Accrochez-vous, car nous allons prendre beaucoup de vitesse en seulement quelques
pages  ! Lorsqu'il s'agit de développer des applications dans Azure, l'IA et le ML se
recoupent souvent. Voyons en quoi chacune des technologies consiste avant de nous
intéresser à la façon dont elles travaillent ensemble.

17.1.1 Intelligence artificielle

L'IA permet aux ordinateurs d'accomplir tes tâches avec un certain niveau de souplesse
et de conscience, ainsi que d'ajuster leurs décisions en fonction de facteurs externes
ou sans intervention humaine. En général, l'objectif n'est pas de construire un système
complètement autonome capable d'évoluer et de devenir doué de pensée, mais plutôt
d'utiliser un ensemble de modèles de données et d'algorithmes pour orienter le
processus décisionnel.
Siri, Cortana et l'Assistant Google sont quelques exemples de systèmes d'IA communs
disponibles sur ordinateur et sur smartphone. Comme le montre la figure 17.1, ces
ressources d'IA vous permettent de communiquer, souvent via des commandes vocales,
pour obtenir un itinéraire, définir des rappels, effectuer des recherches sur le Web, etc.

Commandes vocales
Définir Commandes textuelles
un rappel Vérifier la
météo Créer un E-mail
Appeler mémo envoyé
Bob IA d'assistants
numériques courants Lancer une
minuterie
Assistant
Google Cortana

Siri

Applications intégrées
Rdv de
Notifications
calendrier
par e-mail
Circulation
+ trajet

Figure 17.1  Dans la vie quotidienne, l'IA est fréquemment utilisée sous la forme d'assistants
numériques tels que Cortana, Siri, et l'Assistant Google. Vous pouvez utiliser des commandes vocales ou
textuelles pour interagir avec eux, et ils peuvent surveiller votre calendrier quotidien ou les conditions de
circulation pour vous avertir d'éventuels problèmes.

Les assistants numériques comme ceux-ci ne peuvent pas généralement être qualifiés
de très intelligents. Ils écoutent vos entrées et y répondent. Mais ces entrées peuvent
varier, et il peut ne pas toujours s'agir de commandes spécifiques. Pensez à la façon
dont un assistant numérique vous permet de définir un rappel. Vous pouvez utiliser
l'une des phrases suivantes :
 Présentationdel'intelligenceartificielle(IA)etduMachineLearning(ML),ainsiquedulienentrelesdeuxtechnologies 255

¡ « Rappelle-moi d'acheter du lait à 17 heures. »

¡ « Dis-moi d'acheter du lait lorsque je rentrerai du travail. »
¡ « Il faut que je prenne du lait lorsque je serai au supermarché. »
Si vous développiez une application traditionnelle, vous devriez écrire du code capable
de gérer toutes les variantes possibles dans la manière de fournir des instructions. Vous
pourriez créer des expressions régulières pour comprendre certaines des variantes,
mais que se passerait-il si l'utilisateur utilisait une phrase que vous n'aviez pas
programmée  ? Ou s'il interagissait par commande textuelle et faisait une faute de
frappe que vous n'aviez pas anticipée  ? L'IA est très bien adaptée à ces types
d'interactions. Comme le montre la figure  17.2, l'application est programmée pour
plusieurs phrases communes et est alors en mesure d'émettre une hypothèse bien
fondée d'après ce qu'elle « pense » que l'utilisateur demande.

L'utilisateur ne veut probablement

« Rappelle-moi d'acheter
du lait à 17 heures. »
« Dis-moi d'acheter du
lait lorsque je rentrerai
du travail. »
« Il faut que je prenne du
lait lorsque je serai au
supermarché. »
pas être réveillé à 5 heures du
Création du rappel pour
matin pour acheter du lait.
que l'utilisateur achète
IA d'assistants du lait à 17 h
numériques courants L'utilisateur quitte son
lieu de travail et entre
Assistant dans sa voiture pour Contrôle et détection du
Google Cortana rentrer chez lui moment où l'utilisateur
rentre chez lui
Siri
Utilisation de la
localisation GPS pour
La position GPS de l'utilisateur et la détecter un supermarché
recherche sur la carte indiquent qu'il
se trouve dans un supermarché

Figure 17.2  L'IA peut tenir compte des entrées de l'utilisateur et prendre les décisions qui conviennent le mieux à
l'action prévue. L'IA n'est pas préprogrammée avec toutes les réponses et tous les arbres de décision possibles. Au
lieu de cela, elle utilise des modèles de données et des algorithmes pour appliquer le contexte à l'entrée de
l'utilisateur et interpréter sa signification ainsi que le résultat souhaité.

Même dans des formes complexes d'IA, il ne s'agit pas (encore) d'une véritable
intelligence, mais plutôt d'une supposition éclairée basée sur un modèle de données
utilisé pour l'apprentissage de l'IA. Ce modèle de données peut inclure de nombreuses
variantes et expressions, ainsi qu'apprendre de nouvelles significations au fil du temps.
Comment l'IA apprend-elle, et d'où viennent ces modèles de données ? C'est dans ce
cadre que le Machine Learning joue un rôle majeur.

17.1.2 Machine Learning

Ces dernières années, Big Data est devenu un terme particulièrement à la mode dans le
monde de l'informatique. Voici le concept : les systèmes informatiques, en particulier
ceux mis en œuvre dans le cloud, constituent une excellente ressource pour traiter de
grands volumes de données. De très grands volumes de données. L'exécution de ces
tâches de traitement peut prendre quelques minutes ou plusieurs heures, selon le
volume de données et les calculs requis. Elles permettent de préparer et d'analyser de
grands volumes de données afin d'identifier des tendances et des corrélations spécifiques.
Ces apprentissages forment des modèles de données que d'autres applications ou
256 Chapitre 17  Machine Learning et intelligence artificielle

Les données sont Des algorithmes de Les applications

Le Big Machine Learning Modèle de
prétraitées et utilisent le modèle
Data préparées / assainies sont appliqués aux données de données
données

Figure 17.3  De grandes quantités de données brutes sont traitées et rendues prêtes à l'emploi. Différentes méthodes
de préparation et d'assainissement des données peuvent être mises en œuvre en fonction des signaux d'entrée bruts.
Des algorithmes de Machine Learning sont ensuite appliqués aux données préparées afin de construire un modèle de
données approprié qui reflète la meilleure corrélation entre tous les points de données. Différents modèles de données
peuvent être créés et affinés au fil du temps. Les applications peuvent utiliser les modèles de données sur leurs propres
entrées de données pour prendre de meilleures décisions et comprendre les tendances.

IA peuvent utiliser pour prendre de meilleures décisions. Comme le montre la figure 17.3,

le Machine Learning implique quelques étapes et comprend des entrées et des sorties.
Voici comment fonctionne le Machine Learning dans sa forme la plus élémentaire :
1 Pour lancer le processus, de grandes quantités de données brutes sont fournies
en tant qu'entrées.
2 Elles sont traitées et préparées dans un format utilisable afin de se concentrer sur
les points de données spécifiques requis à des fins d'analyse.
3 Des algorithmes de Machine Learning sont appliqués aux données. Cette étape
représente le plus gros du volume de traitement. Les algorithmes sont conçus
pour détecter et calculer les similitudes ou les différences entre les nombreux
points de données.
4 L'analyse des algorithmes est utilisée comme base pour créer un modèle de
données qui définit des tendances dans les données. Ces modèles de données
peuvent être affinés au fil du temps si des parties du modèle s'avèrent erronées
ou incomplètes lorsque des données réelles supplémentaires sont appliquées.
5 Les applications utilisent les modèles de données pour traiter leurs propres jeux
de données. Le volume de ces jeux de données est généralement beaucoup plus
petit que celui des données brutes fournies aux algorithmes de Machine
Learning. Si le modèle de données est valide, même un petit volume de données
d'entrée provenant de l'application suffit pour déterminer le bon résultat ou la
corrélation correspondante.
Le Machine Learning implique souvent des algorithmes complexes, conçus pour traiter
tous les points de données fournis. Hadoop et Apache Spark sont deux piles d'applications
couramment utilisées pour traiter du Big Data. Azure HDInsight est un service géré qui
vous permet d'analyser les jeux de données volumineux traités par ces piles d'applications.
Pour aller plus loin en matière d'analyse et d'algorithmes, le langage de programmation R
est couramment utilisé par les data scientists pour concevoir les modèles requis. Ne vous
souciez pas trop d'Hadoop ou de R. Voici l'essentiel : Azure peut exécuter les outils de
Machine Learning courants qui sont largement reconnus dans le secteur.

17.1.3 Association de l'IA et du Machine Learning

L'application de navigation est un exemple courant d'application que l'on peut trouver
sur smartphone, comme illustré à la figure  17.4. Votre fournisseur (Google, par
exemple) peut suivre l'itinéraire que vous prenez pour travailler chaque jour,
l'heure habituelle à laquelle vous partez de chez vous et le temps qui vous est nécessaire
pour effectuer ce trajet.
Cet exemple de Google Maps constitue un scénario de collaboration entre l'IA
et le Machine Learning. L'IA est utilisée pour savoir quand générer une notification
basée sur les données reçues après le traitement du
 Présentationdel'intelligenceartificielle(IA)etduMachineLearning(ML),ainsiquedulienentrelesdeuxtechnologies 257

Prévisions
Utilisateur 1 météo
Trajet quotidien Météo en Automobiliste
Trajet quotidien temps réel actif 1
Trajet quotidien Automobiliste
actif 2

Utilisateur 2 Automobiliste
actif 3
Trajet quotidien Service Google
Trajet quotidien Maps
Trajet quotidien

Utilisateur 3 Suggestions et alertes

sur la circulation
Trajet quotidien
Trajet quotidien Votre
smartphone
Trajet quotidien

Figure 17.4  Chaque jour, le service Google Maps reçoit plusieurs points de données de la part des
utilisateurs qui enregistrent les détails de leur trajet. Ces données peuvent être préparées et traitées,
tout comme les prévisions météorologiques et les conditions météo en temps réel lors de ces trajets
domicile-travail. Des algorithmes de ML peuvent être appliqués à ces jeux de données volumineux et à un
modèle de données généré. Les utilisateurs actifs d'un plus petit échantillon fournissent les données des
conditions de leur trajet ou météorologiques actuelles au service Google Maps. Ainsi, le modèle de
données peut être appliqué afin de prédire le déroulement de leur trajet domicile-travail et de générer une
alerte concernant la circulation sur leur smartphone, qui suggère alors un itinéraire alternatif.

modèle de données de Machine Learning. Un autre exemple de collaboration entre

l'IA et le Machine Learning est l'idée concernant la création d'un rappel pour acheter
du lait. Si l'IA a été formée avec des modèles de données de Machine Learning,
l'assistant sait que vous achetez probablement du lait au supermarché, de sorte qu'il ne
vous rappellera pas de le faire si vous vous rendez dans un magasin de bricolage. Le
modèle de données de Machine Learning serait également en mesure d'aider
l'IA à comprendre qu'il est très probable que vous souhaitiez recevoir un rappel à
5 heures de l'après-midi, et non du matin. Ainsi, elle ne devrait pas vous réveiller à
5 heures en vous rappelant d'aller acheter du lait. Si votre smartphone sait que vous
vous mettez au volant à 17  heures pour rentrer du travail, le système de Machine
Learning génèrera un modèle de données qui prédit que vous rentrez chez vous, soit
le bon moment pour l'IA de vous rappeler d'acheter du lait.
Ces exemples élémentaires mais très clairs montrent comment le Machine Learning
permet d'améliorer l'IA. Vous formez une IA en fournissant un ensemble de points de
données qui sont traitées par le Machine Learning pour améliorer l'exactitude de ses
résultats ou lui permettre de prendre de meilleures décisions.

17.1.4 Outils Azure de Machine Learning pour les data scientists

Je tiens à présenter rapidement quelques façons d'associer l'analyse de chiffres et le
Machine Learning en conditions réelles. Pour rendre ce chapitre accessible à tous, les
exercices utilisent Microsoft Bot  Framework pour l'IA et Language Understanding
Intelligent Service (LUIS) pour le Machine Learning. Pour que vous mettiez la main à
la pâte avec le Machine Learning, nous devons nous intéresser d'un peu plus près au
traitement des données et aux algorithmes.
258 Chapitre 17  Machine Learning et intelligence artificielle

Azure propose plusieurs composants très intéressants lorsqu'il s'agit d'explorer des
données à très large échelle. Tout d'abord, il y a Azure Machine Learning, un service
Web qui vous permet de créer des expériences visuellement en ajoutant des jeux de
données et des modèles d'analyse. Ces expériences peuvent utiliser des sources de
données telles que Hadoop et SQL, ainsi que des fonctionnalités de programmation
supplémentaires via des langages comme R et Python. Vous pouvez faire glisser et
déposer des sources de données, des méthodes de préparation des données et des
algorithmes de Machine Learning. Vous pouvez ajuster ces algorithmes, puis revoir et
mettre au point les modèles de données générés.
L'objectif d'Azure Machine Learning est de rendre aussi accessibles que possible les
ressources de calcul à grande échelle disponibles dans Azure. L'un des principaux avantages
offerts par l'exécution des tâches d'analyse des données de Machine Learning dans Azure
est que cela vous permet de bénéficier d'une puissance de calcul très importante, que vous
pouvez utiliser seulement lorsque cela est nécessaire pour réaliser vos calculs. Dans les
environnements traditionnels, ces ressources de calcul onéreuses resteraient longtemps
inactives entre chaque tâche de traitement de données.
Azure propose une autre ressource intéressante pour effectuer des opérations
avancées de Machine Learning et d'analyses de chiffres  : les machines virtuelles de
science de données (DSVM). Ces VM sont disponibles sous Linux et sous Windows.
Elles sont proposées avec de nombreuses applications courantes préinstallées, telles
que Jupyter Notebooks, Anaconda Python et R Server ou SQL Server (figure 17.5).

Figure 17.5  Des DSVM sont disponibles sous Linux et sous Windows. Cette DSVM Window Server 2016
est proposée avec plusieurs applications de science des données préinstallées, telles R Server et
Jupyter Notebooks. Les DSVM vous permettent d'être rapidement opérationnel en matière de traitement
du Big Data et de création d'algorithmes de Machine Learning.
 Azure Cognitive Services 259

Vous n'avez pas besoin d'installer tous les outils et toutes les dépendances sur votre
ordinateur local. Vous pouvez créer une DSVM dotée d'autant de ressources processeur
et mémoire que nécessaire pour traiter rapidement vos données, puis la supprimer
lorsque votre tâche de traitement est terminée et que vous avez les modèles de données
dont vous avez besoin.

17.2 Azure Cognitive Services

Qu'en est-il des services d'IA disponibles pour rendre vos applications plus
intelligentes ? Azure propose la suite Cognitive Services, qui regroupe un ensemble de
services connexes. Les services couvrent quelques domaines communs de l'IA qui vous
permettent d'intégrer rapidement ces ressources intelligentes dans vos applications.
Ils sont répartis dans les domaines généraux suivants :
¡ Vision
¡ Voix
¡ Langue
¡ Décision
¡ Recherche
Plus de deux douzaines de services font partie de la famille Cognitive Services. Voici
certains de ces services :
¡ Vision, qui comprend les fonctionnalités suivantes :
– Vision par ordinateur pour l'analyse d'image, le sous-titrage et l'identification.
– Visage pour analyser et détecter les visages dans les images.
¡ Parole, qui comprend les fonctionnalités suivantes :
– Reconnaissance vocale pour analyser et convertir la parole en texte, et inversement.
– Reconnaissance d'interlocuteur pour identifier et confirmer l'interlocuteur.
¡ Langage, qui comprend les fonctionnalités suivantes :
– Language Understanding (LUIS) pour comprendre et traiter les interactions avec
les utilisateurs. Nous découvrirons LUIS dans l'exercice pratique à la fin de ce
chapitre.
– Traduction de texte pour analyser et corriger les fautes d’orthographe ou
effectuer des traductions.
¡ Décision, qui comprend les fonctionnalités suivantes :
– Content Moderator pour examiner et modérer des photos, des vidéos et du texte.
– Personalizer pour analyser les modèles et fournir des recommandations aux clients.
¡ Recherche, qui comprend les fonctionnalités suivantes :
– Recherche personnalisée Bing pour mettre en œuvre des fonctionnalités de recher-
che sur vos données personnalisées et dans les applications.
– Suggestion automatique Bing pour fournir des suggestions automatiques lorsque
les utilisateurs saisissent des termes de recherche et des requêtes.
Comme vous pouvez le voir, de nombreux services Azure combinent des fonctions d'IA
et de Machine Learning. Ce chapitre met l'accent sur le langage, en particulier LUIS.
Ce service est souvent utilisé pour créer un bot intelligent capable de venir en aide aux
clients sur votre site Web. Vous pouvez ensuite créer une application qui utilise des
services d'IA dans Azure, capable d'interpréter des expressions et des questions, et
fournir la réponse appropriée pour guider un utilisateur lors d'un processus de
commande ou d'une demande de support.
260 Chapitre 17  Machine Learning et intelligence artificielle

17.3 Création d'un bot intelligent pour aider les clients à commander
des pizzas
Un bot est une application programmée pour répondre à des tâches et à des entrées
d'un utilisateur. Si cette description vous fait penser à n'importe quelle application,
c'est normal  : un bot, c'est à peu près ça  ! La différence réside dans la façon dont
l'application de bot détermine la réponse.
Le plus souvent, un bot basique courant n'est rien de plus qu'une application
proposant une certaine forme d'automatisation. Lorsqu'un utilisateur envoie un
message, définit une balise sur un e-mail ou soumet un terme de recherche, le bot
effectue des tâches préprogrammées qui exécutent une action spécifique. Ni l'IA ni le
Machine Learning n'entrent véritablement en jeu ici. L'application de bot répond
simplement à l'entrée de l'utilisateur.
Avec l'infrastructure adaptée, les capacités d'un bot peuvent être étendues, et nous
pouvons le rendre plus libre et plus intelligent. Au début de ma présentation de l'IA, j'ai
expliqué qu'une application classique doit être préprogrammée avec toutes les entrées
utilisateur prévues et leur sortie correspondante. Mais cela n'offre aucune flexibilité si
l'utilisateur fournit une expression d'entrée différente ou fait une erreur d'orthographe,
par exemple.
Microsoft produit le Bot  Framework, qui permet à un bot Azure
d'intégrer les kits de développement logiciel (SDK) Bot Builder et de se connecter à
Azure Cognitive Services en toute simplicité. Une expérience limitée en programmation
suffit pour créer des bots intelligents qui exploitent toute la puissance d'Azure afin
d'offrir une expérience client de qualité. Gardez-vous toutefois de créer Skynet, à moins
que vous ne connaissiez la fin de Terminator !

17.3.1 Création d'un bot d'application Web Azure

Déployons un bot et intégrons quelques services d'IA et de Machine Learning. Le bot
s'exécute dans une application Web Azure et utilise Microsoft Bot Framework pour se
connecter à LUIS et permettre au client de commander des pizzas. La figure  17.6
décrit ce que ces exercices permettent de créer et quels services sont utilisés.

Abonnement Azure
Plan App Service

Compréhension Application Web

du langage et de
l'intention Microsoft Bot
Application Application
Connector
LUIS Node.js
Framework

Stockage des données persistantes

du bot et de l'état de la session
Figure 17.6  Dans les exercices
Compte de à venir, vous créerez un bot
stockage
d'application Web qui intègre
Table plusieurs services d'IA et de
Machine Learning Azure pour
interagir avec un client et l'aider
à commander des pizzas.
 Création d'un bot intelligent pour aider les clients à commander des pizzas 261

Tester
Pour créer un bot d'application Web Azure, procédez comme suit :

1 Ouvrez le portail Azure, puis sélectionnez Créer une ressource dans le coin
supérieur gauche.
2 Recherchez et sélectionnez Web App Bot (Bot d'application Web), puis
sélectionnez Créer.
3 Saisissez un nom, tel que azuremol, puis créez un nouveau groupe de ressources,
tel que azuremolchapter17.
4 Sélectionnez la région la plus appropriée, puis choisissez le niveau de tarification
F0. Votre bot ne traitera pas beaucoup de messages. Le niveau gratuit (F0)
convient donc très bien.
5 Sélectionnez un modèle de bot et choisissez le langage de SDK node.js.
6 Créez un bot de base, car nous fournirons notre propre exemple de code
d’application dans un exercice ultérieur. Cette étape crée une application LUIS que
vous pouvez utiliser à des fins d'apprentissage linguistique et de Machine Learning.
7 Choisissez la région la plus appropriée pour votre application LUIS et créez un
compte LUIS.
8 Nommez le compte LUIS, par exemple, azuremol. Ce compte LUIS gère le
sentiment des utilisateurs pour notre bot.
9 Choisissez Plan App Service, puis créez un plan. Saisissez un nom, par exemple
azuremol, et là encore, sélectionnez la région la plus appropriée.
10 Désactivez App Insights, car votre bot n'utilisera pas cette fonctionnalité. Comme
pour les chapitres précédents sur les applications Web, vous pouvez exploiter
tout le potentiel d'App Insights à des fins de production pour bénéficier d'une
visibilité sur les performances de votre application en transmettant des données
et des analyses directement à partir du code.
11 Acceptez l'option de création automatique de l'ID d'application et de mot de
passe Microsoft, acceptez le contrat et sélectionnez Créer.
La création du bot d'application Web et des composants associés prend quelques
minutes. Le travail réalisé en arrière-plan est considérable :
¡ Un plan Azure App Service est créé.
¡ Une application Web est déployée, ainsi qu'une application Web Node.js d'exemple.
¡ Une application LUIS est créée, et les clés de connexion sont configurées avec
votre application Web.
¡ Un bot est créé avec le Microsoft Bot Connector, et les clés de connexion sont
configurées à partir de votre application Web.

17.3.2 Langage et compréhension de l'intention avec LUIS

Le langage est l'un des domaines Azure Cognitive Services dont nous avons parlé plus
tôt. Cela est logique, car l'interaction avec une IA implique souvent l'utilisation d'une
certaine forme de langage. Vous pouvez utiliser LUIS pour traiter un message ou une
expression de l'utilisateur, puis déterminer son intention. La connaître permet alors
à votre application de fournir une réponse appropriée. Développons les capacités de
votre bot avec LUIS.
262 Chapitre 17  Machine Learning et intelligence artificielle

Tester
Pour créer une application LUIS et utiliser le Machine Learning pour la former, procédez
comme suit

1 Ouvrez un navigateur Web à l'adresse www.luis.ai, et connectez-vous avec

les  informations d’identification Microsoft que vous utilisez pour votre
abonnement Azure.
2 Sélectionnez Accéder à Mes applications, puis choisissez votre application
azuremol, par exemple. Le nom de votre application LUIS comporte
probablement quelques caractères numériques supplémentaires, ajoutés à partir
du nom de bot que vous avez spécifié dans le portail Azure.
Quelques intentions préconçues ont été créées, mais vous devez écraser
l'application LUIS avec un exemple plus approprié à une pizzeria.
3 Tout d'abord, téléchargez le fichier azuremol.json depuis GitHub à l'adresse
https://github.com/fouldsy/azure-mol-samples-2nd-ed/blob/master/17/luisapp/
azuremol.json sur votre ordinateur local. Pour vous simplifier la vie, sélectionnez le
bouton Raw (Brut) dans GitHub afin de n'afficher que le contenu du fichier.
4 De retour dans votre application LUIS, choisissez Paramètres en haut à droite,
puis sélectionnez Versions.
5 Choisissez d'importer une version, accédez au fichier azuremol.json que vous
avez téléchargé et sélectionnez-le. Ensuite, saisissez 1.0 en guise de nom de
version, puis sélectionnez Terminé.
6 Revenez dans la section consacrée à la version dans le menu du haut pour
afficher les intentions importées à partir de l'exemple d'application. Choisissez
une ou deux intentions, par exemple greetings ou orderFood, puis regardez
quelques-uns des exemples de phrases qu'un client pourrait utiliser pour
communiquer avec le bot.
7 Avant que vous puissiez voir l'application en action, vous devez la former.
Sélectionnez Former, puis attendez quelques secondes pour que le processus se
termine. La figure  17.7 montre les processus de Machine Learning à l'œuvre
pour former votre application LUIS.
Intentions

greetings

showMenu

orderFood
Modèle de
Formation données de Bot d'application
l'application LUIS Compréhension du Web
Entités langage et traitement
« Une pizza au de l'intention
pepperoni »

« Une pizza végétarienne,

s'il vous plaît »

Figure 17.7  Lorsque vous formez l'application LUIS, les intentions et les entités sont entrées et traitées pour créer un modèle de
données. Votre bot d'application Web utilise ensuite ce modèle de données pour traiter la compréhension du langage et de
l'intention. Seul un petit nombre d'intentions et d'entités sont entrées à des fins de traitement. Le modèle de données n'est donc
pas parfait. En situation réelle, beaucoup plus d'intentions et d'entités seraient fournies. Vous formeriez, testeriez et affineriez le
modèle de données à plusieurs reprises afin de créer des jeux de données de plus en plus volumineux, qui vous permettraient
d'élaborer un modèle précis pour le traitement du langage et de l'intention.
 Création d'un bot intelligent pour aider les clients à commander des pizzas 263

Dans une application plus complexe utilisée en situation réelle, il faudrait

probablement plus de temps pour compléter ce processus de formation. En effet,
toutes vos intentions et entités sont traitées par les algorithmes de Machine Learning
afin de construire le modèle de données dont votre application a besoin pour
répondre de manière appropriée lors des interactions avec le client.
8 Une fois l'application LUIS formée, sélectionnez Tester. Saisissez quelques formules
de salutations, comme hi et hello. Sous chacun de vos messages figure l'intention
considérée comme la plus plausible, ainsi que la probabilité que le message ou
l'énoncé que vous avez fourni corresponde à l'intention. Ces salutations simples
devraient correspondre à l'intention greetings (salutations).
9 Essayez de saisir une formulation de salutation différente, comme (good) afternoon
(bonjour, en matinée) ou (good) evening (bonsoir). La formule de politesse en un seul mot
définie selon le moment de la journée peut renvoyer une intention la plus plausible
s'avérant incorrecte (orderStatus, par exemple). Essayez d'autres expressions
jusqu'à ce qu'une d'entre elles ne corresponde pas à l'intention prévue, ce qui
indique que l'application LUIS ne comprend pas bien ce que vous voulez dire.
Sélectionnez l'un de vos messages incorrects, tels que morning (formule de politesse
en un seul mot pour la matinée) et choisissez Inspecter.
10 Dans le menu d'inspection, modifiez l'intention notée comme la plus plausible. Dans
le menu déroulant, choisissez greetings (ou l'intention la mieux adaptée à votre
expression incorrecte).
11 Puisque vous venez de modifier votre application, vous devez à nouveau former
l'application LUIS. La figure  17.8 montre comment fournir des entrées
supplémentaires pour les algorithmes de Machine Learning afin de
traiter le modèle de données et d'affiner la compréhension du langage et de
l'intention.
12 Dans la fenêtre consacrée aux messages de test, saisissez à nouveau le message
incorrect (morning, par exemple). Cette fois, l'intention notée comme étant la plus
plausible devrait être la bonne (greetings).
13 Pour rendre l'application LUIS mise à jour disponible pour votre bot d'application
Web, sélectionnez l'option Publier dans le menu du haut. Acceptez toutes les valeurs
par défaut, puis sélectionnez Publish to a production slot (Publier dans l'emplacement
de production). Le processus de publication prend quelques secondes.

Intentions

greetings

showMenu

orderFood

Formation Modèle de données Figure 17.8  Lorsque vous reclassez

de l'application LUIS l'intention des messages et formez à
nouveau l'application LUIS, le modèle
Entités
de données est affiné à mesure que des
« Une pizza au entrées de données supplémentaires
pepperoni » sont fournies aux algorithmes de
Machine Learning. Lorsque vous
« Une pizza végétarienne,
s'il vous plaît » Reclassification entrerez des salutations similaires
de l'intention du à l'avenir, le modèle de données sera
message (normalement) plus performant et
répondra de manière plus appropriée.
264 Chapitre 17  Machine Learning et intelligence artificielle

N'oubliez pas, votre bot est exécuté sur une application Web. Il comporte donc des
emplacements de production et de préproduction, comme vous l'avez appris dans le
chapitre 3. En situation réelle, vous devriez effectuer la publication dans un emplacement
de préproduction, vérifier que tout fonctionne comme prévu, puis publier le bot dans
l'emplacement de production. Les mêmes fonctions PaaS qui vous ont permis de tester
et de déplacer du code Web entre les cycles de développement et de production sont
également utiles pour votre bot d'application Web optimisé par LUIS.
Cet exemple simple montre que le système de Machine Learning a été en mesure de
comprendre que votre entrée de donnée (good) morning est une salutation et que les
formules de politesse similaires, telles que (good) evening, en sont également. Le Machine
Learning permet d'obtenir les meilleurs résultats lorsqu'un jeu de données volumineux
peut être entré dans le modèle de données. Il est donc important d'effectuer des tests
approfondis et de favoriser la formation de votre application. Les performances de l'IA
(l'application LUIS, dans notre cas) dépendent directement du volume et de la qualité
des données fournies aux algorithmes de Machine Learning.
17.3.3 Création et exécution d'un bot d'application Web avec LUIS
Vous disposez maintenant d'un bot d'application Web simple dans Azure et d'une
application LUIS chargée du traitement du langage et de la compréhension de l'intention
des clients. Pour intégrer ces deux éléments,vous devez modifier le code de votre bot pour
utiliser LUIS. Des kits de développement logiciel (SDK) sont disponibles pour les langages
de programmation C# and Node.js. Si vous êtes néophyte en la matière, je trouve qu'il est
plus rapide et plus simple de comprendre comment fonctionne le code avec Node.js. Si
vous connaissez bien le langage C#, libre à vous de découvrir le SDK C# lorsque vous aurez
fini de lire ce chapitre. Pour l'instant, nous allons utiliser une application Node.js basique
tirée du référentiel d'exemples GitHub pour voir votre bot à l'œuvre avec LUIS.

Tester
Pour mettre à jour votre bot d'application Web avec votre bot LUIS formé, procédez comme suit :

1 Sur le portail Azure, sélectionnez Groupes de ressources dans le menu à gauche,

puis choisissez votre groupe, par exemple azuremolchapter17. Sélectionnez
ensuite votre bot d'application Web, par exemple azuremol.
Nous allons utiliser un exemple de bot dans notre référentiel d’exemples
GitHub. L’exemple de bot est écrit dans Node.js, mais comme avec les exemples
d’applications précédents, ne vous inquiétez pas vous n'y connaissez rien.
2 Pour déployer l’exemple de bot, ouvrez Cloud Shell. Si nécessaire, clonez le
référentiel d’exemples GitHub dans votre Cloud Shell comme suit :
git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

3 Accédez au répertoire pour le chapitre 17 :

cd azure-mol-samples-2nd-ed/17/webappbot

4 Initialisez le référentiel Git et ajoutez les fichiers du bot :

git init && git add . && git commit -m "Pizza"

5 Pour télécharger l'exemple de bot, créez une connexion à votre application

Web. La commande suivante accède au référentiel de l'application Web et
configure vos exemples de référentiels Git locaux pour s'y connecter. Dans les
chapitres précédents, vous avez du rechercher cette adresse. Mais j'espère qu'à
présent, vous avez commencé à découvrir les fonctionnalités de la CLI d'Azure et
à réaliser que la plupart de ces informations peuvent être obtenues rapidement.
 Création d'un bot intelligent pour aider les clients à commander des pizzas 265

git remote add webappbot \

$(az webapp deployment source config-local-git \
--resource-group azuremolchapter17 \
--name azuremol \
--output tsv)

6 Poussez l'exemple de bot Node.js vers votre application Web à l'aide de la

commande suivante :
git push webappbot master

7 Lorsque vous y êtes invité, saisissez le mot de passe de l'utilisateur Git que vous
avez créé et utilisé dans les chapitres précédents (le compte créé au chapitre 3).

Si vous avez oublié de noter votre mot de passe Git sur un Post-It
Si vous avez oublié le mot de passe, vous pouvez le réinitialiser. Tout d'abord, obtenez le
nom d'utilisateur de votre compte de déploiement Git local :
az webapp deployment user show --query publishingUserName

Pour réinitialiser le mot de passe, saisissez le nom de votre compte à partir de la com-
mande précédente, puis répondez aux invites pour définir un nouveau mot de passe.
L'exemple suivant réinitialise le mot de passe du compte utilisateur nommé azuremol :
az webapp deployment user set --user-name azuremol

Examinons la figure 17.9 pour voir ce que vous avez déployé. L'application LUIS est
maintenant formée avec des algorithmes de Machine Learning, et votre modèle de
données est prêt à être utilisé par l'application Node.js pour permettre aux clients
d'interagir avec le bot et de commander des pizzas.

Abonnement Azure
Plan App Service
Compréhension Application Web
du langage et de
l'intention Microsoft Bot Un client affamé
Application Node.js
Connector veut commander
LUIS Web Le client interagit
Framework une pizza en ligne
avec le bot, puis la
conversation est
Stockage des données persistantes traitée par LUIS
du bot et de l'état de la session

Compte de stockage

Table

Figure 17.9  Un client peut maintenant accéder à votre bot en ligne et demander à voir le menu ou commander une
pizza. LUIS fournit les capacités de compréhension du langage, qui permettent au bot de traiter les commandes et
de les envoyer à Azure Storage à des fins de traitement supplémentaire.
266 Chapitre 17  Machine Learning et intelligence artificielle

Une fois de retour dans le portail Azure pour votre bot d'application Web, sélectionnez
Tester dans la discussion Web. La première connexion au bot prend quelques
secondes, mais vous devriez alors être en mesure d'interagir avec celui-ci, d'afficher la
liste des pizzas du menu et de créer une commande, comme illustré à la figure 17.10.
Essayez par vous-même !

Figure 17.10  Avec votre bot d'application Web en cours d'exécution, engagez une conversation et
essayez de commander une pizza. Dans cet exemple de dialogue, vous pouvez afficher le menu, commander
une pizza et vérifier l'état de la commande. L'application est rudimentaire et ne crée pas vraiment de
commandes ni ne met à jour leur état (autrement que pour indiquer quelle pizza a été commandée), mais
l'exercice devrait normalement pouvoir vous montrer comment déployer rapidement un bot dans Azure.
 Création d'un bot intelligent pour aider les clients à commander des pizzas 267

J'espère que ces exercices simples vous ont donné une idée de ce qu'Azure peut offrir
en matière d'IA et de Machine Learning. Les capacités du bot d'application Web avec
LUIS peuvent être étendues afin d'inclure d'autres services Azure Cognitive Services,
tels que la Vérification orthographique ou le Traducteur. Grâce à ces services, vous
pouvez interpréter des mots et des expressions employés par l'utilisateur s'il les
orthographie incorrectement. Ils peuvent également permettre à votre bot de
dialoguer dans plusieurs langues. Vous pouvez aussi utiliser Visage et Personalizer
pour identifier le client effectuant une commande grâce aux capacités de
reconnaissance faciale de son appareil photo, afin de suggérer automatiquement des
pizzas qu'il serait susceptible d'apprécier.
Le Machine Learning fait partie intégrante de l'application LUIS, mais Azure
propose bien d'autres ressources et outils en la matière. La possibilité de traiter des jeux
de données volumineux et de calculer des modèles de données de Machine Learning
sur des ressources de calcul Azure très performantes permet de lever les obstacles à la
création d'applications reposant sur des jeux de données conséquents. Les applications
sont plus précises et efficaces, et il n'est pas nécessaire d'acheter du matériel ni
d'installer des outils spéciaux, car les DSVM comprennent tous des composants requis.
L'IA et le Machine Learning ne constituent pas les outils parfaits pour toutes les
applications, mais ces services Azure peuvent souvent vous permettre de sortir du lot en
cette ère où les attentes des clients envers votre entreprise augmentent.

Traitement des charges de travail par lots

Les services Azure Batch et HPC constituent deux autres domaines couverts par Azure
qui peuvent s'avérer intéressants en matière de Big  Data et de calcul à des fins de
Machine Learning. Azure Batch vous permet d'effectuer des tâches de calcul
volumineuses et répétitives sans devoir gérer des clusters de planificateurs. Batch
exécute des tâches sur des machines virtuelles avec son outil de gestion et son
planificateur pour vous aider, tout comme les groupes de machines virtuelles (VMSS)
proposent des capacités de mise à l'échelle automatique et d'équilibrage de charge pour
les VM. Bien qu'il ne s'agisse pas d'un service directement lié au Machine Learning,
Batch est l'outil idéal si vous avez besoin d'autres tâches de traitement des
calculs volumineuses.
Azure propose également des composants de calcul haute performance (HPC, High-
Performance Computing) pour les machines virtuelles imposantes et les machines
virtuelles de traitement graphique (GPU). Il est également possible d'utiliser des outils et
des suites spécifiques tels que DataSynapse et Microsoft HPC Pack pour exécuter des
applications exigeant une puissance de calcul élevée.
Les éléments tels que le Machine Learning, Azure Batch et le service HPC sont de très
bons exemples d'utilisation des fournisseurs de cloud computing comme Azure pour
exécuter des tâches de calcul volumineuses. Puisque vous ne payez que les
ressources de calcul dont vous vous servez, il n'est pas nécessaire d'acheter et
d'entretenir du matériel coûteux qui reste rarement utilisé.
268 Chapitre 17  Machine Learning et intelligence artificielle

17.4 Exercice pratique : ajout de canaux de communication avec un bot

Dans les exemples précédents, vous communiquiez avec votre bot via une fenêtre de
test dans le portail Azure. Les canaux multiplient les possibilités qui s'offrent à vous en
matière d'interaction avec votre bot. Vous pouvez lui permettre de communiquer via
Skype ou Facebook Messenger, ou à l'aide d'applications telles que Microsoft Teams et
Slack. Azure Bot Service simplifie les étapes nécessaires à l'intégration d'un bot avec
ces services externes :

1 Dans le portail Azure, sélectionnez votre bot d'application Web, puis choisissez
Canaux.
2 Sélectionnez le canal de votre choix (Skype, par exemple).
Souvent, d'autres canaux comme Facebook ou Slack nécessitent de créer une
connexion développeur. Avec Skype, il vous suffit de copier et coller du code
HTML pour que l'opération fonctionne.
3 Fournissez toutes les informations requises, telles que l'ID de l'application de
bot. Vous pouvez trouver cet identifiant sous Paramètres pour Bot Management
(Gestion de bots).
4 Si nécessaire, utilisez l'éditeur de code en ligne pour créer une page HTML de
base, telle que default.htm, dans le répertoire wwwroot, puis collez tout code
intégré pour votre canal. Vous pouvez ouvrir votre application Web à partir du
portail Azure, puis sélectionner son URL pour ouvrir la page default.htm qui
inclut le code de votre canal, par exemple http://azuremol.azurewebsites.net/
default.htm.
 18 Azure Automation

Dans la mesure du possible, évitez de vous connecter manuellement à un serveur

pour y apporter des modifications. Il n'est pas nécessaire d'installer le logiciel en
cliquant sur des boutons dans une interface graphique, ni nécessaire d'apporter des
mises à jour aux fichiers de configuration dans un éditeur de texte. Ces actions
manuelles introduisent un risque d'erreurs qui peut entraîner une mauvaise
configuration et des échecs d'application. Si vous souhaitez répliquer la
configuration d'un serveur, pouvez-vous vous souvenir de toutes les étapes
nécessaires pour mettre le serveur actuel en état de marche ? Et si vous devez réitérer
l'opération d'ici six mois ?
Au chapitre  16, nous avons abordé un moyen de vérifier et d'appliquer
automatiquement les mises à jour aux serveurs. Cette magie est arrivée avec
l'utilisation d'Azure Automation. Dans ce chapitre-ci, nous examinerons comment
créer, exécuter et modifier des procédures opérationnelles, et utiliser la
configuration d'état souhaité de PowerShell pour installer automatiquement des
applications et configurer des serveurs.

18.1 Qu'est-ce que Azure Automation ?

Un compte Azure Automation rassemble de nombreux éléments, comme illustré
à la figure 18.1. Une des fonctionnalités de base consiste en la création et l'exécution
de scripts à la demande ou selon un calendrier défini. Vous pouvez créer des scripts
dans PowerShell ou Python, et laisser la plateforme Azure gérer la planification et
l'exécution de ces procédures opérationnelles. Vous pouvez partager les
informations d'identification et les objets de connexion, puis appliquer et signaler
automatiquement les configurations de serveurs souhaitées. La gestion des mises
à jour, examinée au chapitre 16, permet de maintenir vos serveurs sécurisés et à jour
au moyen des derniers correctifs et dernières mises à jour de l'hôte tout au long du
cycle de vie de votre environnement applicatif.

269
270 Chapitre 18  Azure Automation

Configuration de l’état souhaité

Procédures opérationnelles
• Définit les applications, les
• Automatisent les tâches avec configurations et les fichiers
PowerShell ou python
• Applique, signale et
• Outils de conception graphique remédie aux écarts
• Exécution planifiée • Prise en charge Windows + Linux

Azure Automation

Gestion des mises à jour Ressources partagées

• Mises à jour des hôtes Windows/Linux • Informations d'identification,
certificats et connexions
• Rapports de conformité
• Import de modules supplémentaires
• Mises à jour planifiées
• Réutilisation des calendriers

Figure 18.1  Azure Automation propose de nombreuses fonctionnalités connexes. Vous pouvez utiliser
un ensemble partagé de ressources, tels que des informations d'identification, des certificats, des
calendriers et des objets de connexion pour exécuter automatiquement des scripts PowerShell ou python
sur des serveurs cibles. Vous pouvez définir l'état souhaité d'un serveur, et Azure Automation installera
et configurera le serveur de manière appropriée. Les mises à jour de l'hôte et les correctifs de sécurité
peuvent être appliqués automatiquement. Toutes ces fonctionnalités valent à la fois pour les serveurs
Windows et Linux, dans Azure et sur site, ou auprès d'autres fournisseurs de cloud.

Pour simplifier la gestion au niveau de plusieurs procédures opérationnelles ou

configurations d'état souhaité dans un compte Automation, vous pouvez partager les
ressources suivantes :
¡ Les calendriers vous permettent de définir un ensemble de périodes et de récurrences
qui peuvent être appliquées à chaque procédure opérationnelle ou à chaque tâche
de gestion de la mise à jour. Si vous souhaitez modifier ultérieurement une
occurrence périodique, vous pouvez modifier l'un des calendriers partagés plutôt
que chaque procédure opérationnelle ou chaque tâche de mise à jour qui l'utilise.
¡ Les modules étendent la fonctionnalité principale en stockant des modules
PowerShell supplémentaires. Les modules Windows PowerShell et Azure de base
sont déjà disponibles, mais des modules supplémentaires, tels que Linux
Management, peuvent être ajoutés et utilisés dans les procédures opérationnelles.
¡ Les informations d'identification pour les différents comptes qui possèdent des
autorisations pour exécuter diverses procédures opérationnelles sont stockées en
tant qu'actifs, non définis dans chaque procédure. Cette approche vous permet de
mettre à jour et de réinitialiser les informations d'identification si besoin, et chaque
procédure opérationnelle qui les utilise est automatiquement mise à jour. Ainsi, les
informations d'identification ne sont pas stockées sous forme de texte brut dans les
procédures opérationnelles, ce qui accroît la sécurité de ces dernières.
¡ Les connexions définissent les propriétés d'authentification en fonction des principaux
de service Azure AD. Il s'agit d'un type spécial de compte utilisateur qui permet aux
procédures opérationnelles d'accéder à vos ressources Azure. Ces connexions utilisent
généralement des certificats numériques, et non des noms d'utilisateur et des mots de
passe, pour fournir une couche supplémentaire de sécurité.
¡ Les certificats sont souvent intégrés aux ressources de connexion pour fournir un
moyen sécurisé de vérifier l'identité d'un principal de service. Comme pour les
informations d'identification de base, vous pouvez régulièrement mettre à jour
 Qu'est-ce que Azure Automation ? 271

ces certificats dans un emplacement central, et chaque procédure opérationnelle

qui les utilise peut accéder automatiquement aux nouveaux certificats. Vous pou-
vez créer et stocker vos propres certificats à utiliser avec les procédures opéra-
tionnelles ou les définitions de configuration d'état souhaité.
¡ Les variables fournissent un emplacement central pour les valeurs d'exécution
telles que les noms, les chaînes d'emplacement et les entiers à stocker. Lorsque
vos procédures opérationnelles sont exécutées, ces variables sont injectées. Cette
approche limite la quantité de ressources programmées en dur à l'intérieur de
chaque procédure opérationnelle.

Travailler plus intelligemment, pas plus dur

Au chapitre 16, nous avons abordé la façon dont les services de gestion Azure
fonctionnent ensemble pour surveiller et rendre compte des serveurs dans Azure, sur
site, ou auprès d'autres fournisseurs de cloud. Vous installez et configurez les agents
requis sur des serveurs distants, puis vous leur fournissez un moyen de se connecter de
nouveau à l'infrastructure Azure.
Azure Automation peut également fonctionner sur toutes les plates-formes et
infrastructures. Par exemple, la procédure opérationnelle worker hybride peut exécuter
des procédures opérationnelles Automation sur des serveurs situés à l'extérieur
d'Azure. Vous continuez à utiliser les ressources partagées Automation qui définissent
les informations d'identification, les connexions et les certificats, mais cette fois ces
ressources peuvent être utilisées pour définir les composants d'authentification pour les
différentes plateformes. Vous pouvez également utiliser les configurations d'état
souhaité sur des machines virtuelles non-Azure, à la fois pour Windows et pour Linux.
Dans tous les cas, un composant passerelle est installé dans l'environnement distant
pour agir en tant que proxy pour les commandes Automation lorsqu'elles sont envoyées
aux cibles désignées. Cette approche de proxy passerelle fournit un point de connexion
unique pour Automation dans les environnements distants et minimise les problèmes de
sécurité, car il n'existe pas d'accès direct à des serveurs distants autrement.
Les procédures opérationnelles et les définitions de configuration d'état souhaité
peuvent devoir être modifiées légèrement pour s'exécuter sur des serveurs physiques
sur site par rapport aux machines virtuelles d'Azure. Comme avec Azure Backup, Site
Recovery ou Update Management, l'avantage d'Azure Automation est qu'il fournit un plan
de gestion unique et un ensemble d'outils pour assurer l'automatisation sur l'ensemble
de vos serveurs et infrastructures.

18.1.1 Création d'un compte Azure Automation

Franchissons le pas en créant un compte Azure Automation, puis jetons un coup d'œil aux
procédures opérationnelles par défaut qui sont fournies. Les procédures opérationnelles
de démonstration fournissent le cadre idéal pour élaborer vos propres procédures
opérationnelles. Il existe également un éditeur graphique que vous pouvez utiliser pour
glisser-déposer des blocs de construction afin de générer des scripts d'automatisation.

Tester
Pour créer un compte Azure Automation et des exemples de procédures opérationnelles,
procédez comme suit :

1 Dans le coin supérieur gauche du portail Azure, sélectionnez Créer une ressource.
2 Recherchez et sélectionnez Automation, puis sélectionnez Créer.
272 Chapitre 18  Azure Automation

L'option Automatisation et contrôle crée également un espace Operations

Management Suite (OMS), et configure Automation Hybrid Worker pour gérer les
ressources en dehors d'Azure. OMS est devenu obsolète. Il a été remplacé
par les principaux services Azure que nous avons étudiés dans les chapitres
précédents. Pour l'instant, choisissez de créer uniquement la ressource Automation.
3 Saisissez un nom, tel que azuremol, puis créez un groupe de ressources, tel
que azuremolchapter18.
4 Sélectionnez la région Azure la plus appropriée qui est la plus proche de vous et
acceptez l'option Créer un compte d'identification Azure.
L'option Créer un compte d'identification crée des comptes supplémentaires
dans Azure AD. Les certificats de sécurité sont également créés pour permettre
aux comptes de s'authentifier de manière automatisée, sans avoir besoin d'invites
d'utilisateur ou d'enregistrement de mot de passe. Vous pouvez créer et spécifier
des informations d'identification de compte standard supplémentaires, définies
comme une ressource Automation, pour fournir un contrôle plus granulaire des
comptes utilisés pour exécuter certaines procédures opérationnelles.
Combinés avec les RBAC, déjà examinés au chapitre 6, des comptes d'identification
spécifiques peuvent être créés pour les procédures opérationnelles, qui fournissent un
ensemble limité d'autorisations nécessaires pour accomplir les tâches que nécessite
chaque procédure opérationnelle, ou ensemble de procédures opérationnelles. Du
point de vue de la sécurité, cette approche vous permet de vérifier et de contrôler
comment et quand ces comptes sont utilisés. Évitez la tentation de ne créer qu'un seul
compte d'identification qui fournit des autorisations de type administrateur, car cette
approche fournit peu de protections contre les abus.

18.1.2 Actifs multimédias et procédures opérationnelles Azure Automation

Le compte Azure Automation que vous avez créé à la section 18.1.1 précédente inclut
quelques exemples de procédures opérationnelles. Des exemples à la fois en
PowerShell et en Python sont disponibles. Des ressources et des certificats de
connexion sont également ajoutés au compte Automation pour les comptes
d'identification qui ont été créés. Explorons ces ressources de connexion partagées.

Tester
Pour visualiser les ressources et les exemples de procédures opérationnelles configurés,
procédez comme suit :

1 Sur le portail Azure, sélectionnez les groupes de ressources à gauche, puis

choisissez votre groupe, tel que azuremolchapter18  ; et sélectionnez votre
compte Azure Automation, azuremol par exemple.
2 Sous Ressources partagées dans le menu à gauche, sélectionnez Connexions.
3 Sélectionnez AzureRunAsConnection, comme illustré à la figure 18.2.
4 Sélectionnez Certificats dans le menu principal du compte Automation sous
Ressources partagées, puis choisissez AzureRunAsCertificate. Comme illustré à
la figure 18.3, l'empreinte numérique correspond au modèle RunAsConnection
de l'étape précédente.
 Qu'est-ce que Azure Automation ? 273

Figure 18.2  Les informations sur le compte d'identification sont affichées,

dont les identifiants ApplicationId et TenantId. Il s'agit de propriétés
spécifiques pour Azure AD qui permettent d'identifier les informations
d'identification de ce compte. Une empreinte de certificat correspond
à un certificat numérique, que nous étudierons à l'étape suivante.

Figure 18.3  L'empreinte du
certificat RunAsCertificate
correspond à celle affichée
dans RunAsConnection.
Dans vos procédures
opérationnelles, vous
définissez la ressource
de connexion à utiliser.
Le certificat approprié
est utilisé pour ouvrir une
session sur le compte Azure.
274 Chapitre 18  Azure Automation

5 Maintenant que vous comprenez les ressources pour les connexions et les
certificats, examinons un des exemples de procédures opérationnelles.
Sélectionnez Procédures opérationnelles dans le menu à gauche dans le compte
Automation. Plusieurs exemples de procédures opérationnelles sont disponibles.
6 Choisissez la procédure opérationnelle PowerShell appelée
AzureAutomationTutorialScript.
7 En haut de l'exemple de procédure opérationnelle, se trouvent les options
permettant de Démarrer, Afficher et Modifier la procédure opérationnelle. Ces
options devraient être explicites !
Vous disposez également d'une option pour la planification, qui vous permet de
créer ou de sélectionner une ressource partagée qui définit un calendrier pour
exécuter la procédure opérationnelle à un moment donné, et d'une option pour
Webhook, qui vous permet de créer une URL webhook pour exécuter la procédure
opérationnelle à partir d'un autre script ou action. Choisissez Afficher.

Azure Automation et contrôle de code source avec GitHub

Des procédures opérationnelles peuvent être intégrées à un système de contrôle de
code source, tel que GitHub. Un des grands avantages d'un système de contrôle de code
source pour vos procédures opérationnelles est que celui-ci permet de documenter la
gestion des modifications et de revenir à des versions antérieures des procédures opéra-
tionnelles en cas de problème.
Chaque fois que vous enregistrez une procédure opérationnelle Azure Automation, une
nouvelle version est validée à l'égard du contrôle de code source. Vous n'êtes pas obligé
de quitter l'éditeur de procédure opérationnelle pour que cela se produise, car la
plateforme Azure et le système de contrôle de code source configuré sont paramétrés
pour fonctionner en va-et-vient. Si vous rencontrez un problème avec la nouvelle
procédure opérationnelle, vous pouvez extraire une version précédente du
contrôle de code source qui permet aux tâches de continuer à s'exécuter sans délai, puis
corriger la cause à l'origine du problème affectant la version mise à jour.
L'utilisation du contrôle de code source fournit également un enregistrement des modifi-
cations survenues et du moment. S'il vous faut auditer vos procédures opérationnelles
ou comprendre comment celles-ci ont évolué au fil du temps, les systèmes de contrôle
de source fournissent un excellent moyen de voir les différences avec chaque révision.

18.2 Azure Automation, exemple de procédure opérationnelle

Examinons comment l'exemple de procédure opérationnelle PowerShell,
AzureAutomationTutorialScript, se connecte à Azure et collecte des informations sur
vos ressources. Vous pouvez suivre avec l'exemple de procédure opérationnelle Python
si vous le préférez  ; la disposition est similaire. PowerShell et Python sont les seuls
langages actuellement pris en charge dans les procédures opérationnelles Azure
Automation. La liste suivante définit les informations d'identification de connexion
dans la procédure opérationnelle.

Liste 18.1  Configuration des informations d'identification de connexion

$connectionName = "AzureRunAsConnection" Crée un objet pour $connectionName

try
{ Établit la requête de connexion
  # Get the connection "AzureRunAsConnection "
  $servicePrincipalConnection=Get-AutomationConnection -Name
➥$connectionName Crée un objet de principal
de service
 Azure Automation, exemple de procédure opérationnelle 275

   "Logging in to Azure..."
  Add-AzureRmAccount `
    -ServicePrincipal `
    -TenantId $servicePrincipalConnection.TenantId ` Se connecte
    -ApplicationId $servicePrincipalConnection.ApplicationId ` à Azure
    -CertificateThumbprint
➥$servicePrincipalConnection.CertificateThumbprint
}

Le code commence par créer un objet pour $connectionName. Dans l'exercice « Testez
dès maintenant  », vous avez vu qu'une ressource de connexion par défaut pour
AzureRunAsConnection a été créée. Lorsque vous créez vos propres procédures
opérationnelles, vous pouvez créer des comptes d'identification supplémentaires et
des ressources de connexion pour séparer les procédures opérationnelles et les
informations d'identification qu'elles utilisent. Les parties de connexion et la gestion
des exceptions, que nous examinerons ensuite, doivent être communes à toutes les
procédures opérationnelles. Au besoin, vous pouvez modifier la ressource l'actif
connexion d'identification à utiliser.
Ensuite, une instruction try est utilisée pour établir la requête de connexion. Un
objet principal de service nommé $servicePrincipalConnection est créé, basé sur
$connectionName. La procédure opérationnelle se connecte ensuite à Azure avec Add-
AzureRmAccount et utilise l'objet $servicePrincipalConnection pour obtenir les
éléments TenantId, ApplicationId, et Certificate-Thumbprint. Nous avons
précédemment discuté de ces paramètres dans le cadre de la ressource de connexion.
La ressource de certificat qui correspond à l'empreinte de
$servicePrincipalConnection est alors utilisée pour finaliser la connexion à Azure.
La liste suivante montre que si la connexion échoue, la procédure opérationnelle
intercepte l'erreur et arrête l'exécution.

Liste 18.2  Interception d'une erreur et arrêt de l'exécution de la procédure opérationnelle

catch {
   if (!$servicePrincipalConnection)
   {
      $ErrorMessage = "Connection $connectionName not found."
      throw $ErrorMessage
   } else{
      Write-Error -Message $_.Exception
      throw $_.Exception
   }
}

L'instruction catch gère les erreurs dans le cadre de la tentative de connexion. Si une
connexion à un principal de service est introuvable, une erreur est générée.
Généralement, cette erreur indique que la ressource de connexion que vous avez
spécifiée est introuvable. Vérifiez deux fois le nom et l'orthographe de votre connexion.
Sinon, cela signifie que l'objet de connexion a été trouvé, et que le principal de
service a été utilisé pour se connecter, mais que ce processus d'authentification a
échoué. Cet échec peut provenir de la fin de validité du certificat ou de la fin d'activation
du compte d'identification. Cette fonctionnalité montre comment vous pouvez
révoquer un compte dans Azure AD et vous assurer que toutes les procédures
opérationnelles qui utilisent les informations d'identification ne peuvent plus
s'exécuter correctement.
276 Chapitre 18  Azure Automation

À présent, la procédure opérationnelle obtient une liste de toutes les

ressources Azure.

Liste 18.3  Obtention d'une liste de ressources Azure

$ResourceGroups = Get-AzureRmResourceGroup
foreach ($ResourceGroup in $ResourceGroups)
{
   Write-Output ("Showing resources in resource group "
➥+ $ResourceGroup.ResourceGroupName)
   $Resources = Find-AzureRmResource -ResourceGroupNameContains
➥$ResourceGroup.ResourceGroupName |
➥Select ResourceName, ResourceType
   ForEach ($Resource in $Resources)
   {
      Write-Output ($Resource.ResourceName + " of type "
➥+ $Resource.ResourceType)
   }
   Write-Output ("")
}

La dernière partie de la procédure opérationnelle représente la destination de votre

code de procédure opérationnelle. Un objet est créé pour $ResourceGroups qui
génère une liste de tous les groupes de ressources Azure disponibles.
Une boucle foreach passe ensuite par les groupes de ressources, trouve une liste de
ressources et écrit une liste des noms et des types de ressources.
Cet exemple de base montre comment vous pouvez interagir avec Azure, une fois que
la procédure opérationnelle a été authentifiée par rapport à l'abonnement. Si vous
implémentez le RBAC sur le compte d'identification, seuls les groupes de ressources que
le compte est autorisé à consulter sont renvoyés. Cette approche de RBAC souligne en
quoi c'est un bon principe de sécurité de créer et d'utiliser des comptes d'identification
pour limiter l'accès des procédures opérationnelles aux ressources de votre
environnement Azure. Essayez toujours de fournir le moins de privilèges nécessaires.
Si ces éléments en PowerShell ou Python sont nouveaux pour vous, ne vous inquié-
tez pas. Les deux sont de bons langages de script de base, mais peuvent également être
utilisés pour développer des applications complexes et puissantes.
En votre qualité de développeur, vous devriez assez facilement maîtriser et utiliser l'un
ou l'autre de ces langages. Si vous êtes un pro de l'informatique, l'automatisation des
tâches vous permet de dégager du temps pour effectuer toutes les autres tâches accu-
mulées, et PowerShell ou Python sont tous deux un bon point de départ. Manning Pub-
lications publie également d'autres bons ouvrages susceptibles de vous aider !

18.2.1 Exécution et affichage du résultat à partir d'un exemple de procédure opérationnelle

Maintenant que vous avez vu ce que contient l'exemple de script de procédure
opérationnelle, et que vous avez noté comment sont utilisées les ressources de
connexion et de certificat, nous allons exécuter la procédure opérationnelle et en
observer le résultat.

Tester
Pour observer la procédure opérationnelle en action, procédez comme suit :

1 Fermez la fenêtre qui affiche le contenu de la procédure opérationnelle, puis

revenez à la vue d'ensemble de AzureAutomationScriptTutorial.
 Azure Automation, exemple de procédure opérationnelle 277

2 Sélectionnez Démarrer en haut de la fenêtre de procédure opérationnelle.

3 Confirmez que vous souhaitez démarrer la procédure opérationnelle, puis attendez
quelques secondes que la procédure opérationnelle commence à s'exécuter.
4 Sélectionnez Résultat, comme illustré à la figure 18.4, puis observez la fenêtre de
la console lorsque la procédure opérationnelle se connecte à Azure, obtient une
liste des groupes de ressources, les parcourt en boucle et génère la liste des
ressources de chacun d'eux.

Figure  18.4  Vous pouvez consulter le résultat de la procédure opérationnelle, ainsi que les
rapports ou erreurs et avertissements générés. Cet exemple de base s'exécute en quelques
secondes, mais des procédures opérationnelles plus complexes peuvent prendre plus de temps.
Vous pouvez surveiller l'état de ces procédures opérationnelles plus longues, et arrêter ou
suspendre leur exécution si nécessaire.

Les procédures opérationnelles d'Automation n'ont pas besoin d'exister de manière

isolée. Une procédure opérationnelle peut exécuter une autre procédure
opérationnelle. Cette capacité vous permet de créer des automatisations complexes et
multi-étapes et de minimiser la duplication de code. Lorsque vous concevez et
développez des procédures opérationnelles, essayez de les décomposer en petits blocs
discrets de code. Les fonctions courantes que vous pouvez réutiliser, telles que la
connexion à Azure et la génération d'une liste de ressources ou d'une liste de machines
virtuelles, doivent être créées sous forme de petites procédures opérationnelles qui
peuvent être intégrées à des procédures opérationnelles plus volumineuses. Lorsque
de nouveaux cmdlets de commande PowerShell sont publiés ou que des paramètres
sont modifiés, vous pouvez rapidement mettre à jour une procédure opérationnelle
partagée unique qui inclut ces cmdlets plutôt que de devoir mettre à jour plusieurs
procédures opérationnelles différentes. Dans un premier temps, il se peut que vous
278 Chapitre 18  Azure Automation

estimiez qu'il est inutile de consacrer du temps à la mise en œuvre de petites procédures
opérationnelles réutilisables. Vous changerez toutefois d'avis à mesure que votre
environnement et votre utilisation de l’automatisation se développent. Une grande
partie des opérations effectuées dans cet ouvrage a concerné de plus petits
déploiements, maais vous devez néanmoins réfléchir à la façon de déployer et de gérer
des applications à grande échelle.

18.3 PowerShell et configuration d'état souhaité (DSC)

Le chapitre 12 a introduit le concept d'extensions de machine virtuelle. Une extension est un
petit composant logiciel installé dans une machine virtuelle pour effectuer une tâche
donnée. L'extension de diagnostic VM a été installée sur une machine virtuelle pour
permettre de consigner les métriques de performances et les rapports de diagnostic sur la
plateforme Azure à partir de l'intérieur de la machine virtuelle. C'est génial, mais nous
avons aussi un peu parlé de la façon dont vous pouvez installer automatiquement le logiciel.
Une façon d'installer un logiciel et de configurer un serveur consiste à utiliser la
configuration d'état souhaité (DSC) de PowerShell. Avec DSC, vous définissez la façon
dont vous souhaitez qu'un serveur soit configuré : l'état souhaité. Vous pouvez définir des
packages à installer, des fonctionnalités à configurer ou des fichiers à créer, par exemple.
Ce qui est intéressant concernant la DSC, c'est qu'elle va au-delà de la première installation
et configure l'action. Au fil du temps, les serveurs subissent souvent des événements de
maintenance ou de dépannage dans lesquels les configurations et les packages sont
modifiés manuellement. Le serveur s'éloigne alors de l'état souhaité que vous avez défini
initialement. La figure 18.5 montre comment Azure Automation peut agir en tant que
serveur central qui stocke les définitions DSC, permettant aux serveurs cibles de recevoir
leurs configurations et de rendre compte de leur conformité.
Le gestionnaire de configurations local (LCM) de chaque serveur cible contrôle le
processus de connexion au serveur pull Azure Automation, reçoit et analyse la
définition DSC, et applique et signale la conformité. Le moteur LCM peut fonctionner
sans serveur pull ; vous appelez alors localement le processus pour lire et appliquer une

Serveurs pull DSC

Azure Automation
1. Configuration
souhaitée enregistrée 3. Les serveurs vont chercher et
dans Azure Automation 2. Serveurs configurés appliquent la configuration souhaitée
pour utiliser le serveur
pull DSC Automation
configuration WebServer {
Nœud localhost {
WindowsFeature WebServer { Ord. virt Azure Serveur
Assurer = "présent" Machine
Name = "serveur Web
physique sur
site virtuelle d'un
}
} autre fournisseur
} de Cloud

Figure  18.5  La configuration d'état souhaité pour un serveur est créée et stockée dans Azure
Automation. Le compte Automation agit comme un serveur de type pull, ce qui permet aux serveurs
connectés de venir chercher la configuration requise à partir d'un emplacement central. Différents modes
de configuration peuvent être définis pour le comportement de remédiation du serveur lorsque leur
configuration s'écarte de l'état souhaité.
 PowerShell et configuration d'état souhaité (DSC) 279

définition DSC. Dans ce mode, où vous effectuez manuellement un push de la

configuration vers le moteur LCM, vous passez à côté d'un grand nombre de contrôles
centraux et de rapports qui sont souvent nécessaires lorsque vous gérez de nombreux
serveurs.
Il existe également une certaine souplesse dans la façon dont les serveurs cibles
traitent les définitions DSC reçues du serveur pull Azure Automation. Vous pouvez
configurer DSC pour qu'il fonctionne dans l'un des trois modes de configuration :
¡ Appliquer uniquement : l'état souhaité est poussé et appliqué sur le serveur cible, et
c'est tout. Cela ressemble au comportement de l'extension de script personnalisé
Azure, en cela que toutes les configurations ou installations sont appliquées lors
du premier déploiement, mais qu'il n'y a pas de processus en place pour arrêter
les configurations modifiées manuellement au cours du cycle de vie du serveur.
¡ Appliquer et superviser  : une fois l'état souhaité appliqué au serveur, DSC
continue de surveiller toutes les modifications qui font que le serveur s'écarte de
cette configuration initiale. Un rapport central peut être utilisé pour afficher les
serveurs qui ne sont plus conformes à leur état souhaité. Cette configuration
représente un bon compromis entre la nécessité de maintenir un serveur
conforme à l'état souhaité et de fournir un élément d'interaction humaine pour
décider des options de remédiation.
¡ Application et correction automatique : la configuration la plus automatisée et la plus
autonome applique l'état souhaité, puis surveille les éventuels écarts et corrige
automatiquement le serveur si des modifications se produisent, afin de s'assurer
qu'il reste conforme. Il y a un risque que des modifications manuelles légitimes
soient écrasées et restaurées à l'état souhaité configuré, mais ce mode de
configuration veille à ce que les paramètres attribués prennent toujours la priorité.
PowerShell DSC peut être utilisé sur les machines virtuelles qui s'exécutent chez
d'autres fournisseurs de cloud, ainsi que sur des machines virtuelles et des serveurs
physiques sur site. Grâce à .NET Core, PowerShell DSC peut également être utilisé sur
les serveurs Linux ; ce n'est donc pas une solution pour Windows uniquement. Cette
prise en charge multifournisseurs et multi- OS fait de PowerShell un choix puissant
pour configurer et gérer des serveurs à l'échelle.
Vous pouvez créer et gérer votre propre serveur pull DSC, mais les fonctionnalités
intégrées d'Azure Automation offrent des avantages supplémentaires :
¡ Les informations d'identification sont gérées de manière centralisée et les
certificats sont générés automatiquement.
¡ La communication entre le serveur pull DSC et les serveurs cibles est chiffrée.
¡ Des rapports intégrés sont fournis aux fins de la conformité DSC, et une intégration
existe avec Log Analytics en vue de générer des rapports et alertes plus détaillés.
Cette section est un cours intensif sur PowerShell DSC : c'est en soi un composant puissant
et il est largement disponible depuis quelques années maintenant. Combiné avec Azure
Automation, DSC est un excellent choix pour automatiser l'installation et la configuration
des logiciels. Repensez aux chapitres précédents sur les groupes VMSS, par exemple.
Vous pouvez appliquer une configuration DSC au groupe VMSS avec Azure Automation,
puis, à mesure que chaque machine virtuelle est créée dans le groupe VMSS, elle sera
automatiquement configurée avec les composants et les fichiers d'application requis.
280 Chapitre 18  Azure Automation

18.3.1 Définition et utilisation de PowerShell DSC et d'un serveur pull

Azure Automation
J'espère que cette visite éclair de PowerShell DSC vous a donné une idée de ce qui est
possible  ! Utilisons PowerShell DSC pour automatiser l'exemple d'installation d'un
serveur Web de base sur une machine virtuelle.

Tester
Pour afficher PowerShell DSC en cours d’exécution, procédez comme suit :

1 Créez une machine virtuelle Datacenter Windows Server 2019, et ouvrez le port

TCP  80 pour le trafic HTTP. Je ne vous tiens plus la main à présent  : nous en
sommes au chapitre 18, que diable ! Vous pouvez créer la machine virtuelle dans
Cloud Shell ou Azure Portal, au choix. Utilisez le groupe de ressources que vous
avez créé dans les exercices précédents ,tels que azuremolchapter18. Vous pouvez
continuer avec les prochaines étapes alors que la machine virtuelle se déploie.
2 Sur votre ordinateur local, créez un fichier nommé webserver.ps1, entrez le code
suivant et enregistrez et fermez le fichier lorsque vous avez terminé :
configuration WebServer {
   Node localhost {
    WindowsFeature WebServer {
      Ensure = "Present"
      Name = "Web-Server"
    }
  }
}

3 Sur le portail Azure, sélectionnez votre groupe de ressources, puis choisissez

votre compte Automation.
4 À gauche, choisissez Configuration d’état (DSC)  ; Sélectionnez l’onglet
Configurations ; et en haut de la fenêtre, choisissez Ajouter une configuration.
5 Accédez à votre fichier webserver.ps1 et sélectionnez-le. Le nom de configuration
doit correspondre au fichier, laissez le nom par défaut de WebServer, puis
cliquez sur OK.
Cela prend quelques instants pour télécharger et créer la configuration.
6 Quand elle est prête, sélectionnez la configuration dans la liste, puis choisissez
Compiler.

Dans les coulisses du DSC

Marquons une pause pour parler de ce qui se passe lorsque vous compilez la configuration,
comme illustré à la figure suivante. Pour distribuer les définitions DSC, vos
fichiers PowerShell sont convertis en un fichier MOF (Managed Object Format). Ce type de
fichier est utilisé pour bien plus que PowerShell DSC et permet des modifications de
configuration sur les composants Windows d'une manière centrale et maîtrisée. Toute
définition DSC, pas simplement dans Automation Azure, doit être compilée avant d'être
appliquée à un serveur cible. Le moteur LCM accepte et traite uniquement les fichiers MOF.
 PowerShell et configuration d'état souhaité (DSC) 281

Le serveur pull Azure Automation DSC compile automatiquement la définition DSC que vous
fournissez dans un fichier MOF (Managed Object Format). Les certificats numériques gérés par
Automation sont utilisés pour chiffrer le fichier MOF. Les serveurs cibles DSC reçoivent les
certificats numériques publics requis et permettent au moteur LCM de déchiffrer et de traiter le
fichier MOF. L'état souhaité peut alors être appliqué au serveur.

Étant donné que le fichier MOF définit l'état complet de vos serveurs, vous devez protéger
son contenu. Si un utilisateur malveillant connaissait tous les composants d'application
installés et l'emplacement des divers fichiers de configuration et de code personnalisé,
cela augmenterait les risques de compromettre vos serveurs. Les versions récentes de
PowerShell chiffrent l'intégralité du fichier MOF. Azure Automation génère
automatiquement les certificats et les clés numériques requis lorsqu'un serveur cible est
configuré pour DSC, ce qui vous permet d'utiliser de façon transparente des
fichiers MOF chiffrés. Automation chiffre également le trafic entre le serveur pull
DSC et les nœuds cibles, et pas seulement le fichier MOF.
Le processus de compilation dans Azure Automation convertit à la fois la définition DSC
que vous fournissez dans un fichier MOF et chiffre le fichier MOF avec les certificats et
les clés numériques. Le processus de compilation de votre définition DSC prend
quelques secondes, mais sécurise considérablement votre environnement. Voilà encore
un autre exemple où Azure sécurise vos ressources par défaut !

7 Pour appliquer la configuration à votre machine virtuelle, sélectionnez l’onglet

Nœuds dans la fenêtre de configuration d’état (DSC). Sélectionnez Ajouter et
choisissez la machine virtuelle que vous avez créée dans les étapes précédentes.
8 Choisissez Se connecter.
9 Dans le menu déroulant Nom de configuration du nœud, sélectionnez webserver.
loca lhost.
10 Définissez le mode de configuration par défaut sur ApplyAndMonitor, puis
sélectionnez OK.
Quelques minutes sont nécessaires pour que la machine virtuelle utilise le
serveur pull DSC d'Azure PowerShell et applique l'état initial souhaité.
11 Lorsque le portail Azure indique que la configuration est appliquée, sélectionnez
votre groupe de ressources. Sélectionnez ensuite la machine virtuelle que vous
avez créée dans les étapes précédentes.
282 Chapitre 18  Azure Automation

12 Avez-vous ouvert le port TCP  80 pour la machine virtuelle lorsque vous l'avez
créée ? Si ce n’est pas le cas, créez une règle de groupe de sécurité réseau pour
autoriser le trafic, puis ouvrez l’adresse IP publique de la machine virtuelle dans
un navigateur Web. Le processus DSC installe le serveur Web IIS et la page Web
par défaut se charge, comme illustré à la figure 18.6.

Figure 18.6  Une fois que l'ordinateur virtuel a été connecté à Azure Automation DSC, l'état souhaité
est appliqué et le serveur Web IIS est installé.

Cet exemple de base de PowerShell DSC installe uniquement la fonctionnalité serveur

Web. Vous pouvez utiliser PowerShell DSC pour configurer le serveur Web IIS ou copier
votre code d'application sur la machine virtuelle et exécuter le site. Des définitions de
DSC complexes peuvent être employées pour faire en sorte que la machine virtuelle soit
prête à servir le trafic aux clients de votre pizzeria sans interaction manuelle. Encore une
fois, repensez à la façon dont vous devez concevoir vos applications de sorte que leur
évolutivité se fasse automatiquement  : la machine virtuelle ne peut pas attendre que
quelqu'un se connecte et installe et configure tout manuellement !

18.4 Exercice pratique : utilisation de DSC avec Linux

Juste pour démontrer que PowerShell DSC fonctionne sur les serveurs Linux, nous allons
créer une machine virtuelle Ubuntu, installer les éléments prérequis nécessaires, puis
installer un serveur Web de base NGINX avec DSC. En production, vous pourriez utiliser
une image de machine virtuelle personnalisée pour laquelle les composants de gestion
sont déjà installés, puis appliquer des définitions DSC PowerShell comme d'habitude :
 Exercice pratique : utilisation de DSC avec Linux 283

1 PowerShell DSC pour Linux présente quelques limitations dans les distributions
Linux qu’il prend en charge sans configuration supplémentaire. Afin de
maintenir cet exercice pratique de fin de chapitre aussi simple que possible,
créez une machine virtuelle CentOS 7.7 ou ultérieure, et ouvrez le port 80.
2 Dans votre compte Azure Automation, sélectionnez Modules dans le menu
de gauche.
3 Sélectionnez Parcourir la galerie, puis recherchez, sélectionnez et importez le
module nx pour gérer les ressources Linux DSC.
4 Sur votre ordinateur local, créez un fichier nommé httpd.ps1, et tapez le
code suivant :
configuration httpd {
   Import-DSCResource -Module nx
   Node localhost {
    nxPackage httpd {
      Name = "httpd"
      Ensure = "Present"
      PackageManager = "yum"
    }
    nxService httpd {
      Name = "httpd"
      State = "running"
      Enabled = $true
      Controller = "systemd"
    }
  }
}

5 Ajoutez une configuration DSC au compte Azure Automation, téléchargez le

fichier httpd.ps1 et compilez la configuration.
6 Ajoutez un nœud DSC à votre compte Azure Automation, sélectionnez votre
machine virtuelle CentOS, puis choisissez votre nom de configuration de nœud
httpd.localhost.
Encore une fois, quelques minutes sont nécessaires pour que la machine
virtuelle applique la configuration souhaitée. Vous pouvez afficher la liste des
machines virtuelles connectées et leur état de conformité dans la fenêtre des
nœuds DSC. Les rapports concernant les machines virtuelles attestent de leur
conformité lorsque le LCM a accepté et appliqué le fichier MOF, mais les
commandes visant à installer et à configurer les packages httpd requis à l’intérieur
de la machine virtuelle requièrent quelques minutes.
7 Sélectionnez votre machine virtuelle CentOS dans le portail Azure, obtenez son
adresse IP publique et saisissez l’adresse IP de votre machine virtuelle dans un
navigateur Web pour vérifier si le serveur Web a été installé par DSC. Si le site
Web ne se charge pas, attendez une minute ou deux pour que le processus
d'installation se termine, puis actualisez la page.
Si vous voulez vraiment faire l'expérience du meilleur des mondes de Microsoft et Linux,
vous pouvez installer PowerShell sur votre machine virtuelle Linux. Suivez les étapes de
configuration rapide décrites à l'adresse http://mng.bz/VgyP pour comprendre toute la
puissance dont sont désormais capables les scripts PowerShell multi-plateformes !
 19 Conteneurs Azure

En quelques années, les conteneurs, Docker et Kubernetes, se sont massivement

imposés. Tout comme la virtualisation des serveurs s'est mise à changer la façon
dont les équipes informatiques exécutaient leurs datacenters au milieu des
années 2000, les outils de conteneur et les orchestrateurs modernes sont en train de
bouleverser la manière dont nous créons et exécutons nos applications. Rien ne lie
de manière inhérente la croissance des conteneurs au cloud computing, mais la
combinaison des deux technologies offre un excellent moyen de développer des
applications avec une approche cloud native. Des livres entiers ont été écrits sur
Docker et Kubernetes ; nous nous contenterons donc ici d'une introduction éclair
sur le sujet pour savoir comment exécuter rapidement des conteneurs dans Azure.
Azure dédie aux conteneurs une puissante suite de services, davantage alignée sur
l'approche PaaS. Celle-ci vous permet de vous concentrer sur la façon de créer et
d'exécuter vos applications, plutôt que sur la gestion de l'infrastructure des
conteneurs, l'orchestration et les composants du cluster.
Dans ce chapitre, nous allons voir ce que sont les conteneurs, ce que Docker leur
apporte et ce que Kubernetes peut faire pour vous. Pour apprendre à exécuter
rapidement une ou plusieurs instances de conteneur dans un cluster, nous explorerons
par ailleurs ACI (Azure Container Instances) et AKS (Azure Kubernetes Service).

19.1 Que sont les conteneurs ?

Les conteneurs ont déclenché à leur endroit un grand mouvement d'intérêt et
d'adoption au cours des dernières années, et je serais étonné que vous n'ayez pas au
moins entendu parler d'une entreprise ayant pris le virage de Docker. Mais qu'est-ce
qu'un conteneur au juste et qu'est-ce que Docker a à voir avec tout cela ?
Tout d'abord, observons un hôte de virtualisation traditionnel qui exécute des
machines virtuelles. La figure  19.1 est semblable au diagramme que nous avons
examiné au chapitre 1, où chaque VM possède son propre matériel virtuel et son
propre système d'exploitation invité.

284
 Que sont les conteneurs ? 285

Hôte de virtualisation
Figure 19.1  Avec une infrastructure de machines
Hyperviseur
virtuelles traditionnelle, l'hyperviseur de chaque hôte de
virtualisation fournit une couche d'isolation en délivrant
VM 1 VM 2 à chaque machine virtuelle son propre ensemble de
ressources matérielles virtuelles, telles qu'une UC
vCPU vRAM vNIC vCPU vRAM vNIC
virtuelle, une RAM virtuelle et des cartes réseau
OS invité Linux OS invité Windows virtuelles. La machine virtuelle installe un système
d'exploitation invité, tel qu'Ubuntu Linux ou
Bibliothèques principales + binaires Bibliothèques principales + binaires Windows Server, qui peut utiliser ce matériel virtuel.
Enfin, vous installez votre application et toutes les
Votre code d'application Votre code d'application bibliothèques requises. Ce niveau d'isolation crée des
machines virtuelles très sécurisées, mais ajoute aussi
une couche de contrainte en termes de ressources de
calcul, de stockage et de temps de démarrage.

Un conteneur supprime le
matériel virtuel et le système Hôte de conteneurs
d'exploitation invité. Tout ce Runtime de conteneurs (tel que docker)
qu'il contient, ce sont les Conteneur 1 Conteneur 2
applications et les bibliothèques
Bibliothèques principales + binaires Bibliothèques principales + binaires
de base requises pour exécuter
votre application, comme Votre code d'application Votre code d'application

illustré à la figure 19.2.
De nombreuses machines
Figure 19.2  Un conteneur contient uniquement les
virtuelles peuvent s'exécuter sur bibliothèques de base, les binaires et le code d'application
un même hyperviseur, chaque nécessaires pour exécuter une application. Le conteneur est
VM avec son propre système léger et portable, car il supprime le système d'exploitation
d'exploitation invité virtuel, son invité et la couche de matériel virtuel, ce qui réduit également
matériel virtuel et sa pile la taille sur disque du conteneur et les temps de démarrage.
d'applications. L'hyperviseur
gère les demandes du matériel
virtuel de chaque VM, planifie
l’allocation et le partage des
ressources matérielles physiques
et applique la sécurité et
l’isolation requises au niveau de Hôte de virtualisation
chaque machine virtuelle. Le Processeur RAM physique NIC physique
physique
travail de l'hyperviseur est
illustré à la figure 19.3.
Hyperviseur

Figure 19.3  Dans un
hôte de VM traditionnel, l'hyperviseur
assure la planification des demandes du
matériel virtuel de chaque VM sur vCPU vRAM vNIC vCPU vRAM vNIC
le matériel physique et l'infrastructure
sous-jacents. L'hyperviseur n'a VM 1 VM 2
généralement pas connaissance des
instructions spécifiques que le système OS invité Linux OS invité Windows
d'exploitation invité planifie concernant le
temps processeur physique, simplement
que du temps processeur est nécessaire.
286 Chapitre 19  Conteneurs Azure

Plusieurs conteneurs peuvent également s'exécuter sur un même hôte. L'hôte de con-
teneurs reçoit les divers appels système de chaque conteneur et planifie l'allocation et
la distribution de ces demandes sur un noyau de base, un système d'exploitation et des
ressources matérielles partagés. Les conteneurs fournissent une isolation logique des
processus d'application. Le travail du runtime de conteneurs est illustré à la
figure 19.4.

Hôte de conteneurs
Système Noyau invité
d’exploitation invité

Figure 19.4  Les conteneurs

présente un système d'exploitation
Runtime de conteneurs (tel que docker)
invité et un noyau communs. Le
Demandes OS et noyau runtime de conteneurs traite les
invités partagés demandes issues des conteneurs
en direction du noyau partagé.
Conteneur 1 Conteneur 2 Chaque conteneur s'exécute dans
un espace utilisateur isolé et
Bibliothèques principales + binaires Bibliothèques principales + binaires
certaines fonctionnalités de
Votre code d'application Votre code d'application sécurité supplémentaires
protègent les conteneurs les uns
des autres.

Les conteneurs sont généralement beaucoup plus légers que les machines virtuelles.
Les conteneurs démarrent plus rapidement que les machines virtuelles, souvent en
quelques secondes contre plusieurs minutes pour les VM. La taille d'une image de
conteneur ne représente généralement que quelques dizaines ou centaines de Mo,
contre plusieurs dizaines de Go pour une VM. Il y a toujours des limites et des contrôles
de sécurité en place, mais il est important de garder en tête que chaque conteneur
partage techniquement le même noyau que les autres conteneurs sur le même hôte.

Tester
Il vous faudra quelques minutes pour créer un cluster AKS pour les exercices à venir , par
conséquent, créez-le dès à présent à la l'aide de la procédure ci-après avant de pour-
suivre la lecture de ce chapitre :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell dans le menu du haut.
2 Créez un groupe de ressources. Spécifiez un nom, par exemple
azuremolchapter19, et un emplacement, par exemple eastus. La disponibilité
régionale d'AKS peut varier ; choisissez par conséquent une région majeure, telle
qu'eastus ou westeurope. (Pour obtenir la liste actualisée des disponibilités
régionales, accédez à la page https://azure.microsoft.com/regions/services.)
az group create --name azuremolchapter19 --location eastus
 L'approche microservices des applications 287

3 Pour créer un cluster Kubernetes, définissez --node-count sur 2 et utilisez les VMSS
et les zones de disponibilité (que nous avons évoqués dans les chapitres précédents) :
az aks create \
--resource-group azuremolchapter19 \
--name azuremol \
--node-count 2 \
--vm-set-type VirtualMachineScaleSets \
--zones 1 2 3 \
--no-wait

Le paramètre final --no-wait restitue le contrôle au Cloud Shell tandis que le reste de

votre cluster est créé. Poursuivrez votre lecture pendant le déploiement du cluster.
Docker s'est engagé dans les conteneurs avec un ensemble d'outils et de formats standard
définissant la manière de créer et d'exécuter un conteneur. Docker s'appuie sur les
fonctionnalités existantes au niveau du noyau Linux et Windows pour offrir une expérience
de conteneur portable et cohérente sur toutes les plateformes. Un développeur peut créer
sur son ordinateur portable un conteneur Docker exécutant macOS, valider et tester son
application, puis exécuter ce conteneur Docker à l'identique, sans modification, dans un
cluster de serveurs Linux ou Windows plus traditionnel, sur site ou dans Azure. Tous les
binaires d'application, les bibliothèques et les fichiers de configuration requis sont
regroupés en bundle dans le conteneur, de sorte que le système d'exploitation hôte sous-
jacent ne devienne pas un facteur ou une contrainte de conception.
L'importance de Docker ne doit pas être négligée à cet égard. Les termes conteneur et
Docker sont souvent utilisés l'un pour l'autre, bien qu'ils ne soient en réalité pas
interchangeables d'un point de vue technique. Docker est un ensemble d'outils
permettant aux développeurs de construire et d'utiliser des conteneurs de manière
cohérente, fiable et portable. La facilité d'utilisation de ces outils a conduit à leur
adoption rapide et à la large intégration de la technologie sous-jacente des conteneurs
qui existait déjà depuis plus d'une décennie sous une forme ou sous une autre. Les
développeurs ont adopté les conteneurs et la plateforme Docker, et les départements
informatiques ont dû rattraper leur retard depuis.
Docker participe à l'Open Container Initiative. Le format et les spécifications
que Docker a définis autour de la manière de packager et d'exécuter un conteneur
comptent parmi les principes fondateurs qui ont été adoptés pour ce projet. Le travail
de Docker s'est poursuivi et a été complété par d’autres. Parmi les grands contributeurs
à la technologie des conteneurs, on peut citer IBM et Red Hat, qui ont contribué à
certaines des conceptions de base adoptées et au code qui alimente les plateformes de
conteneurs actuelles. L’Open Container Initiative et les formats de conception pour le
packaging des conteneurs et les runtimes sont importants, car ils permettent à chaque
fournisseur de venir superposer ses propres outils sur les formats courants, avec l'intérêt
pour vous de pouvoir déplacer le conteneur sous-jacent d’une plateforme à l’autre tout
en conservant la même expérience fondamentale.

19.2 L'approche microservices des applications

Si les conteneurs utilisent un concept d'isolation similaire à celui des VM, pouvez-vous
y exécuter les mêmes types de charges de travail que dans vos VM ? Eh bien, oui, mais
ce n'est pas parce que vous pouvez le faire qu'il est souhaitable que vous le fassiez ! Les
conteneurs peuvent être utilisés pour exécuter toutes les charges de travail qui vous
sont familières, et il y a des avantages en termes de portabilité et d'orchestration que
288 Chapitre 19  Conteneurs Azure

nous examinerons à la section 19.4 Pour maximiser les avantages des conteneurs et

prendre la bonne voie, il est souhaitable d'adopter un modèle mental légèrement
différent lorsque vous travaillez avec des conteneurs. La figure 19.5 compare le modèle
d'application traditionnel à une approche de type microservices.

Microservices
Application monolithique

Traitement des Traitement des Traitement des Traitement

commandes paiements commandes des paiements

Gestion des Informations Gestion des Informations

comptes sur les stocks comptes sur les stocks

Figure 19.5  Dans une application monolithique traditionnelle, l'application tout entière fonctionne comme
une seule et même application. L'application peut comprendre divers composants, mais elle s'exécute
à partir d'une seule installation et est corrigée et mise à jour en tant qu'instance unique. Dans l'approche
microservices, chaque composant constitue un service applicatif et une unité d'exécution à part entière.
Chaque composant peut être mis à jour, corrigé et mis à l'échelle indépendamment des autres.

Une machine virtuelle standard inclut une installation complète de son système
d'exploitation invité, tel qu'Ubuntu ou Windows Server. Cette installation du système
d'exploitation de base comprend des centaines de composants, de bibliothèques et
d'outils. Vous installez ensuite d'autres bibliothèques et applications, par exemple
pour le serveur Web NGINX ou Microsoft SQL Server. Enfin, vous déployez votre code
d'application. Cette machine virtuelle exécute généralement une grande partie, sinon
la totalité, de l'application. Vous disposez en fait d'une grosse instance d’installation et
d’exécution de votre application. Pour améliorer les performances, vous pouvez
ajouter plus de mémoire ou de capacité UC à votre machine virtuelle (mise à l'échelle
verticale, telle que décrite plus tôt dans ce document) ou augmenter le nombre
d'instances qui exécutent votre application (mise à l'échelle horizontale, comme avec
des VMSS). La création d'instances multiples de l'application ne fonctionne que si
cette dernière est compatible avec les clusters, et elle implique souvent une certaine
forme de stockage partagé pour assurer un état cohérent entre les instances
d'application. Cette forme traditionnelle de déploiement est qualifiée de monolithique.
Une autre façon d'approcher la conception, le développement et l'exécution d'une
application consiste à décomposer les choses en composants de plus petite taille. On
parle dans ce cas d'approche microservices du développement et du déploiement
d'applications. Chaque microservice est responsable d'une petite partie de
l'environnement applicatif plus large. Les microservices peuvent croître, être mis à
l'échelle et être mis à jour indépendamment du reste de l'environnement applicatif.
Bien que ce modèle puisse poser quelques difficultés au début, le temps que les
équipes de développement et le département informatique s'approprient cette
manière différente de créer et de déployer des applications, les conteneurs sont
parfaitement adaptés à l'approche microservices. Les développeurs sont en mesure de
déployer des mises à jour plus petites et plus incrémentielles à un rythme plus rapide
qu'avec l'approche monolithique du développement d'applications. Les microservices
et les conteneurs sont également une solution idéale pour les workflows d'intégration
continue et de livraison continue (CI/CD), en ceci qu'ils vous permettent de créer, de
tester, de mettre en préproduction et de déployer plus facilement vos mises à jour. Vos
clients reçoivent les nouvelles fonctionnalités ou les corrections de bogues plus
rapidement, ce qui est susceptible de profiter à votre activité.
 Azure Container Instances 289

Les microservices avec Azure Service Fabric

Ce chapitre traite principalement des conteneurs Docker et de l'orchestration avec
Kubernetes, mais Azure propose également un autre service qui fait évoluer de manière
similaire le développement d'applications vers un modèle de type microservices. Azure
Service Fabric, qui existe depuis plusieurs années, proposait à l'origine une approche
centrée sur Windows de la création d'applications avec mise en œuvre de chaque
composant en tant que microservice à part entière. Service Fabric garde la trace de
l'emplacement où s'exécute chaque composant de microservice dans un cluster, permet
aux services de se découvrir et de communiquer entre eux, et gère la redondance et la
mise à l'échelle.
De nombreux grands services Azure s'appuient sur Service  Fabric, parmi lesquels
Cosmos DB. Cela vous donne une idée de la capacité et de la puissance de
Service Fabric ! Service Fabric lui-même s'exécute sur des VMSS. Vous vous y connaissez
un peu en VMSS maintenant, n'est-ce pas ?
La plateforme Service Fabric a mûri et prend désormais en charge aussi bien Windows
que Linux en tant que système d'exploitation invité, si bien que vous pouvez créer votre
application avec n'importe quel langage de programmation que vous connaissez. Autre
possibilité à noter dans Azure : vous pouvez choisir la façon dont vous voulez gérer et
orchestrer vos applications en conteneurs. Service Fabric et AKS offrent tous deux des
avantages et cas d'utilisation très intéressants.
À ce stade, si vous développez actuellement, ou souhaitez développer, des
microservices sans recourir à des conteneurs, Service Fabric est un excellent choix. Les
applications conçues autour du modèle acteur sont également très intéressantes, car
Service Fabric a été construit à l’origine avec ce modèle de programmation à l’esprit.
Service Fabric offre une approche unifiée pour la mise en œuvre autant d'applications
en microservices plus traditionnelles que d'applications basées sur des conteneurs. Si
vous choisissez d'adopter des conteneurs pour d'autres charges de travail, vous pourrez
utiliser les mêmes outils de gestion et la même interface Service Fabric pour gérer tous
vos environnements applicatifs.
Pour une approche davantage orientée conteneurs dès le départ, AKS peut être une
meilleure option, la croissance et l'adoption de Kubernetes fournissant une expérience
de choix. Vous pouvez exécuter des conteneurs Linux et Windows dans AKS.

19.3 Azure Container Instances
Maintenant que vous en savez plus sur ce que sont les conteneurs et sur la façon de les
utiliser, nous allons nous lancer et créer une instance de base de notre pizzeria. Cet
exemple est identique à celui des chapitres précédents, dans lequel vous avez créé une
machine virtuelle de base pour exécuter votre site Web, et déployé votre application
sur une application Web. Dans les deux cas, vous aviez dû créer la VM ou l'application
web, vous y connecter, puis y déployer une page Web de base. La puissance des
conteneurs aurait-elle pu vous faciliter la vie ? C'est certain !
Le service ACI (Azure Container Instances) vous permet de créer et d'exécuter des
conteneurs en quelques secondes. Vous n'avez pas de ressources réseau initiales à créer
et à configurer, et chaque instance de conteneur vous est facturée à la seconde de
consommation. Si vous n'avez jamais utilisé de conteneurs et que vous ne voulez rien
installer localement sur votre ordinateur, ACI est un excellent moyen de tester la
technologie.
290 Chapitre 19  Conteneurs Azure

Pour voir comment vous pouvez rapidement exécuter votre pizzeria en ligne, nous
allons créer une instance de conteneur. Si une seule commande suffit pour exécuter
une instance de conteneur, la figure 19.6 vous montre les divers composants mobilisés
en coulisses pour que cela soit possible. Nous verrons ici les composants d'un Dockerfile
et du Docker Hub une fois l'instance de conteneur opérationnelle.

Image de base

1. NGINX :1.17.5
Dockerfile
Azure Container
FROM nginx : 1.17.5 Docker Hub Instance
2. Mappage port externe 80 Déployer
EXPOSE 80:80 iainfoulds
-> port de conteneur 80 azuremol
: azuremol
COPY index.html
/usr/share/nginx/html 3.
index.html
/usr/share/nginx/html
Image de conteneur
local créée à parr du
Dockerfile et poussée
vers le référenel
azuremol public Docker Hub

Figure 19.6  Un Dockerfile a été utilisé pour créer une image complète du conteneur : azuremol. Cette
image a été poussée vers un registre public en ligne, le Docker Hub. Vous pouvez alors créer une instance
de conteneur à l'aide de cette image publique prédéfinie à partir du Docker Hub, qui fournit une image
d'application prête à être exécutée.

Tester
Pour créer une instance de conteneur Azure qui exécute un site Web de base, procé-
dez comme indiqué ci-après :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell dans le menu
du haut.
2 Créez une instance de conteneur et spécifiez que vous souhaitez disposer d’une
adresse IP publique pour ouvrir le port 80 :
az container create \
--resource-group azuremolchapter19 \
--name azuremol \
--image iainfoulds/azuremol \
--ip-address public \
--ports 80

Cet exercice utilise un exemple d'image que j'ai créé pour vous, que nous
examinerons un peu plus lorsque le conteneur sera opérationnel.
 Azure Container Instances 291

3 Pour voir ce que nous avons créé, regardez la sortie de la commande pour créer
le con teneur.
Dans la section Événements, vous pouvez voir que l'image est extraite
(téléchargée) du Docker Hub, qu'un conteneur est créé et que le conteneur est
ensuite démarré.
Certaines réservations de capacité UC et de mémoire sont également
affectées, qui peuvent être ajustées au besoin. Une adresse IP publique est affichée,
ainsi qu'un certain nombre d'informations sur le conteneur, telles que son état de
provisionnement, son type de système d'exploitation et sa stratégie de redémarrage.
4 Pour ouvrir le site Web de base exécuté dans le conteneur, il vous suffit
d'interroger l'adresse IP publique attribuée :
az container show \
--resource-group azuremolchapter19 \
--name azuremol \
--query ipAddress.ip \
--output tsv

5 Ouvrez l'adresse IP publique de votre instance de conteneur dans un navigateur

Web. Le site Web de base de la pizzeria doit s'afficher, comme illustré à la
figure 19.7.

Figure 19.7  Lorsque vous créez une instance de conteneur, le site Web de la pizzeria
s'exécute sans aucune configuration supplémentaire. Toute la configuration et le
contenu sont inclus dans l'image du conteneur. Ce bref exercice met en lumière la
portabilité et la puissance des conteneurs : une fois l'image du conteneur préparée, votre
application est opérationnelle dès qu'une nouvelle instance de conteneur est déployée.

Examinons l'image du conteneur. Je ne voudrais pas rentrer dans trop de détails sur le
fonctionnement de Docker et la manière dont sont créées les images de conteneur,
mais il est important de comprendre d'où nous est venue cette image et comment elle
exécute notre site Web sans aucune configuration supplémentaire.
292 Chapitre 19  Conteneurs Azure

L’image est créée à partir d’une définition de configuration appelée Dockerfile. Dans
un Dockerfile, vous définissez la plateforme de base, la configuration que vous souhaitez
appliquer et les commandes à exécuter ou les fichiers à copier. Les Dockerfiles peuvent
être, et sont souvent, plus complexes que l'exemple de définition suivant, qui nous a
servi à créer notre conteneur azuremol :
FROM nginx:1.17.5
EXPOSE 80:80

COPY index.html /usr/share/nginx/html

Lorsque ce Dockerfile a été employé pour générer une image de conteneur Docker,
NGINX a été utilisé comme image source, et l'exemple de page Web a été copié
dedans. Ce conteneur a ensuite été poussé vers le Docker Hub, un référentiel public
en ligne que Docker fournit pour partager et déployer des conteneurs. Pour déployer
l'instance de conteneur, vous avez fourni iainfoulds/azuremol comme image de
conteneur à utiliser. Azure a examiné le Docker  Hub et y a trouvé un référentiel
nommé iainfoulds et, à l'intérieur, une image nommée azuremol.
Passons en revue chacune des lignes du Dockerfile :
¡ FROM nginx : 1.17.5 : dans les chapitres précédents, vous aviez créé une VM de
base, vous y étiez connecté avec SSH, puis aviez installé manuellement le serveur
web NGINX. Dans notre exemple de Dockerfile, tout cela est réalisé au moyen
d'une seule ligne. Cette ligne indique de baser le conteneur sur une image de
conteneur existante qui est préinstallée avec NGINX. Le 1.17.5 est la version de
l’image de conteneur NGINX public à utiliser. C’est la version la plus récente au
moment de la rédaction du présent document. Il est recommandé d’inclure un
numéro de version spécifique. Si vous ne le faites pas, la dernière version est
toujours utilisée. Même si cela semble judicieux en théorie, les applications de
microservices peuvent s'étenddre vers un grand nombre de conteneurs actifs.
Vous devez donc vérifier l'homénégité de votre environnement et contrôler le
numéro de version exact de chaque composant utilisé.
¡ EXPOSE 80:80 : pour permettre l'accès à votre VM dans les chapitres précédents,
vous aviez créé une règle NSG qui autorisait le port 80. Dans notre Dockerfile, cette
ligne indique au conteneur d'ouvrir le port 80 et de le mapper sur le port 80 interne.
Lorsque vous avez créé votre instance de conteneur avec az container create,
vous avez également indiqué à la plateforme Azure d'autoriser le trafic approprié
avec --ports 80. Vous n'avez rien d'autre à faire pour la mise en réseau virtuelle !
¡ COPY index.html /usr/share/nginx/html : la dernière ligne vous permet de copier
votre application dans le conteneur. Dans les chapitres précédents, vous aviez utilisé
Git pour récupérer la page Web de la pizzeria et l'afficher dans votre application Web.
Avec le Dockerfile, vous copiez simplement avec COPY le fichier index.html dans le
répertoire /usr/share/nginx/html local du conteneur. Et le tour est joué !
Pour vos propres scénarios, vous pouvez définir un Dockerfile qui utilise une image de
base différente, telle que Node.js ou Python. Vous installez ensuite les bibliothèques ou les
packages supplémentaires requis, extrayez votre code d'application du contrôle de source,
tel que GitHub, et déployez votre application. Ce Dockerfile serait utilisé pour créer des
images de conteneur qui seraient ensuite stockées dans un registre de conteneurs privé, et
non dans un référentiel Docker Hub public comme celui de l'exemple.
 Azure Kubernetes Service 293

Azure Container Registry

Vous vous dites peut-être : le Docker Hub, ça a l'air super ; Y a-t-il quelque chose d'aussi
génial dans Azure ? Eh bien oui ! Étant donné que vous devez créer un Dockerfile et
générer une image de conteneur, un exercice sur le sujet nous prendrait
malheureusement un peu de temps, et nous avons encore beaucoup de choses à voir
dans ce chapitre. Vous pouvez facilement intégrer Azure Container Registry (ACR) et
AKS, de sorte que les deux services fonctionnent bien ensemble. Vous pouvez toutefois
générer vos propres images à partir d'un Dockerfile dans le Cloud  Shell, et je vous
encourage à tester cela si vous en avez le temps. Mais personnellement, Azure Container
Registry (ACR) est la solution que je choisirais pour ma part pour stocker mes images de
conteneur, et ce pour plusieurs raisons :
¡ Tout d'abord, il s'agit d'un registre privé pour vos images de conteneur, de sorte
que vous n'avez pas besoin de vous soucier des accès indésirables potentiels à
vos fichiers d'application et de configuration. Vous pouvez appliquer les mêmes
mécanismes RBAC que ceux que nous avons évoqués au chapitre 6. RBAC vous
aide à limiter et à auditer les accès à vos images.
¡ Le stockage de vos images de conteneur dans un registre dans Azure signifie
qu'elles résident dans les mêmes datacenters que l'infrastructure utilisée pour
exécuter vos instances de conteneur ou vos clusters (point que nous examinerons à
la section 19.4.1). Bien que les images de conteneur soient de relativement petite
taille, (souvent de quelques dizaines de Mo seulement), elles peuvent finir par peser
cumulativement lorsqu'elles sont téléchargées depuis un registre distant.
ACR fournit également des options de réplication et de redondance intégrées que vous
pouvez utiliser pour placer vos conteneurs près de là où vous les déployez et les exécuter
pour l'accès utilisateur. Cette proximité régionale s'inscrit dans la même logique que
celle de la réplication globale Cosmos DB que vous avez mise en œuvre au chapitre 10,
pour gagner ces petites millisecondes qui comptent et assurer à vos clients l'accès le
plus rapide possible à vos applications.
Si tout cela vous parle, jetez un coup d'œil aux guides de démarrage rapide dédiés à ACR
pour mettre en place votre propre référentiel privé en quelques minutes seulement :
http://mng.bz/04rj.

19.4 Azure Kubernetes Service

L'exécution d'une instance de conteneur unique, c'est déjà très bien, mais cela ne vous
donne pas beaucoup de redondance ni de capacité de mise à l'échelle. Vous vous
rappelez des chapitres entiers que nous avons consacrés précédemment dans ce livre
aux moyens d'exécuter plusieurs instances d'une application, d'équilibrer la charge
entre elles et d'assurer leur mise à l'échelle automatique ? Ne serait-ce pas génial de
pouvoir faire la même chose avec les conteneurs ? Pour cela, vous avez besoin d'un
orchestrateur de conteneurs.
Comme son nom l'indique, un orchestrateur de conteneurs gère vos instances de
conteneur, surveille leur état de santé et les met à l'échelle au besoin. Les orchestrateurs
peuvent, et c'est souvent le cas, faire beaucoup plus que cela, mais d'un point de vue
général, l'objectif principal est de gérer tous les éléments en mouvement impliqués
dans l'exécution d'une application hautement disponible, évolutive et basée sur des
conteneurs. S'il existe différents orchestrateurs de conteneurs, tels que Docker Swarm
ou encore Distributed Cloud Operating System (DC/OS) par exemple, l'un d'eux s'est
imposé comme la solution de référence en la matière : Kubernetes.
Kubernetes a vu le jour dans le cadre d'un projet open source lancé et parrainé par
Google et capitalisant sur l’outil d’orchestration de conteneurs interne de la société.
Largement accepté par la communauté open source, Kubernetes est l'un des projets
294 Chapitre 19  Conteneurs Azure

open source les plus importants et les plus dynamiques sur GitHub. De nombreuses
grandes entreprises technologiques, telles que Red Hat, IBM et Microsoft, contribuent
au projet Kubernetes de base.
Dans cette section, reprenons notre exemple d'application Web de l'exercice précédent
avec ACI pour exécuter un déploiement redondant et évolutif dans Kubernetes. La
figure 19.8 illustre les composants avec lesquels nous allons nous retrouver.

Azure Kubernetes Déploiement

Services (AKS) Kubernetes

Docker Hub Cluster Kubernetes Service Kubernetes

Exécuon
iainfoulds : Équilibreur de
Nœud 1
azuremol charge Port TCP 80
Nœud 2

Pod 1

Pod 2

Figure 19.8  Votre exemple de conteneur issu du Docker Hub s'exécute sur un cluster

Kubernetes à deux nœuds que vous créez dans AKS. Le déploiement Kubernetes contient
deux pods logiques, un sur chaque nœud de cluster, avec une instance de conteneur qui
s'exécute dans chaque pod. Vous exposez ensuite un équilibreur de charge publique pour
permettre la visualisation en ligne de votre application Web.

19.4.1 Création d'un cluster avec Azure Kubernetes service

Au chapitre 9, nous avons vu comment les VMSS permettent de réduire la complexité
du déploiement et de la configuration de l'infrastructure sous-jacente. Vous indiquez
combien d'instances de VM vous souhaitez dans votre VMSS, et le reste du réseau, du
stockage et de la configuration est automatiquement déployé sans que n'ayez rien à
faire. AKS fonctionne de la même manière pour délivrer un cluster Kubernetes
résilient et évolutif, la gestion étant assurée par la plateforme Azure. Les VMSS peuvent
être utilisés pour les machines virtuelles sous-jacentes qui s’exécutent dans le cluster
AKS, et ces machines virtuelles peuvent être distribuées dans les zones de disponibilité.
Les équilibreurs de charge Azure, également redondants dans les zones, sont
utilisés. En gros, AKS rassemble plusieurs des composants d’infrastructure et des
bonnes pratiques que vous avez appris jusqu’à présent dans ce livre !

Tester
Pour afficher les informations sur votre cluster AKS, procédez comme indiquez ci-après :

1 Ouvrez le portail Azure, puis sélectionnez l'icône Cloud Shell dans le menu du haut.
2 Plus tôt dans ce chapitre, vous avez créé un cluster Kubernetes. Le processus a dû
prendre quelques minutes, mais j'espère que votre cluster est prêt maintenant !
Vérifiez l'état du cluster comme suit :
az aks show \
--resource-group azuremolchapter19 \
--name azuremol
 Azure Kubernetes Service 295

Le provisioningState près de la fin doit indiquer Succeeded.

3 Si votre cluster est prêt, procurez-vous un fichier d'informations d'identification
qui vous permettra d'utiliser les outils en ligne de commande Kubernetes pour
authentifier et gérer les ressources :
az aks get-credentials \
--resource-group azuremolchapter19 \
--name azuremol

C'est tout ce qu'il y à faire pour rendre Kubernetes opérationnel dans Azur ! Vous vous
demandez peut-être : « Est-ce que je ne peux pas simplement créer mon propre cluster
avec des machines virtuelles ou des VMSS, et installer manuellement les mêmes
composants Docker et Kubernetes  ? Si, c'est tout à fait possible. On peut faire le
parallèle avec l'approche IaaS et PaaS des VM par rapport aux applications Web.
L'approche des applications Web offre de nombreux avantages : vous ne vous occupez
que des options de configuration de haut niveau, puis vous chargez votre code
d'application. Un cluster Kubernetes managé, tel que le propose AKS, réduit le niveau
de complexité et de gestion, et vous permet ainsi de mieux vous concentrer sur vos
applications et l'expérience de vos clients.
De la même façon que vous pouvez faire le choix de machines virtuelles au lieu
d'applications Web, vous pouvez choisir de déployer votre propre cluster Kubernetes
plutôt que d'utiliser AKS. Aucun problème, les deux approches finissent par utiliser les
mêmes composants de services d'Azure. Les VM, les VMSS, les équilibreurs de charge et
les NSG, sujets que nous avons étudiés aux chapitres précédents, sont tous des composants
qui restent présents, bien qu'abstraits, dans les clusters AKS. Du point de vue de la
planification et du dépannage, vous devez disposer des compétences voulues pour
comprendre ce qui se passe sous le capot aux fins du bon fonctionnement de l'offre de
service Kubernetes managé. Votre niveau de confort et le temps que vous pouvez
consacrer à la gestion de l'infrastructure guideront votre prise de décision au moment de
vous lancer dans la création d'une nouvelle application avec des conteneurs dans Azur.

19.4.2 Exécution d'un site Web de base dans Kubernetes

Vous avez créé un cluster Kubernetes à la section 19.4.1, mais aucune application ne s'y
exécute à ce stade. Changeons cela ! Vous devez à présent créer le déploiement Kubernetes
que nous avons vu plus haut à la figure 19.8 et à nouveau illustré à la figure 19.9.
Azure Kubernetes Déploiement
Services (AKS) Kubernetes

Docker Hub Cluster Kubernetes Service Kubernetes

Exécuon
iainfoulds : Équilibreur de
Nœud 1
azuremol charge Port TCP 80
Nœud 2

Pod 1

Pod 2

Figure 19.9  Avec le cluster Kubernetes créé dans AKS, vous pouvez désormais créer un déploiement
Kubernetes et exécuter votre application. Votre conteneur s'exécutera sur deux nœuds, avec un pod
logique sur chaque nœud ; vous devez créer un service Kubernetes qui exposera un équilibreur de charge
publique pour acheminer le trafic vers votre application.
296 Chapitre 19  Conteneurs Azure

Tester
Pour déployer une application sur votre cluster Kubernetes, procédez comme indiqué
ci-après :

1 Vous interagissez avec un cluster Kubernetes à l'aide d'un utilitaire de ligne de

commande baptisé kubectl. Utilisez la même image de conteneur iainfoulds/
azuremol du Docker Hub que celle que vous avez exécutée en tant qu'instance
de conteneur :
kubectl run azuremol \
--image=docker.io/iainfoulds/azuremol:latest \
--port=80

Le téléchargement de l’image de conteneur depuis le Docker Hub et le lancement

de l’application dans Kubernetes prennent de l'ordre d'une minute. L'application
s'exécute dans un pod : une construction logique dans Kubernetes qui héberge
chaque conteneur.
2 Les pods peuvent contenir des composants d'assistance supplémentaires, mais
pour l'instant, contrôlez l'état de votre conteneur en interrogeant le pod :
kubectl get pods --watch

Même si l'état du pod est Running, vous ne pourrez pas accéder à votre application.
L'instance de conteneur que vous avez créée précédemment pourrait acheminer le trafic
sur une adresse IP publique directement vers cette seule instance, mais de quoi un
cluster Kubernetes a-t-il besoin selon vous pour acheminer le trafic vers des conteneurs ?
Si vous avez deviné, « un équilibreur de charge », Félicitations ! Pour le moment, vous
n'avez qu'un seul pod : une seule instance de conteneur. Vous augmenterez le nombre
de pods dans l'exercice pratique de la fin du chapitre, et pour que cela fonctionne, vous
avez besoin d'un moyen d'acheminer le trafic vers plusieurs instances. Nous devons donc
indiquer à Kubernetes d'utiliser un équilibreur de charge.
Et c'est là que l’intégration entre Kubernetes et Azure devient puissante. Lorsque vous
demandez à Kubernetes de créer un équilibreur de charge pour vos conteneurs, en
coulisses, Kubernetes joint la plateforme Azure et crée automatiquement un équilibreur de
charge Azure. Cet équilibreur de charge Azure est semblable à celui que nous avons étudié
au chapitre 8. Il s'appuie sur des pools d'adresses IP front-end et back-end ainsi que sur des
règles d'équilibrage de charge, et vous donne la possibilité de configurer des sondes
d’intégrité. Lorsque votre déploiement Kubernetes voit son nombre de pods augmenter ou
diminuer, l'équilibreur de charge est automatiquement mis à jour au besoin.

Tester
Pour exposer votre application à Internet, procédez comme suit :

1 Indiquez à Kubernetes que vous souhaitez utiliser un équilibreur de charge et

ajoutez une règle pour distribuer le traffic sur le port 80 :
kubectl expose deployment/azuremol \
--type=”LoadBalancer” \
--port 80
 Azure Kubernetes Service 297

2 Comme précédemment, contrôlez avec un watch l'état de votre déploiement de

service :
kubectl get service azuremol --watch
Une fois l'adresse IP publique externe attribuée, l'équilibreur de charge Azure
a terminé son déploiement et le cluster Kubernetes et ses nœuds sont connectés.
3 Ouvrez l'adresse IP publique de votre service dans un navigateur Web pour voir
s'exécuter votre application Web.
Les déploiements d'application dans Kubernetes sont souvent beaucoup plus denses
que dans le cas de cet exemple de base. Vous définissez généralement un manifeste de
service, semblable à un modèle Resource Manager, qui définit toutes les caractéristiques
de votre application. Ces propriétés peuvent inclure le nombre d'instances de votre
application à exécuter, le stockage à rattacher, les méthodes d'équilibrage de charge et
les ports réseau à utiliser, etc. Dans le monde réel, vous n’avez même pas à le faire
manuellement. Un système de CI/CD comme Azure DevOps ou Jenkins automatise les
déploiements d’applications et de services directement à l’intérieur du cluster AKS. Ce
qui est génial avec AKS, c'est que vous n'avez pas à vous soucier de l'installation et de la
configuration de Kubernetes. Comme pour les autres services PaaS comme les
applications Web et Cosmos DB, vous fournissez vos applications et laissez la plateforme
Azure gérer l'infrastructure sous-jacente et la redondance.

Pensez au ménage
N'oubliez pas de nettoyer et de supprimer vos groupes de ressources pour ne pas vous
retrouver avec une surconsommation de vos crédits Azur gratuits. Lorsque vous vous
mettez à utiliser des conteneurs, il devient encore plus important de faire attention aux
ressources Azure que vous laissez activées. Une application Web en elle-même ne coûte
pas cher, mais un cluster AKS de cinq nœuds et quelques instances de conteneur avec
des images ACR géorépliquées, c'est une autre affaire !
Les instances ACI sont facturées à la seconde, et les frais s'accumulent rapidement
lorsqu'on les laisse s'exécuter pendant des jours ou des semaines. Un cluster AKS exécute
une VM pour chaque nœud ; dès lors que vous augmentez le nombre de nœuds et exécutez
plusieurs VM dans votre cluster, vous payez donc une VM pour chaque nœud présent.
Le nombre de conteneurs que chacun de ces nœuds AKS exécute n'a pas d'impact sur la
note, mais comme avec n'importe quelle VM, un nœud AKS devient coûteux quand on le
laisse tourner. Ce qui est génial avec Kubernetes, c'est que vous pouvez exporter vos
configurations de service (la définition de vos pods, équilibreurs de charge, règles de
mise à l’échelle automatique, etc.) pour les déployer ailleurs. Lorsque vous créez et
testez vos applications, vous n'avez pas besoin de laisser votre cluster AKS s'exécuter ;
vous pouvez déployer un cluster au moment où vous en avez besoin et déployer votre
service à partir d'une configuration précédente.
Les clusters AKS peuvent être dimensionnés, comme nous le verrons dans l’exercice
pratique de fin de chapitre. Vous pouvez également configurer la mise à l’échelle
automatique qui effectue cette mise à l’échelle pour vous en fonction de la
charge. Il s’agit de la même sorte de mise à l’échelle automatique que nous avons
évoquée au chapitre  9 pour les VMSS et les applications Web. Commencez-vous
à réaliser comment tout s'assemble dans Azure ?
Dans ce chapitre, nous avons dû ici passer très vite sur le sujet des conteneurs et de
Kubernetes, alors ne vous inquiétez pas si vous vous sentez un peu décontenancé
maintenant ! Manning propose plusieurs excellents livres, comme par exemple Learn
Docker in a Month of Lunches, par Elton Stoneman (https://livebook.manning.com/
book/learn-docker-in-a-month-of-lunches) et Kubernetes dans
298 Chapitre 19  Conteneurs Azure

(suite)
Action, par Marko Luksa (https://livebook.manning.com/book/kubernetes-in-action),
qui peuvent vous aider à approfondir sur Docker, le développement d'applications en
microservices et Kubernetes. Consultez-les si ce sujet vous intéresse et que vous désirez
en savoir plus !

Les exemples de ce chapitre utilisaient des machines virtuelles Linux pour les nœuds
de cluster AKS, avant d'exécuter des conteneurs Linux pour NGINX. Les conteneurs
sont un peu compliqués car vous ne pouvez exécuter des conteneurs Linux que sur des
nœuds Linux, par exemple. Comme vous l’avez appris au début du chapitre, les
conteneurs partagent le système d’exploitation invité et le noyau. Ainsi, vous ne pouvez
pas exécuter de conteneurs Windows sur un nœud Linux. En général, vous ne pouvez
pas non plus exécuter de conteneurs Linux sur un nœud Windows. Certaines astuces
techniques intéressantes peuvent être appliquées, mais en général, le conteneur et le
système d’exploitation du nœud sous-jacent doivent correspondre l'un à l'autre.
AKS est une solution très intéressante car vous pouvez exécuter à la fois des nœuds
Linux et Windows, afin de pouvoir exécuter des conteneurs Linux et Windows ! Même
si devez aborder avec soin la planification de ces différents conteneurs sur les différents
systèmes d’exploitation de nœuds, cette approche élargit considérablement les
applications et les services que vous pouvez exécuter dans AKS.

19.5 Exercice pratique : mise à l'échelle de vos déploiements Kubernetes

L'exemple de base utilisé dans ce chapitre nous a conduit à créer un cluster Kubernetes à
deux nœuds et un pod unique exécutant votre site Web. Dans cet exercice pratique, vous
allez apprendre comment redimensionner ce cluster et augmenter le nombre d'instances
de conteneur. Même s'il s'agit d'un exemple de base, plus vos nœuds sont nombreux et
plus vous pouvez exécuter d’instances de conteneur, ce qui est particulièrement utile si
vous devez exécuter de nombreuses applications dans votre cluster.
1 Vous pouvez voir combien de nœuds compte votre cluster Kubernetes à l'aide de
la commande kubectl  get  nodes. Augmentez à trois le nombre de nœuds de
votre cluster :
az aks scale \
--resource-group azuremolchapter19 \
--name azuremol \
--node-count 3

La mise à l'échelle et l'ajout du nouveau nœud ne devrait pas prendre plus d'une
minute ou deux.
2 Utilisez à nouveau kubectl pour contrôler l'état de vos nœuds. Lorsque vous
mettez à l’échelle un nœud, Kubernetes ne crée aucune instance de conteneur
supplémentaire pour vos applications de manière automatique. Ainsi, vous ne
bénéficiez pas immédiatement des avantages des ressources de
calcul supplémentaires fournies par le nouveau nœud.
 Exercice pratique : mise à l'échelle de vos déploiements Kubernetes 299

3 Observez votre déploiement actuel avec kubectl get deployment azuremol.

Nous n'avons créé qu'une seule instance précédemment. Cet exemple d’applica-
tion ne permet pas de tirer le meilleur parti du nouveau nœud que vous avez
ajouté au cluster à l’étape  1. Augmentez à cinq le nombre d'instances, ou
réplicas :
kubectl scale deployment azuremol --replicas 5

4 Utilisez à nouveau kubectl pour examiner le déploiement. Observez les pods,

les instances de conteneur en cours d'exécution, avec kubectl get pods. En
quelques secondes, tous ces réplicas supplémentaires ont été démarrés et ont été
connectés à l'équilibreur de charge.
5 Utilisez kubectl get pods -o wide pour identifier les nœuds sur lesquels s'ex-
écutent les pods. Notez le dernier nombre du nom du nœud, qui indique le
nœud qui est utilisé dans le VMSS. Les pods doivent être distribués sur tous les
nœuds de votre cluster. À mesure que d’autres applications augmentent le nom-
bre de conteneurs de la même manière, vous pouvez commencer à optimiser
l’utilisation des ressources de calcul sur tous les nœuds du cluster.
 20
Azure et l'Internet des objets

Pour moi, l'une des avancées technologiques les plus intéressantes de ces dernières
années est certainement l’Internet des objets (IoT). Je ne crois pas vraiment qu'un
lave-vaisselle ou un réfrigérateur ait besoin d'être connecté à Internet pour l'instant,
et un téléviseur ou un appareil audio connecté en permanence à Internet et
toujours à l'affût du son de votre voix pour émettre une commande pose sans nul
doute des préoccupations légitimes s'agissant de la protection de la vie privée.
Néanmoins, il y a aussi de nombreuses applications utiles de l'IoT. Prenons par
exemple un équipement de fabrication installé dans différentes usines à travers le
monde et capable de rendre compte de son état d'intégrité, de générer des alertes
de maintenance et dont il est possible de comprendre les performances. Pour une
entreprise de camionnage, il est utile de pouvoir streamer les données télémétriques
de ses véhicules concernant les charges transportées et les temps de conduite
moyens, et de pouvoir rediriger ses chauffeurs de manière plus intelligente au
besoin. Et pour une compagnie maritime, la possibilité de suivre chaque conteneur
et la capacité d'indiquer à tout moment à ses clients où sont leurs ressources pour
les aider à mieux gérer leur chaîne logistique, n'est pas non plus sans intérêt.
Dans Azure, vous pouvez intégrer des appareils IoT avec un certain nombre de
services. Azure Web Apps fournit un front-end pour la visualisation de vos données,
Azure Storage vous permet d'enregistrer les données transmises par les appareils, et
des fonctionnalités serverless telles qu'Azure  Logic  Apps (décrites au chapitre
suivant) traitent les données reçues.
Dans ce chapitre, nous allons examiner ce qu'est l'IoT ainsi la façon dont
Azure IoT Hub peut être utilisé pour gérer et collecter de manière centralisée les
données des appareils. Nous verrons ensuite comment utiliser une application Web
Azure pour visualiser les données en temps réel d'un appareil IoT.

20.1 Qu’est-ce que l’Internet des objets ?

L'intérêt pour l'Internet des objets s'est considérablement accru ces dernières années,
mais derrière ce concept flou se cachent tout un éventail de réalités différentes.
Fondamentalement, l'IoT est un modèle dans lequel un parc d'appareils
interconnectés, généralement de petits appareils électroniques peu coûteux, se
connectent à des systèmes et applications centraux. Les appareils connectés

300
 Qu’est-ce que l’Internet des objets ? 301

rapportent généralement les informations qu'ils collectent via leurs capteurs ou entrées.
Ces informations peuvent ensuite être traitées par un système central, intégrant
potentiellement de l’IA ou du ML comme évoqué au chapitre  17, pour l'exécution
d'actions appropriées. La figure 20.1 décrit le schéma de principe général de l'IoT.

Des messages sont échangés

entre les appareils IoT et le
système central.
Appareil IoT

Appareil IoT
Système Applications
central Les données collectées sur les
et services
Appareil IoT appareils IoT sont traitées et
des instructions peuvent être
renvoyées aux appareils ou à
d’autres systèmes.

Figure 20.1  Des messages sont échangés entre le parc des appareils IoT connectés et un système central.
Vos applications et services peuvent dès lors traiter les données reçues et envoyer des instructions aux
appareils pour l'exécution d'actions supplémentaires compte tenu des données collectées.

Voici quelques exemples d'application concrète de l'IoT :

¡ Parking  : un petit capteur situé au-dessus de chaque place de stationnement
détecte si un véhicule y est stationné. Un témoin lumineux au-dessus de chaque
place peut alors s'allumer en vert si la place est libre, ou en rouge si elle est
occupée. Les automobilistes accédant au parking peuvent voir des panneaux
d'information en temps réel à chaque étage qui leur indiquent combien ils y
trouveront de places disponibles. Les témoins rouges et verts au-dessus de chaque
place permettent aux conducteurs de localiser rapidement les places libres
lorsqu'ils parcourent chaque allée.
¡ Usine  : les machines d'un atelier peuvent rapporter des informations sur leur
production, les niveaux de consommables ainsi que leurs besoins en maintenance.
Ces informations peuvent dès lors être utilisées par un système central pour
planifier une intervention proactive sur l'équipement ou un réapprovisionnement
en consommables lorsqu'il y a lieu, avec l'intérêt de réduire les temps d'arrêt dans
la chaîne de production. Avec l'aide de l'IA et du ML, les besoins en maintenance
peuvent être prédits, et les consommables ou matières premières peuvent être
livrés en quantités appropriées juste avant que la production n'en ait besoin.
¡ Transport : les transports en commun, autobus comme trains, peuvent inclure des
capteurs GPS rendant compte de leur position et de leur vitesse. Il est également
possible de collecter des informations sur les billets pour connaître le nombre de
personnes transportées. Les panneaux d'information de la gare ferroviaire ou de
la gare routière peuvent dès lors fournir des informations en temps réel
sur l'heure d'arrivée de chaque train ou bus. Avec l'appui de l'IA et du ML, cette
technologie permet de suggérer des itinéraires alternatifs aux passagers en
attente lorsqu'il y a lieu, au vu des conditions de trafic, d'un retard prévu ou d'un
trop gros volume de passagers.
L'IoT est souvent complété par d'autres applications et services. Dans les scénarios de
l'usine et du transport, par exemple, l'IA et le ML sont évoqués respectivement pour
éclairer la prise de décisions en matière de production et pour apporter des suggestions
aux passagers. Des applications Web peuvent utiliser les informations transmises par les
302 Chapitre 20  Azure et l'Internet des objets

appareils IoT pour les rendre accessibles sur des appareils mobiles ou générer des alertes
et des notifications. Les données reçues des appareils IoT peuvent être consignées dans
un système de base de données tel qu'Azure Cosmos DB pour traitement ultérieur par
des applications de Business Intelligence et pour la génération de rapports.
Au nombre des applications futures envisagées de l'IoT, on peut également citer des
choses telles que des réfrigérateurs capables de détecter les quantités restantes de vos
aliments et de générer une liste de courses en conséquence, voire de passer commande
auprès de votre épicerie locale. Votre voiture pourra sans doute à l'avenir transmettre à
votre concessionnaire toutes les données utiles pour que l'ensemble des
pièces et consommables voulus pour sa révision soient fin prêts à son arrivée au garage.
Et que diriez-vous d'une sonnerie de réveil qui commanderait à votre cafetière de vous
préparer votre café du petit-déjeuner ?
La sécurité des appareils est un grand sujet de préoccupation avec l'IoT. Avec autant
d'appareils en dehors de votre infrastructure réseau principale et souvent connectés à
l'Internet public, le provisionnement, la maintenance et la mise à jour de ces appareils
représentent un véritable défi. De nombreux appareils IoT sont des dispositifs
électroniques simples, basse consommation, qui peuvent ne pas disposer des capacités
de stockage ou de traitement nécessaires pour s'appliquer eux-mêmes les mises à jour
de sécurité et d'application requises de la même manière qu'un ordinateur de bureau
ou portable classique. Il est hasardeux de déployer un parc d'appareils IoT, en
particulier des appareils grand public, sans un plan pour les sécuriser de manière
appropriée et assurer leur mise à jour et leur maintenance.
Ces questions de sécurité ne doivent pas vous dissuader de créer des applications et
des services utilisant ces appareils IoT. L'IoT pose des problématiques d'un nouveau
genre à la maintenance traditionnelle, mais il existe des solutions qui vous permettent
de provisionner et de maintenir vos appareils IoT de manière centralisée et de sécuriser
les communications avec eux.
À ce stade, je suppose que vous avez deviné qu'Azure dispose d'une telle solution IoT !
Il offre une suite de services IoT. Voyons comment vous pouvez explorer l’IoT avec Azure.

Accélération de vos déploiements Azure IoT

Ce chapitre se focalise sur Azure IoT Hub, un service qui vous permet de provisionner et
de connecter des appareils IoT pour bâtir vos propres solutions. Vous pouvez définir la
façon dont ces appareils IoT doivent se connecter ainsi que les utilisateurs ou
applications autorisés à accéder à leurs données, et sécuriser la connectivité. C'est à
vous de créer et de déployer l'infrastructure applicative pour tout connecter ensemble.
Les accélérateurs de solution Azure IoT sont des scénarios clés prédéfinis, par exemple pour
la surveillance à distance d'appareils ou d'une usine connectée. Les accélérateurs déploient
des services Azure classiques, tels qu'IoT Hub, Web Apps, Cosmos DB ou encore le service de
stockage Azure, et exécutent un exemple d'application intégrant l'ensemble de ces services.
L'application reste à personnaliser compte tenu de votre propre environnement, des
appareils IoT utilisés et des données à collecter et à surveiller, mais les accélérateurs de
solution IoT offrent un cadre idéal pour démarrer. Alors qu'IoT Hub vous donne le moyen
de connecter vos appareils IoT à Azure et vous laisse ensuite déployer les services
supplémentaires dont vous avez besoin, les accélérateurs de solutions IoT déploient des
solutions prédéfinies qui utilisent les services Azure les plus classiquement utilisés.
Si vous devenez accro à l'IoT à l'issue de ce chapitre et que vous souhaitez en savoir plus,
les accélérateurs de solution Azure IoT sont un excellent moyen de comprendre les
possibilités qu'offre Azure en la matière. Comme nous l'avons vu tout au long de ce livre,
Azure est bien plus qu'une simple plateforme offrant deux ou trois services
indépendants. Vous pouvez déployer de nombreux services parallèlement pour offrir la
meilleure expérience d'application qui soit à vos clients.
 Gestion centralisée des appareils avec Azure IoT Hub 303

20.2 Gestion centralisée des appareils avec Azure IoT Hub

Azure IoT Hub vous permet de gérer un parc d'appareils IoT, de les mettre à jour et de
streamer leurs données de manière centralisée. Grâce à ce service, vous pouvez
notamment configurer des routages pour diriger les données reçues des appareils vers
des applications, provisionner et gérer les certificats voulus pour sécuriser les
communications, et surveiller l'état de santé des appareils au moyen des diagnostics et
métriques Azure. Vous pouvez connecter vos appareils IoT à d'autres services et
applications Azure pour leur permettre d'envoyer et de recevoir des données dans le
cadre d'une solution plus large. Comme pour tout ce qui se trouve dans Azure, les
accès peuvent être contrôlés avec des RBAC, et des données de diagnostic peuvent être
collectées de manière centralisée pour le dépannage et la surveillance ou la génération
d'alertes. La Figure 20.2 illustre le rôle d'un hub IoT en tant que point central pour la
connexion d'appareils IoT aux services et applications Azure au sens large.

Suivi de la configuration, de Provisionnement Routage des messages

l’état et des métadonnées automatisé des appareils vers d’autres services Stockage
Azure pour traitement Azure
Appareils Provisionnement
jumeaux des appareils ou analyse

Azure Azure Web

Appareil IoT
Service Bus Apps
Appareil IoT
Azure IoT
Hub Azure Event
Appareil IoT Azure Logic
Grid
Messages appareil vers Apps
cloud et cloud vers Surveillance,
appareil pour la réception dépannage et alertes
et l’envoi de données sur les problèmes

Figure 20.2  Avec un hub IoT, vous pouvez provisionner et gérer de manière centralisée tout un parc
d'appareils IoT à l'échelle. Une communication bidirectionnelle s'installe entre les appareils et Azure
pour la lecture et l'écriture des données. Vous pouvez traiter les données reçues des appareils et les
router vers d'autres services Azure, tels que Azure Web Apps et Azure Storage. Pour la surveillance et
le dépannage, vous pouvez router les informations vers Azure Event Grid, que nous examinerons dans le
chapitre 21, puis relier d'autres solutions de surveillance.

Vous contrôlez l'accès à un hub IoT au moyen de stratégies d'accès partagé. Ces
stratégies s'appuient sur des comptes utilisateur et des autorisations. Des stratégies par
défaut sont proposées qui permettent aux appareils et services de se connecter au
hub IoT, ou de lire et d'écrire des informations dans le registre des appareils qui assure
le suivi des appareils IoT connectés et des clés de sécurité. Chaque stratégie peut se
voir attribuer une ou plusieurs des autorisations suivantes :
¡ Lecture du registre
¡ Écriture du registre
¡ Connexion de service
¡ Connexion d'appareil
304 Chapitre 20  Azure et l'Internet des objets

Des clés d'accès partagées sont utilisées par les applications et les services pour se
connecter au hub IoT. Comme pour le stockage, (sujet traité au chapitre 4), les clés
d'accès partagé vous permettent de définir des chaînes de connexion pour identifier
l'hôte, la stratégie d'accès et la clé d'accès. Une chaîne de connexion combine la clé
d'accès, le type de stratégie d'accès et le nom d'hôte du hub IoT. Voici un exemple de
chaîne de connexion à un hub IoT :
HostName=azuremol.azure-devices.net;SharedAccessKeyName=registryRead;
➥SharedAccessKey=6be2mXBVN9B+UkoPUMuwVDtR+7NZVBq+C7A1xCmQGAb=
Il existe des clés primaires et secondaires, qui peuvent être régulièrement changées et
mises à jour à des fins de sécurité, à l'image du schéma classique appliqué aux mots de
passe. Des solutions telles qu'Azure  Key  Vault (présenté au chapitre  15), offrent un
moyen efficace de suivre et de stocker ces clés pour que les applications puissent se les
procurer lorsqu'elles en ont besoin. Cette approche de la gestion des clés signifie que
vous pouvez changer fréquemment les clés d'accès sans avoir à mettre à jour tout votre
code d'application.
Des certificats numériques peuvent être stockés sur le hub IoT et automatiquement
fournis aux appareils IoT. N'oubliez pas que vos appareils IoT se trouvent souvent en
dehors de votre infrastructure principale et peuvent se connecter directement sur
Internet sans aucune forme de connexion réseau sécurisée, telle qu'un VPN. Veillez à
ce que toutes les données transitant entre vos appareils et le hub IoT soient chiffrées à
l'aide de connexions SSL/TLS. Azure Key Vault peut générer et stocker des certificats
SSL qui sont ensuite ajoutés au hub IoT. Ou vous pouvez aussi utiliser une autorité de
certification existante pour demander et émettre des certificats. L'important est de
faire en sorte que toutes les communications entre vos appareils IoT et Azure soient
chiffrées. Vous recevrez probablement une erreur si ce n'est pas le cas.
Les routages du hub IoT vous permettent d'envoyer des données transmises par vos
appareils IoT vers d'autres services Azure. Vous pouvez définir des critères, tels que la
présence dans le message d'un certain mot-clé ou d'une certaine valeur, puis router de
manière appropriée les messages à stocker sur Azure  Storage ou à traiter par une
application Web. Dans l'un des exercices ci-après, vous simulerez un capteur de
température de base connecté à un appareil IoT. Vous pourriez définir un routage sur
le hub  IoT pour surveiller les données entrantes et, en cas d'enregistrement d'une
température supérieure à 30°C, router les données vers une
application logique pour l'envoi d'une alerte par e-mail. Nous discuterons du monde
merveilleux de l'informatique serverless et des applications logiques au prochain 21.

Traitement à la périphérie
Dans ce chapitre, il est essentiellement question d'Azure IoT Hub. Un autre service,
Azure  IoT  Edge, vous permet d'exécuter certains services tels qu'Azure  Functions et
Stream Analytics dans votre environnement local. Plutôt que de streamer les données de
l'ensemble de vos appareils IoT pour les traiter de manière centralisée dans Azure, vous
pouvez aussi traiter les données sur place.
Azure IoT Edge exécute des applications et des services dans des conteneurs (abordés
au chapitre 19). L’utilisation de conteneurs permet à l’IoT Edge de fonctionner de façon
portable et cohérente sur différents appareils et environnements. Vous pouvez déployer
des services Azure prédéfinis ou écrire vos propres applications et les distribuer sur les
sites périphériques.
 Gestion centralisée des appareils avec Azure IoT Hub 305

Le principal avantage d'IoT Edge est qu'avec ce traitement périphérique, vous allégez le

traitement central et le trafic de données réseau. Avec un traitement local dans IoT Edge,
vous pouvez regrouper de grandes quantités de données pour les transmettre en lots à
Azure. Les applications centrales peuvent ensuite agréger les informations provenant
des sites périphériques pour traitement par des services d'IA ou de ML.
Un autre scénario intéressant pour Azure IoT Edge concerne les lieux reculés, que l'on
trouve souvent dans les secteurs du pétrole et du gaz ou des transports par exemple, où
la connectivité Internet n'est parfois pas suffisamment fiable pour que toutes les
données des appareils IoT soient streamées vers Azure pour un traitement
centralisé. IoT Edge permet à ces sites reculés de continuer à fonctionner avec une
certaine autonomie, même en l'absence de connexion Internet.
Lorsque vous planifiez une infrastructure applicative impliquant des appareils IoT, posez-
vous la question de la gestion des pannes réseau et des mauvaises connexions Internet.
Si votre environnement est tributaire d'Internet, prévoyez de la redondance dans les
connexions Internet et dans l'équipement pour le routage des données. Ou envisagez
IoT Edge pour traiter localement les données quand le traitement ne peut être réalisé de
manière centralisée dans Azure.

Tester
Pour vous lancer et créer un hub IoT, procédez comme indiqué ci-après :

1 Ouvrez le portail Azure, lancez Cloud Shell et créez un groupe de ressources, par
exemple azuremolchapter20 :
az group create --name azuremolchapter20 --location eastus

2 Vous avez beaucoup utilisé la CLI Azure dans ce livre pour la simple raison que
les commandes Cloud Shell et CLI accélèrent la création et la gestion des
ressources. Comme indiqué précédemment, la CLI  Azure peut également
utiliser des modules complémentaires, appelés extensions. Ces extensions
apportent des fonctionnalités supplémentaires et se mettent souvent à jour
en dehors du cycle de publication ordinaire de la CLI Azure principale.
Azure IoT se développant rapidement et proposant régulièrement de nouvelles
fonctionnalités, les commandes principales pour interagir avec IoT  Hub
proviennent d'une extension de la CLI Azure.
Pour obtenir toutes les fonctionnalités dont vous avez besoin pour ces
exercices, installez l'extension Azure CLI IoT :
az extension add --name azure-cli-iot-ext

3 Sélectionnez Créer, puis fournissez un nom, par exemple azuremol. Pour ces
exercices, vous pouvez utiliser un hub IoT de niveau Gratuit, f1 :
az iot hub create \
--resource-group azuremolchapter20 \
--name azuremol \
--sku f1 \
--partition-count 2

REMARQUE  Vous ne pouvez créer qu'un seul hub de niveau Gratuit par

abonnement, mais ces hubs sont parfaits pour tester la communication avec les
306 Chapitre 20  Azure et l'Internet des objets

appareils et s'intégrer à d'autres services Azure. Le hub de niveau Gratuit est

actuellement limité à 8 000 messages par jour et prend en charge 500 appareils
connectés au maximum. Cela peut sembler beaucoup, mais notez qu'il suffit
qu'un même appareil envoie un message au hub IoT toutes les 12 secondes
environ pour que cette limite journalière de 8 000 messages soit dépassée !
Votre hub IoT est plutôt vide pour le moment. Il n'y a pas grand-chose que vous puissiez
faire avec sans un ou plusieurs appareils IoT connectés. Le Raspberry Pi est un appareil
couramment utilisé pour l'IoT. Il s'agit d'un mini-ordinateur peu coûteux capable de se
connecter à des réseaux Wi-Fi et d'utiliser des capteurs de température, d'humidité et de
pression standard du commerce. Vous pouvez également utiliser ce type d'appareil pour
contrôler de petits moteurs, des voyants ou encore des minuteries. Pas de panique ! Nul
besoin de vous précipiter chez le revendeur le plus proche  ; pour travailler avec un
hub IoT, vous pouvez simuler un Raspberry Pi dans votre navigateur Web !

20.3 Création d'un Raspberry Pi simulé

Les appareils IoT, très bien me direz-vous, mais il y a une barrière à l'entrée dans la
mesure où il me faut un appareil physique, non ? Absolument pas ! Il y a plusieurs
façons de simuler un appareil IoT par logiciel. Cette approche logicielle vous permet
de vous focaliser sur la création rapide de votre application avant de passer sur le
matériel physique. Notez qu'il vous faudra toujours vérifier la bonne exécution de
votre code sur le matériel IoT physique, en particulier dans le cas d'appareils basse
consommation, qui pourront ne pas avoir accès à toutes les bibliothèques, voire aux
ressources mémoire, que vous avez prévues dans votre simulation.
Microsoft fournit un simulateur Raspberry Pi gratuit via GitHub à l’adresse https://
azure-samples.github.io/raspberry-pi-web-simulator. Même si un Raspberry Pi est idéal
pour les tests, veillez à utiliser un matériel bon marché, comme le Raspberry Pi dans les
environnements de production. Planifiez la mise à jour et la gestion de ces appareils.
Les appareils IoT dédiés, tels qu’Azure Sphere (https://azure.microsoft.com/services/
azure-sphere), fournissent des options de sécurité et de gestion supplémentaires. Le
Raspberry Pi constitue une bonne option pour les exercices de ce livre et vos propres
tests. Dans ce simulateur, un capteur BME280 classique simule la collecte de relevés de
température et d'humidité dans le logiciel, et un voyant LED simulé signale quand
l'appareil transmet des données au hub IoT. Il n'y a pas beaucoup de possibilités de
personnalisation, mais ce simulateur vous permet de voir comment une application
Node.js de base peut fonctionner sur un Raspberry Pi, de récupérer les données d'un
capteur et de les transmettre à Azure.
REMARQUE  Si certaines choses telles que le Raspberry Pi, l'électronique et les
capteurs de température, ainsi que Node.js vous font un peu peur, ne vous
inquiétez pas. Comme pour l'IA et le ML, les conteneurs ou encore kubernetes,
nous n'irons pas très loin sur le sujet des appareils IoT et de la programmation.
Ceci dit, si vous vous sentez prêt à brancher un fer à souder et à bidouiller de
l'électronique d'ici la fin de ce chapitre, je vous y encourage sans réserve !
Pour pouvoir utiliser le simulateur Raspberry  Pi, vous devez au préalable créer une
affectation d'appareil dans Azure IoT Hub. Ce processus crée un ID d'appareil unique
qui permet à votre hub IoT de savoir avec quel appareil il communique et comment
traiter les données. Dans des scénarios plus complexes, vous pouvez aussi spécifier des
paramètres supplémentaires pour l'appareil et pousser des certificats numériques.
Dans le cadre de cet exercice, nous allons simplement créer une identité d'appareil.
 Création d'un Raspberry Pi simulé 307

Tester
Pour créer un appareil IoT Raspberry Pi simulé, procédez comme indiqué ci-après :

1 Dans Azure Cloud Shell, créez une identité d’appareil dans votre Hub IoT, par
exemple azuremol, et indiquez un nom pour l’appareil, par exemple
raspberrypi :
az iot hub device-identity create \
--hub-name azuremol \
--device-id raspberrypi

2 Vous vous souvenez des stratégies d'accès partagé de la section  20.2  ? Chaque
appareil IoT possède également ses propres clé d'accès et chaîne de connexion
qui sont utilisées pour l'identifier lorsqu'il communique avec le hub IoT. Cette
fonctionnalité clé d’Azure IoT sécurise les appareils et minimise le risque
d’exposition en cas de compromis.
Pour utiliser votre appareil avec le simulateur Raspberry Pi, vous avez besoin
de la chaîne de connexion de l'appareil. Cet identificateur unique se compose du
nom d'hôte de votre hub IoT, de l'ID de l'appareil et d'une clé d'accès :
az iot hub device-identity show-connection-string \
--hub-name azuremol \
--device-id raspberrypi \
--output tsv

3 Copiez le contenu de votre chaîne de connexion  ; vous en aurez besoin à

l'étape 4. La sortie est du type de celle présentée ci-dessous :
HostName=azuremol.azure-devices.net;DeviceId=raspberrypi;
➥SharedAccessKey=oXVvK40qYYI3M4u6ZLxoyR/PUKV7A7RF/JR9WcsRYSI=
4 Venons-en à présent à la partie sympa ! Ouvrez le simulateur Raspberry Pi dans
votre navigateur Web  : https://azure-samples.github.io/raspberry-pi-web-
simulator. Observez la section du code à droite dans le simulateur. Autour de la
ligne 15, vous devriez trouver une variable connectionString, qui vous invite à
spécifier la chaîne de connexion de votre appareil ([Your IoT hub device connection string]).
Copiez et collez votre chaîne de connexion de l'étape 3, comme illustré à la figure 20.3.
5 Cliquez sur le bouton Run juste en dessous de la fenêtre de code pour démarrer
le simulateur.
Toutes les deux  secondes, la fenêtre de la console affiche un message qui
indique les données envoyées au hub IoT. Simultanément, la LED rouge sur le
schéma de circuit clignote, simulant la façon dont les sorties connectées au
Raspberry Pi peuvent être contrôlées. Le message de sortie affiché dans la fenêtre
de la console est du type suivant :
Sending message: {"messageId":1,"deviceId":"Raspberry Pi Web
➥Client","temperature":24.207095037347923,
➥"humidity":69.12946775681091}
D'où proviennent ces relevés de température et d'humidité ? Cet appareil est un
Raspberry Pi simulé, et il n'y a pas de véritable capteur BME280 à l'œuvre ; l'application
génère en fait ces valeurs dans le logiciel. Si vous observez le reste du code dans la
308 Chapitre 20  Azure et l'Internet des objets

Figure 20.3  Copiez et collez la chaîne de connexion de votre appareil Azure IoT dans le simulateur
Raspberry Pi. La variable connectionString est utilisée pour la connexion pour permettre la
transmission des données du capteur simulé à Azure.

fenêtre du simulateur, l'application définit le capteur autour de la ligne 99. Le

simulateur reproduit dès lors la façon dont se comporterait le capteur réel et
génère les données renvoyées par le capteur à l'application. Il s'agit là d'un
exemple de base, mais pensez à ce que vous pourriez lire d'autre ici : le nombre
de tours par minute (tr/min) d'un moteur, par exemple, les coordonnées GPS
d'un conteneur d'expédition ou celles d'un camion, etc. C'est à ce stade
qu'apparaissent les limites de la simulation logicielle d'un appareil aux fins de la
création d'une application fonctionnelle avec du matériel physique et des
données de capteur réelles. À un certain moment, il vous faut acheter ou
emprunter du matériel si vous voulez aller plus loin avec Azure IoT.
6 Pour vérifier que les messages de votre appareil simulé sont bien reçus par le hub
IoT, examinez l'état du quota. Spécifiez le nom de votre hub IoT, ici azuremol :
az iot hub show-quota-metrics --name azuremol

La sortie est similaire à la suivante, laquelle montre que 5 messages sur un total de
8 000 messages par jour autorisés ont été reçus et qu’un périphérique sur un total
de 500 périphériques autorisés est connecté. La génération de ces métriques peut
prendre quelques minutes  ; par conséquent, ne vous inquiétez pas si vous ne
voyez aucune donnée tout de suite :
[
 {
  "currentValue": 5,
 Streaming de données Azure IoT Hub vers des applications Web Azure 309

  "maxValue": 8000,
  "name": "TotalMessages"
 },
 {
  "currentValue": 1,
  "maxValue": 500,
  "name": "TotalDeviceCount"
 }
]

Vous pouvez également consulter le portail Azure : choisissez votre groupe de

ressources, puis sélectionnez votre hub IoT. Sur la page de vue d'ensemble, les
informations sur l'utilisation du hub indiquent le nombre de messages reçus et le
nombre d'appareils connectés. Là encore, un petit délai d'une ou deux minutes
peut être nécessaire pour l'affichage des données sur les messages et leur prise en
compte dans le quota. Les messages reçus pourraient parfaitement
être immédiatement utilisés par n'importe quelle application, comme nous
allons le voir à la section 20.4.

Rififi au paradis
Si vous ne recevez aucun message dans votre hub IoT, vérifiez la fenêtre de sortie de
votre appareil Raspberry Pi simulé. L'une des premières choses que fait l'application est
de se connecter à Azure IoT Hub. Une erreur de connexion s'affiche si votre chaîne de
connexion est incorrecte. Vérifiez que vous avez correctement copié et collé l'ensemble
de la chaîne de connexion. La chaîne de connexion commence par HostName, et le
dernier caractère de toute clé d'accès est toujours un signe égal (=).
Si la fenêtre de sortie signale une erreur, copiez le texte de l'erreur dans votre
moteur de recherche favori et recherchez un résultat correspondant. Vérifiez que vous n'avez
modifié aucune des autres lignes de code, ce qui causerait un problème ! La seule chose que
vous devez modifier dans la fenêtre du code est la ligne de votre chaîne de connexion.
Étant donné que l'appareil Raspberry Pi simulé s'exécute dans un navigateur Web, il est
possible que vous rencontriez un problème de site Web générique. Essayez d'actualiser
la page ou d'accéder au simulateur dans un autre navigateur (https://azure-samples.
github.io/raspberry-pi-web-simulator).

20.4 Streaming de données Azure IoT Hub vers des applications Web Azure

Un appareil qui se connecte à un hub IoTest inutile si vous n'êtes pas en mesure
d'exploiter les données. C'est là ce moment que vous pouvez commencer à intégrer les
nombreux services et fonctionnalités découverts dans ce livre. Vous souhaitez streamer
vers des tables ou des files d'attente Azure Storage ? C'est possible. Vous voulez traiter
des données d'appareils IoT vers des machines virtuelles ou des conteneurs Azure ?
Lancez-vous ! Ou vous préférez plutôt utiliser Azure Cosmos DB pour répliquer vos
données, puis y accéder via des applications Web Azure redondantes et distribuées à
l’échelle mondiale et via Traffic Manager ? Pas de problème !
Dans l'exemple, le hub IoT représente le mécanisme de connexion et le
point d'entrée de vos appareils IoT vers Azure. Le hub en lui-même n'effectue aucune
action directe avec les données. Il existe un point de terminaison par défaut pour les
événements, qui agit en réalité comme un grand récipient pour tous les messages reçus
de l'appareil IoT. Votre appareil Raspberry Pi simulé envoie des messages au hub IoT,
qui atteignent le point de terminaison des événements. Le flux de messages circulant
des appareils vers un point de terminaison, via un hub IoT, est illustré à la figure 20.4.
310 Chapitre 20  Azure et l'Internet des objets

Messages envoyés par les

appareils IoT vers Azure IoT Hub.
Appareil IoT

Appareil IoT
Azure IoT Point de
Hub terminaison
Messages envoyés à un
Appareil IoT
point de terminaison
défini.

Figure 20.4  Un hub IoT reçoit des messages d'appareils IoT connectés et les envoie à un point de
terminaison. Ces points de terminaison peuvent être utilisés par d'autres services Azure afin d'utiliser
des données d'appareils IoT. Il existe un point de terminaison par défaut pour les événements, à partir
duquel des services, tels que des applications Web, peuvent accéder en lecture.

Vous pouvez créer des points de terminaison personnalisés qui routent directement les
messages vers des services Azure, tels que Azure Storage et Azure Service Bus. Au le
chapitre 4, nous avons étudié les files d'attente Azure Storage afin de transférer des
messages entre des applications. Azure Service Bus est une plateforme de messagerie
d'entreprise évolutive et plus performante. Les messages peuvent être ajoutés au
service bus, tels que des données reçues d'appareils IoT, et d'autres applications
peuvent ensuite se mettre à l’écoute de ces messages et agir en conséquence.
Si vous ne souhaitez pas faire face à la complexité de la lecture de messages depuis
une file d'attente de messages (telle qu'un service bus), vous pouvez utiliser des groupes
de consommateurs avec les points de terminaison des événements par défaut. Un
groupe de consommateurs permet aux services comme Azure Web Apps de lire des
données depuis le point de terminaison, comme illustré à la figure 20.5. Chaque service
qui lit depuis Azure IoT Hub devrait avoir son propre groupe de consommateurs.
Plusieurs services, chacun avec son propre groupe de consommateurs, peuvent recevoir
les mêmes messages et les traiter selon les besoins.

Messages envoyés par les appareils IoT via événements

Azure IoT Hub vers un point de terminaison
Appareil IoT msg msg
Appareil IoT
Azure IoT Point de msg msg
terminaison
Hub
Appareil IoT Groupe de Applicaons
clients Web

Un groupe de clients permet à d’autres services,

tels qu’Azure Web Apps, d’accéder aux
messages reçus par un point de terminaison.

Figure 20.5  Les messages sont envoyés par des appareils IoT au hub IoT, qui dirige ensuite les messages vers un
point de terminaison. Des groupes de consommateurs peuvent être créés dans chaque point de terminaison. Ces
groupes de consommateurs permettent à d'autres services Azure d'accéder aux messages des appareils, auxquels
ils n'auraient autrement pas accès. Avec les groupes de consommateurs, vous n'avez pas besoin d'utiliser les files
d'attente de messages pour autoriser des applications externes à lire des données d'appareils IoT.

Créons une application Web Azure qui utilise un groupe de consommateurs pour lire
les données de message en temps réel à partir de votre appareil Raspberry Pi simulé.
Cet exemple basique illustre comment diffuser des données à partir d'appareils IoT et
y accéder depuis des applications Web.
 Streaming de données Azure IoT Hub vers des applications Web Azure 311

Tester
Pour créer une application Web Azure qui lit des données d'appareils IoT, procédez
comme suit :

1 Créez un plan Azure App Service pour votre application Web dans Azure Cloud
Shell et indiquez un nom, par exemple azuremol. Pour ces exercices, le niveau
gratuit (f1) est suffisant et n'est pas trop coûteux :
az appservice plan create \
--resource-group azuremolchapter20 \
--name azuremol \
--sku f1

2 Créez votre application Web. Spécifiez un nom, ici molwebapp, et activez-le pour
l'utiliser avec Git afin de déployer l'exemple d'application. Comme avec d’autres
ressources Azure accessibles au public, vous devez fournir un nom unique au monde.
az webapp create \
--resource-group azuremolchapter20 \
--plan azuremol \
--name molwebapp \
--deployment-local-git

3 Définissez le groupe de consommateurs pour votre hub IoT, ainsi que certains
paramètres d'application Web. Ces paramètres permettent à votre application
Web de se connecter à votre hub IoT. La figure 20.6 illustre ce que vous allez
réaliser lors des prochaines étapes.

Les paramètres d’application sont

Azure Web App transmis à votre code d’application. Le
nom du groupe de clients et la chaîne
Paramètre d’application de connexion ne sont pas codés en dur
consumergroup=molwebapp dans votre application.

Point de Paramètre d’application Code d’application

terminaison iot=$iotconnectionstring
Azure IoT Hub
msg msg
WebSockets activé vrai
msg msg

Groupe de
clients Navigateur web
Les messages reçus par le point de terminaison Azure IoT Hub sont
lus par une application Web. Une connexion WebSocket est utilisée
pour pousser automatiquement les mises à jour vers les navigateurs
Web connectés.

Figure 20.6  Pour permettre à votre application Web de lire les données de votre appareil Raspberry Pi simulé,
vous devez créer un groupe de consommateurs dans le hub IoT. Vous définissez ensuite deux paramètres
d'application pour votre application Web, qui vont vous permettre de vous connecter au groupe de consommateurs.
Pour que votre navigateur Web puisse recevoir automatiquement le flux de données du Raspberry Pi au fur et à
mesure que de nouvelles données sont reçues, vous devez également activer un paramètre pour WebSockets.
312 Chapitre 20  Azure et l'Internet des objets

4 Créez un groupe de consommateurs permettant à votre application Web

d'accéder aux données d'événement streamées depuis votre appareil IoT.
Spécifiez votre hub IoT, ici azuremol, puis donnez un nom à votre groupe de
consommateurs, ici molwebapp. Veillez à utiliser votre propre nom au cours des
prochaines étapes. Votre groupe de consommateurs est créé dans le point de
terminaison des événements par défaut :
az iot hub consumer-group create \
--hub-name azuremol \
--name molwebapp

5 Vous devez indiquer à votre application Web le nom de votre groupe de

consommateurs. Créez un paramètre d'application Web App utilisé par l'exemple
d'application que vous allez déployer à la fin de l'exercice. Les paramètres
d'application dans les applications Web vous permettent de définir certains
paramètres spécifiques, tels que le nom du groupe de consommateurs et la chaîne
de connexion, sans que ces valeurs ne soient codées en dur dans votre application.
Spécifiez le nom du groupe de consommateurs créé à l'étape 4, dans notre cas
mol webapp :
az webapp config appsettings set \
--resource-group azuremolchapter20 \
--name molwebapp \
--settings consumergroup=molwebapp

6 Pour vous connecter à votre hub IoT, votre application Web doit connaître la
chaîne de connexion pour le hub. Cette chaîne de connexion est différente de
celle que vous avez copiée à l'exercice précédent pour votre appareil Raspberry Pi
simulé. Rappelez-vous qu’il existe une chaîne de connexion pour votre Hub IoT,
qui utilise des stratégies d’accès partagé pour définir les autorisations d'accès.
Chaque appareiI IoT dispose d'une chaîne de connexion . Votre application
Web doit lire à partir du point de terminaison du
groupe de consommateurs du point de terminaison du hub IoT. Vous devez
donc définir une chaîne de connexion pour le hub IoT lui-même.
7 Obtenez la chaîne de connexion du hub IoT et assignez-la à une variable
nommée iotconnectionstring, qui est utilisée à l'étape 8 :
iotconnectionstring=$(az iot hub show-connection-string \
--hub-name azuremol \
--output tsv)

8 Créez un autre paramètre d'application Web App, mais cette fois pour la chaîne
de connexion du hub IoT. La variable définie à l'étape  7 permet à l'exemple
d'application de se connecter et de lire des données de l'appareil IoT :
az webapp config appsettings set \
--resource-group azuremolchapter20 \
--name molwebapp \
--settings iot=$iotconnectionstring

9 Activez les WebSockets. Un WebSocket est un moyen de communication

bidirectionnel entre un navigateur et un serveur. L'exemple d'application met
automatiquement à jour le navigateur Web avec les données reçues de l'appareil
 Streaming de données Azure IoT Hub vers des applications Web Azure 313

Raspberry Pi. Pour effectuer cette mise à jour automatisée, l'application utilise

WebSockets. Le serveur peut ensuite transférer des données par push vers le
navigateur et déclencher sa mise à jour automatique :
az webapp config set \
--resource-group azuremolchapter20 \
--name molwebapp \
--web-sockets-enabled

Faisons une pause et discutons de ce que vous avez réalisé jusqu'à présent. Vous
avez travaillé avec des applications Web dans la plupart des chapitres précédents,
mais les paramètres d'application Web App et WebSockets sont des concepts
nouveaux. La figure 20.7 récapitule la connexion entre votre application Web et
le hub IoT.

Les paramètres d’application sont

Azure Web App transmis à votre code d’application.
Le nom du groupe de clients et la
Paramètre d’application chaîne de connexion ne sont pas
consumergroup=molwebapp codés en dur dans votre application.

Point de Paramètre d’application Code d’application

terminaison Azure iot=$iotconnectionstring
IoT Hub
msg msg
WebSockets activé vrai
msg msg

Groupe de
clients Navigateur web
Les messages reçus par le point de terminaison Azure IoT Hub sont
lus par une application Web. Une connexion WebSocket est utilisée
pour pousser automatiquement les mises à jour vers les navigateurs
Web connectés.

Figure 20.7  Lorsque des messages sont envoyés depuis des appareils IoT, ils passent par le hub IoT jusqu'à
atteindre un point de terminaison. Votre code d'application lit dans les paramètres des applications Web qui
définissent quelle chaîne de connexion du hub IoT et du groupe de consommateur utiliser. Une fois l'application
connectée au hub IoT, le groupe de consommateurs permet aux applications Web de lire les messages de l'appareil
IoT. Chaque fois qu'un nouveau message est reçu d'un appareil IoT, votre application Web utilise une connexion
WebSocket avec des navigateurs Web qui accèdent à votre site pour pousser automatiquement les mises à jour.
Cette connexion vous permet de visualiser en temps réel les données streamées depuis des appareils IoT (telles
que des informations relatives à la température et au taux d'humidité), et cela à partir de votre appareil
Raspberry Pi simulé.

Terminons à présent l'exercice en déployant l'exemple d'application à partir du

référentiel GitHub vers votre application Web. Vous pouvez alors ouvrir
l'application Web dans votre navigateur et consulter les données en temps réel,
streamées depuis votre appareil Raspberry Pi simulé !
10 Si nécessaire, clonez le référentiel d’exemples GitHub dans votre Cloud  Shell
comme suit :
git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git

11 Accédez au répertoire pour le chapitre 20 :

cd azure-mol-samples-2nd-ed/20
314 Chapitre 20  Azure et l'Internet des objets

12 Initialisez le référentiel Git et ajoutez la page Web basique :

git init && git add . && git commit -m "Pizza"

13 Pour télécharger l'exemple d'application, créez une connexion à votre

application Web. La commande suivante accède au référentiel de l'application
Web et configure vos exemples de référentiels Git locaux pour s'y connecter :
git remote add molwebapp \
$(az webapp deployment source config-local-git \
--resource-group azuremolchapter20 \
--name molwebapp \
--output tsv)

Dans les chapitres précédents, vous avez du rechercher cette adresse. Mais
j'espère qu'à présent, vous avez commencé à découvrir les fonctionnalités de la
CLI d'Azure et à réaliser que la plupart de ces informations peuvent être obtenues
rapidement.
14 Poussez l'exemple de site HTML vers votre application Web à l'aide de la
commande suivante :
git push molwebapp master

15 Lorsque vous y êtes invité, saisissez le mot de passe de l'utilisateur Git que vous
avez créé et utilisé dans les chapitres précédents (le compte créé au chapitre 3).

Si vous avez oublié de noter votre mot de passe Git sur un Post-It
Si vous avez oublié le mot de passe, vous pouvez le réinitialiser. Tout d'abord, obtenez le
nom d'utilisateur de votre compte de déploiement Git local :
az webapp deployment user show --query publishingUserName

Pour réinitialiser le mot de passe, saisissez le nom de votre compte à partir de la

commande précédente, puis répondez aux invites pour définir un nouveau mot de passe.
L'exemple suivant réinitialise le mot de passe du compte utilisateur nommé azuremol :
az webapp deployment user set --user-name azuremol

16 Affichez le nom d'hôte de votre application Web, puis accédez à l'adresse dans
un navigateur Web :
az webapp show \
--resource-group azuremolchapter20 \
--name molwebapp \
--query defaultHostName \
--output tsv

Lors de la première ouverture du site dans un navigateur, la connexion de

l'application Web à votre hub IoT peut nécessiter quelques secondes. Initialisez la
connexion WebSocket et attendez que le premier message soit reçu. Toutes les
deux secondes, le navigateur Web devrait être mis automatiquement à jour avec
les dernières données simulées depuis l'appareil Raspberry Pi, comme illustré à la
figure 20.8.
 Examen des composants Azure IoT 315

Figure 20.8  L'exemple d'application utilise une connexion WebSocket entre votre navigateur et votre
application Web, afin d'effectuer une mise à jour automatique toutes les deux secondes, en affichant les
données les plus récentes de votre appareil Raspberry Pi simulé.

Si votre instance d'application Web n'affiche aucune donnée, assurez-vous que

l'appareil Raspberry  Pi simulé est toujours en cours d'exécution. Si nécessaire,
démarrez l'appareil simulé, puis assurez-vous qu'il se connecte à Azure IoT et qu'il
envoie des messages. Les données devraient alors commencer à apparaître dans votre
instance d'application Web.

20.5 Examen des composants Azure IoT

J'espère que les exercices de ce chapitre ont pu vous donner une idée des services
disponibles dans Azure pour les solutions IoT :
¡ Azure IoT Hub permet de configurer, de connecter et de gérer tout un parc
d'appareils IoT, ainsi que de faire la liaison avec d'autres services Azure.
¡ Les accélérateurs de solutions Azure IoT fournissent des scénarios prédéfinis qui
intègrent automatiquement de nombreux services Azure différents, afin de
proposer un environnement d'application complet.
¡ Azure IoT Edge vous permet de déployer des services Azure dans votre
environnement local afin de traiter les données des appareils IoT, sans avoir
besoin de streamer toutes les données de manière centralisée vers Azure.
Si vous souhaitez aller plus loin sur Azure IoT et les appareils IoT en général, je vous
conseille de faire l'acquisition d'un Raspberry Pi basique ou de tout appareil similaire.
Ces appareils sont relativement bon marché, sont souvent livrés avec quelques capteurs
de base ou composants électriques pour tester différentes idées, et constituent une
plateforme d'expérimentation idéale pour voir ce qu'il est possible de faire en matière
d'intégration du matériel et du logiciel. Souvenez-vous seulement des avertissements
donnés au chapitre  17, concernant l'IA et le ML, ainsi que la construction Skynet  !
Manning propose également d'excellents ouvrages, tels que Building the Web of Things,
de Dominique D. Guinard et Vlad M. Trifa (https://www.manning.com/books/
building-the-web-of-things) et JavaScript on Things, de Lyza Danger Gardner (https://
www.manning.com/books/javascript-on-things), qui approfondissent les bonnes
pratiques relatives à Raspberry Pi, à l’IoT, ainsi que la programmation JavaScript et
Node.js sur les appareils IoT.

Vous souvenez-vous que j'ai déclaré que « Vous deviez toujours supprimer vos
groupes de ressources » ?
Il vous a été conseillé, tout au long de cet ouvrage, de supprimer vos groupes de
ressources à chaque fin de chapitre. Cela permet de s'assurer que vous ne continuiez
pas d'utiliser des applications et des services payants lorsque vous n'en avez pas besoin.
316 Chapitre 20  Azure et l'Internet des objets

(suite)
Azure IoT vous offre une plateforme efficace pour streamer des données vers Azure.
Vous avez généralement besoin de traiter ces données, et non pas seulement de les
afficher dans une application Web, comme vous avez pu le faire dans les exercices. Le
chapitre 21 aborde le sujet de l'informatique sans serveur avec les services Functions et
Logic Apps.
Pour montrer comment ces services Azure fonctionnent parfaitement ensemble, ne
supprimez pas le groupe de ressources et les services que vous avez déployés dans ce
chapitre. Vous commencerez à les prendre en main dès le début du chapitre 21, afin de voir
comment vous pouvez prendre des mesures selon les données reçues de vos appareils IoT.
Assurez-vous seulement de revenir sur votre appareil Raspberry Pi simulé et de cliquer sur le
bouton Stop, faute de quoi votre limite de 8  000  messages sera rapidement atteinte  !

20.6 Exercice pratique : exploration de cas d'utilisation pour l'IoT

Nous avons abordé beaucoup de nouveaux concepts dans ce chapitre, et sans un réel
appareil IoT, vous êtes limité dans vos actions. Le chapitre  21 approfondit plus en
détail Azure IoT Hub et le Raspberry Pi simulé, je ne m'y attarderai donc pas plus à ce
stade. Voici quelques questions que vous pouvez vous poser afin de réfléchir davantage
à l'IoT :

1 Dans quels domaines pensez-vous que les appareils IoT pourraient profiter
à  votre entreprise  ? Si vous ne travaillez pas au sein d'une entreprise pour
l'instant, pensez donc à la pizzeria mentionnée à maintes reprises dans cet ouvrage.
2 Que pourriez-vous faire pour améliorer l'expérience client grâce à l'IoT ?
3 Utiliseriez-vous Azure IoT Edge  ? Quelles sont les raisons qui motivent votre
réponse ?
4 Quels autres services Azure seriez-vous susceptible d'intégrer pour exécuter vos
applications ?
5 S'il vous reste un peu de temps durant votre pause déjeuner, testez donc l'un des
accélérateurs de solution Azure IoT disponibles sur www.azureiotsolutions.com/
Accelerators. Vous trouverez un scénario de Simulation d'appareil, qui crée une
machine virtuelle et des capteurs simulés. Celui-ci est similaire à l'appareil
Raspberry  Pi simulé, mais en bien plus important  ! La configuration
des ressources nécessaires prend quelques minutes, mais vous pouvez ensuite
naviguer sur le portail Azure afin de découvrir ce qui a été créé et comment
fonctionne l'ensemble.
6 Arrivez-vous à comprendre comment sont utilisés les services mentionnés dans
les chapitres précédents, tels que Azure Storage et Cosmos DB ?
7 Quels sont les autres accélérateurs de solutions IoT disponibles  ? Certains
conviennent-ils à des idées que vous pourriez avoir pour vos propres applications ?
 21
Informatique Serverless

Dans ce dernier chapitre, regardons vers l’avenir avec l’informatique Serverless,

c’est-à-dire l’informatique sans serveur. Si vous êtes développeur, l’idée de
conteneurs (que nous avons examinée au chapitre 19) peut vous avoir séduit parce
que le besoin de configurer l’infrastructure sous-jacente pour vos applications est
moindre. Si c’est le cas, vous allez adorer les composants sans serveur Azure ! Et si
vous êtes un administrateur informatique qui se demande soudainement en quoi va
consister son travail s’il n’y a plus de serveurs dans le futur, ne vous inquiétez pas !
L’informatique serverless est peut-être avant tout un terme de marketing, et nombre de
vos compétences liées aux serveurs et à l’infrastructure sont indispensables !
Dans Azure, deux offres principales proposent des fonctionnalités de calcul sans
serveur  : applications logiques Azure et applications de fonction d'Azure. Dans ce
chapitre, nous explorons ce qu'offre chaque service et la manière dont ils peuvent
travailler ensemble. Pour vous assurer que vos applications sans serveur
peuvent communiquer entre elles et transmettre des données, nous aborderons
également des services de messagerie tels qu'Azure Event Grid, Service Bus et Event Hubs.

21.1 Qu’est-ce que l’informatique Serverless ?

Dire que l’informatique sans serveur fonctionne sans serveur est tout bonnement
faux  : il y a, quelque part, un serveur qui exécute un certain code pour vous. La
différence avec les charges de travail des applications IaaS comme les machines
virtuelles d’Azur et les charges de travail dans les applications Web PaaS est que les
applications sans serveur sont généralement scindées en unités d’application discrètes
et plus petites. Vous n’exécutez pas une seule grande application : mais plutôt des
mini-composants d’application. Si cela ressemble aux conteneurs et aux microservices
dont nous avons parlé au chapitre  19, ne vous inquiétez pas, vous n’êtes pas fou  :
l’informatique serverless a beaucoup de points communs avec ces sujets dans la façon
de concevoir les applications. Vous pouvez sans doute créer des microservices à l’aide
des approches sans serveur que nous examinerons dans ce chapitre.
La figure 21.1 montre comment une application est scindée en petits composants
qui s’exécutent sur un fournisseur d’informatique serverless et constituent de petites
unités de sortie.

317
318 Chapitre 21  Informatique Serverless

Petite fonction Sortie de

d’application l’application
Fournisseur
Petite fonction Sortie de
d’application d’informatique l’application
serverless
Petite fonction Sortie de
d’application l’application

Figure 21.1  Dans un environnement d’informatique serverless, chaque application est décomposée en

petites unités discrètes de composants d’application. Chaque composant s’exécute sur un fournisseur
d’informatique serverless, tel que les applications de fonction d'Azure et la sortie produite peut ensuite
être consommée par d’autres composants d’application sans serveur ou d’autres services Azure tels
qu'Azure IoT ou Azure Storage.

Dans Azure, l’informatique serverless concerne deux services principaux :

¡ Applications logiques Azure  : pour répondre à certaines entrées et à certains
déclencheurs, les applications logiques vous permettent de créer visuellement
des workflows qui peuvent traiter et générer des actions supplémentaires grâce à
un simple pointer-cliquer, sans impliquer de code. Les applications logiques
peuvent être construites par des utilisateurs n’ayant aucune connaissance en
programmation ou en infrastructure informatique. Un schéma d’application
logique simple est illustré à la figure 21.2.

Message d’entrée

Réception du message de l’appareil IoT

Vérification du contenu du message
Extraction des données contenues
dans le message
Application de la logique au contenu
Vérification de la température
par rapport au seuil
Génération d’une action de sortie
E-mail envoyé
 igure 21.2  Dans une application
F
logique, est considérée comme une
entrée la publication d'un tweet, le
téléchargement d'un fichier ou la
réception d'un message à partir d’un
appareil IoT. L’application logique
applique des règles et des filtres aux
données et détermine si le message
répond aux critères que vous avez
définis. Les actions de sortie, telles
que la génération d’un e-mail, sont
ensuite effectuées. Toute cette logique
ne nécessite ni programmation ni
infrastructure d’application autres
qu’un abonnement Azure.

Il n’y a aucune mise à jour de sécurité à effectuer, ni aucune exigence de

conception autour de la haute disponibilité ou de la capacité d’évolution. La
plateforme Azure gère ces tâches automatiquement. Des centaines de
connecteurs prédéfinis existent pour que les applications logiques s’intègrent à
des services tels que Twitter, Office  365, SharePoint et Outlook. Vous pouvez
répondre aux tweets publics au sujet de votre entreprise ou de vos produits,
envoyer une alerte lorsqu’un fichier est téléchargé vers SharePoint, ou envoyer
une notification lorsqu’un message est reçu d’un appareil IoT.
 Plateformes de messagerie Azure 319

¡ Applications de fonction d'Azure : pour exécuter de petits blocs de code, les applications
de fonction vous permettent d’utiliser des langages de programmation courants
tels que C#, node.js et Python, sans gestion d’infrastructure supplémentaire. Votre
code s’exécute dans un environnement sécurisé et isolé, et vous êtes facturé sur la
base de la consommation de mémoire par seconde. La figure  21.3 décrit le
processus de base d’une application de fonction.

Un événement, tel qu’un message

reçu d’un appareil IoT Azure,
déclenche une application de
fonction. Applications de
fonction d’Azure
Notification Sortie de
Petite unité de code
d’événement l’exécution
C#, Node.js, Python
Une petite unité de code est
exécutée et la sortie qui peut
s’intégrer à d’autres services ou
applications est fournie.

Figure 21.3  Une notification d’événement ou un déclencheur démarre généralement une

fonction Azure, de la même façon qu'avec une application logique. L’application de fonction
contient une petite unité de code qui exécute une tâche spécifique. Il n’y a aucune infrastructure
à configurer ou à entretenir. Seul votre petit bloc de code est requis. Une fois l’exécution du code
terminée, la sortie peut être intégrée à un autre service ou à une autre application Azure.

Il n’y a pas de machine virtuelle à entretenir et aucune application Web n’est

requise. Vous n’avez pas à vous soucier de la haute disponibilité ou de l’évolutivité,
puisque le service applications de fonction d'Azure gère ces tâches pour vous.
Vous devez juste fournir votre code et la plateforme Azure s’assure que chaque
fois que vous avez besoin d’exécuter ce code, les ressources sont
disponibles pour traiter votre demande.
Les applications logiques ne nécessitent pas de code  ; elles ont donc une base
d’utilisateurs potentiels plus large. Les propriétaires d’applications commerciales ou
les équipes en charge des finances et de la comptabilité, par exemple, peuvent créer
leurs propres applications logiques sans avoir à écrire de code. Les applications de
fonction fournissent plus de contrôle et de flexibilité et vous permettent de manipuler
des événements d’une manière spécifique. Par ailleurs, elles s’intègrent mieux à
d’autres composants d’application.
Les applications logiques et de fonction vous offrent toutes deux un moyen d’effectuer
des actions basées sur des déclencheurs sans avoir à maintenir un environnement ou une
infrastructure d’application. Un serveur quelque part dans Azure exécute votre
application logique ou de fonction, mais de votre point de vue en tant qu’administrateur
informatique ou développeur, ce sont des technologies sans serveur.

21.2 Plateformes de messagerie Azure

Au chapitre 12, nous avons observé comment superviser et dépanner les ressources
Azure, et au chapitre 16, nous avons vu comment utiliser Azure Security Center pour
détecter les problèmes et gérer des mises à jour. Ces deux fonctionnalités s’appuient
sur des flux de données, comme l’extension Azure VM Diagnostics, pour informer la
plateforme de ce qui se passe dans la machine virtuelle. Les plateformes de diagnostic
et de surveillance Azure sont excellentes et d’autres services tels que Web  Apps,
Azure  Container  Instances et Azure  IoT  Hub peuvent également diffuser des
diagnostics de service à des fins d’analyse centralisée.
320 Chapitre 21  Informatique Serverless

Avec les applications sans serveur, vous avez souvent besoin d’un moyen d’échanger
des messages et de transmettre des données d’application à jour, pas seulement les
diagnostics de panne ou les mises à jour de statut. C’est à cet égard que vous avez besoin
d’une plateforme de messagerie.

21.2.1 Azure Event Grid

Que faire si vous voulez simplement générer un rapport sur certaines actions ou
activités en cours d’achèvement ? Dans les workflows d’automatisation et l’informatique
serverless, la possibilité d’effectuer une action en réponse à un événement est utile,
comme illustré à la figure 21.4.

Lorsque des services ou des actions de

ressources sont exécutés, les notifications
peuvent être envoyées à Azure Event Grid.

Azure IoT Azure Functions

Blobs d’Azure Azure Event

Azure Automation
Storage Grid
Groupes de
ressources Webhooks

Les services Azure ou les fournisseurs

externes peuvent être configurés
pour répondre à ces événements.

Figure 21.4  Les services Azure comme Azure IoT et Azure Storage peuvent envoyer des notifications
à Azure Event Grid. Ces notifications peuvent se produire lorsqu’un message est reçu d’un appareil IoT
ou qu’un fichier est téléchargé dans le stockage. Azure Event Grid permet à d’autres services et
fournisseurs de s’abonner à ces notifications pour effectuer des actions supplémentaires en réponse
à des événements.

Examinons quelques scénarios que vous pourrez peut-être utiliser dans votre pizzéria :
¡ Message reçu dans un hub IoT  : un appareil IoT raccordé au hub IoT peut
signaler une mesure de température dans un four ou la position d’un véhicule de
livraison. Le hub IoT est configuré pour transférer une notification à
Azure Event Grid.
Une fonction Azure est abonnée aux notifications d’Event  Grid pour le
hub IoT et exécute un petit composant d’application sans serveur pour
enregistrer les informations dans Azure Cosmos DB et envoyer une notification
par e-mail. Vous pouvez également utiliser des applications logiques au lieu des
applications de fonction d’Azure, selon le niveau de complexité attendue de la
réponse de l’application.
¡ Fichier téléchargé vers le stockage Azure : le service marketing peut télécharger dans le
stockage un coupon promotionnel pour économiser de l’argent sur une
commande de pizza. Lorsqu’un nouveau fichier est créé, une notification est
envoyée à Event Grid.
Un webhook est abonné à Event Grid et publie une copie de l’image depuis le
stockage vers Twitter. Ce tweet informe le client sur l’affaire de la semaine ou le
coupon de remise.
 Plateformes de messagerie Azure 321

Ces scénarios valent pour des scénarios informatiques serverless vraiment non-
interventionnistes, mais Event  Grid peut également s’intégrer à des ressources plus
traditionnelles telles que les machines virtuelles et les applications Web. Par exemple,
un groupe de ressources peut être configuré pour envoyer des notifications à
Event Grid. Il existe de nombreuses façons de créer une machine virtuelle, comme sur
le portail, avec la CLI Azure, ou avec un modèle Ressource Manager, de sorte que vous
devez vous assurer que la machine virtuelle est correctement configurée pour la gestion
des mises à jour via le Security Center. Une procédure opérationnelle Azure Automation
peut être abonnée à Event Grid pour les notifications concernant les opérations de
création de machines virtuelles, puis embarquer la machine virtuelle dans le service de
gestion des mises à jour et installer les mises à jour de sécurité ou d’application requises.

21.2.2 Azure Event Hubs et Service Bus

Event Grid peut fonctionner avec de nombreuses ressources Azure et est bien adaptée
à l’informatique serverless avec des applications logiques ou des applications de
fonction. Mais les applications logiques et les applications de fonction peuvent être
exécutées en fonction d’autres entrées de données, telles que les hubs d’événements
ou les services bus. Examinons les différences entre ces divers services de messagerie
afin que vous puissiez mieux décider quand les utiliser :
¡ Azure Event Hub vous permet de recevoir un flux de données, tels que ceux émis par
des appareils IoT ou la télémétrie d’application. Les hubs d’événements fournissent
une plateforme de messagerie à faible latence capable de gérer des millions
d’événements par seconde à partir de nombreux fournisseurs simultanés. Les hubs
d’événements sont une banque de données plutôt qu’une file d’attente de
messages, et le client ou l’application vérifie les événements dans le hub, quelle que
soit la fréquence souhaitée. Ensuite les données reçues dans le hub d’événements
peuvent être traitées par d’autres servicess, comme illustré à la figure 21.5.
¡ Azure Service Bus permet aux composants d’application d’échanger des données
de message, telles que les files d’attente de stockage que nous avons étudiées au
chapitre 4. Les files d’attente de stockage sont une implémentation plus ancienne
et plus basique d’une plateforme de messagerie dans Azure. Un service bus

Plusieurs appareils IoT se

connectent à Azure IoT Hub et aux
données du capteur de débit.
Appareil IoT

Azure IoT Azure Event Azure

Appareil IoT
Hub Hubs
Appareil IoT
Les données sont transmises en
continu à Azure Event hubs, qui
peut gérer de nombreux
événements et flux de données
volumineux simultanés.
HDInsight
Les flux de données Event hubs
peuvent être traités par des
services de calcul Big Data tels que
HDInsight et des infrastructures tels
que Hadoop et Spark.

Figure 21.5  Les appareils IoT se connectent au hub IoT et peuvent diffuser toutes leurs données issues de
capteurs. Il pourrait y avoir des centaines ou des milliers de d’appareils l’IoT connectés. Azure Event Hub gère tous
ces flux de données distincts et permet aux services tels qu’Azure HDInsight de traiter les données brutes dans
des clusters Hadoop ou Spark pour faire des analyses et générer des rapports.
322 Chapitre 21  Informatique Serverless

fournit des fonctionnalités plus avancées, comme la garantie de l’ordre des

messages, les opérations atomiques et l’envoi de messages par lots. La figure 21.6
décrit un scénario standard pour un service bus.

Application Application Application

front-end middleware back-end

Le composant Le message est

d’application place les récupéré à partir de la
données de message file d’attente de Service
sur la file d’attente de Le message est disponible pour les
Bus et traité par un
Service Bus. autres composants d’application
autre composant
connectés.
d’application.

Msg Msg
Azure Service Bus

Figure 21.6  Les messages sont placés dans une file d’attente de service bus par des composants
d’application, en l'occurrence une application front-end dans cet exemple. D’autres applications
middleware ou back-end peuvent récupérer ces messages et les traiter au besoin. Ici, une application
back-end récupère le message et le traite. Les fonctions de messagerie avancées incluent la garantie de
l’ordre des messages dans la file d’attente, le verrouillage des messages, les temporisations et les relais.

Avec trois services qui vous permettent de transmettre, recevoir et traiter les données
entre les applications et les services dans Azure, lequel devez-vous utiliser et quand ? Le
tableau  21.1 fournit un bref récapitulatif des services proposés par Event  Grid,
Event Hubs et Service Bus.

Tableau 21.1  Chaque service est conçu pour recouvrir un scénario différent. Event Grid vous permet
de réagir aux événements, Event  Hubs vous permet de diffuser de grandes quantités de données et
Service Bus vous permet de transmettre des messages entre les services et les composants d’application.

Service Azure Foncon Cas d’ulisaon

Event Grid Distribuon des Effectuer une acon supplémentaire en foncon de la

événements survenance d’un événement.

Event Hubs Flux de données Recevoir et transmere de gros volumes de données simultanées.

Service Bus Transmission de messages Assurer une communicaon entre les services et les applicaons.

Les applications logiques et les applications de la fonction Azure peuvent être

déclenchées par les trois plateformes de messagerie. Créons un service bus qui peut
être utilisé pour déclencher une application logique.

21.2.3 Création d’un service bus et intégration de ce service bus à un hub d’IoT
Dans ce scénario, vous utilisez un service bus pour transmettre des messages reçus d’un
hub IoT. Votre appareil simulé Raspberry Pi du chapitre  20 génère des mesures de
température et les transmet au hub IoT. Si la température est supérieure à 30 °C, une
 Plateformes de messagerie Azure 323

autre donnée est incluse dans le message émis par l’appareil IoT : temperature-Alert
= true. La figure 21.7 décrit comment vous pouvez intégrer un hub IoT à un service
bus pour traiter les messages contenant cette alerte de température.

Azure IoT Hub Azure Logic Apps

L’appareil IoT envoie

des données avec une
alerte de température ;
le message est placé
sur la file d’attente de
Service Bus.
Le message est récupéré
à partir de la file
Le message est disponible pour les d’attente de Service Bus
autres composants d’application et déclenche
connectés. l’application logique.

Msg Msg
Azure Service Bus

Figure 21.7  Lorsque votre appareil IoT Raspberry Pi simulé envoie des données de message, une
mesure de température supérieure ou égale à 30 °C génère une alerte. Les messages marqués avec
cette alerte sont placés sur un service bus. Ces messages peuvent ensuite être utilisés pour déclencher
des applications logiques.

Tester
Pour créer un service bus, procédez comme suit :

1 Ouvrez le portail Azure et sélectionnez Créer une ressource, en haut à gauche

du menu.
2 Recherchez et sélectionnez Service Bus, puis choisissez Créer.
3 Fournissez un nom, azuremol par exemple, puis sélectionnez le niveau tarifaire
de base.
4 Créez un groupe de ressources, puis saisissez un nom tel que azuremol-
chapter21. Assurez-vous que l’emplacement est le même que pour les ressources
créées au chapitre 20, par exemple Est des États-Unis. L’interaction entre une
file d’attente de services bus, une application logique et une application de
fonction peut créer des problèmes si vous n’êtes pas cohérent dans
vos emplacements.
5 Acceptez les autres valeurs par défaut et choisissez de créer le service bus.
6 Une fois la ressource créée, sélectionnez votre groupe de ressources, puis
choisissez le service bus que vous avez créé à l’étape 5.
7 Sélectionnez File d’attente, ajoutez une nouvelle file d'attente, puis entrez un
nom, par exemple azuremol.
8 Conservez toutes les autres valeurs par défaut et choisissez Créer.
Maintenant que vous avez créé un service bus et une file d’attente, comment pouvez-
vous configurer un hub IoT pour les utiliser ? Dans le hub IoT, vous définissez des points
de terminaison comme destinations pour les messages reçus des périphériques de l’IoT.
Un point de terminaison par défaut existe dans le hub IoT pour tous les messages qui
ne correspondent pas aux critères définis. Vous pouvez configurer le service bus en
tant que point de terminaison pour recevoir des messages. Un itinéraire qui inclut les
324 Chapitre 21  Informatique Serverless

critères selon lesquels les messages doivent être dirigés vers un point de terminaison
est alors défini. Dans l'exemple, cet itinéraire impose que tout message contenant
temperatureAlert = true dans le corps du message soit acheminé vers le point de
terminaison du service bus, comme illustré à la figure 21.8.

Un appareil IoT envoie un

message indiquant qu’un
averssement de température Hub IoT
a été généré.
Inéraire Service
Appareil IoT
bus
Msg
temperatureAlert = true Point de
terminaison Le service bus est configuré en
tant que point de terminaison
Le Hub IoT achemine les messages recevant des messages avec
vers un point de terminaison une alerte de température.
spécifique si un critère, tel qu’une
alerte de température, est remplit.

Figure 21.8  Au fur et à mesure que les messages sont transmis des appareils IoT à un hub IoT, ils
peuvent être acheminés vers des points de terminaison spécifiques en fonction des critères que vous
définissez. Les messages qui contiennent une alerte de température dans le corps du message peuvent
être acheminés vers un point de terminaison qui utilise la file d’attente de service bus. Les messages
placés dans la file d’attente de service bus et contenant une alerte de température peuvent ensuite être
utilisés pour déclencher, entre autres, des applications logiques ou des applications de fonction d’Azure.

Tester
Pour configurer un hub IoT afin d’acheminer les messages d’alerte de température vers
le service bus, procédez comme suit :

1 Sélectionnez votre groupe de ressources du chapitre 20, azuremolchapter20 par

exemple, puis choisissez le hub IoT.
2 Sous Messagerie dans la barre de navigation à gauche, sélectionnez Routage des
messages, et choisissez d’ajouter un point de terminaison personnalisé pour une
file d’attente de service bus.
3 Spécifiez un nom de point de terminaison, ici azuremol.
4 Sélectionnez votre espace de nom de file d’attente service bus, par exemple
azuremol, puis votre file d’attente réelle.
5 Pour diriger des messages vers ce point de terminaison, créez un itinéraire. Dans
le message Routage des messages dans la barre de navigation de gauche,
sélectionnez Itinéraires et choisissez d’ajouter un nouvel itinéraire.
6 Fournissez un nom, par exemple temperatureAlert.
7 Choisissez le point de terminaison de service bus que vous avez créé lors de
l’étape précédente, par exemple azuremol.
8 Pour la requête de routage, saisissez les éléments suivants :
temperatureAlert = "true"

9 Lorsque vous êtes prêt, enregistrez l'itinéraire.

 Création d’une application logique Azure 325

Vous disposez maintenant d’un appareil simulé Raspberry Pi qui envoie des données
au hub IoT et d’un itinéraire pour placer des messages contenant une alerte de
température dans une file d’attente de messages de service bus. Vous n’avez pas encore
vraiment d’application : vous ne pouvez rien faire avec les données de la file d’attente
de service bus. Que voulez-vous faire d’une alerte de température  ? L’envoi d’une
notification par e-mail est un exemple courant, nous allons donc voir comment vous
pouvez déclencher une application logique chaque fois qu’un message est placé dans
la file d’attente Service Bus.

21.3 Création d’une application logique Azure

Comme vous l’avez vu, lorsque nous avons discuté des applications logiques à la
section 21.1, un message reçu à partir d’une file d’attente de service bus peut être utilisé
comme déclencheur pour démarrer le processus d’exécution. Vous utilisez le hub IoT
pour traiter les messages reçus des appareils  IoT et acheminer vers les points de
terminaison des files d’attente de service bus, uniquement les messages contenant
temperatureAlert = true dans le corps du message. Avec cette approche, votre
application logique s’exécute uniquement lorsqu’une alerte de température est générée.
La figure 21.9 décrit ce que fait votre application logique. Lorsqu’un message est
placé dans la file d’attente des services bus, l’application logique s’exécute et envoie
une alerte par e-mail.

Le Hub IoT achemine les

messages vers le point de
terminaison du service bus.
Files d’aente de
service bus Applicaon logique
Hub IoT
Msg Connecteur de Boîte de récepon
messagerie
électronique

Chaque message de la file Un e-mail est envoyé via un

d’aente de service bus connecteur de fournisseur de
déclenche l’applicaon logique. messagerie qui vous avert que
l’appareil IoT a renvoyé une
température élevée.

Figure 21.9  Chaque message reçu dans la file d’attente des services bus du Hub IoT déclenche
l’application logique. Lorsque l’application logique s’exécute, elle envoie une notification par e-mail par
l’intermédiaire d’un fournisseur de messagerie défini.

Tester
Pour créer une application logique, procédez comme suit :

1 Sur le portail Azure, sélectionnez Créer une ressource, en haut à gauche du menu.
2 Recherchez et sélectionnez Logic App, puis choisissez Créer.
3 Fournissez un nom, par exemple azuremol et sélectionnez votre groupe de
ressources, par exemple azuremolchapter21. Encore une fois, choisissez
l'emplacement utilisé par vos autres ressources au chapitre 20.
4 Acceptez les autres valeurs par défaut et choisissez Créer.
5 Une fois la ressource créée, sélectionnez votre groupe de ressources, puis
ouvrez l’application logique. Sélectionnez « Quand un message est reçu dans la
file d’attente Service Bus » pour l'option « Ajouter des déclencheurs courants ».
326 Chapitre 21  Informatique Serverless

6 Fournissez un nom, par exemple azuremol et sélectionnez votre file d’attente de

service bus, par exemple azuremol.
7 Choisissez la stratégie de service bus par défaut, telle que
RootManageSharedAccess-Key, et créez la connexion.
8 Sélectionnez Continuer, puis choisissez votre nom de file d’attente de service
bus, par exemple azuremol.
9 Acceptez les valeurs par défaut, telles que la fréquence pour vérifier les messages.
10 Choisissez d’ajouter une nouvelle étape à l’application logique.
11 Pour ajouter une action, recherchez ce que vous souhaitez effectuer. Dans cet
exercice, recherchez e-mail. Sélectionnez votre fournisseur, par exemple Gmail -
Envoyer un e-mail, Outlook.com - Envoyer un e-mail, ou SMTP - Envoyer un
e-mail, comme illustré à la figure 21.10.

Figure 21.10  Recherchez et sélectionnez votre fournisseur de messagerie actuel, tel

que Gmail ou Outlook.com. Vous pouvez également choisir SMTP - Envoyer un e-mail
pour configurer manuellement un autre fournisseur.

12 Connectez-vous à votre fournisseur de messagerie pour autoriser le routage de

courrier, puis confirmez que vous souhaitez autoriser les applications logiques à
envoyer des e-mails.
 Création d’une application logique Azure 327

13 Fournissez l’adresse e-mail du destinataire à laquelle vous recevrez un e-mail ; un

sujet d’e-mail, Alerte de température par exemple ; et un corps de message, du
type Température élevée détectée par l’appareil IoT.
14 Enregistrez l’application logique.
Arrêtons-nous un instant et examinons ce que vous avez construit dans les derniers
exercices, comme illustré à la figure 21.11. Cette conception d’application sans serveur
basique n’inclut aucun contrôle limitant le nombre de messages à envoyer. Dans
l’application logique, vous pouvez définir que vous voulez seulement envoyer un
maximum de cinq alertes e-mail, puis attendre 30  minutes avant d’en envoyer
plus. Dans le cadre de votre conception d’application, vous devriez réfléchir à la façon
dont vous voulez être informé des situations comme celles-ci. Vous pouvez également
configurer l’application logique pour qu’elle lise dans les données de message à partir
de la file d’attente de service bus et qu’elle inclut l’horodatage du message de l’appareil
IoT et la température réelle enregistrée. Nous verrons comment le faire dans le
prochain exercice.

3. Le message de la file
d’attente de service bus
1. Envoi du message déclenche l’exécution de
Hub IoT
de l’appareil IoT l’application logique.
Application
Itinéraire Service bus logique
Raspberry
pi simulé Connecteur
Msg
de messagerie
Msg électronique
Point de
temperatureAlert = true
terminaison
4. L’application logique
envoie une notification
Adresse de
2. Le Hub IoT achemine le par e-mail concernant messagerie
message vers un point de l’alerte de température.
terminaison du service bus.

Figure 21.11  Le Raspberry Pi simulé envoie, toutes les deux secondes, un message au hub IoT, qui
contient les mesures de température effectuées par la sonde. Si la température est supérieure à 30 °C,
une alerte de température est constatée. Le hub IoT achemine tous les messages contenant une alerte
de température vers une file d’attente de service bus. Les messages dans cette file d’attente
déclenchent l’exécution d’une application logique Azure. L’application logique est connectée à un
fournisseur de messagerie, comme Outlook ou Gmail, et envoie une notification par e-mail concernant
l’avertissement de température émis par l’appareil IoT.

Voyons cette application sans serveur basique en action.

Tester
Pour exécuter votre Raspberry Pi simulé et tester votre application logique, procédez
comme suit :

1 Dans un navigateur Web, ouvrez votre appareil IoT Raspberry Pi simulé du

chapitre 20 (https://azure-samples.github.io/raspberry-pi-web-simulator).
2 Vérifiez que la chaîne de connexion de votre hub IoT est toujours inscrite dans la
fenêtre de code que vous avez configurée au chapitre 20.
328 Chapitre 21  Informatique Serverless

3 Choisissez d'exécuter l’application.

Des simulations de mesures de capteurs de température et d’humidité sont
générées toutes les deux secondes, et un message est envoyé au hub IoT. Cela
peut prendre quelques messages avant qu’une mesure simulée de température
de 30 °c soit générée et affichée dans la fenêtre Sortie.
Le hub IoT achemine tous les messages contenant temperatureAlert: true
vers le point de terminaison de service bus. Lorsque ces messages sont placés dans
la file d’attente de service bus, l’application logique les récupère et envoie un
e-mail via le fournisseur défini. Vous recevez alors un e-mail pour vous aviser
d’une mesure de température élevée. Ce processus ne devrait prendre que
quelques secondes en tout.
4 Le Raspberry Pi simulé génère des messages toutes les deux  secondes, alors
arrêtez l’application à moins que vous n’aimiez recevoir beaucoup d’alertes e-mail !
Le message des alertes que vous recevez par e-mail ne contient pas beaucoup
d’informations. Votre application logique n’extrait pas le contenu du message du
service bus et formate les informations. Ça serait génial si l’e-mail d’alerte pouvait
inclure le nom de l’appareil d’IoT ou la température enregistrée. Comment pouvez-
vous traiter chaque message et effectuer des analyses le concernant ? Qu’en est-il de
l’autre composant sans serveur Azure dont nous avons parlé  : les applications de
fonction Azure ?

21.4 Création d’une application de fonction Azure pour

analyser les données de l’appareil IoT
Pour étendre votre application sans serveur actuelle, vous pouvez déclencher une
application de fonction Azure à partir de votre application logique. Les données de
message du service bus peuvent être envoyées à une application de fonction pour
analyser la température enregistrée. La notification par e-mail envoyée par l’application
logique peut ensuite inclure des informations sur le nom de l’appareil IoT et la
température enregistrée. L’interaction entre l’application logique et l’application de
fonction est illustrée à la figure 21.12.

1. L’application logique déclenche

l’application de fonction et
transmet le message de la file Fonction Web
d’attente de service bus.
Application logique Reçoit un message Analyse les
Msg du service bus
données Extrait la mesure de
température La retourne à
2. L’application de fonction l’application logique
exécute le code pour analyser
le message, extraire les
données et renvoyer la valeur
à l’application logique

Figure 21.12  L’application logique déclenche l’application de fonction. Le message reçu dans la file
d’attente de service bus est transmis dans la fonction. Le code dans l’application de fonction analyse
le message, extrait la température et retourne cette valeur à l’application logique. Il faut quelques
millisecondes à l’application de fonction pour exécuter ce code, ainsi le coût pour exécuter ces
tâches de calcul est de l’ordre de quelques fractions de centimes.
 Création d’une application de fonction Azure pour analyser les données de l’appareil IoT 329

Tester
Pour créer une application de fonction et la déclencher à partir de l’application logique,
procédez comme suit :

1 Sur le portail Azure, sélectionnez Créer une ressource, en haut à gauche du menu.
2 Recherchez et sélectionnez Function App, puis choisissez Créer.
3 Sélectionnez votre groupe de ressources, par exemple azuremolchapter21 et
fournissez un nom, comme azuremol. Vous devez sélectionner la même région
que celle de vos ressources précédentes.
Vous devez publier du code, mais notez que vous pouvez également publier
une image de conteneur Docker (chapitre 19). Vous n’avez même pas besoin de
créer une instance de conteneur, ni d'infrastructure supplémentaire  ; un
conteneur éphémère s’exécuterait selon les besoins, avant de s'arrêter.
4 Pour cette application de base, choisissez un runtime Node.js, étant donné que
nous utilisons simplement JavaScript.
5 Vous disposez de trois options de plan d’hébergement. Un Modèle de consommation
vous permet de payer en fonction de l'exécution et les ressources dont vous avez
besoin sont affectées dynamiquement au moment de l’exécution. Pour des
applications plus cohérentes et prêtes à la production, vous pouvez utiliser un
plan Premium ou un plan d'hébergement dédié qui propose un coût fixe et plus
prévisible. Les plans Premium fournissent des fonctions supplémentaires, telles
que la sécurisation de la connectivité sur un ensemble défini de réseaux virtuels
Azure et une instance toujours prête pour prévenir certains retards dans un
scénario de démarrage à froid de votre application. Pour cet exercice, choisissez
un plan de consommation.
6 Acceptez les autres valeurs par défaut pour créer un compte de stockage nommé
et Application Insights, puis choisissez Examiner + créer.
7 Lorsque vous êtes prêt, créez l’application de fonction. La création de
l’application de fonction nécessite quelques minutes.
8 Une fois la ressource créée, sélectionnez votre groupe de ressources, puis ouvrez
votre application logique créée lors de l'exercice précédent, puis sélectionnez
Modifier.
9 Dans le Concepteur d'applications logiques, choisissez d’ajouter une
nouvelle étape.
10 Recherchez et sélectionnez Azure Functions, puis choisissez la fonction créée au
cours des étapes précédentes, par exemple azuremol, et sélectionnez Créer une
nouvelle fonction.
11 Fournissez un nom de fonction, par exemple analyzeTemperature.
12 Supprimez tout code existant, remplacez-le par le code des extraits suivants,
puis sélectionnez Créer.
Ce code est également disponible dans le référentiel GitHub à l’adresse w.
 330 Chapitre 21  Informatique Serverless

Liste 21.1  analyzeTemperature code JavaScript pour application de fonction

Crée la fonction. Chaque application de fonction en
JavaScript commence par exporter une fonction qui
contient un objet représentant le contexte. Cet objet Lit le contenu du message
à partir du service bus Crée un objet JSON
de contexte est utilisé pour faire circuler des données. de messages de
service bus décodés
module.exports = function (context, req) {
  var buffer = new Buffer(req.body.ContentData, 'base64')
  var decodedString = buffer.toString(); Extrait la température
Décode à enregistrée à partir
  var objects = JSON.parse(decodedString);
partir de de l’appareil IoT
base64   var temperature = objects["temperature"];
  context.res = {
Affiche la    body: {
température      analysis: "Recorded temperature was " + temperature + "!" Génère une
dans le    } réponse à renvoyer
journal de la   }; à l’application
console   context.log("Recorded temperature was " + temperature); logique
  context.done(); Met fin à la fonction. Chaque application de
}; fonction JavaScript doit se terminer par un
appel à context.done, qui indique à l’application
de fonction que votre code est terminé.

13 De retour dans le concepteur d’application logique pour votre étape de fonction,

sélectionnez la zone de texte Corps de la demande, puis choisissez Message
Service Bus dans la liste de contenu dynamique à droite.
14 Dans le concepteur d’application logique, réorganisez les étapes par glisser-
déposer afin que l’action Envoyer un e-mail se trouve en dessous de l’étape
analyzeTemperature de l’application de fonction, comme illustré à la figure 21.13.
15 Sélectionnez l’action Envoyer un e-mail, puis choisissez la zone de texte pour le
Corps du message électronique.

Figure 21.13  Faites glisser l’action Envoyer un e-mail sous la fonction analyzeTemperature.

Sélectionnez la fin du Corps du message et la boîte de dialogue Contenu dynamique s’affiche. Pour
insérer la valeur de température calculée par l’application de fonction, sélectionnez le Corps du message
à partir de la fonction analyzeTemperature.
 Création d’une application de fonction Azure pour analyser les données de l’appareil IoT 331

16 À partir de la fonction analyzeTemperature, sélectionnez le Corps de la réponse,

comme illustré à la figure 21.13.
17 Dans le concepteur d’application logique, sélectionnez Enregistrer.
Votre application sans serveur comporte beaucoup d’éléments mobiles.
Examinons ce que vous avez construit avant d’exécuter l’appareil IoT Raspberry Pi
simulé pour générer des alertes e-mail qui incluent la mesure de la température
calculée par l’application de fonction. La figure 21.14 fournit une vue d’ensemble
de tous les composants maintenant utilisés dans l’application sans serveur.

4. L’application de fonction traite

les données dans le message du
service bus, extrait et retourne
la valeur de température à Application
l’application logique. de fonction

Application Code JavaScript

1. Envoi du message de Hub IoT logique
l’appareil IoT Déclencheur
d’application
Itinéraire de fonction
Raspberry pi
simulé Connecteur Adresse de
de messagerie
électronique messagerie
Msg
Point de
temperatureAlert = true
terminaison 5. L’application logique envoie une
notification par e-mail concernant
l’alerte de température.
2. Le Hub IoT achemine le message vers 3. Le message de la file d’attente de
un point de terminaison du service bus. service bus déclenche l’exécution
de l’application logique.
Service bus
Msg

Figure 21.14  Lorsque des messages sont reçus du Raspberry Pi simulé, tous les messages contenant une alerte de
température sont acheminés vers le point de terminaison de la file d’attente de service bus. Les messages de la file
d’attente de service bus déclenchent une application logique qui transmet le message à une application de fonction.
Une fonction JavaScript analyse la mesure de la température et la renvoie à l’application logique, qui envoie ensuite
une notification par e-mail comportant la température enregistrée par un capteur sur l’appareil de l’IoT.

18 Ouvrez votre appareil IoT Raspberry  Pi simulé dans un navigateur Web et

exécutez l’application. Chaque fois que l'alerte de température est générée,
l’application logique déclenche l’application de fonction pour extraire les
données de température du corps du message et les inclure dans la notification
par e-mail. Quelques instants peuvent être nécessaires avant d’avoir une mesure
de température supérieure à 30  °C qui référencie alors le message avec une
alerte de température. Lorsque cette alerte est envoyée et que le message est
traité, vous recevez une notification par e-mail qui rend compte de la température
consignée.
Prenez une grande respiration et félicitez-vous  ! C’était une pause déjeuner bien
remplie !
332 Chapitre 21  Informatique Serverless

Erreurs d’authentification de votre application logique à l’application de

fonction
Vous pouvez voir l’historique des exécutions dans la fenêtre de vue d’ensemble de votre
application logique dans le portail Azure. Si vous recevez beaucoup d’erreurs
récurrentes, sélectionnez l’une des erreurs pour en savoir plus sur la cause de l'échec.
Cela peut être dû au problème courant selon lequel l’application logique n’est pas
automatiquement autorisée à interagir avec l'application de fonction. Le redéploiement
de l’application logique corrige généralement cette erreur, mais la résolution réelle
consiste probablement à ajouter ce que l’on appelle la clé de fonction à l’en-tête de votre
application logique.
Pour obtenir cette clé, sélectionnez votre application de fonction, puis choisissez la
fonction que vous avez créée, par exemple analyzeTemperature. Dans l’option gérer,
la touche de fonction par défaut peut être affichée et copiée. Copiez cette clé, retournez
à votre application logique et ouvrez le concepteur.
Dans la fonction analyzeTemperature, choisissez d’ajouter un paramètre, puis
d’ajouter un en-tête. Vous devez envoyer quelques informations au début de l’appel
à l'application de fonction qui envoie la clé. Le processus est un petit retour en arrière
lorsque vous entrez la paire de clés. Entrez x-functions-key pour la clé, puis collez
votre clé de fonction réelle en tant que valeur.
La mise à jour de l'intégration de l'application logique/application de fonction nécessite
quelques minutes. Après cela, l'storique des exécutions de l’application logique doit
indiquer les événements qui fonctionnent correctement, avant que les
notifications par e-mais ne soient envoyées.

21.5 N’arrêtez pas d’apprendre

Ce chapitre contenait beaucoup de nouveaux concepts. En fait, les derniers chapitres
étaient truffés de nouvelles idées et technologies ! Ne vous inquiétez pas si vous avez du
mal à réaliser comment vous pouvez commencer à mettre en œuvre tous ces services
Azure, tels que les conteneurs, l’IA et le ML, ainsi que l’informatique serverless. Ces
chapitres sont là pour vous montrer d’une part ce qu’il est possible de faire
dans Azure et, d’autre part, que vous n’avez pas besoin de vous contenter de répliquer
des applications dont vous avez hérité. Lorsque vous commencez à créer et à exécuter
des applications dans Azure, profitez de l’occasion pour moderniser les applications et
revoir les workflows de gestion ou de déploiement. De nombreux services Azure
simplifient et accélèrent le cycle de vie de l’application. Ne vous sentez donc pas obligé
de vous en tenir à l’exécution de machines virtuelles, simplement parce que
l’entreprise les utilise sans difficulté.
Oui, Azure offre beaucoup de nouveaux services brillants, mais ils reposent tous en
grande partie sur les composants de l’infrastructure de base qui ont été abordés dans la
partie 1 de cet ouvrage. Les développeurs peuvent commencer à utiliser les dernières
approches de conception d’application qui impliquent Kubernetes ou l’informatique
serverless, tandis que les administrateurs peuvent réutiliser leurs connaissances des
datacenters sur site sur les bases du cloud computing et dans les techniques de
dépannage. Azure peut soutenir les besoins de votre entreprise à mesure qu'ils évoluent.
Au chapitre 1, j’étais ouvert et honnête en déclarant que je ne couvrirais pas tous les
services d'Azure. Il y a beaucoup plus de services Azure à découvrir et plus de détails à
creuser dans les services que nous avons abordés dans le livre. J’espère que vous avez trouvé
au moins quelques domaines qui vous intéressent et qui vous motivent à aller encore plus
loin. Les VMSS, Cosmos DB et Azure Kubernetes Service font partie de mes favoris.
 N’arrêtez pas d’apprendre 333

21.5.1 Matériel didactique supplémentaire

Je suis partial, mais le site https://docs.microsoft.com/azure est l’endroit idéal pour
continuer à approfondir vos connaissances sur Azure. Cette page Web contient toute la
documentation de base sur les services Azure, des guides d’architecture, des ressources
de référence et le kit de développement logiciel (SDK), ainsi que des exemples. Chaque
service Azure possède son propre ensemble de ressources (guide de démarrage rapide,
tutoriels et exemples, informations conceptuelles et guides pratiques différenciés).
Si vous prenez les choses plus au sérieux, explorez les options de certification pour
Azure. Les examens individuels incluent Microsoft azure Administrator (AZ-104), Microsoft
Azure Architect Technologies and Design (AZ-303 and AZ-304) et Microsoft Azure Security Technologies
(AZ-500). Ce livre et les exercices pratiques que vous avez complétés ont couvert un grand
nombre de domaines testés au cours de ces examens. Vous devrez néanmoins étudier
d’autres domaines d’Azure AD et les bonnes pratiques en matière de conception avant de
pouvoir passer les examens. Le site Microsoft Learn à l'adresse https://docs.microsoft.
com/learn propose des parcours de formation supplémentaires pour les différentes
options de certification Azure, qui vous permettront de vous y préparer.

21.5.2 Ressources GitHub

Tout au long de ce livre, vous avez utilisé des exemples de code, des modèles, et des
exemples d’applications issus du site https://github.com/fouldsy/azure-mol-samples-
2nd-edition. Ces exemples devraient rester à jour au fur et à mesure que les nouvelles
versions de la CLI Azure sont commercialisées, et le référentiel GitHub inclut
également des exemples et des modèles PowerShell pour tous les exercices. Ce livre
insiste sur la CLI Azure dans Azure Cloud Shell, mais n’hésitez pas à aller voir ce que
donne chaque exercice dans PowerShell.
Si vous remarquez des problèmes avec les exemples, merci de créer un ticket dans
GitHub à l’adresse https://github.com/fouldsy/azure-mol-samples-2nd-edition/
issues. Les choses changent rapidement dans Azure et je veux m’assurer que vous ayez
toujours les exemples de travail les plus récents pour vous aider à apprendre. N’hésitez
pas également à faire des suggestions ! Tous les documents Azure sur https://docs.
microsoft.com/azure peuvent également faire l'objet de commentaires, de tickets et de
modifications. Pendant que vous continuez d’explorer les possibilités d’Azure, n’hésitez
pas à vous impliquer et à aider les autres à apprendre et à progresser.

21.5.3 Un dernier mot

Prenez une profonde respiration et réalisez que le changement s'inscrit désormais
dans la normalité. De nouvelles fonctionnalités et des nouveaux services sortent
presque tous les jours. Azure, comme tous les principaux fournisseurs de cloud
computing, vous donnera sans doute toujours l’impression d’être un peu différent
depuis la dernière fois que vous l’avez utilisé (il y a une heure). Tant que vous possédez
les compétences et la compréhension fondamentales de base que vous avez, je l’espère,
acquises dans ce livre, vous pourrez vous adapter et progresser avec toutes les nouvelles
opportunités qu’offre Azure. Vous avez toujours quelque chose de nouveau à
apprendre et j’adorerais savoir ce que vous avez fini par construire et par faire
fonctionner sur Azure !
 index
Symboles mise à l’échelle des applications web verticalement
caractère &&  27 127–128
objet $ResourceGroups  276 mise à l’échelle des machines virtuelles
objet $servicePrincipalConnection  275 verticalement 125–127
mise à l’échelle des ressources horizontalement
128–129
A avantages des 124–129
création 131–133
accès interactif à la console de démarrage  176 création de règles de mise à l’échelle automatique
ACI (Azure Container Instance) 284, 290, 292 133–136
ACR (Azure Container Registry) 293 groupes de machines virtuelles identiques 129–136
adresses IP privées  108 mise à l’échelle des applications web 136–139
adresses IP publiques  20, 62–64, 94, 108 applications évolutives 124–140
adresses IPv4  109 applications logiques Azure  318
adresses IPv6 109 applications logiques  35, 182, 325–328
affectation dynamique 62 applications. Voir aussi Azure Web Apps
affectation statique 63 apprentissage machine. Voir ML
agents 180 APT (Advanced Packing Tool) 27
affichage des informations sur 294 attaques de déni de service distribué (DDoS) 182
création de clusters avec 294–295 Automation Hybrid Worker 272
AWS (Amazon Web Services) 191
exécution de sites web dans Kubernetes 295-297
az keyvault secret show, commande 221
AKS (Azure Kubernetes Service) 284, 293–297
az vm list-sizes, commande 127
alertes 178–182
Azure AD (Azure Active Directory)  222
alertes métriques 182
Azure Application Gateway  108
alimentation de bases de données 145–149
Azure Application Insights 180
Amazon Web Services (AWS) 191 actifs 272–274
analyseur jq  226 création de comptes dans 271–272
API (interfaces de programmation d’applications) 31 définition 280–282
API REST 161 serveurs pull d’Azure Automation et 280–282
application monolithique 288 PowerShell DSC 278–282
Application Gateway 107–108 présentation de 179, 269–274
cycles de vie des 76-77 exécution 276–277
Function Apps 328–331 exemple de 274–277
Logic Apps 325–328 visualisation des résultats de 276–277
plans de service 38 procédures opérationnelles 272–274
applications Azure Automation 243, 269-283
applications d’équilibrage de charge 106–123 planification des sauvegardes 196–198
Applications de fonction d’Azure 318 restauration au niveau du fichier 199

335
336 index

restauration complète de VM 199–201 redondance 56–57

restauration des VM 198–201 stockage de table 53–54
RPO (objectif de point de récupération) 194–195 stockage en file d’attente 55–56
RTO (objectif de temps de récupération) 195–196 avantages de 52–57
stratégies et conservation 193–196 disques de données 49–50
Azure Backup 191–201, 243 disques temporaires 49–50
Azure Bastion 24, 115 options de mise en cache du disque 50
Azure CLI 7, 12-13, 28, 31, 81-82, 152, 161 stockage standard contre stockage premium 48–49
Azure Cloud Shell  12–13 stockage sur machine virtuelle 47–50
Azure Container Registry. Voir ACR Azure Storage 47–57
Azure DNS (Domain Name Service)  158–162 Azure Traffic Manager. Voir Traffic Manager
Azure Event Grid  320–321 consultation et application des mises à jour 245–249
Azure Event Hubs  321–322 OMS (Operations Management Suite) 243
Azure Front Door  163–164 Azure Update Management 241–249
création d’applications de fonction pour analyser les affichage des journaux de diagnostic 42–44
données d’appareils création d’applications web de base 37
diffusion des données du concentrateur dans des déploiement d’exemples de site HTML 39–42
applications web 309-315 création 37–42
données 328–331 création de connexions réseau d'accès distant 68–69
examen des composants 315 création de VM 69–70
Hub, gestion des appareils de manière centralisée avec utilisation d’agents SSH pour se connecter aux
303-309 machines virtuelles 70–72
intégration au Service Bus 322-325 création avec un trafic sécurisé 68–72
présentation de 300–302 création de bots 260
Azure IoT (Internet des objets) 300–316 création de bots avec LUIS 264–267
création de certificats 229-232 déploiement de l’application sur une application web
injection de certificats 229-232 exécutant plusieurs instances 140
MSI (identités des services gérées) 221–229 emplacements de déploiement et 35, 44–46
présentation de 211 exécution de bots avec LUIS 264–267
coffres de logiciels et HSM 217-218 gestion 42–44
création de coffres de clés et de secrets 219-221 langages et environnements pris en charge 34–35
sécurisation des informations dans le cloud 216–221 mise à l’échelle 127–139
stockage de clés de chiffrement dans 211-213 présentation de 34–35
Azure Key Vault 216–233, 304 réplication Azure-Azure 203
Azure Kubernetes Service. Voir AKS streaming des données Azure IoT Hub 309–315
Azure Machine Learning service 258 Azure Web Apps 33–45
Azure Monitor 243 Azure Cognitive Services 259–260
affichage des règles NSG effectives 184–186 Azure IoT Edge 304-305
capture de paquets réseau 186–188 Azure Service Bus 310, 321–322
vérification des flux IP 183–184 barre oblique inverse 40, 68
Azure Network Watcher 182–188
Azure PowerShell 11, 13, 31, 81–82, 161
conception tout au long du cycle de vie des B
applications 76–77
gestion et regroupement des ressources avec des base zéro, système de numérotation 99
balises 80–81 ajout d’une redondance globale à 149–152
protection des ressources à l’aide de verrous 79–80 alimentation 145–149
sécurisation et contrôle des ressources 78–79 création 145, 149–152
approche d' 75–81 dans Cosmos DB
création 82–84 mise à l’échelle 143–144
création de plusieurs instances d’un type de bases de données
ressource 84–85 bases de données structurées SQL  142
outils pour créer 85–86 Bash shell 12
stockage 87 création 260
modèles 81–87 création avec LUIS 264–267
Azure Resource Manager 75–89 exécution avec LUIS 264–267
Azure Service Fabric 289 bots pour applications Web
Azure Site Recovery 201–204, 243 Bouton Access Control (IAM – contrôle d’accès) 79
ajout de disques à des machines virtuelles 50–52 branches, dans Git 41
disponibilité du stockage 56–57
 index 337

C connectionString, variable 307

capture de paquets réseau 186–188 connectivité réseau (vNIC)  11
caret, symbole 27 connexion RDP (Remote Desktop Protocol)  20, 71
cartes d'interface réseau virtuel (NIC)  61 connexion Remote Desktop Protocol (RDP)  20, 71
cartes d'interface  61 connexions 270
CD (livraison continue) 75 connexions réseau d'accès distant  68–69
Centre de sécurité Azure 234, 249 consultation des mises à jour 245–249
certificat SSL  207 ACI (Azure Container Instance) 289–292
création 229–232 création de clusters avec 294–295
injection 229–232 exécution de sites web dans Kubernetes 295-297
certificats 270 AKS (Azure Kubernetes Service) 293–297
certificats SSL personnalisés  207 présentation de 284–288
au repos 208–209 conteneurs 146, 284–299
des machines virtuelles 211–214 contrats de niveau de service (SLA)  247
présentation de 206–208 ressources 78–79
SSE (Storage Service Encryption) 209–210 association de NSG à des sous-réseaux 66–67
stockage des clés dans Azure Key Vault 211–213 création de NSG 64–65
chiffrement 206–215 création de règles de filtrage NSG 67–68
CI (intégration continue) 75 trafic avec des NSG 64–68
clé de fonction 332 contrôle
clé privée, d’une paire de clés SSH 20–22, 71 contrôle d’accès basé sur les rôles (RBAC) 78, 161, 211
clé privée, d’une paire de clés SSH  71 copyIndex() fonction 84, 98, 102, 104
création de coffres de clés 219–221 accès aux données distribuées mondialement 152–156
stockage des clés de chiffrement dans Azure Key Vault ajout d’une redondance globale à 149–152
211–213 création de comptes et de bases de données 145–152
clés création et alimentation de bases de données 145–149
CLI (interface de ligne de commande) 12 déploiement d’une application web avec 156–157
coffres de logiciels et HSM 217-218 bases de données non structurées (NoSQL) 142–143
création de coffres de clés et de secrets 219-221 bases de données structurées (SQL) 142
cloud, sécurisation des informations dans 216–221 mise à l’échelle de bases de données 143–144
clusters avec AKS 294–295 collections 146 présentation de 141–144
code source  5 Cosmos DB 141–157
coffres avec protection logicielle  217–218 création du web des objets (Guinard et Trifa) 315
coffres, clé  219–221 cycles de vie des applications 76–77
commande az cosmosdb show  152
commande az group create  131
commande az keyvault create  212 D
commande az storage account create 210 data center operating system (DC/OS) 293
commande az vm 95 data scientists, outils pour  257–259
commande az vm create 51, 95, 197 database_password variable 228
commande az vm disk attach 51 DC/OS (data center operating system) 293
commande az vm resize 127, 129 DDoS (attaques de déni de service distribué) 182
commande az vm show 105 de l’intelligence artificielle. Voir IA
commande ssh-keygen 21 délégation de domaines réels  160–162
commandes, retour à la ligne des longues lignes  40 Démonter les disques, option  199
compte Azure, création  5–7 DenyAll, règles  185
dans Azure Automation, création 271-272 DenyAllInBound, règle  67, 184
ajout d’une redondance globale à 149–152 alertes 178–182
alimentation 145–149 affichage des règles NSG effectives 184–186
création 145–149, 152 capture de paquets réseau 186–188
dans Cosmos DB vérification des flux IP 183–184
comptes Azure Network Watcher 182–188
comptes d’identification 272 diagnostics de machines virtuelles 175–177
conditions de performances, alertes pour  181–182 mesures de performances 178–182
machines virtuelles avec équilibreurs de charge plateforme Azure 31–32
119–122 dépannage 175
sondes d’intégrité 110–112 dépendances 82
configuration dependsOn 104
configuration d'état souhaité (DSC) 179, 278, 282–283 déploiement de sites HTML 39–42
338 index

Déployer dans Azure, bouton  98 définition de la distribution du trafic avec des règles
détection du point de terminaison 153 112–114
diagnostics de démarrage 175–177 en action 120–122
disque dur virtuel (VHD)  53 équilibreurs de charge 94
ajout à des machines virtuelles 50–52 erreurs d’authentification 332
disques de données 49–50 espaces de travail Log Analytics  243
options de mise en cache 50 état de refus  238
temporaire 49–50 ETW (suivi d'événements Windows) 180
disques exemple Google Maps  256
disques de données 49–50 ExpressRoute 19, 183
disques durs standard  18 extension de script personnalisé  179
disques gérés 18 extensions 305
disques SSD(solid-state drive) premium  18–19
disques temporaires 49–50
distant 41 f
Docker 284, 287
Docker Swarm 293 fenêtre Vue d’ensemble d’Update Management 243
Dockerfile 291–292 fenêtre Vue d’ensemble de Security Center  236
erreur 96–97 fichier Managed Object Format (MOF)  280
mettre à jour 97–98 fichiers journaux. Voir journaux de diagnostic
réel, délégation à Azure DNS 160–162 filtrage 67–68
domaines flux des fichiers journaux  43
domaines de défaillance 96–97 flux IP, vérification  183–184
domaines de mise à jour 96 fonction concat, Resource Manager 85
DomainKeys Identified Mail (DKIM) 160 fonction copy, Resource Manager 84
DomainKeys Identified Mail (DKIM) 160 forum, pour cet ouvrage  5
données au repos  208 FPIS (Federal Information Processing Standard) 218
données distribuées mondialement  152–156 FPIS (Federal Information Processing Standard) 218
données non structurées  144 FQDN (nom de domaine qualifié complet)  63
données structurées  144 Function Apps 328–331
DR (récupération d'urgence) 201
DSVM (machines virtuelles de science de données) 258
durée de vie (TTL) 167
G
échange automatique 46 Gardner, Lyza Danger  315
échange avec aperçu 46 Gestionnaire de Configuration Local (LCM) 278
éditeur Visual Studio 85–86 déploiement d’exemples de site HTML avec 39–42
emplacement de production  46 formations 37
emplacements de déploiement 44–46 mot de passe pour, réinitialisation 314
emplacements des points de terminaison 153 Git 12
git push azure master, commande 156
git push dev master, commande 45
E Azure Automation et contrôle de code source avec 274
enableHttpsTrafficOnly, paramètre 210 compte pour, création 7
enregistrements d’alias 160 exemples de démarrage rapide Azure sur 87
environnements App Service  36 présentation de 39
environnements isolés  36 référentiel, pour cet ouvrage 5
équilibreur de charge interne  108 ressources 333
équilibreur de charge Internet  108 GitHub
affectation de groupes de machines virtuelles à des GPU (processeur graphique)  267
pools back-end 116–119 distribution des VM sur 98–101
création de pools IP front-end 108–110 domaines de défaillance 96–97
définition de la distribution du trafic avec des règles domaines de mise à jour 97–98
d’équilibrage de charge 112–114 redondance des VM avec 96–102
routage du trafic direct à l’aide de règles de visualisation de la distribution des VM sur 101–102
traduction d’adresses réseau 114–116 groupes à haute disponibilité 91
sondes d’intégrité 110–112 création 131–133
composants des 106–119 création de règles de mise à l’échelle automatique
création et configuration de machines virtuelles avec 133–136
119–122 groupes de machines virtuelles identiques 129–136
groupes de ressources 315
 index 339

groupes de sécurité réseau. Voir NSG intermédiaire 41

GRS (stockage géoredondant) 56 Internet Information Services (IIS)  29, 233
Guinard, Dominique D. 315 intervalle de détection, point de terminaison 168
iotconnectionstring, variable  312

H
J
HashiCorp 86
hôte Bastion 23–24 JavaScript sur les objets (Gardner) 315
hôte IPv4, enregistrement  160 jeton de signature d'accès partagé (SAS)  87
hôte IPv6, enregistrement  160 journaux de diagnostic 42–44
HPC (calcul haute performance) 267 JSON (JavaScript Object Notation) 82–83, 86
HSM (modules de sécurité matérielle)  212, 217–218 JWT (JSON Web Token) 226
HTTP 20, 168, 206 Voir aussi AKS
HTTPS  20, 168, 206 Kubernetes 293, 295–299
Hyper-V 15 Kubernetes in Action (Luksa) 298
Azure Cognitive Services 259–260 langage de programmation Perl  34
création 260 langage de programmation Python 28, 34
création avec LUIS 264–267 langage de requête structurée (SQL) 53, 142
exécution avec LUIS 264–267 langues prises en charge 34–35
bots d’application web LCM (Gestionnaire de Configuration Local)  278
LUIS 261–264 Learn Docker in a Month of Lunches (Stoneman) 297
machine learning et 254–259 Learn Git in a Month of Lunches (Umali) 37
présentation de 254–255 exécution de Web Apps sur 34
IA (intelligence artificielle) 253–268 utilisation de DSC avec 282–283
Linux
livraison continue (CD) 75
I Logiciel en tant que service (SaaS) 10
création de bots d’application web avec 264–267
IaaS (Infrastructure en tant que service)  9, 14, 33–34 exécution de bots d’application web avec 264–267
IaC (infrastructure en tant que code)  82 présentation de 257–264
identités gérées attribuées à l’utilisateur  222 LUIS (Language Understanding Intelligent Service)
identités gérées attribuées au système 222 Luksa, Marko 298
IIS (Internet Information Services)  29, 233
images, machine virtuelle  16–17
IMDS (Instance Metadata Service)  222 M
informations d’identification 270
création d’applications de fonction pour analyser les machine virtuelle B-series 18
données de l’appareil IoT 328–331 machines virtuelles de science de données
création d’applications logiques 325–328 (DSVM) 258
Azure Event Grid  320–321 machines virtuelles. Voir VM
Azure Event Hubs  321–322 Marketplace, Azure  7
Azure Service Bus 321–322 Maven 12
création de service bus 322–325 mémoire (vRAM)  11
intégration de Service Bus aux hubs IoT 322–325 Message Analyzer, Microsoft 186
présentation de 317–319 Message Text, propriété 56
plateformes de messagerie 319–325 messages d’erreur 31
plateformes de messagerie 319–325 mesures de performances  178–182, 188
ressources GitHub 333 méthode de routage pondéré, Traffic Manager  163
informatique sans serveur 317–333 méthode de routage prioritaire, Traffic Manager  163
infrastructure en tant que code (IaC) 82 Microsoft Message Analyzer 186
Infrastructure en tant que service (IaaS)  9, 14, 33 présentation de 136–139
injection de certificats 229-232 verticalement 127–128
install, commande  27 applications web
installation de serveurs web  24–27 bases de données 143–144
Instance de conteneur Azure. Voir ACI descente en puissance des machines virtuelles 127
Instance Metadata Service (IMDS)  222 horizontale des ressources 128–129
instances, création  290–292 mise à l’échelle à un niveau inférieur 127
intégration continue (CI) 75 redimensionnement des machines virtuelles
interface de ligne de commande (CLI)  12 126–127
340 index
verticale des machines virtuelles 125–127
mise à l’échelle
mise en cache en lecture/écriture  50
adresses IP publiques 62–64
cartes d’interface réseau virtuel 61
création de réseaux virtuels 59
création de sous-réseaux 59
résolution DNS 62–64
composants d’un réseau virtuel 58–64
création de connexions réseau d'accès distant 68–69
création de VM 69–70
utilisation d’agents SSH pour se connecter aux
machines virtuelles 70–72
création d’exemples d’applications web avec un trafic
sécurisé 68–72
association de NSG à des sous-réseaux 66–67
création de NSG 64–65
création de règles de filtrage NSG 67–68
sécurisation et contrôle du trafic avec des NSG 64–68
mise en réseau Azure 58–72
mise en réseau. Voir Mise en réseau Azure
consultation et application des mises à jour 245–249
OMS (Operations Management Suite) 243
Azure Update Management 241–249
JIT (Juste à temps) 237–241, 249
NSG sur Azure Security Center 234
mises à jour 234–249
mises à jour JIT (Juste à temps)  237–249
Azure Cognitive Services 259–260
création 260
création avec LUIS 264–267
exécution avec LUIS 264–267
bots d’application web
intelligence artificielle et 254, 256
lien avec l’intelligence artificielle 257–259
LUIS (Language Understanding Intelligent Service)
261–264
outils pour les data scientists 257–259
présentation de 255–256
ML (machine learning) 253–268
mode Affinité de session  112–113
mode application et autocorrection, DSC 279
mode appliquer et surveiller, DSC 279
mode appliquer seulement, DSC 279
mode basé sur le chemin d'accès, sondes d'intégrité  110
mode basé sur le port, sondes d’intégrité 110
modèles Azure Quickstart 7
création 82–84
création de plusieurs instances d’un type de ressource
84–85
outils pour créer 85–86
stockage 87
modèles, pour Azure Resource Manager 81–87
module nx 283
modules 270
MOF (Managed Object Format), fichier 280
MSI (identités des services gérées) 221–229
NAT (Network Address Translation)  107, 114–116
Azure Storage 18
tailles de machine virtuelle 17
N
navigateurs web, création de machines virtuelles à partir
de 22
NIC (cartes d'interface réseau virtuel)  61, 117
Niveau de carte réseau virtuelle 185
niveau de sous-réseau 185
niveau du groupe de sécurité de l'application  185
--no-self-perms, paramètre  220
NoSQL (bases de données non structurées) 142–143
affichage des règles effectives 184–186
association à des sous-réseaux 66–67
création 64–65, 118
création de règles de filtrage 67–68
dans Azure Security Center 234
présentation de 112
sécurisation et contrôle du trafic avec 64–68
NSG (Groupes de sécurité réseau) 20
objectif de point de récupération (RTO) 193
observateur de réseau 184
O
OMS (Operations Management Suite) 243, 272
option Tester dans la discussion web 266
orchestrateur de conteneurs 293
outils tiers  86
P
PaaS (Plateforme en tant que service) 10, 33, 37, 137
paires de clés 20
paires de clés SSH 20–22
paquets réseau  186–188
parallèle, machine virtuelle 102
paramètre -A 121
--paramètre de zone  95
paramètre d'intervalle, sondes d'intégrité  111
paramètre seuil, sondes d’intégrité 111
paramètres  82, 84, 89
Pare-feu Azure  238
PHP 34
alertes 178–182
affichage des règles NSG effectives 184–186
capture de paquets réseau 186–188
vérification des flux IP 183–184
Azure Network Watcher 182–188
diagnostics de machines virtuelles 175–177
mesures de performances 178–182
pilotage 175
plages d'adresses IP  60
plan de service de base 36
Plan de service gratuit/partagé  36
plan de service premium 36
plan de service standard  36
 index 341

planification des sauvegardes 196–198

R
planifications 134, 270 RA-GRS (stockage géoredondant avec accès en lecture)
plans App Service 35–38 57
plans de service pour applications 35–38 Raspberry Pi  306–309
dépannage 31–32 RBAC (contrôles d’accès en fonction du rôle)  78, 161,
Azure Cloud Shell  12–13 184, 211
Azure PowerShell 13 readLocations 153
CLI locale Azure 13 récepteurs 180
portail Azure 12 récupération d’urgence (DR) 201
outils de gestion 11–13 redimensionnement des machines virtuelles 126–127
présentation de 8–13 avantages de 90–91
stockage dans 18 des machines virtuelles avec des groupes à haute
virtualisation dans 10–11 disponibilité 96–102
plateforme Azure présentation de 56–57
Plateforme en tant que service (PaaS) 10, 33 redondance
Azure Event Grid  320–321 création de ressources réseau dans des zones de
Azure Event Hubs  321–322 disponibilité 94–95
Azure Service Bus 321–322 création de VM dans des zones de disponibilité 95
création de service bus 322–325 redondance des infrastructures, avec zones de
intégration de Service Bus aux hubs IoT 322–325 disponibilité 95
plateformes de messagerie 319–325 redondance mondiale 149–152
point de récupération 193 redondance. Voir aussi Redondance des infrastructures,
point de terminaison des événements 310, 312 avec zones de disponibilité
pointeur, enregistrement 160 règle AllowAzureLoadBalancerInBound 67
points de terminaison 323 règle AllowVnetInBound 67
points de terminaison de service 146 règle default-allow-ssh  241
pool d’IP back-end, dans les équilibreurs de charge 107 règles autoscale 133–136
back-end 116–119 regroupement de ressources 80–81
pools IP front-end 108–110 Representational State Transfer (REST)  31
pools requête curl 226–227
pools back-end 107, 116–119 réseau anycast  160
pools IP front-end 107–110 réseaux privés virtuels (VPN) 19, 36, 38
pools IP 107 adresses IP publiques 62–64
portail Azure 12 cartes d'interface  61
définition 280–282 création 59
serveurs pull Azure Automation et 179, 280–282 création de sous-réseaux 59
PowerShell et DSC (configuration d'état souhaité) résolution DNS 62–64
278–282 réseaux virtuels 58–64
PowerShell. Voir Azure PowerShell Résolution DNS 62–64, 158
principal de service  222 création de profils sur Traffic Manager 164–166
prise en charge à long terme (LTS) 22 distribution du trafic vers l’instance la plus proche à
prise en charge à long terme (LTS)  22 l’échelle mondiale 167–173
exécution 182 résolution, avec Traffic Manager 162–173
exécution 276–277 gestion 80–81
présentation de 272–274 regroupement 80–81
visualisation des résultats de 276–277 avec des balises
procédures opérationnelles, pour Azure Automation contrôle 78–79
274–277 mise à l’échelle horizontale 128–129
profils, sur Traffic Manager  164–166 nettoyage 30
projet Let’s Encrypt 207 protection à l’aide de verrous 79–80
protection des ressources  79–80 sécurisation 78–79
protocole, surveillance des points de terminaison 168 ressources 5, 7
ressources réseau 94–95
ressources, dans Azure Automation 272-274
Q REST (Representational State Transfer) 31
quotas par défaut  102 restauration au niveau du fichier 199
quotas  102, 132 restauration au niveau du fichier 199
restauration complète de VM 199–201
restauration des machines virtuelles 198–201
342 index

RPO (objectif de point de récupération) 194–195 service Face 259

RTO (objectif de temps de récupération) 195–196 service personnalisé  259
rétention 193–196 service Reconnaissance des interlocuteurs  259
rôle d’administrateur de l’accès utilisateur 78 service Translator Text 259
rôle de contributeur 78 service Vision 259
rôle de contributeur de machine virtuelle 79 service Vision par ordinateur 259
rôle de contributeur de site web 79 création 322–325
rôle de lecteur  78 intégration aux hubs IoT 322–325
rôle de propriétaire 78 Service Bus
routage « géographique » 163–164 service, enregistrement  160
routage « performance »  163–164 service PrincipalName  224
routage du trafic direct à l’aide de règles de traduction services redondants de zone 93
d’adresses réseau 114–116 Services voix  259
création de profils sur Traffic Manager 164–166 services zonaux  93
distribution du trafic vers l’instance la plus proche à sites HTML, déploiement  39–42
l’échelle mondiale 167–173 sites web, exécutés dans Kubernetes  295–297
routage mondial, avec Traffic Manager 162–173 SLA (contrats de niveau de service)  247
RPO (objectif de point de récupération) 193–195 SMB (Server Message Block)  53
RTO (objectif de point de récupération)  193, 195–196 configuration 110–112
création 110–112
présentation de 107
S sondes d’intégrité
SONiC (Software for Open Networking in the
SaaS (Logiciel en tant que service) 10 Cloud) 11
SAS (jeton de signature d’accès partagé) 87 source de noms (SOA), enregistrement 160
planification des sauvegardes 196–198 association de NSG à 66–67
restauration des VM 198–201 création 59
stratégies et conservation 193–196 sous-réseaux
Azure Backup 191–201 SPF (Sender Protection Framework)  160
Azure Site Recovery 201–204 SQL (langage de requête structurée)  53, 142
sauvegardes 191–204 SSD à performances élevées 18
sauvegardes incrémentielles  193 SSD standard  18–19
création 219–221 SSE (Storage Service Encryption) 209–210
obtention à partir de machines virtuelles avec des MSI agents SSH pour se connecter aux machines virtuelles
224–229 70–72
secrets connexion aux machines virtuelles avec 24–27
ressources 78–79 SSH (Secure Socket Shell)
association de NSG à des sous-réseaux 66–67 dans Azure 18
création de NSG (groupes de sécurité réseau) 64–65 disques de données 49–50
création de règles de filtrage NSG 67–68 disques temporaires 49–50
trafic avec des NSG 64–68 options de mise en cache du disque 50
sécurisation stockage standard contre stockage premium 48–49
sécurité 115 dans une machine virtuelle 47–50
Sender Protection Framework (SPF)  160 disponibilité du 56–57
séparation des rôles  62 redondance 56–57
série, machine virtuelle  102 stockage en file d’attente 55–56
Server Message Block (SMB) 53 stockage
serveur de nom, enregistrement  160 stockage (vDisk) 11
serveur web LAMP 27, 72 stockage Blob 52
serveurs de base de données, échelle verticale pour 126 stockage de fichiers  53
serveurs pull  280–282 stockage des modèles  87
en action 28–29 stockage en file d’attente 53, 55–56
installation 24–27 gestion des ressources avec 80–81
serveurs web regroupement de ressources avec 80–81
service Content Moderator 259 stockage en table 52 balises
service d’auto-suggestion Bing 259 stockage géoredondant (GRS) 56
service de langue 259 stockage géoredondant avec accès en lecture (RA-
Service de prise de décision  259 GRS) 57
service de recherche 259 Stockage localement redondant (LRS)  56
service de recherche personnalisée Bing 259 stockage localement redondant (LRS)  56
 index 343

stratégie de cache en lecture seule  50 Umali, Rick 37

RPO (objectif de point de récupération) 194–195 unité centrale virtuelle (vCPU)  11
RTO (objectif de temps de récupération) 195–196 Universal Coordinated Time (UTC) 196
stratégies 193–196 UTC (Universal Coordinated Time)  196
streaming de données hub IoT  309–315 utilitaires DevOps d’Azure 7
supports de formation 333 variable access_token 226
suppression des VM protégées 205
système de numérotation à base zéro  99
V
T variables  82, 84, 89, 271
vérification des flux IP 183–184
tailles de machine virtuelle GPU  17 verrous 79–80
tailles de machines virtuelles à usage général  17 VHD (disque dur virtuel)  53
tailles de machines virtuelles optimisées pour la vidages sur incident 180
mémoire 17 virtualisation 10–11
tailles de machines virtuelles optimisées pour le affectation de groupes de machines virtuelles à des
calcul 17 pools back-end 116–119
tailles de machines virtuelles optimisées pour le stockage affichage de la distribution dans les groupes à haute
17 disponibilité 101–102
Terraform 86 ajout de disques à 50–52
création de profils dans 164–166 atelier 214–215
déploiement d’applications web sur 174 stockage des clés de chiffrement dans Azure Key
distribution du trafic vers les instances les plus proches Vault 211–213
à l’échelle mondiale 167–173 chiffrement de 211–214
routage mondial et résolution avec 162–173 images de machines virtuelles et 16–17
zone de dépannage 183 mise en réseau virtuelle 19–20
Traffic Manager stockage Azure 18–19
définition de la distribution du trafic avec des règles tailles de machine virtuelle 17–18
d’équilibrage de charge 112–114 configuration 15–20
distribution vers les instances les plus proches à configuration avec des équilibreurs de charge 119–122
l’échelle mondiale 167–173 avec des agents SSH 70–72
routage du trafic direct à l’aide de règles de traduction avec SSH 24–27
d’adresses réseau 114–116 connexion à 120–122
association de NSG à des sous-réseaux 66–67 à partir de navigateurs Web 22
création de NSG 64–65 avec des équilibreurs de charge 119–122
création de règles de filtrage NSG 67–68 dans des zones de disponibilité 95
sécurisation et contrôle avec des NSG 64–68 dépannage Azure 31–32
trafic nettoyage des ressources 30
trafic direct, routage 114–116 réduction des coûts et 18
gestion 158–174 vm Windows 29–30
routage 158–174 création 14–32, 69–70
trafic réseau déploiement à partir de modèles 102–105
création de connexions réseau d'accès distant 68–69 désallocation 30
création de VM 69–70 diagnostics 175–177
utilisation d’agents SSH pour se connecter aux distribution dans des groupes à haute disponibilité
machines virtuelles 70–72 98–101
trafic sécurisé, création d’applications web avec 68–72 extensions de diagnostic 178
création de règles autorisant 28 création 131–133
permettant d’atteindre les machines virtuelles 27–29 création de règles de mise à l’échelle automatique
trafic web 133–136
Trifa, Vlad M. 315 installation d’applications sur 139
TTL (durée de vie) 167 groupes de machines virtuelles identiques 129–136
types de ressources 84–85 installation de serveurs web  24–27
types d'enregistrements DNS Azure  160 mise à l’échelle à un niveau inférieur 127
mise à l’échelle verticale 125–127
obtention de secrets avec des MSI 224–229
U paire de clés SSH, création pour l’authentification
20–22
Ubuntu Linux 14, 26 création de règles autorisant le trafic web 28
344 index

observation du serveur web en action 28–29 VMSS à une seule machine virtuelle  130
permettant au trafic web d’atteindre 27–29 VMware 15
redimensionnement 126–127 VPN (réseaux privés virtuels) 19, 36, 38, 183
domaines de défaillance 96–97
domaines de mise à jour 97–98
redondance des machines virtuelles avec des groupes à W
haute disponibilité 96–102
webhooks 274
restauration au niveau du fichier 199
WebSockets 312
restauration complète de VM 199–201
Windows, exécution de Web Apps sur  34
restauration 198–201
création de ressources réseau sur 94–95
disques de données 49–50
création de VM dans 95
disques temporaires 49–50
redondance de l’infrastructure avec 95
options de mise en cache du disque 50
stockage standard contre stockage premium 48–49
stockage 47–50
suppression 30
Z
tailles de 17 zones de disponibilité 91
VM (machines virtuelles) ZRS (stockage redondant interzone) 56
VM protégées, suppression  205
By developers, Get technical articles, sample
code, and information on
● Keep up on the latest
technologies

for developers upcoming events in ● Connect with your peers

Microsoft.Source, the at community events Sign up

curated monthly developer ● Learn with

Microsoft.Source newsletter community newsletter. hands-on resources