Articles Tagués ‘ARM’

Hello Azure (Classic :D) Guys,

Microsoft a publié le 06 Décembre une Update pour annoncer la suppression « définitive » du Portail Azure « Classic », le 08 Janvier 2018.

D’ailleurs, si vous vous connectez sur le Portail Azure Classic (https://manage.windowsazure.com), vous constaterez l’apparition du message /alerte suivante « Avis de suppression du portail classic Azure » :

BUT, do not worry :).

Toutes vos ressources /services déployés en mode ASM (Azure Service Manager) seront automatiquement migrés vers le nouveau Portail (https://portal.azure.com), MS s’en occupe, donc transparence totale pour les « Cloud Consumers » :).

En attendant, commencez à découvrir toutes les nouvelles features, options et services introduits avec le nouveau Portail Azure.

Ci-après quelques liens utiles que je vous invite à consulter pour prendre en main le nouveau modèle de déploiement Azure et ses différents outils d’automatisation (e.g : Az PS, Az CLI ..etc)

Démarrer avec Azure (ARM)

Découvrez l’interface Azure CLI

Découvrez Azure Cloud Shell 

Découvrez Azure PowerShell

Publicités

 

Hello Azure Guys,

Si vous êtes amenés à gérer vos ressources Cloud Azure via l’interface Azure CLI 2.0, vous devriez penser à checker de manière régulière les nouvelles Releases d’Azure CLI proposées/publiées par l’équipe MS Azure Corp, car de nouvelles commandes /sous-commandes sont fournies avec celle-ci.

Note : Le Releases History d’Azure CLI 2.0 est disponible ici. N’hésitez pas à consulter cette page si vous voulez en savoir plus.

 

Prenons l’exemple suivant : ma machine d’administration (sous WS10) ayant l’interface Azure CLI 2.0 d’installée et dont la version actuelle est la 2.0.17

Comme illustré dans l’image ci-dessous, mon interface Az CLI 2.0 n’inclut pas encore les nouvelles commandes telle que BatchAI (Azure Batch  Artificial Intelligence) :

 

HowTo : Updater son interface Azure CLI 2.0

Lancez l’Invite de commande (CMD.exe) en tant qu’Administrateur et saisissez la commande suivante :

Az Component Update 

ou

Az Component Update –debug pour afficher de plus amples informations sur d’éventuels problèmes rencontrés lors du processus d’Update /Upgrade : affichage des journaux de Debug (Debug Logs).

Une fois l’update terminée, les messages suivants sont affichés :

Enfin, saisissez Az –version pour noter la nouvelle version de l’interface CLI installée sur votre machine :

Maintenant que mon interface Az CLI 2.0 est mise à jour, je vais simplement ressaisir Az -h pour faire réapparaître la liste complète des commandes disponibles :

Comme montré dans la screenshot ci-dessus, les nouvelles commandes telles que « BatchAI » sont désormais intégrées et disponibles sur mon interface Azure CLI 2.0.

Stay connected, de nouveaux posts autour d’Azure & Azure CLI seront bientôt publiés :).

A bientôt

#HK.

 
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

 

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