Partager via


Démarrage rapide : Mise à l’échelle des services déployés avec les modèles web Python azd à l’aide de Bicep

Les modèles web azd Python vous permettent de créer rapidement une application web et de la déployer sur Azure. Les azd modèles ont été conçus pour utiliser des options de service Azure à faible coût. Sans aucun doute, vous souhaiterez ajuster les niveaux de service (ou références SKU) pour chacun des services définis dans le modèle pour votre scénario.

Dans ce guide de démarrage rapide, vous allez mettre à jour les fichiers de modèle bicep appropriés pour effectuer un scale-up des services existants et ajouter de nouveaux services à votre déploiement. Ensuite, vous allez exécuter la azd provision commande et afficher la modification que vous avez apportée au déploiement Azure.

Prérequis

Un abonnement Azure - En créer un gratuitement

Vous devez avoir installé les éléments suivants sur votre ordinateur local :

Déploiement d’un modèle

Pour commencer, vous avez besoin d’un déploiement opérationnel azd . Une fois que vous avez cela en place, vous pouvez modifier les fichiers Bicep générés par le azd modèle.

  1. Suivez les étapes 1 à 7 dans l’article de démarrage rapide. À l’étape 2, utilisez le azure-django-postgres-flexible-appservice modèle. Pour votre commodité, voici l’ensemble de la séquence de commandes à émettre à partir de la ligne de commande :

    mkdir azdtest
    cd azdtest
    azd init --template azure-django-postgres-flexible-appservice
    azd auth login
    azd up
    

    Une fois azd up terminé, ouvrez le Portail Azure, accédez à Azure App Service qui a été déployé dans votre nouveau groupe de ressources et prenez note du plan tarifaire App Service (consultez la page Vue d’ensemble du plan App Service, section Essentials, valeur « Plan tarifaire »).

  2. À l’étape 1 de l’article de démarrage rapide, vous avez été invité à créer le dossier azdtest . Ouvrez ce dossier dans Visual Studio Code.

  3. Dans le volet Explorateur, accédez au dossier infra . Observez les sous-dossiers et les fichiers dans le dossier infra .

    Le fichier main.bicep orchestre la création de tous les services déployés lors de l’exécution d’un azd up ou azd provision. Il appelle d’autres fichiers, tels que db.bicep et web.bicep, qui à leur tour appellent des fichiers contenus dans le sous-dossier \core.

    Le sous-dossier \core est une structure de dossiers profondément imbriquée contenant des modèles bicep pour de nombreux services Azure. Certains des fichiers du sous-dossier \core sont référencés par les trois fichiers bicep de niveau supérieur (main.bicep, db.bicep et web.bicep) et certains ne sont pas utilisés du tout dans ce projet.

Mettre à l’échelle un service en modifiant ses propriétés Bicep

Vous pouvez mettre à l’échelle une ressource existante dans votre déploiement en modifiant sa référence SKU. Pour illustrer cela, vous allez remplacer le plan App Service du « plan de service de base » (conçu pour les applications avec des exigences de trafic inférieures et n’ayant pas besoin de fonctionnalités avancées de mise à l’échelle automatique et de gestion du trafic) par le « plan de service standard », conçu pour exécuter des charges de travail de production.

Remarque

Toutes les modifications de référence SKU ne peuvent pas être apportées après le fait. Certaines recherches peuvent être nécessaires pour mieux comprendre vos options de mise à l’échelle.

  1. Ouvrez le fichier web.bicep et recherchez la définition du appService module. En particulier, recherchez le paramètre de propriété :

       sku: {
          name: 'B1'
       }
    

    Remplacez la valeur par B1 S1 la suivante :

       sku: {
          name: 'S1'
       }
    

    Important

    En raison de ce changement, le prix par heure augmente légèrement. Vous trouverez des détails sur les différents plans de service et leurs coûts associés dans la page de tarification App Service.

  2. En supposant que vous disposez déjà de l’application déployée dans Azure, utilisez la commande suivante pour déployer les modifications apportées à l’infrastructure tout en ne redéployant pas le code de l’application lui-même.

    azd provision
    

    Vous ne devez pas être invité à entrer un emplacement et un abonnement. Ces valeurs sont enregistrées dans le fichier .azure<environment-name.env>, où <environment-name> est le nom de l’environnement que vous avez fourni pendant azd init.

  3. Une fois azd provision terminé, vérifiez que votre application web fonctionne toujours. Recherchez également le plan App Service pour votre groupe de ressources et vérifiez que le plan tarifaire est défini sur le plan de service standard (S1).

Ajouter une nouvelle définition de service avec Bicep

Vous pouvez ajouter une nouvelle ressource à votre déploiement en apportant des modifications plus importantes à Bicep dans le projet. Pour illustrer cela, vous allez ajouter une instance de Azure Cache pour Redis à votre déploiement existant en préparation d’une nouvelle fonctionnalité fictive que vous prévoyez d’ajouter à une date ultérieure.

Important

En conséquence de cette modification, vous payez pour une instance de Azure Cache pour Redis jusqu’à ce que vous supprimiez la ressource dans le Portail Azure ou l’utilisationazd down. Vous trouverez des détails sur les différents plans de service et leurs coûts associés dans la page de tarification Azure Cache pour Redis.

  1. Créez un fichier dans le dossier infra nommé redis.bicep. Copiez et collez le code suivant dans le nouveau fichier :

    param name string
    param location string = resourceGroup().location
    param tags object = {}
    param keyVaultName string
    param connStrKeyName string
    param passwordKeyName string
    param primaryKeyKeyName string
    
    @allowed([
      'Enabled'
      'Disabled'
    ])
    param publicNetworkAccess string = 'Enabled'
    
    @allowed([
      'C'
      'P'
    ])
    param skuFamily string = 'C'
    
    @allowed([
      0
      1
      2
      3
      4
      5
      6
    ])
    param skuCapacity int = 1
    @allowed([
      'Basic'
      'Standard'
      'Premium'
    ])
    param skuName string = 'Standard'
    
    param saveKeysToVault bool = true
    
    resource redis 'Microsoft.Cache/redis@2020-12-01' = {
      name: name
      location: location
      properties: {
        sku: {
          capacity: skuCapacity
          family: skuFamily
          name: skuName
        }
        publicNetworkAccess: publicNetworkAccess
        enableNonSslPort: true    
      }
      tags: tags
    }
    
    resource keyVault 'Microsoft.KeyVault/vaults@2022-07-01' existing = {
      name: keyVaultName
    }
    
    resource redisKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = if (saveKeysToVault) {
      name: primaryKeyKeyName
      parent: keyVault
      properties: {
        value: redis.listKeys().primaryKey
      }
    }
    
    resource redisConnStr 'Microsoft.KeyVault/vaults/secrets@2018-02-14' = if (saveKeysToVault) {
      name: connStrKeyName
      parent: keyVault
      properties: {
        value: '${name}.redis.cache.windows.net,abortConnect=false,ssl=true,password=${redis.listKeys().primaryKey}'
      }
    }
    resource redisPassword 'Microsoft.KeyVault/vaults/secrets@2018-02-14' = if (saveKeysToVault) {
      name: passwordKeyName
      parent: keyVault
      properties: {
        value: redis.listKeys().primaryKey
      }
    }
    
    output REDIS_ID string = redis.id
    output REDIS_HOST string = redis.properties.hostName
    
  2. Modifiez le fichier main.bicep pour créer une instance de la ressource « redis ».

    Dans le fichier main.bicep , ajoutez le code suivant sous les accolades de fin associées à la section frontend Web et au-dessus de la section secrets .

    // Caching server
    module redis 'redis.bicep' = {
      name: 'redis'
      scope: resourceGroup
      params: {
        name: replace('${take(prefix, 19)}-rds', '--', '-')
        location: location
        tags: tags
        keyVaultName: keyVault.outputs.name
        connStrKeyName: 'RedisConnectionString'
        passwordKeyName: 'RedisPassword'
        primaryKeyKeyName: 'RedisPrimaryKey'
        publicNetworkAccess: 'Enabled'
        skuFamily: 'C'
        skuCapacity: 1
        skuName: 'Standard'
        saveKeysToVault: true
      }
    }
    
  3. Ajoutez des valeurs de sortie au bas du fichier :

    output REDIS_ID string = redis.outputs.REDIS_ID
    output REDIS_HOST string = redis.outputs.REDIS_HOST
    
  4. Vérifiez que l’intégralité du fichier main.bicep est identique au code suivant :

    targetScope = 'subscription'
    
    @minLength(1)
    @maxLength(64)
    @description('Name which is used to generate a short unique hash for each resource')
    param name string
    
    @minLength(1)
    @description('Primary location for all resources')
    param location string
    
    @secure()
    @description('DBServer administrator password')
    param dbserverPassword string
    
    @secure()
    @description('Secret Key')
    param secretKey string
    
    @description('Id of the user or app to assign application roles')
    param principalId string = ''
    
    var resourceToken = toLower(uniqueString(subscription().id, name, location))
    var prefix = '${name}-${resourceToken}'
    var tags = { 'azd-env-name': name }
    
    resource resourceGroup 'Microsoft.Resources/resourceGroups@2021-04-01' = {
      name: '${name}-rg'
      location: location
      tags: tags
    }
    
    // Store secrets in a keyvault
    module keyVault './core/security/keyvault.bicep' = {
      name: 'keyvault'
      scope: resourceGroup
      params: {
        name: '${take(replace(prefix, '-', ''), 17)}-vault'
        location: location
        tags: tags
        principalId: principalId
      }
    }
    
    module db 'db.bicep' = {
      name: 'db'
      scope: resourceGroup
      params: {
        name: 'dbserver'
        location: location
        tags: tags
        prefix: prefix
        dbserverDatabaseName: 'relecloud'
        dbserverPassword: dbserverPassword
      }
    }
    
    // Monitor application with Azure Monitor
    module monitoring 'core/monitor/monitoring.bicep' = {
      name: 'monitoring'
      scope: resourceGroup
      params: {
        location: location
        tags: tags
        applicationInsightsDashboardName: '${prefix}-appinsights-dashboard'
        applicationInsightsName: '${prefix}-appinsights'
        logAnalyticsName: '${take(prefix, 50)}-loganalytics' // Max 63 chars
      }
    }
    
    // Web frontend
    module web 'web.bicep' = {
      name: 'web'
      scope: resourceGroup
      params: {
        name: replace('${take(prefix, 19)}-appsvc', '--', '-')
        location: location
        tags: tags
        applicationInsightsName: monitoring.outputs.applicationInsightsName
        keyVaultName: keyVault.outputs.name
        appCommandLine: 'entrypoint.sh'
        pythonVersion: '3.12'
        dbserverDomainName: db.outputs.dbserverDomainName
        dbserverUser: db.outputs.dbserverUser
        dbserverDatabaseName: db.outputs.dbserverDatabaseName
      }
    }
    
    // Caching server
    module redis 'redis.bicep' = {
      name: 'redis'
      scope: resourceGroup
      params: {
        name: replace('${take(prefix, 19)}-rds', '--', '-')
        location: location
        tags: tags
        keyVaultName: keyVault.outputs.name
        connStrKeyName: 'RedisConnectionString'
        passwordKeyName: 'RedisPassword'
        primaryKeyKeyName: 'RedisPrimaryKey'
        publicNetworkAccess: 'Enabled'
        skuFamily: 'C'
        skuCapacity: 1
        skuName: 'Standard'
        saveKeysToVault: true
      }
    }
    
    var secrets = [
      {
        name: 'DBSERVERPASSWORD'
        value: dbserverPassword
      }
      {
        name: 'SECRETKEY'
        value: secretKey
      }
    ]
    
    @batchSize(1)
    module keyVaultSecrets './core/security/keyvault-secret.bicep' = [for secret in secrets: {
      name: 'keyvault-secret-${secret.name}'
      scope: resourceGroup
      params: {
        keyVaultName: keyVault.outputs.name
        name: secret.name
        secretValue: secret.value
      }
    }]
    
    output AZURE_LOCATION string = location
    output AZURE_KEY_VAULT_ENDPOINT string = keyVault.outputs.endpoint
    output AZURE_KEY_VAULT_NAME string = keyVault.outputs.name
    output APPLICATIONINSIGHTS_NAME string = monitoring.outputs.applicationInsightsName
    output BACKEND_URI string = web.outputs.uri
    
    output REDIS_ID string = redis.outputs.REDIS_ID
    output REDIS_HOST string = redis.outputs.REDIS_HOST
    
  5. Vérifiez que toutes vos modifications sont enregistrées, puis utilisez la commande suivante pour mettre à jour vos ressources approvisionnées sur Azure :

    azd provision
    

    Remarque

    En fonction de nombreux facteurs, l’ajout d’une instance de Azure Cache pour Redis au déploiement existant peut prendre beaucoup de temps. Lors des tests, nous avons connu des temps d’exécution supérieurs à 20 minutes. Tant que vous ne voyez pas d’erreurs, laissez le processus continuer jusqu’à la fin.

  6. Une fois azd provision terminé, ouvrez le Portail Azure, accédez au groupe de ressources pour votre déploiement et, dans la liste des services, vérifiez que vous disposez maintenant d’une instance de Azure Cache pour Redis.

Cela conclut le démarrage rapide, mais il existe de nombreux services Azure qui peuvent vous aider à créer des applications plus évolutives et prêtes pour la production. Un excellent point de départ serait d’en savoir plus sur Azure Gestion des API, Azure Front Door, Azure CDN et Azure Réseau virtuel, pour en nommer quelques-uns.

Nettoyer les ressources

Nettoyez les ressources créées par le modèle en exécutant la commande azd down .

azd down

La azd down commande supprime les ressources Azure et le workflow GitHub Actions. Lorsque vous y êtes invité, acceptez de supprimer toutes les ressources associées au groupe de ressources.

Vous pouvez également supprimer le dossier azdtest ou l’utiliser comme base pour votre propre application en modifiant les fichiers du projet.