DevOpsFacile
AccueilParcours de formationCertificationsModulesCheat SheetÀ Propos
DevOpsFacile

Une plateforme d'apprentissage complète pour maîtriser les pratiques DevOps modernes, du débutant à l'expert.

contact@devopsfacile.fr

Formation

  • Parcours de formation
  • Modules

Informations

  • À Propos
  • Conditions d'utilisation
  • Confidentialité
  • Mentions légales

© 2026 DevOps Facile. Tous droits réservés.

Fait avec pour la communauté DevOps

ModulesAzure - Intermédiaire : VNet, App Service, AKS et Bicep

Module

Maîtrisez le réseau Azure avec les Virtual Networks, le PaaS avec App Service, l'orchestration de conteneurs avec AKS et l'Infrastructure as Code avec Bicep.

  • 2h30
  • Intermédiaire
  • 3 exercices
Voir les exercices

Formation 100 % Linux

Tous les modules nécessitent un environnement Linux. Si vous êtes sur Windows, installez d'abord WSL (Windows Subsystem for Linux) avant de continuer.

Azure - Intermédiaire : VNet, App Service, AKS et Bicep

🎯 Objectifs

  • ✅ Concevoir des Virtual Networks avec sous-réseaux et Network Security Groups
  • ✅ Déployer des applications web avec Azure App Service
  • ✅ Créer et gérer un cluster AKS (Azure Kubernetes Service)
  • ✅ Écrire des templates Bicep pour automatiser l'infrastructure
  • ✅ Monitorer ses ressources avec Azure Monitor et Log Analytics

📋 Prérequis

  • Azure Débutant (Entra ID, VMs, Blob Storage, Azure CLI)
  • Kubernetes Débutant (pods, services, kubectl)
  • Docker Débutant (images, conteneurs)

🌐 Virtual Networks (VNet)

Architecture réseau Azure

VNet : 10.0.0.0/16
├── Subnet public   10.0.1.0/24  → Application Gateway, Load Balancer
├── Subnet applicatif 10.0.2.0/24 → VMs applicatives, App Service
└── Subnet données  10.0.3.0/24  → Azure SQL, Redis Cache

Créer un VNet avec l'Azure CLI

bash
# Créer le Resource Group
az group create --name rg-reseau --location francecentral

# Créer le VNet
az network vnet create \
  --resource-group rg-reseau \
  --name mon-vnet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name subnet-public \
  --subnet-prefix 10.0.1.0/24

# Ajouter un sous-réseau privé
az network vnet subnet create \
  --resource-group rg-reseau \
  --vnet-name mon-vnet \
  --name subnet-prive \
  --address-prefix 10.0.2.0/24

Network Security Groups (NSG)

Un NSG filtre le trafic réseau entrant et sortant des sous-réseaux ou des interfaces réseau. Les règles sont évaluées par priorité (100 = haute priorité, 4096 = basse).

bash
# Créer un NSG
az network nsg create \
  --resource-group rg-reseau \
  --name mon-nsg

# Autoriser HTTPS en entrée
az network nsg rule create \
  --resource-group rg-reseau \
  --nsg-name mon-nsg \
  --name allow-https \
  --protocol tcp \
  --direction inbound \
  --priority 100 \
  --source-address-prefix Internet \
  --destination-port-range 443 \
  --access allow

# Refuser tout le reste en entrée (règle de bas priorité)
az network nsg rule create \
  --resource-group rg-reseau \
  --nsg-name mon-nsg \
  --name deny-all-inbound \
  --protocol '*' \
  --direction inbound \
  --priority 4000 \
  --source-address-prefix '*' \
  --destination-port-range '*' \
  --access deny

# Associer le NSG à un sous-réseau
az network vnet subnet update \
  --resource-group rg-reseau \
  --vnet-name mon-vnet \
  --name subnet-public \
  --network-security-group mon-nsg

VNet Peering

Le VNet Peering connecte deux VNets pour qu'ils communiquent comme s'ils étaient sur le même réseau (latence ultra-faible, même région ou régions différentes) :

bash
az network vnet peering create \
  --resource-group rg-reseau \
  --name peering-vnet1-vers-vnet2 \
  --vnet-name vnet1 \
  --remote-vnet vnet2 \
  --allow-vnet-access

🌐 Azure App Service

Concept

App Service est une plateforme PaaS (Platform as a Service) pour héberger des applications web sans gérer de VMs. Azure gère l'OS, les patchs, la scalabilité horizontale.

Langages supportés : .NET, Node.js, Python, Java, PHP, Ruby.

💡 Analogie : App Service, c'est comme héberger son site sur un hébergeur classique, mais avec scalabilité automatique, déploiement depuis GitHub, et intégration avec toute l'infrastructure Azure.

App Service Plan

Un App Service Plan définit les ressources allouées (CPU, RAM, région). Plusieurs applications peuvent partager le même plan.

TierUsageFonctionnalités
Free/SharedDev/testPas de scaling, domaine .azurewebsites.net
BasicDev, faible chargeSSL, domaine custom
StandardProductionAuto-scaling, slots de déploiement, VNet integration
PremiumProduction haute perfInstances plus grandes, Private Endpoints

Déployer une application

bash
# Créer un App Service Plan (Standard S1)
az appservice plan create \
  --resource-group rg-appservice \
  --name mon-plan \
  --sku S1 \
  --is-linux

# Créer une Web App (Node.js 20)
az webapp create \
  --resource-group rg-appservice \
  --plan mon-plan \
  --name mon-app-unique-123 \
  --runtime "NODE:20-lts"

# Déployer depuis un repo GitHub (CI/CD automatique)
az webapp deployment source config \
  --resource-group rg-appservice \
  --name mon-app-unique-123 \
  --repo-url https://github.com/monorg/mon-app \
  --branch main \
  --manual-integration

# Variables d'environnement
az webapp config appsettings set \
  --resource-group rg-appservice \
  --name mon-app-unique-123 \
  --settings DATABASE_URL="postgresql://..." NODE_ENV="production"

# Voir les logs en temps réel
az webapp log tail \
  --resource-group rg-appservice \
  --name mon-app-unique-123

Deployment Slots

Les slots permettent de déployer une nouvelle version sans interruption et de basculer en production sans temps d'arrêt :

bash
# Créer un slot "staging"
az webapp deployment slot create \
  --resource-group rg-appservice \
  --name mon-app-unique-123 \
  --slot staging

# Déployer sur staging, tester, puis basculer en production (swap)
az webapp deployment slot swap \
  --resource-group rg-appservice \
  --name mon-app-unique-123 \
  --slot staging \
  --target-slot production

☸️ AKS - Azure Kubernetes Service

Créer un cluster AKS

bash
# Créer le Resource Group
az group create --name rg-aks --location francecentral

# Créer le cluster AKS (noeud Standard_B2s, 2 noeuds)
az aks create \
  --resource-group rg-aks \
  --name mon-cluster-aks \
  --node-count 2 \
  --node-vm-size Standard_B2s \
  --enable-managed-identity \
  --network-plugin azure \
  --generate-ssh-keys

# Récupérer les credentials kubectl
az aks get-credentials \
  --resource-group rg-aks \
  --name mon-cluster-aks

# Vérifier les noeuds
kubectl get nodes

# Déployer une application
kubectl apply -f deployment.yaml
kubectl get pods

# Supprimer le cluster (stoppe la facturation)
az aks delete --resource-group rg-aks --name mon-cluster-aks --yes

Intégration avec Azure Container Registry (ACR)

bash
# Créer un registry ACR
az acr create \
  --resource-group rg-aks \
  --name monregistryacr123 \
  --sku Basic

# Autoriser AKS à puller depuis ACR
az aks update \
  --resource-group rg-aks \
  --name mon-cluster-aks \
  --attach-acr monregistryacr123

# Construire et pousser une image dans ACR
az acr build \
  --registry monregistryacr123 \
  --image mon-app:v1.0 .

Node Pools

Un cluster AKS peut avoir plusieurs node pools (groupes de noeuds) avec des tailles différentes :

bash
# Ajouter un node pool GPU pour des workloads ML
az aks nodepool add \
  --resource-group rg-aks \
  --cluster-name mon-cluster-aks \
  --name gpunodes \
  --node-count 1 \
  --node-vm-size Standard_NC6s_v3 \
  --node-taints sku=gpu:NoSchedule

📐 Bicep - Infrastructure as Code Azure

Pourquoi Bicep plutôt qu'ARM templates ?

Les templates ARM (Azure Resource Manager) sont en JSON - verbeux et difficiles à écrire. Bicep est un DSL (Domain Specific Language) compilé en ARM, bien plus lisible.

bicep
// Exemple : même ressource en ARM JSON (32 lignes) vs Bicep (8 lignes)
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'monstorageaccount123'
  location: 'francecentral'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Structure d'un fichier Bicep

bicep
// Paramètres (valeurs injectées au déploiement)
@description('Localisation pour toutes les ressources')
param location string = resourceGroup().location

@allowed(['dev', 'staging', 'prod'])
param environment string = 'dev'

@secure()
param adminPassword string

// Variables (calculées)
var prefix = 'monapp-${environment}'
var vmName = '${prefix}-vm'

// Ressource : Resource Group doit exister en amont
resource vnet 'Microsoft.Network/virtualNetworks@2023-06-01' = {
  name: '${prefix}-vnet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
    subnets: [
      {
        name: 'default'
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
    ]
  }
}

// Outputs (valeurs exportées)
output vnetId string = vnet.id
output vnetName string = vnet.name

Déployer un template Bicep

bash
# Installer Bicep CLI
az bicep install

# Valider le template
az bicep build --file main.bicep

# Déployer (mode incremental par défaut)
az deployment group create \
  --resource-group mon-rg \
  --template-file main.bicep \
  --parameters environment=prod adminPassword='MonMotDePasse!'

# Mode what-if : voir les changements AVANT de les appliquer
az deployment group what-if \
  --resource-group mon-rg \
  --template-file main.bicep

# Exporter l'infrastructure existante vers Bicep
az group export --name mon-rg > export.json
az bicep decompile --file export.json

Modules Bicep

Les modules Bicep permettent de réutiliser des blocs d'infrastructure :

bicep
// Appeler un module Bicep
module storage './modules/storage.bicep' = {
  name: 'storageDeployment'
  params: {
    location: location
    storageAccountName: 'monstorageaccount'
  }
}

// Utiliser l'output du module
output storageId string = storage.outputs.storageAccountId

📊 Azure Monitor et Log Analytics

Architecture du monitoring Azure

Ressources Azure
├── Métriques (séries temporelles : CPU, mémoire, requêtes/s)
│   └── Azure Monitor Metrics → Alertes + Dashboards
└── Logs (événements structurés : erreurs, audits)
    └── Log Analytics Workspace → Requêtes KQL + Alertes

Log Analytics et KQL

bash
# Créer un workspace Log Analytics
az monitor log-analytics workspace create \
  --resource-group rg-monitoring \
  --workspace-name mon-workspace \
  --location francecentral

# Connecter une VM pour envoyer ses logs
az monitor diagnostic-settings create \
  --name vm-diagnostics \
  --resource /subscriptions/SUB_ID/resourceGroups/rg/providers/Microsoft.Compute/virtualMachines/ma-vm \
  --workspace /subscriptions/SUB_ID/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/mon-workspace \
  --metrics '[{"category": "AllMetrics", "enabled": true}]'

Exemple de requête KQL (Kusto Query Language) dans Log Analytics :

kusto
// Erreurs applicatives des 24 dernières heures
AppExceptions
| where TimeGenerated > ago(24h)
| where SeverityLevel == "Error"
| summarize count() by bin(TimeGenerated, 1h), Type
| render timechart

📌 Points Clés

  • Les NSG protègent les sous-réseaux et interfaces réseau ; les règles sont prioritaires par numéro
  • App Service est la solution PaaS pour les apps web : pas de VM à gérer, slots de déploiement intégrés
  • AKS = Kubernetes managé sur Azure ; intégrez ACR pour le stockage de vos images
  • Bicep remplace les templates ARM JSON par une syntaxe concise et lisible
  • Log Analytics + KQL pour interroger et corréler les logs de toutes vos ressources

📚 Ressources

  • Documentation VNet
  • Documentation App Service
  • Documentation AKS
  • Documentation Bicep
  • KQL Reference
  • Azure Architecture Center

🚀 Prochaines étapes

Vous maîtrisez les services intermédiaires Azure. Passez au niveau avancé :

  1. Azure Avancé : AKS avancé, Azure DevOps et gouvernance - sécurité, CI/CD et architecture d'entreprise

Exercices Pratiques

3 exercices pour mettre en pratique

01

02 - Déployer une application web avec Azure App Service et Bicep

45 minutesIntermédiaire
02

06 - Virtual Network, sous-réseaux et NSG

40 minutesIntermédiaire
03

07 - Déployer un cluster AKS et sa première application

45 minutesIntermédiaire
Retour aux modules

Sur cette page

  • 🎯 Objectifs
  • 📋 Prérequis
  • 🌐 Virtual Networks (VNet)
  • Architecture réseau Azure
  • Créer un VNet avec l'Azure CLI
  • Network Security Groups (NSG)
  • VNet Peering
  • 🌐 Azure App Service
  • Concept
  • App Service Plan
  • Déployer une application
  • Deployment Slots
  • ☸️ AKS - Azure Kubernetes Service
  • Créer un cluster AKS
  • Intégration avec Azure Container Registry (ACR)
  • Node Pools
  • 📐 Bicep - Infrastructure as Code Azure
  • Pourquoi Bicep plutôt qu'ARM templates ?
  • Structure d'un fichier Bicep
  • Déployer un template Bicep
  • Modules Bicep
  • 📊 Azure Monitor et Log Analytics
  • Architecture du monitoring Azure
  • Log Analytics et KQL
  • 📌 Points Clés
  • 📚 Ressources
  • 🚀 Prochaines étapes