Déployer une infrastructure Linux et PostgreSQL

45 minutes

Cette unité vous guide dans la création des ressources de calcul qui hébergent votre application dans Azure.

Il existe plusieurs méthodes pour déployer l’infrastructure dans Azure, notamment le Portail Azure, l’interface de ligne de commande Azure et les modèles d’infrastructure en tant que code (y compris Bicep et Terraform). Dans cette unité, vous déployez un modèle Bicep préconfiguré qui encapsule les ressources de calcul requises pour votre application. Les ressources clés sont les suivantes :

Une machine virtuelle exécutant Linux (Ubuntu 24.04 LTS)
Azure Database pour Postgres exécutant Postgres 16 ou version ultérieure
Identité managée permettant d’activer l’accès sécurisé de la machine virtuelle à la base de données
RBAC, y compris les rôles permettant d’accéder à la base de données en tant qu’administrateur et les rôles plus restrictifs pour l’application elle-même
Un réseau virtuel pour la machine virtuelle et la base de données

Étant donné que cet exemple est une charge de travail de dev/test, et que nous souhaitons que les choses restent à la fois rentables et performantes, nous avons choisi la configuration suivante pour vous :

La machine virtuelle est une D2s_v4 Standard (deux processeurs virtuels, 8 Go de mémoire). Elle dispose de SSD Premium Azure avec 3 200 opérations d’E/S maximales par seconde (IOPS) et 128 Go de stockage. Elle a un disque SSD Premium P10 128 Go attaché avec 500 IOPS pour le disque du système d’exploitation. Vous pouvez mettre à niveau le disque du système d’exploitation pour qu’il corresponde aux IOPS de la machine virtuelle en fonction des besoins.
La base de données est une D2ds_v4 usage général (deux vCores, 8 Go de RAM) avec 3 200 IOPS maximum. Elle dispose d’un disque SSD Premium P10 de 128 Go avec 500 IOPS. Vous pouvez mettre à niveau ce disque pour qu’il corresponde aux IOPS de calcul selon les besoins.

À la fin du module, vous supprimez ces ressources pour économiser des coûts. Toutefois, vous pouvez également désactiver la machine virtuelle et la base de données quand elles ne sont pas utilisées pour économiser les coûts de calcul et payer uniquement le stockage que vous utilisez. Vous pouvez également effectuer un scale-up de cette charge de travail en fonction des besoins.

Le modèle Bicep de ce module utilise des modules vérifiés Azure (AVM). AVM est une initiative visant à normaliser les modules d’infrastructure en tant que code. Microsoft gère ces modules et encapsule de nombreuses bonnes pratiques pour le déploiement de ressources dans Azure.

Vérifier que vous disposez d’un abonnement Azure et de l’interface de ligne de commande Azure

Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.

Ce module nécessite Azure CLI version 2.0.30 ou ultérieure. Recherchez la version à l’aide de la commande suivante :

az --version

Si vous avez besoin d’installer ou de mettre à niveau, consultez Installer Azure CLI.

Pour exécuter des commandes dans Azure à l’aide de l’interface de ligne de commande Azure, vous devez d’abord vous connecter. Connectez-vous à l’aide de la commande az login :

az login

Créer un groupe de ressources

Un groupe de ressources est un conteneur de ressources associées. Toutes les ressources doivent être placées dans un groupe de ressources. Utilisez la commande az group create pour créer un groupe de ressources :

az group create \
    --name 240900-linux-postgres \
    --location westus2

Déployer le modèle Bicep à l’aide de l’interface de ligne de commande Azure

Bicep est un langage spécifique à un domaine (DSL) qui utilise la syntaxe déclarative pour déployer des ressources Azure. Dans un fichier Bicep, vous définissez l’infrastructure que vous souhaitez déployer sur Azure. Ensuite, vous utilisez ce fichier tout au long du cycle de vie du développement pour déployer votre infrastructure à plusieurs reprises. Vos ressources sont déployées de manière cohérente.

Le fichier Bicep que vous utilisez pour déployer les ressources de calcul pour cette unité se trouve dans le dépôt GitHub deploy/vm-postgres.bicep . Il contient une machine virtuelle, un réseau virtuel, une identité managée, un groupe de sécurité réseau (NSG) pour la machine virtuelle. Vous pouvez en savoir plus sur Bicep dans Qu’est-ce que Bicep ?.

Cloner l’exemple de référentiel sur votre ordinateur local :

git clone https://github.com/Azure-Samples/linux-postgres-migration.git

Accédez au répertoire linux-postgres-migration :
```
cd linux-postgres-migration
```

Déployez le modèle Bicep :

az deployment group create \
    --resource-group 240900-linux-postgres \
    --template-file deploy/vm-postgres.bicep

À la fin du déploiement, la sortie JSON confirme que les ressources sont déployées.

Dans les sections suivantes, vous allez configurer et explorer les rôles RBAC et les règles de sécurité réseau sur votre infrastructure déployée à l’aide du Portail Azure. Lorsque vous utilisez le Portail Azure, vous pouvez encoder les rôles et les règles dans le modèle Bicep. Le portail Azure fournit une interface visuelle qui facilite la compréhension des relations entre les ressources et les autorisations qui leur sont attribuées.

Ouvrir le groupe de ressources dans le Portail Azure

Ouvrez le portail Azure.
Dans le menu du service, sélectionnez Groupes de ressources.
Dans le volet Groupes de ressources, sélectionnez le groupe 240900-linux-postgresde ressources.

Dans la partie supérieure droite du volet, la zone Déploiements affiche l’état de votre déploiement de modèle Bicep. Une fois le déploiement réussi, il affiche Réussi.

Afficher le groupe de sécurité réseau de la machine virtuelle

Sélectionnez la machine virtuelle vm-1.
Dans la section Mise en réseau , sélectionnez Paramètres réseau.

Les paramètres réseau indiquent que le groupe de sécurité réseau (240900-linux-postgres-nsg) est attaché au même sous-réseau du réseau virtuel (240900-linux-postgres-vnet) que la machine virtuelle.

Le NSG est également visible à l’intérieur du groupe de ressources. Il contient un ensemble de règles de sécurité entrantes et sortantes qui contrôlent le trafic vers et depuis la machine virtuelle.

Revenir au groupe de ressources

En haut de la page, sélectionnez le lien de navigation pour revenir au groupe de ressources (Home > Resource groups > 240900-linux-postgres).

Notez que l’identité managée affectée par l’utilisateur 240900-linux-postgres-identity est répertoriée dans le groupe de ressources.

Vous pouvez en savoir plus sur les identités managées affectées par le système et affectées par l’utilisateur dans Qu’est-ce que les identités managées pour les ressources Azure ?.

Ajouter une règle de sécurité entrante au groupe de sécurité réseau

Ajoutez une règle de sécurité entrante au NSG pour autoriser le trafic SSH à partir de votre adresse IP actuelle vers la machine virtuelle.

Dans un scénario de production, vous utilisez souvent un accès juste-à-temps, Azure Bastion ou un VPN (par exemple, Azure ou un VPN de maillage) pour restreindre l’accès à votre machine virtuelle.

Sélectionnez 240900-linux-postgres-nsg.
Sélectionnez Paramètres>des règles de sécurité entrantes.
Sélectionnez Ajouter.
Sous Source, sélectionnez Mon adresse IP.
Sous Service, sélectionnez SSH.
Sélectionnez Ajouter.

Afficher l’administrateur du serveur flexible Azure Database pour PostgreSQL

Recherchez et sélectionnez le serveur flexible Azure Database pour PostgreSQL. Il est nommé postgres-xxxxx, où xxxxx est une chaîne unique définie par le modèle Bicep. La chaîne reste cohérente entre les déploiements de votre abonnement et de votre groupe de ressources.
Sélectionnez Sécurité>Authentification.

Pour ce scénario, vous utilisez uniquement l’authentification Microsoft Entra. L’identité managée affectée par l’utilisateur 240900-linux-postgres-identity est répertoriée sous Microsoft Entra Admins.

L’identité managée 240900-linux-postgres-identity est actuellement le seul administrateur du serveur. Vous pouvez éventuellement ajouter votre propre compte d’utilisateur en tant qu’administrateur. Toutefois, pour ce scénario, vous utilisez l’identité managée déjà en place.

Dans une section à venir, vous utilisez l’identité de la machine virtuelle pour administrer le serveur via l’interface de ligne de commande Azure. Vous utilisez également cette identité pour fournir l’accès au serveur pour votre application.

Dans un scénario de production, vous utiliseriez probablement une combinaison d’identités managées, Microsoft Entra ID et d’un RBAC précis pour permettre à votre charge de travail d’application d’accéder aux données et de gérer les ressources dans Azure en toute sécurité. Vous devez suivre le principe du privilège minimum.

En savoir plus sur ces scénarios dans l’authentification Microsoft Entra avec Azure Database pour PostgreSQL - Serveur flexible et utiliser l’ID Microsoft Entra pour l’authentification avec Azure Database pour PostgreSQL - Serveur flexible.

Passer en revue les règles de pare-feu de serveur flexible Azure Database pour PostgreSQL

Sélectionnez Paramètres>Réseau.

Si vous gériez le serveur à partir de votre ordinateur local, plutôt que de la machine virtuelle, vous devez ajouter votre adresse IP aux règles de pare-feu.

Vous pouvez créer une règle de pare-feu pour votre adresse IP actuelle en sélectionnant Ajouter l’adresse IP du client actuelle (xxx.xxx.xxx.xxx)>Enregistrer. Cette règle vous permet d’accéder au serveur dev/test à l’aide d’outils sur votre ordinateur local. Toutefois, étant donné que vous utilisez une machine virtuelle pour accéder à la base de données, vous ne créez pas de règle de pare-feu pour l’instant.

En production, vous isoleriez probablement ce serveur de l’Internet public entièrement en désactivant l’autorisation d’accès public à cette ressource via Internet à l’aide d’une option d’adresse IP publique .

Contrairement à la machine virtuelle, vous n’avez pas associé Azure Database pour PostgreSQL à un réseau virtuel. Vous conservez la possibilité d’accéder à Azure Database pour PostgreSQL via l’Internet public, ce qui est utile pour les scénarios dev/test.

Pour assurer la sécurité et la flexibilité, vous allez activer l’accès à partir de la machine virtuelle via son réseau virtuel à l’aide d’un point de terminaison privé. Le point de terminaison privé permet à la machine virtuelle d’accéder à la base de données sans l’exposer à l’Internet public. En savoir plus sur les points de terminaison privés dans Azure Database pour PostgreSQL - Mise en réseau de serveur flexible avec Private Link.

Ici, le point de terminaison privé a été créé pour vous à l’aide de Bicep.

Passez en revue les attributions de rôles pour l’identité managée affectée par le système de la machine virtuelle

Revenez au groupe de ressources 240900-linux-postgres, puis sélectionnez vm-1.
Dans le menu du service, sélectionnez Identité de sécurité>.

Ici, vous pouvez confirmer que l’identité managée affectée par le système est attachée à la machine virtuelle.
Sous Attribution du système, sélectionnez Attributions de rôles Azure.

Ici, vous pouvez confirmer que le rôle Lecteur est attribué à l’identité managée affectée par le système. Le rôle est limité au groupe de ressources 240900-linux-postgres.

Les autorisations de cette identité vous permettent d’utiliser l’interface de ligne de commande Azure au sein de la machine virtuelle pour répertorier les ressources dans le groupe de ressources. Avec cette possibilité, vous n’avez pas besoin de coder en dur des détails de ressources spécifiques dans vos scripts.

À une étape ultérieure, vous allez attribuer un rôle supplémentaire à l’identité managée de la machine virtuelle afin que la machine virtuelle puisse accéder directement à un compte stockage Blob Azure.

Ensuite, vous allez explorer et configurer l’infrastructure déployée.

Ressources

Commentaires

Cette page a-t-elle été utile ?