Créer des App Service Plan dans un ASE v3
App Service Plan (ASP) vous permet de créer et d’héberger des applications Web, des backends mobiles et des API RESTful dans le langage de programmation de votre choix sans avoir à gérer l’infrastructure.
App Service Environment (ASE) est une fonctionnalité Azure App Service qui fournit un environnement entièrement isolé et dédié pour exécuter en toute sécurité des applications App Service à grande échelle. Cette capacité peut héberger votre :
- Applications Web Windows
- Applications Web Linux
- Conteneurs Docker
- Application mobile
- Fonctions (Serverless)
Les principaux avantages d’un ASE interne (load balancer interne) sont : isolation et accès réseau sécurisé. Cela nous permet de profiter pleinement d’un service cloud PaaS sans être exposé à l’extérieur (pas d’IP publique sur l’application) et d’accéder en même temps à des ressources on-premises via le pairing de VNET et l’Express Route par exemple.
Il faut privilégier l’utilisation d’ASP dans l’ASE car il est plus simple et souple à gérer qu’une VM. De plus, il offre de nombreuses fonctionnalités prêtes à l’emploi : scaling automatique, zone redondance, load balancing, etc….
Si vous avez besoin d’exposer une ou plusieurs applications de l’ASE, il est recommandé de passer par une Application Gateway avec WAF afin de sécuriser totalement son application.
Mise en place ASE et les droits nécessaires aux équipes applicatives
Dans un contexte d’entreprise, il faudra créer les ASEs dans une souscription partagée gérée par une équipe dédiée (INFRA, DevOps, etc…) car avec l’ASE v3, il est possible de créer des ASPs dans des souscriptions différentes que celle de l’ASE. Ainsi, les équipes applicatives pourront créer leurs ASPs dans leur landing zone en référençant l’ASE hébergée dans la souscription partagée.
Pour que les équipes soient complètement autonomes pour créer des ASPs ainsi que des App Services (Web Apps, API App, Function App, Containers, etc…) et les gérer de manière autonome; ils doivent avoir les rôles suivants sur l’ASE:
Les Service Principals utilisés dans les pipelines CI/CD pour créer des ASPs devront avoir les mêmes rôles aussi.
Aussi, je recommande d’avoir 2 ASEs:
- 1 ASE DEV ou NonProduction ==> cet ASE ne sera pas zone redondant et hébergera tous les ASPs de non production (DEV, HOM, ACC, etc….)
- 1 ASE PROD ==> cet ASE sera zone redondant. Ainsi lorsque vous créez un ASP, il y aura 3 instances minimum crées : une dans chaque zone. Le coût n’est pas négligeable mais il faudra déployer plusieurs App Services App sur les ASPs pour rentabiliser et mutualiser.
En terme d’optimisation de coût, l’ASE v3 supporte les instances réservées et les Saving Plans.
Code Bicep pour créer un ASP
Partons des pré-requis suivants:
- 2 ASEs (ase-nonprod-01 et ase-prod-01) créés dans la souscription avec l’id 8364de18-b22e-40ea-a2ba-d3744f33df98 et dans le resource group rg-ases
- Si vous ne connaissez pas Bicep, je vous recommande le parcours d’apprentissage de Microsoft : Learn Bicep.
Voici le Bicep nécessaire pour créer un ASP sur un des ASEs
param aspName string
@allowed([
'windows'
'linux'
])
param operatingSystem string
@allowed([
'I1v2'
'I2v2'
'I3v2'
])
param appServicePlanSize string = 'I1v2'
@allowed([
'Production'
'NonProduction'
])
param aseEnvironment string
param location string = resourceGroup().location
param tags object = {}
var aseEnvironmentConfigurationMap = {
Production: {
name: 'ase-prod-001'
resourceGroup : 'rg-ases'
}
NonProduction: {
name: 'ase-nonprod-001'
resourceGroup : 'rg-ases'
}
}
var aseSuscriptionId = '8364de18-b22e-40ea-a2ba-d3744f33df98'
resource hostingEnvironment 'Microsoft.Web/hostingEnvironments@2021-03-01' existing = {
name: aseEnvironmentConfigurationMap[aseEnvironment].name
scope: resourceGroup(aseSuscriptionId, aseEnvironmentConfigurationMap[aseEnvironment].resourceGroup)
}
resource appServicePlan 'Microsoft.Web/serverfarms@2021-03-01' = {
name: aspName
location: location
tags: tags
sku: {
name: appServicePlanSize
tier: 'IsolatedV2'
capacity: aseEnvironment == 'NonProduction' ? 1 : 3
}
properties: {
hostingEnvironmentProfile: {
id: hostingEnvironment.id
}
perSiteScaling: true
reserved: operatingSystem == 'windows' ? false : true
}
}
output id string = appServicePlan.idCependant, on ne peut pas le distribuer ainsi aux équipes applicatives. Il faut trouver un moyen pérenne de le partager afin de garantir sa maintenance et sa montée en version si nécessaire.
Il existe 2 moyens pour partager le code Bicep produit en modules utilisables pour les équipes applicatives :
- Azure Container Registry
- Template Specs
Dans notre cas, nous allons utiliser les Template Specs car ça permet de déployer aussi directement depuis le portail Azure.
Pour ce faire, nous allons utiliser az cli pour publier le code Bicep de l’ASP en tant que Template Spec. La publication se fera dans la souscription partagée (la même que l’ASE) dans un resource group que nous nommerons rg-templatespecs. Il faudra donner le rôle Reader sur ce resource group aux équipes applicatives et aux service principals de déploiement.
$subscriptionId = '8364de18-b22e-40ea-a2ba-d3744f33df98'
az login
az account set -s $subscriptionId
az ts create --name ASPonASE `
--resource-group rg-templatespecs `
--description "Deploy an ASP on the ASEs" `
--template-file main.bicep `
--version 2022-12-02Créer un ASP via le module Bicep (template spec)
Pour ce faire, nous aurons besoin de mettre en place le fichier bicepconfig.json en intégrant la souscriptionId de la souscription partagée où le Template Spec est publié et le nom du resource group :
{
"moduleAliases": {
"ts": {
"CoreSpecs": {
"subscription": "8364de18-b22e-40ea-a2ba-d3744f33df98",
"resourceGroup": "rg-templatespecs"
}
}
}
}Aussi, je vous recommande fortement d’activer le linter pour valider automatiquement vos fichiers Bicep ==> linter settings.
Après avoir configuré le fichier bicepconfig.json, on peut créer le fichier bicep pour déployer l’ASP de manière très simple. Appelons ce ficher appservice.bicep et voici son contenu pour déployer un ASP dans l’ASE de NonProduction:
param aspName string = 'asp-nonprod-win-01'
param operatingSystem string = 'windows'
param appServicePlanSize string = 'I1v2'
param aseEnvironment string = 'NonProduction'
param location string = resourceGroup().location
param tags object = {}
module appServicePlan 'ts/CoreSpecs:ASPonASE:2022-12-02' = {
name: 'deploy-appserviceplan'
params: {
aspName: aspName
aseEnvironment: aseEnvironment
operatingSystem: operatingSystem
appServicePlanSize: appServicePlanSize
location: location
tags: tags
}
}Comme vous pouvez le voir, le fichier Bicep des équipes applicatives est très simple avec le minimum d’informations requis. Par conséquent, le développeur peut créer l’ASP dans sa landing zone avec les commandes suivantes:
$landingZoneSuscriptionId = "00000-00-....."
$resourceGroup = 'rg-<appname>-nonprod'
az login
az account set -s $landingZoneSuscriptionId
az deployment group create --resource-group $resourceGroup `
--template-file .\appservice.bicep Pour déployer un ASP dans l’ASE de Production, il faut surcharger les paramètres de appservice.bicep. Il est recommandé d’utiliser un fichier de paramètres pour la production parameters.prod.json avec le contenu suivant par exemple :
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"aspName": {
"value": "asp-prod-win-01"
},
"operatingSystem": {
"value": "windows"
},
"appServicePlanSize": {
"value": "I1v2"
},
"aseEnvironment": {
"value": "Production"
}
}
}Et le déploiement se fera avec la commande suivante :
az deployment group create --resource-group $resourceGroup `
--template-file .\appservice.bicep `
--parameters .\parameters.prod.jsonOrganisation du code source
Il faudrait 2 repositories:
- bicep-modules : repository central qui contient les modules Bicep pour toutes les équipes et qui sont publiées comme Template Specs dans Azure. Le but est d’éviter que chaque équipe recrée de son côté les mêmes modules. Ainsi, nous pouvons mutualiser et tout le monde pourra l’enrichir ou corriger des bugs via pull requests (inner sourcing :)).
- project-startup-template : un repository template configuré pour utiliser les modules Bicep publiés dans Azure. Les équipes applicatives utiliseront ce template pour démarrer leur projet.
Conclusion
Nous avons vu comment comment mettre à disposition des équipes applications un module Bicep pour créer un ASP dans leur landing zone en toute autonomie tout en respectant les bonnes pratiques.
Dans les prochains articles, je vous montrerai comment créer les modules Bicep pour les App Service Apps (We Apps, API App, Function Apps, Containers, etc….) et les mettre à disposition des équipes de développement. Je montrerai aussi comment l’intégrer dans une pipeline CI/CD DevOps.
