Articles Tagués ‘Azure Resource Manager’

 
Introduction 

Un réseau virtuel Azure (Azure Virtual Network) est la représentation de votre réseau local d’entreprise dans le Cloud. En effet, quand vous décidez de déployer des ressources dans le Cloud et choisissez Microsoft comme fournisseur de Cloud public, eh bien votre « Réseau dans le Cloud » est le Azure Virtual Network (appelé aussi VNET : cf documentations Microsoft)

Vous pouvez configurer votre ou vos VNETs Azure de la même manière que pour votre ou vos réseaux locaux « On-Premise » : définir le plan d’adressage IP, les sous-réseaux (Subnets), le(s) serveur(s) DNS, les stratégies de sécurité, le routage …Etc

Vous pouvez également subdiviser votre VNET Azure en sous-réseaux pour isoler les différents trafics réseaux (e.g : environnements DMZ /INT /PREPROD /PROD) , ces sous-réseaux peuvent aussi représenter des « Branch Office » ou simplement des Sites de Backup /PRA pour votre S.I, un VNET Azure devient alors une extension de vos réseaux locaux internes « On-Prem » dans le Cloud.

La création d’un VNET Azure 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 vnet

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 Virtual Network via Azure CLI 2.0__O

 

Comment ça marche ?
  • Ouvrez une Session Windows sur la machine d’administration sur laquelle Azure CLI 2.0 a été installé
  • Lancez l’invite de commande (CMD.exe) en tant qu’Administrateur et saisissez az pour vérifier la disponibilité de l’interface Azure CLI 2.0
  • Après avoir saisi et exécuté la commande az, le Menu suivant vous est retourné :

  • La commande qui nous intéresse est Network. En effet, l’interface az dans le contexte Network vnet permet de créer et gérer les réseaux virtuels Azure.
  • Pour afficher toutes les commandes & sous-commandes liés à la création et gestion des VNETs, saisissez la commande suivante : az network vnet -h 

  • Pour afficher /lister les VNETs existants, saisissez az network vnet list –output table
    • Note : le paramètre –output table est utilisé pour une meilleure lisibilité du résultat retourné (résultat affiché sous forme de tableau)

  • Pour créer une nouveau VNET nommé « hk-vnet01 » dans le groupe de ressource « hk-ResourceGroup » et l’héberger au niveau de la région Azure « Europe de l’Ouest« , la commande suivante est utilisée : az network vnet create -n « hk-vnet01 » -g « hk-ResourceGroup » -l WestEurope

  • Pour créer une nouveau VNET nommé « hk-vnet02 » dans le groupe de ressource « hk-ResourceGroup » et l’héberger au niveau de la région Azure « Europe de l’Ouest » en spécifiant l’espace d’adressage 10.10.0.0/16 et en créant un premier sous-réseau dont l’ID est 10.10.1.0/24, la commande suivante est utilisée : az network vnet create -g hk-ResourceGroup -n hk-vnet02 -l WestEurope –address-prefix 10.10.0.0/16 –subnet-name HK-SUB-PROD –subnet-prefix 10.10.1.0/24

  • Pour afficher des informations détaillées sur un VNET spécifique (hk-vnet01 dans l’exemple suivant), la commande suivante est utilisée : az network vnet show -n « hk-vnet01 » -g « hk-ResourceGroup »

  • Pour supprimer un VNET spécifique (hk-vnet02 dans l’exemple suivant), la commande suivante est utilisée : az network vnet delete -n hk-vnet02 -g hk-ResourceGroup

  • Enfin, pour mettre à jour (modifier) un VNET spécifique, la commande suivante est utilisée : az network vnet update suivie du nom du groupe de ressource hébergeant le VNET (paramètre -g) et le nom du VNET à modifier /updater (paramètre -n). Les paramètres –address-prefixes et –add sont à utiliser pour mettre à jour la configuration de votre VNET. Si toutefois vous voulez afficher l’aide en ligne pour la commande az network vnet update, exécutez la commande suivante : az network vnet update -h

 

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