Articles Tagués ‘Azure VNET’

 

Useful Info : Si vous n’avez pas encore consulté les 6 premiers HowTo Azure CLI 2.0, ceux-ci sont disponibles aux URLs ci-après:

HowTo #N°1 : Connecter l’interface Azure CLI 2.0 à votre abonnement Azure

HowTo #N°2 : Créer et gérer les groupes de ressources Azure

HowTo #N°3 Créer et gérer les réseaux virtuels Azure (VNET : Virtual Network)

HowTo #N°4 Créer et gérer les Machines Virtuelles Azure (Azure VM)

HowTo #N°5 : Gérer la facturation Azure (Azure Billing)

HowTo #N°6 Créer et gérer vos comptes de Stockage Azure

 

Introduction

Azure NSG (Network Security Groups) ou Groupes de Sécurité Réseau vous permettent de contrôler (autoriser ou refuser) le trafic entrant et sortant depuis et vers vos ressources Azure.

Les NSG sont basées sur des listes de règles de sécurité que vous créez/définissez manuellement. Notez que lors de la création d’un NGS, des règles par défaut sont générées automatiquement pour sécuriser certains trafics réseaux. Ces règles peuvent être bypassées en mettant en place des règles personnalisées.

Tip : Je vous invite à consulter cet article pour en savoir plus sur les NSG, leur fonctionnement et leur limitation.

 

La création d’un Groupe de Sécurité Réseau (NSG) peut se faire via :

Le nouveau portail Azure : portal.azure.com

Windows PowerShell : utilisation du module PS Azure

Azure CLI 2.0 : via l’utilisation de la commande az network nsg

 

Nous allons découvrir à travers cet article la troisième méthode qu’est l’utilisation de l’interface Azure CLI 2.0

Now let’s create & manage our Azure NSG via Azure CLI 2.0__O

 

HowTo : créer et gérer vos Groupes de Sécurité Réseau Azure (NGS)

Tout d’abord, je vous invite à saisir az network nsg -h pour en savoir plus sur les sous-commandes disponibles :

Pour lister tous les NSG existants, saisissez la commande suivante : az network nsg list 

Tip : pour une meilleure visibilité de la commande output, saisissez az network nsg list –out table

Commencez par créer un groupe de Ressource 

Azure ARM (Azure Resource Manager) introduit le concept des Groupes de ressources (RG : Resource Group). Ces derniers font office de « Conteneur » pour grouper et gérer les ressources Azure de manière centralisée.

Dans notre cas, nous allons créer un groupe de ressource pour regrouper les différents NSG Azure que nous allons créer par la suite.

Exécutez donc la commande suivante pour créer un nouveau groupe de ressource (nommé hk-demo-howto7) au niveau de la région Europe de l’Ouest (WestEurope)

az group create -n hk-demo-howto7 -l WestEurope

Maintenant que notre Groupe de Ressource est créé, nous allons créer notre premier Groupe de Sécurité Réseau Azure. Pour ce faire, exécutez la commande suivante (NSG nommé hk-demo-nsg dans l’exemple suivant) :

az network nsg create -n hk-demo-nsg -l WestEurope -g hk-demo-howto7

Vous pouvez également ajouter des « Tags » à vos NSG lors de leur création, dans l’exemple suivant nous allons créer un nouveau NSG Taggé « very_secure_network » :

az network nsg create -n hk-demo-nsg-vsecure -l WestEurope -g hk-demo-howto7 –tags very_secure_perimeter no_80 no_22 no_21

Pour afficher des informations détaillées sur un NSG spécifique, la commande suivante est à exécuter (hk-demo-nsg-vsecure dans l’exemple suivant) :

az network nsg show -n hk-demo-nsg-vsecure -g hk-demo-howto7

Enfin, si vous souhaitez supprimer un NSG, exécutez la commande suivante (hk-demo-nsg-vsecure dans l’exemple suivant) :

az network nsg delete -n hk-demo-nsg-vsecure -g hk-demo-howto7

Plusieurs HowTo Azure CLI (N°8/9 et 10) arrivent bientôt, so let’s keep in touch :).

A bientôt

#HK

Publicités

Dans le cadre d’un projet de migration, de réorganisation ou simplement changement de plan d’adressage IP, vous pouvez être amenés à changer le Subnet voire le VNetwork sur lequel une VM ou plusieurs VMs Azure sont placées.

J’aimerais quand même rappeler certaines dépendances entre le réseau Azure et les deux modèles de déploiement disponibles actuellement avec Azure :

Avec ARM (Azure Resource Manager) : chaque VM Azure doit obligatoirement être attachée à un VNET, cela ne peut être évité ni contourné.

Avec ASM (Azure Service Management) : dans ce mode « Legacy », les VMs Azure peuvent bypasser ce prérequis et ne faire parties d’aucun VNET.

Je vous expliquerai à travers cet article comment changer (via Windows PowerShell) le Subnet ou VNET d’une VM Azure existante et ce pour les deux modes « ARM & ASM ».

De plus, les effets de bord et impacts post-changement de VNET y seront également expliquées.

Il est important de comprendre que le modèle Réseau sous ARM est très différent d’ASM.

La « Big Picture » ci-après illustre cette différence entre les deux modèles :

1

Changer de Subnet sous ASM

Le changement de Subnet d’une VM sous ASM est assez simple. Il existe en effet une Cmd-let PowerShell pour Azure qui permet de réaliser cette action facilement : Set-AzureSubnet

Pour en savoir plus : https://msdn.microsoft.com/en-us/library/mt589103.aspx

Le code PowerShell suivant est à utiliser pour changer le Subnet d’une VM Azure existante :

Get-AzureVM –Name $NomVM –ServiceName $NomServiceCloud | Set-AzureSubnet -SubnetNames $NomNouveauSubnet | Update-AzureVM

Note importante : le nouveau Subnet spécifié DOIT FAIRE PARTIE DU MEME VNET que l’ancien Subnet.

Astuce : Vous pouvez exécuter la commande en bypassant le paramètre -Name. Voir l’exemple suivant ou la VM (dont le nom du service cloud est « NNSRV01 ») sera placé sur un nouveau Subnet nommé « Subnet-2 »:

Get-AzureVM NNSRV01 | Set-AzureSubnet -SubnetNames Subnet-2 | Update-AzureVM

2

Changer de Subnet sous ARM

La Cmd-Let utilisée précédemment n’existe plus sous ARM, mais le changement de Subnet reste aussi assez simple dans ce mode, enfin à partir du moment ou vous connaissez l’endroit qui vous permet de le faire.

Il faut noter que sous ARM, ce changement de Subnet s’effectue au niveau de l’objet NIC (Network Interface Card) et non pas au niveau de la VM (cf Big Picture ci-dessus).

Donc pour commencer, il faut d’abord collecter toutes les informations de références de votre VM {VNET /Subnet /NIC), ceci peut se faire via l’utilisation du code ci-après :

 

# Obtenir les informations de références de la VM et vérifier l’Availability Set #
$NomVM = “NNSRV01”
$VirtualMachine = Get-AzureRmVM -ResourceGroupName $NomGdeR -Name $NomVM

# VM Créée dans l’Availability Set
$VirtualMachine.AvailabilitySetReference

# Obtenir les informations de références sur la NIC /Subnet /VNET #
$NIC = Get-AzureRmNetworkInterface -Name $NomNIC -ResourceGroupName $NomGdeR
$NIC.IpConfigurations[0].PrivateIpAddress # ‘10.0.0.4’
$VNET = Get-AzureRmVirtualNetwork -Name $NomVNET -ResourceGroupName $NomGdeR
$Subnet2 = Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $VNET -Name $NomSubnet2

Le paramètre de Subnet que vous avez besoin de changer est situé au niveau de la propriété « IPConfigurations ».
Il suffit d’y accéder avec l’index [0] et changer directement la valeur « Subnet.Id » avec l’ID du nouveau Subnet:

$NIC.IpConfigurations[0].Subnet.Id = $Subnet2.Id
Set-AzureRmNetworkInterface -NetworkInterface $NIC

Après avoir effectué cette opération, vous devez confirmer la modification à l’aide d’Azure ARM Network Provider en utilisant la Cmd-Let “Set-AzureRmNetworkInterface”. Notez que l’exécution de cette Cmd-Let prend quelques minutes. Ce temps est requis car Azure redémarre automatiquement la VM et donc un « downtime » sur la VM (et les services hébergés associés) est à prévoir.

Changer de VNET sous ARM & ASM

Au moment de l’écriture de cet article, le changement de VNET d’une VM existante est une opération impossible /non supportée sur Azure (pour les deux modes : ARM & ASM).

Cependant, une technique qui permet de réaliser cette opération existe :

  • Exporter la configuration de la VM
  • Supprimer la VM et garder ses vDisques (fichiers VHDs)
  • Recréer une nouvelle VM avec les mêmes paramètres en prenant en compte les deux éléments suivants :
    • Spécifier le nouveau VNET
    • Réattacher les anciens disques VHDs