Compartilhar via

Guia de início rápido: dimensionando serviços implantados com os modelos da Web do azd Python usando o Bicep

  • Artigo

Os modelos Web azd Python permitem que você crie rapidamente um novo aplicativo Web e implante-o no Azure. Os azd modelos foram projetados para usar opções de serviço de baixo custo do Azure. Sem dúvida, convém ajustar os níveis de serviço (ou skus) para cada um dos serviços definidos no modelo para o seu cenário.

Neste Guia de início rápido, você atualizará os arquivos de modelo de bíceps apropriados para expandir os serviços existentes e adicionar novos serviços à sua implantação. Em seguida, você executará o azd provision comando e exibirá a alteração feita na implantação do Azure.

Pré-requisitos

Uma assinatura do Azure – crie uma gratuitamente

Você deve ter o seguinte instalado no computador local:

Implantar um modelo

Para começar, você precisa de uma implantação de trabalho azd . Depois de ter isso em vigor, você é capaz de modificar os arquivos Bicep gerados pelo azd modelo.

  1. Siga as etapas 1 a 7 no artigo Guia de início rápido. Na etapa 2, use o azure-django-postgres-flexible-appservice modelo. Para sua conveniência, aqui está toda a sequência de comandos a serem emitidos a partir da linha de comando:

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

    Quando azd up terminar, abra o portal do Azure, navegue até o Serviço de Aplicativo do Azure que foi implantado em seu novo Grupo de Recursos e anote o plano de preços do Serviço de Aplicativo (consulte a página Visão geral do plano do Serviço de Aplicativo, seção Essentials, valor "Plano de preços").

  2. Na etapa 1 do artigo Guia de início rápido, você foi instruído a criar a pasta azdtest . Abra essa pasta no Visual Studio Code.

  3. No painel Explorer, navegue até a pasta infra . Observe as subpastas e arquivos na pasta infra .

    O arquivo main.bicep orquestra a criação de todos os serviços implantados ao executar um azd up ou azd provision. Ele chama outros arquivos, como db.bicep e web.bicep, que por sua vez chamam arquivos contidos na subpasta \core.

    A subpasta \core é uma estrutura de pastas profundamente aninhada que contém modelos de bíceps para muitos serviços do Azure. Alguns dos arquivos na subpasta \core são referenciados pelos três arquivos bicep de nível superior (main.bicep, db.bicep e web.bicep) e alguns não são usados neste projeto.

Dimensionar um serviço modificando suas propriedades Bicep

Você pode dimensionar um recurso existente em sua implantação alterando sua SKU. Para demonstrar isso, você alterará o plano do Serviço de Aplicativo do "Plano de Serviço Básico" (projetado para aplicativos com requisitos de tráfego mais baixos e que não precisam de recursos avançados de dimensionamento automático e gerenciamento de tráfego) para o "Plano de Serviço Padrão", projetado para executar cargas de trabalho de produção.

Observação

Nem todas as alterações de SKU podem ser feitas após o fato. Algumas pesquisas podem ser necessárias para entender melhor suas opções de escala.

  1. Abra o arquivo web.bicep e localize a definição do appService módulo. Em particular, procure a configuração da propriedade:

       sku: {
      name: 'B1'
   }

    Altere o valor de B1 para da S1 seguinte maneira:

       sku: {
      name: 'S1'
   }

    Importante

    Como resultado dessa mudança, o preço por hora aumentará ligeiramente. Detalhes sobre os diferentes planos de serviço e seus custos associados podem ser encontrados na página de preços do Serviço de Aplicativo.

  2. Supondo que você já tenha o aplicativo implantado no Azure, use o comando a seguir para implantar alterações na infraestrutura sem reimplantar o próprio código do aplicativo.

    azd provision

    Não deve ser solicitada uma localização e uma subscrição. Esses valores são salvos no arquivo .azure<environment-name.env> onde <environment-name> é o nome do ambiente fornecido durante azd inito .

  3. Quando azd provision estiver concluído, confirme se o aplicativo Web ainda funciona. Encontre também o Plano do Serviço de Aplicativo para seu Grupo de Recursos e confirme se o Plano de Preços está definido como o Plano de Serviço Padrão (S1).

Adicionar uma nova definição de serviço com o Bicep

Você pode adicionar um novo recurso à sua implantação fazendo alterações maiores no Bicep no projeto. Para demonstrar isso, você adicionará uma instância do Cache do Azure para Redis à sua implantação existente em preparação para um novo recurso fictício que planeja adicionar em alguma data futura.

Importante

Como resultado dessa alteração, você pagará por uma instância do Cache do Azure para Redis até excluir o recurso no portal do Azure ou usar azd downo . Detalhes sobre os diferentes planos de serviço e seus custos associados podem ser encontrados na página de preços do Cache do Azure para Redis.

  1. Crie um novo arquivo na pasta infra chamado redis.bicep. Copie e cole o seguinte código no novo arquivo:

    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. Modifique o arquivo main.bicep para criar uma instância do recurso "redis".

    No arquivo main.bicep, adicione o seguinte código abaixo das chaves finais associadas à seção de front-end da Web e acima da seção 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. Adicione valores de saída à parte inferior do arquivo:

    output REDIS_ID string = redis.outputs.REDIS_ID
output REDIS_HOST string = redis.outputs.REDIS_HOST

  4. Confirme se o arquivo main.bicep inteiro é idêntico ao seguinte código:

    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. Verifique se todas as alterações foram salvas e use o seguinte comando para atualizar seus recursos provisionados no Azure:

    azd provision

    Observação

    Dependendo de muitos fatores, adicionar uma instância do Cache do Azure para Redis à implantação existente pode levar muito tempo. Nos testes, experimentamos tempos de execução superiores a 20 minutos. Contanto que você não veja nenhum erro, permita que o processo continue até a conclusão.

  6. Quando azd provision concluir, abra o portal do Azure, navegue até o Grupo de Recursos para sua implantação e, na lista de serviços, confirme se você agora tem uma instância do Cache do Azure para Redis.

Isso conclui o Guia de início rápido, no entanto, há muitos serviços do Azure que podem ajudá-lo a criar aplicativos mais escalonáveis e prontos para produção. Um ótimo lugar para começar seria aprender sobre o Gerenciamento de API do Azure, o Azure Front Door, a CDN do Azure e a Rede Virtual do Azure, para citar alguns.

Limpar os recursos

Limpe os recursos criados pelo modelo executando o comando azd down .

azd down

O azd down comando exclui os recursos do Azure e o fluxo de trabalho de Ações do GitHub. Quando solicitado, concorde em excluir todos os recursos associados ao grupo de recursos.

Você também pode excluir a pasta azdtest ou usá-la como base para seu próprio aplicativo, modificando os arquivos do projeto.

Conteúdo relacionado