Desanexar e excluir recursos de uma pilha de implantação

  • 7 minutos

As alterações continuam com o aplicativo de depósitos. A equipe decidiu remover recursos do aplicativo. Alguns dos recursos precisam continuar a existir no Azure, enquanto outros podem ser excluídos com segurança. Você precisa saber mais sobre como o Azure lida com recursos que uma pilha de implantação não gerencia mais.

Nesta unidade, você aprenderá a usar o controle de como o Azure lida com recursos desanexados de uma pilha de implantação usando o parâmetro action on unmanage.

Observação

Os comandos nesta unidade são mostrados para ilustrar conceitos. Não execute os comandos ainda. Você praticará o que aprendeu aqui em breve.

Revisão de action on unmanage

Com pilhas de implantação, o parâmetro action on unmanage é usado para controlar como o Azure lida com recursos desanexados, grupos de recursos e grupos de gerenciamento. Você pode definir o parâmetro action on unmanage ao criar, modificar ou excluir uma pilha de implantação. Todas as três operações têm a capacidade de definir o comportamento do parâmetro action on unmanage. Tenha em mente que o último conjunto de valores tem precedência.

Há três valores possíveis para o parâmetro --action-on-unmanage:

  • deleteAll - exclui recursos, grupos de recursos e grupos de gerenciamento
  • deleteResources - exclui recursos, mas desanexa grupos de recursos e grupos de gerenciamento
  • detachAll – desanexa todos os recursos, grupos de recursos e grupos de gerenciamento

Há três valores possíveis para o parâmetro -ActionOnUnmanage:

  • DeleteAll - exclui recursos, grupos de recursos e grupos de gerenciamento
  • DeleteResources - exclui recursos, mas desanexa grupos de recursos e grupos de gerenciamento
  • DetachAll – desanexa todos os recursos, grupos de recursos e grupos de gerenciamento

Desanexar um recurso gerenciado

Um recurso desanexado, também conhecido como um recurso não gerenciado, é um recurso que não é mais rastreado ou gerenciado por uma pilha de implantação, mas ainda existe no Azure. O comportamento padrão das pilhas de implantação é desanexar recursos em vez de excluir. Por exemplo, talvez seja necessário manter o recurso para que você possa usá-lo em outra pilha de implantação no futuro ou talvez seja necessário verificar manualmente se os seus dados podem ser excluídos com segurança.

Há dois valores do parâmetro action on unmanage que definem recursos, grupos de recursos e grupos de gerenciamento para desanexar quando a pilha de implantação não os gerencia mais.

As pilhas de implantação não podem excluir segredos do cofre de chaves. Se você estiver removendo segredos do cofre de chaves de um modelo, execute também o comando de atualização/exclusão da pilha de implantação com o modo de desanexação.

  • deleteResources – exclui recursos, mas desanexa grupos de recursos e grupos de gerenciamento
  • detachAll – desanexa todos os recursos, grupos de recursos e grupos de gerenciamento

Usar deleteResources ou detachAll ao criar, modificar ou excluir suas pilhas de implantação oferece alguma proteção adicional contra exclusão acidental. Considere o nosso cenário da última unidade. Adicionamos um workspace do Log Analytics existente à nossa pilha de implantação. O workspace é usado por outros aplicativos, não apenas pelo aplicativo de depósitos. Ele precisa persistir após a vida útil do aplicativo. Ao usar detachAll como o parâmetro action on unmanage, os recursos necessários continuam a existir no Azure.

  • DeleteResources – exclui recursos, mas desanexa grupos de recursos e grupos de gerenciamento
  • DetachAll – desanexa todos os recursos, grupos de recursos e grupos de gerenciamento

Usar DeleteResources ou DetachAll ao criar, modificar ou excluir suas pilhas de implantação oferece alguma proteção adicional contra exclusão acidental. Considere o nosso cenário da última unidade. Adicionamos um workspace do Log Analytics existente à nossa pilha de implantação. O workspace é usado por outros aplicativos, não apenas pelo aplicativo de depósitos. Ele precisa persistir após a vida útil do aplicativo. Ao usar DetachAll como o parâmetro action on unmanage, os recursos necessários continuam a existir no Azure.

Vamos considerar o nosso arquivo Bicep da última unidade. O arquivo de modelo define um plano do serviço de aplicativo, um aplicativo Web, um servidor SQL do Azure e um banco de dados, um workspace do Log Analytics e uma instância do Application Insights. Digamos que precisamos remover o workspace do Log Analytics e a instância do Application Insights que criamos na última unidade. Editamos o nosso arquivo Bicep, removendo o código realçado que faz referência ao nosso aplicativo Web.

// Parameters
@description('The location for all resources.')
param location string = 'eastus'

@description('The name of the SQL database.')
param sqlDatabaseName string = 'sqldb-${uniqueString(resourceGroup().id)}'

@description('The password of the admin user.')
param sqlServerAdminUserName string

@description('The name of the admin user.')
@secure()
param sqlServerAdminPassword string

@description('The name of the SQL server.')
param sqlServerName string = 'sql-${uniqueString(resourceGroup().id)}'

@description('The name of the web application.')
param webApplicationName string = 'webapp-${uniqueString(resourceGroup().id)}'

// Variables
@description('The name of the Application Insights instance.')
var applicationInsightsName = 'appinsights-deposits'

@description('The name of the app service plan.')
var appServicePlanName = 'plan-deposits'

@description('The name of the Log Analytics Workspace.')
var logAnalyticsWorkspaceName = 'log-deposits'

// Resource - App Service Plan
resource appServicePlan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: appServicePlanName
  location: location
  sku: {
    name: 'S1'
    capacity: 1
  }
}

// Resource - Web App
resource webApplication 'Microsoft.Web/sites@2023-12-01' = {
  name: webApplicationName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: applicationInsights.properties.InstrumentationKey
        }     
      ]
    }    
  }
}

// Resource - SQL Server
resource sqlServer 'Microsoft.Sql/servers@2021-11-01' ={
  name: sqlServerName
  location: location
  properties: {
    administratorLogin: sqlServerAdminUserName
    administratorLoginPassword: sqlServerAdminPassword
  }
}

// Resource - SQL Database
resource sqlServerDatabase 'Microsoft.Sql/servers/databases@2021-11-01' = {
  parent: sqlServer
  name: sqlDatabaseName
  location: location
  sku: {
    name: 'Standard'
    tier: 'Standard'
  }
}

// Resource - Log Analytics Workspace
resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2023-09-01' = {
  name: logAnalyticsWorkspaceName
  location: location
  properties: {
    retentionInDays: 30
    sku: {
      name: 'PerGB2018'
    }
  }
}

// Resource - Application Insights
resource applicationInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: applicationInsightsName
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: logAnalyticsWorkspace.id
  }
}

Para aplicar as alterações, precisamos atualizar a pilha de implantação. Para atualizar uma pilha de implantação usando a CLI do Azure, use o comando.az stack group create.

az stack group create \
    --name stack-deposits \
    --resource-group rg-depositsApplication \
    --template-file ./main.bicep \
    --action-on-unmanage detachAll \
    --deny-settings-mode none

Após a conclusão da operação de atualização, a pilha de implantação não gerencia mais o workspace do Log Analytics e a instância do Application Insights. Em nosso comando, usamos --action-on-unmanage detachAll para especificar como o Azure lida com recursos que uma pilha de implantação não gerencia mais. Neste caso, os recursos são desanexados da pilha de implantação, mas ainda existem no grupo de recursos.

Para aplicar as alterações, precisamos atualizar a pilha de implantação. Para atualizar uma pilha de implantação usando o Azure PowerShell, use o comando.Set-AzResourceGroupDeploymentStack.

Set-AzResourceGroupDeploymentStack `
    -Name stack-deposits `
    -ResourceGroupName rg-depositsApplication `
    -TemplateFile ./main.bicep `
    -ActionOnUnmanage DetachAll `
    -DenySettingsMode None

Após a conclusão da operação de atualização, a pilha de implantação não gerencia mais o workspace do Log Analytics e a instância do Application Insights. Em nosso comando, usamos -ActionOnUnmanage DetachAll para especificar como o Azure lida com recursos que uma pilha de implantação não gerencia mais. Neste caso, os recursos são desanexados da pilha de implantação, mas ainda existem no grupo de recursos.

Excluir um recurso gerenciado

As pilhas de implantação fornecem limpeza de recursos confiáveis. Ao atualizar ou excluir uma pilha de implantação, você também pode excluir os recursos gerenciados, os grupos de recursos e os grupos de gerenciamento. Há dois valores do parâmetro action on unmanage que definem recursos, grupos de recursos e grupos de gerenciamento a serem excluídos quando a pilha de implantação não os gerencia mais.

  • deleteAll – exclui recursos, grupos de recursos e grupos de gerenciamento
  • deleteResources – exclui recursos, mas desanexa grupos de recursos e grupos de gerenciamento

Considere o nosso aplicativo de depósitos. Digamos que a equipe de desenvolvimento decida usar um Banco de Dados do Azure para PostgreSQL em vez do Banco de Dados SQL do Azure. Precisamos primeiro atualizar nossa pilha de implantação para remover e excluir totalmente o servidor SQL do Azure e o banco de dados do Azure. Para realizar esse comportamento, use o parâmetro action on unmanage deleteAll ou deleteResources ao atualizar ou excluir a pilha de implantação.

  • DeleteAll – exclui recursos, grupos de recursos e grupos de gerenciamento
  • DeleteResources – exclui recursos, mas desanexa grupos de recursos e grupos de gerenciamento

Considere o nosso aplicativo de depósitos. Digamos que a equipe de desenvolvimento decida usar um Banco de Dados do Azure para PostgreSQL em vez do Banco de Dados SQL do Azure. Precisamos primeiro atualizar nossa pilha de implantação para remover e excluir totalmente o servidor SQL do Azure e o banco de dados do Azure. Para realizar esse comportamento, use o parâmetro action on unmanage DeleteAll ou DeleteResources ao atualizar ou excluir a pilha de implantação.

Vamos considerar o nosso arquivo Bicep da seção anterior. O arquivo de modelo define um plano do serviço de aplicativo, um aplicativo Web e um servidor SQL do Azure e um banco de dados. Digamos que precisamos remover o servidor SQL do Azure e o banco de dados. Editamos o nosso arquivo Bicep, removendo o código realçado que faz referência ao nosso aplicativo Web.

// Parameters
@description('The location for all resources.')
param location string = 'eastus'

@description('The name of the SQL database.')
param sqlDatabaseName string = 'sqldb-${uniqueString(resourceGroup().id)}'

@description('The password of the admin user.')
param sqlServerAdminUserName string

@description('The name of the admin user.')
@secure()
param sqlServerAdminPassword string

@description('The name of the SQL server.')
param sqlServerName string = 'sql-${uniqueString(resourceGroup().id)}'

@description('The name of the web application.')
param webApplicationName string = 'webapp-${uniqueString(resourceGroup().id)}'

// Variables
@description('The name of the app service plan.')
var appServicePlanName = 'plan-deposits'

// Resource - App Service Plan
resource appServicePlan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: appServicePlanName
  location: location
  sku: {
    name: 'F1'
    capacity: 1
  }
}

// Resource - Web App
resource webApplication 'Microsoft.Web/sites@2023-12-01' = {
  name: webApplicationName
  location: location
  properties: {
    serverFarmId: appServicePlan.id  
  }
}

// Resource - SQL Server
resource sqlServer 'Microsoft.Sql/servers@2021-11-01' ={
  name: sqlServerName
  location: location
  properties: {
    administratorLogin: sqlServerAdminUserName
    administratorLoginPassword: sqlServerAdminPassword
  }
}

// Resource - SQL Database
resource sqlServerDatabase 'Microsoft.Sql/servers/databases@2021-11-01' = {
  parent: sqlServer
  name: sqlDatabaseName
  location: location
  sku: {
    name: 'Standard'
    tier: 'Standard'
  }
}

Ficamos com o seguinte código em nosso arquivo:

// Parameters
@description('The location for all resources.')
param location string = 'eastus'

@description('The name of the web application.')
param webApplicationName string = 'webapp-${uniqueString(resourceGroup().id)}'

// Variables
@description('The name of the app service plan.')
var appServicePlanName = 'plan-deposits'

// Resource - App Service Plan
resource appServicePlan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: appServicePlanName
  location: location
  sku: {
    name: 'F1'
    capacity: 1
  }
}

// Resource - Web App
resource webApplication 'Microsoft.Web/sites@2023-12-01' = {
  name: webApplicationName
  location: location
  properties: {
    serverFarmId: appServicePlan.id  
  }
}

Para aplicar as alterações, precisamos atualizar a pilha de implantação. Para atualizar uma pilha de implantação usando a CLI do Azure, use o comando.az stack group create. Desta vez, usamos --action-on-unmanage deleteAll em vez de --action-on-unmanage detachAll

az stack group create \
    --name stack-deposits \
    --resource-group rg-depositsApplication \
    --template-file ./main.bicep \
    --action-on-unmanage deleteAll \
    --deny-settings-mode none

Após a conclusão da operação de atualização, os únicos recursos que permanecem são o plano do serviço de aplicativo e o aplicativo Web. Em nosso comando, usamos --action-on-unmanage deleteAll para especificar como o Azure lida com recursos que a pilha de implantação não gerencia mais. Neste caso, os recursos são excluídos da pilha de implantação e do Azure.

Para aplicar as alterações, precisamos atualizar a pilha de implantação. Para atualizar uma pilha de implantação usando o Azure PowerShell, use o comando.Set-AzResourceGroupDeploymentStack.

Set-AzResourceGroupDeploymentStack `
    -Name stack-deposits `
    -ResourceGroupName rg-depositsApplication `
    -TemplateFile ./main.bicep `
    -ActionOnUnmanage DeleteAll `
    -DenySettingsMode None

Após a conclusão da operação de atualização, os únicos recursos que permanecem são o plano do serviço de aplicativo e o aplicativo Web. Em nosso comando, usamos -ActionOnUnmanage DeleteAll para especificar como o Azure lida com recursos que a pilha de implantação não gerencia mais. Neste caso, os recursos são excluídos da pilha de implantação e do Azure.