Utilizar módulos na Automatização do Azure

Nota

A partir de 1º de fevereiro de 2025, a Automação do Azure descontinuará a execução de todos os runbooks que usam módulos do AzureRM. A partir de 1º de novembro de 2024, você não poderá criar novos runbooks usando módulos do AzureRM. O módulo AzureRM do PowerShell foi oficialmente preterido a partir de 29 de fevereiro de 2024. Recomendamos que você migre do módulo AzureRM para o módulo Az PowerShell para garantir suporte e atualizações contínuos. Embora o módulo AzureRM ainda possa funcionar, ele não é mais mantido ou suportado, e o uso contínuo do módulo AzureRM é por conta e risco do usuário. Para obter mais informações, veja Recursos de migração para obter documentação de orientação sobre a transição para o módulo Az.

A Automação do Azure usa vários módulos do PowerShell para habilitar cmdlets em runbooks e recursos DSC em configurações DSC. Os módulos suportados incluem:

• Azure PowerShell Az.Automation.
• Azure PowerShell AzureRM.Automation.
• Outros módulos do PowerShell.
• Módulo interno Orchestrator.AssetManagement.Cmdlets .
• Módulos Python 2.
• Módulos personalizados que você cria.

Quando você cria uma conta de Automação, a Automação do Azure importa alguns módulos por padrão. Consulte Módulos padrão.

Importante

A nova experiência de ambiente de tempo de execução permite gerenciar módulos e pacotes, permitindo que você configure o ambiente de execução de tarefas. Na nova experiência, as lâminas Módulos e Pacotes não estão disponíveis. Para gerenciar módulos e pacotes, consulte Gerenciar ambiente de tempo de execução e runbooks associados.

Sandboxes

Quando a automação executa trabalhos de compilação de runbook e DSC, ela carrega os módulos em sandboxes onde os runbooks podem ser executados e as configurações de DSC podem compilar. A automação também coloca automaticamente todos os recursos DSC em módulos no servidor de receção DSC. As máquinas podem extrair os recursos quando aplicam as configurações DSC.

O sandbox na nuvem suporta um máximo de 48 chamadas do sistema e restringe todas as outras chamadas por motivos de segurança. Outras funcionalidades, como gerenciamento de credenciais e algumas redes, não são suportadas na área restrita da nuvem.

Devido ao número de módulos e cmdlets incluídos, é difícil saber de antemão qual dos cmdlets fará chamadas sem suporte. Geralmente, vimos problemas com cmdlets que exigem acesso elevado, exigem uma credencial como parâmetro ou cmdlets relacionados à rede. Não há suporte para cmdlets que executam operações de rede de pilha completa na área restrita, incluindo Connect-AipService do módulo AIPService PowerShell e Resolve-DnsName do módulo DNSClient.

Estas são limitações conhecidas com a sandbox. A solução alternativa recomendada é implantar um Runbook Worker híbrido ou usar o Azure Functions.

Importante

Não inclua a palavra-chave "AzureRm" em nenhum script projetado para ser executado com o módulo Az. A inclusão da palavra-chave, mesmo em um comentário, pode fazer com que o AzureRm carregue e, em seguida, entre em conflito com o módulo Az.

Módulos padrão

Todas as novas contas de automação têm a versão mais recente do módulo PowerShell Az importada por padrão. O módulo Az substitui o AzureRM e é o módulo recomendado para usar com o Azure. Os módulos padrão na nova conta de automação incluem os 24 módulos AzureRM existentes e os módulos Az 60+.

Há uma opção nativa para atualizar módulos para o módulo Az mais recente pelo usuário para contas de automação. A operação lidará com todas as dependências do módulo no back-end, removendo assim os aborrecimentos de atualizar os módulos manualmente ou executar o runbook para atualizar os módulos do Azure.

Se a conta de Automação existente tiver apenas módulos do AzureRM, a opção Atualizar módulos Az atualizará a conta de Automação com a versão selecionada pelo usuário do módulo Az.

Se a conta de Automação existente tiver AzureRM e alguns módulos Az, a opção importará os módulos Az restantes para a conta de Automação. Os módulos Az existentes terão preferência e a operação de atualização não atualizará esses módulos. Isso é para garantir que a operação do módulo de atualização não leve a nenhuma falha de execução do runbook atualizando inadvertidamente um módulo que está sendo usado por um runbook. A maneira recomendada para esse cenário é primeiro excluir os módulos Az existentes e, em seguida, executar as operações de atualização para obter o módulo Az mais recente importado na conta de automação. Esses tipos de módulo, não importados por padrão, são chamados de Personalizados. Os módulos personalizados sempre terão preferência sobre os módulos padrão .

Por exemplo: Se você já tiver o módulo importado com a Az.Aks versão 2.3.0 que é fornecida pelo módulo Az 6.3.0 e tentar atualizar o módulo Az para a versão 6.4.0 mais recente. A operação de atualização importará todos os módulos Az do pacote 6.4.0, exceto Az.Aks. Para ter a versão mais recente do Az.Aks, primeiro exclua o módulo existente e, em seguida, execute a operação de atualização, ou você também pode atualizar este módulo separadamente, conforme descrito em Importar módulos Az para importar uma versão diferente de um módulo específico.

A tabela a seguir lista os módulos que a Automação do Azure importa por padrão quando você cria sua conta de Automação. A automação pode importar versões mais recentes desses módulos. No entanto, não é possível remover a versão original da sua conta de automação, mesmo que exclua uma versão mais recente.

Os módulos padrão também são conhecidos como módulos globais. No portal do Azure, a propriedade Global module será true ao exibir um módulo que foi importado quando a conta foi criada.

Nota

Não recomendamos alterar módulos e runbooks em contas de automação usadas para implantação das VMs Start /Stop fora do horário de expediente

Nome do módulo	Versão
Az.*	Veja a lista completa em Detalhes do pacote na Galeria do PowerShell
AuditPolicyDsc	1.1.0.0
Azure	1.0.3
Azure.Storage	1.0.3
AzureRM.Automation	1.0.3
AzureRM.Compute	1.2.1
AzureRM.Profile	1.0.3
AzureRM.Resources	1.0.3
AzureRM.Sql	1.0.3
AzureRM.Storage	1.0.3
ComputerManagementDsc	5.0.0.0
GPRegistryPolicyParser	0.2
Microsoft.PowerShell.Core	0
Microsoft.PowerShell.Diagnostics
Microsoft.PowerShell.Management
Microsoft.PowerShell.Security
Microsoft.PowerShell.Utility
Microsoft.WSMan.Management
Cmdlets Orchestrator.AssetManagement.Cmdlets	1
PSDscRecursos	2.9.0.0
SecurityPolicyDsc	2.1.0.0
StateConfigCompositeResources	1
xDSCDomainjoin	1.1
xPowerShellExecutionPolicy	1.1.0.0
xRemoteDesktopAdmin	1.1.0.0

Cmdlets internos

A Automação do Azure dá suporte a cmdlets internos que só estão disponíveis quando você executa runbooks no ambiente de área restrita do Azure ou em um Runbook Worker Híbrido do Windows. O módulo Orchestrator.AssetManagement.Cmdlets interno é instalado por padrão na sua conta de automação e quando a função Windows Hybrid Runbook Worker é instalada na máquina.

A tabela a seguir define os cmdlets internos. Estes cmdlets foram concebidos para serem utilizados em vez dos cmdlets do Azure PowerShell para interagir com os recursos da sua conta de Automatização. Eles podem recuperar segredos de variáveis criptografadas, credenciais e conexões criptografadas.

Nome	Descrição
Get-AutomationCertificate	Get-AutomationCertificate [-Name] <string> [<CommonParameters>]
Get-AutomationConnection	Get-AutomationConnection [-Name] <string> [-DoNotDecrypt] [<CommonParameters>]
Get-AutomationPSCredential	Get-AutomationPSCredential [-Name] <string> [<CommonParameters>]
Get-AutomationVariable	Get-AutomationVariable [-Name] <string> [-DoNotDecrypt] [<CommonParameters>]
Set-AutomationVariable	Set-AutomationVariable [-Name] <string> -Value <Object> [<CommonParameters>]
Start-AutomationRunbook	Start-AutomationRunbook [-Name] <string> [-Parameters <IDictionary>] [-RunOn <string>] [-JobId <guid>] [<CommonParameters>]
Wait-AutomationJob	Wait-AutomationJob -Id <guid[]> [-TimeoutInMinutes <int>] [-DelayInSeconds <int>] [-OutputJobsTransitionedToRunning] [<CommonParameters>]

Observe que os cmdlets internos diferem em nomenclatura dos cmdlets Az e AzureRM. Os nomes de cmdlets internos não contêm palavras como Azure ou Az no substantivo, mas usam a palavra Automation. Recomendamos seu uso sobre o uso de cmdlets Az ou AzureRM durante a execução de runbook em uma área restrita do Azure ou em um Runbook Worker Híbrido do Windows porque eles exigem menos parâmetros e são executados no contexto do seu trabalho durante a execução.

Use cmdlets Az ou AzureRM para manipular recursos de automação fora do contexto de um runbook.

Módulos Python

Você pode criar runbooks Python 2 na Automação do Azure. Para obter informações sobre o módulo Python, consulte Gerenciar pacotes Python 2 na Automação do Azure.

Módulos personalizados

A Automação do Azure dá suporte a módulos personalizados do PowerShell que você cria para usar com seus runbooks e configurações DSC. Um tipo de módulo personalizado é um módulo de integração que, opcionalmente, contém um arquivo de metadados para definir a funcionalidade personalizada para os cmdlets do módulo. Um exemplo do uso de um módulo de integração é fornecido em Adicionar um tipo de conexão.

A Automação do Azure pode importar um módulo personalizado para disponibilizar seus cmdlets. Nos bastidores, ele armazena o módulo e o usa nas sandboxes do Azure, assim como faz com outros módulos.

Migrar para módulos Az

Esta seção explica como migrar para os módulos Az em Automação. Para obter mais informações, consulte Migrar o Azure PowerShell do AzureRM para Az.

Não recomendamos a execução de módulos do AzureRM e módulos do Az na mesma conta de Automatização. Quando tiver a certeza de que pretende migrar do AzureRM para o Az, é melhor consolidar totalmente uma migração completa. Muitas vezes, a automatização reutiliza sandboxes na conta de Automatização para poupar nos tempos de arranque. Se não efetuar uma migração completa de módulos, poderá iniciar uma tarefa que utilize apenas módulos do AzureRM e, em seguida, iniciar outra tarefa que utilize apenas módulos do Az. O sandbox falha rapidamente e recebe um erro a indicar que os módulos não são compatíveis. Esta situação resulta em falhas aleatórias para qualquer runbook ou configuração específicos.

Nota

Quando cria uma nova conta de Automatização, mesmo após a migração para os módulos do Az, a Automatização continuará a instalar os módulos do AzureRM por predefinição.

Teste seus runbooks e configurações DSC antes da migração do módulo

Certifique-se de testar todos os runbooks e configurações DSC cuidadosamente, em uma conta de automação separada, antes de migrar para os módulos Az.

Parar e anular a eliminação de todos os runbooks que utilizam módulos do AzureRM

Para garantir que não executa runbooks ou configurações DSC existentes que utilizem módulos do AzureRM, tem de parar e anular a encriptação de todos os runbooks e configurações afetados. Primeiro, certifique-se de que revê cada configuração de runbook ou DSC e os respetivos agendamentos separadamente, para garantir que pode reagendar o item no futuro, se necessário.

Quando estiver pronto para remover suas agendas, você poderá usar o portal do Azure ou o cmdlet Remove-AzureRmAutomationSchedule . Consulte Remover uma agenda.

Remover módulos do AzureRM

É possível remover os módulos do AzureRM antes de importar os módulos do Az. No entanto, se o fizer, poderá interromper a sincronização do controlo de origem e fazer com que os scripts que ainda estão agendados falhem. Se você decidir remover os módulos, consulte Desinstalar o AzureRM.

Importar módulos do Az

Importar um módulo do Az para a sua conta de Automatização não importa automaticamente o módulo para a sessão do PowerShell que os runbooks utilizam. Os módulos são importados para a sessão do PowerShell nas seguintes situações:

• Quando um runbook invoca um cmdlet de um módulo.
• Quando um runbook importa o módulo explicitamente com o cmdlet Import-Module .
• Quando um runbook importa o módulo explicitamente com a instrução using module . A instrução using é suportada a partir do Windows PowerShell 5.0 e suporta classes e importação do tipo enum.
• Quando um runbook importa outro módulo dependente.

Pode importar os módulos do Az para a conta de Automatização a partir do portal do Azure. Como Az.Accounts é uma dependência para os outros módulos Az, certifique-se de importar este módulo antes de qualquer outro.

Nota

Com a introdução do suporte ao PowerShell 7.1 (visualização), a opção Procurar galeria foi atualizada com as seguintes alterações:

• A galeria de navegação está disponível na folha Módulos de automação de>processos.
• A página Módulos exibe duas novas colunas - Versão do módulo e Versão do tempo de execução

1. Inicie sessão no portal do Azure.

2. Procure e selecione Contas de Automatização.

3. Na página Contas de Automatização, selecione a sua conta de Automatização a partir da lista de contas de Automatização.

4. Na sua conta de Automatização, em Recursos Partilhados, selecione Módulos.

5. Selecione Adicionar um módulo. Na página Adicionar um módulo, pode selecionar uma das seguintes opções:

   1. Procurar arquivo - seleciona um arquivo de sua máquina local.
   2. Navegar a partir da Galeria - pode navegar e selecionar um módulo existente a partir da Galeria.

6. Clique em Selecionar para selecionar um módulo.

7. Selecione Versão de runtime e clique em Importar.

   

8. Na página Módulos, pode ver o módulo importado na conta de Automatização.

Você também pode fazer essa importação por meio da Galeria do PowerShell, procurando o módulo a ser importado. Quando encontrar o módulo, selecione-o e escolha a guia Automação do Azure. Selecione Implantar na Automação do Azure.

Teste seus runbooks

Depois de importar os módulos Az para a conta de automação, você pode começar a editar seus runbooks e configurações DSC para usar os novos módulos. Uma maneira de testar a modificação de um runbook para usar os novos cmdlets é usando o Enable-AzureRmAlias -Scope Process comando no início do runbook. Ao adicionar este comando ao seu runbook, o script pode ser executado sem alterações.

Módulos de autor

Recomendamos que você siga as considerações desta seção ao criar um módulo personalizado do PowerShell para uso na Automação do Azure. Para preparar o módulo para importação, você deve criar pelo menos um arquivo de .dll de módulo .psd1, .psm1 ou PowerShell com o mesmo nome da pasta do módulo. Em seguida, você compacta a pasta do módulo para que a Automação do Azure possa importá-la como um único arquivo. O pacote .zip deve ter o mesmo nome que a pasta do módulo contido.

Para saber mais sobre como criar um módulo do PowerShell, consulte Como escrever um módulo de script do PowerShell.

Pasta de versão

O controle de versão do módulo lado a lado do PowerShell permite que você use mais de uma versão de um módulo no PowerShell. Isso pode ser útil se você tiver scripts mais antigos que foram testados e só funcionam em uma determinada versão de um módulo do PowerShell, mas outros scripts exigem uma versão mais recente do mesmo módulo do PowerShell.

Para construir módulos do PowerShell para que eles contenham várias versões, crie a pasta do módulo e, em seguida, crie uma pasta dentro dessa pasta do módulo para cada versão do módulo que você deseja que seja utilizável. No exemplo a seguir, um módulo chamado TestModule fornece duas versões, 1.0.0 e 2.0.0.

TestModule
   1.0.0
   2.0.0

Dentro de cada uma das pastas de versão, copie seus arquivos de módulo .psm1, .psd1 ou PowerShell do PowerShell .dll que compõem um módulo para a respetiva pasta de versão. Compacte a pasta do módulo para que a Automação do Azure possa importá-la como um único arquivo .zip. Embora a automação mostre apenas uma das versões do módulo importado, se o pacote do módulo contiver versões lado a lado do módulo, todas elas estarão disponíveis para uso em seus runbooks ou configurações DSC.

Embora a automação ofereça suporte a módulos contendo versões lado a lado dentro do mesmo pacote, ela não suporta o uso de várias versões de um módulo em importações de pacotes de módulos. Por exemplo, você importa o módulo A, que contém as versões 1 e 2 para sua conta de automação. Mais tarde, você atualiza o módulo A para incluir as versões 3 e 4, quando você importa para sua conta de automação, somente as versões 3 e 4 são utilizáveis em quaisquer runbooks ou configurações DSC. Se você precisar que todas as versões - 1, 2, 3 e 4 estejam disponíveis, o arquivo de .zip sua importação deve conter as versões 1, 2, 3 e 4.

Se você for usar versões diferentes do mesmo módulo entre runbooks, deverá sempre declarar a versão que deseja usar em seu runbook usando o Import-Module cmdlet e incluir o parâmetro -RequiredVersion <version>. Mesmo que a versão que você deseja usar seja a versão mais recente. Isso ocorre porque os trabalhos de runbook podem ser executados na mesma área restrita. Se a sandbox já tiver carregado explicitamente um módulo de um determinado número de versão, porque um trabalho anterior nessa sandbox disse fazê-lo, trabalhos futuros nessa sandbox não carregarão automaticamente a versão mais recente desse módulo. Isso ocorre porque alguma versão dele já está carregada na sandbox.

Para um recurso DSC, use o seguinte comando para especificar uma versão específica:

Import-DscResource -ModuleName <ModuleName> -ModuleVersion <version>

Informações de ajuda

Inclua uma sinopse, uma descrição e um URI de ajuda para cada cmdlet em seu módulo. No PowerShell, você pode definir informações de ajuda para cmdlets usando o Get-Help cmdlet. O exemplo a seguir mostra como definir uma sinopse e ajudar o URI em um arquivo de módulo .psm1 .

<#
     .SYNOPSIS
      Gets a Contoso User account
#>
function Get-ContosoUser {
[CmdletBinding](DefaultParameterSetName='UseConnectionObject', `
HelpUri='https://www.contoso.com/docs/information')]
[OutputType([String])]
param(
   [Parameter(ParameterSetName='UserAccount', Mandatory=true)]
   [ValidateNotNullOrEmpty()]
   [string]
   $UserName,

   [Parameter(ParameterSetName='UserAccount', Mandatory=true)]
   [ValidateNotNullOrEmpty()]
   [string]
   $Password,

   [Parameter(ParameterSetName='ConnectionObject', Mandatory=true)]
   [ValidateNotNullOrEmpty()]
   [Hashtable]
   $Connection
)

switch ($PSCmdlet.ParameterSetName) {
   "UserAccount" {
      $cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $UserName, $Password
      Connect-Contoso -Credential $cred
   }
   "ConnectionObject" {
      Connect-Contoso -Connection $Connection
  }
}
}

O fornecimento dessas informações mostra o texto de ajuda por meio do Get-Help cmdlet no console do PowerShell. Esse texto também é exibido no portal do Azure.

Connection type

Se o módulo se conectar a um serviço externo, defina um tipo de conexão usando um módulo de integração personalizado. Cada cmdlet no módulo deve aceitar uma instância desse tipo de conexão (objeto de conexão) como parâmetro. Os usuários mapeiam parâmetros do ativo de conexão para os parâmetros correspondentes do cmdlet cada vez que chamam um cmdlet.

O exemplo de runbook a seguir usa um ativo de conexão Contoso chamado ContosoConnection para acessar recursos da Contoso e retornar dados do serviço externo. Neste exemplo, os campos são mapeados para as UserName propriedades e Password de um PSCredential objeto e, em seguida, passados para o cmdlet.

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $contosoConnection.UserName, $contosoConnection.Password
Connect-Contoso -Credential $cred
}

Uma maneira mais fácil e melhor de abordar esse comportamento é passando diretamente o objeto de conexão para o cmdlet:

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

Connect-Contoso -Connection $contosoConnection
}

Você pode habilitar um comportamento semelhante para seus cmdlets permitindo que eles aceitem um objeto de conexão diretamente como um parâmetro, em vez de apenas campos de conexão para parâmetros. Normalmente, é aconselhável ter um parâmetro definido para cada um para que um utilizador que não esteja a utilizar a Automatização possa chamar os cmdlets sem construir uma tabela hash para atuar como o objeto de ligação. O conjunto de UserAccount parâmetros é usado para passar as propriedades do campo de conexão. ConnectionObject permite que você passe a conexão diretamente.

Tipo de saída

Defina o tipo de saída para todos os cmdlets em seu módulo. A definição de um tipo de saída para um cmdlet permite que o IntelliSense em tempo de design ajude a determinar as propriedades de saída do cmdlet durante a criação. Essa prática é especialmente útil durante a criação de runbooks gráficos, para os quais o conhecimento em tempo de design é fundamental para uma experiência de usuário fácil com seu módulo.

Adicionar [OutputType([<MyOutputType>])], onde MyOutputType é um tipo válido. Para saber mais sobre OutputTypeo , consulte Sobre funções OutputTypeAttribute. O código a seguir é um exemplo de adição OutputType a um cmdlet:

function Get-ContosoUser {
[OutputType([String])]
param(
   [string]
   $Parameter1
)
# <script location here>
}

Esse comportamento é semelhante à funcionalidade "type ahead" da saída de um cmdlet no ambiente do serviço de integração do PowerShell, sem precisar executá-lo.

Estado do cmdlet

Torne todos os cmdlets do módulo sem monitoração de estado. Vários trabalhos de runbook podem ser executados simultaneamente no mesmo AppDomain processo e na mesma área restrita. Se houver algum estado compartilhado nesses níveis, os empregos podem afetar uns aos outros. Esse comportamento pode levar a problemas intermitentes e difíceis de diagnosticar. Aqui está um exemplo do que não fazer:

$globalNum = 0
function Set-GlobalNum {
   param(
       [int] $num
   )

   $globalNum = $num
}
function Get-GlobalNumTimesTwo {
   $output = $globalNum * 2

   $output
}

Dependência do módulo

Certifique-se de que o módulo está totalmente contido em um pacote que pode ser copiado usando xcopy. Os módulos de automação são distribuídos para as caixas de proteção de automação quando os runbooks são executados. Os módulos devem funcionar independentemente do host que os executa.

Você deve ser capaz de compactar e mover um pacote de módulo, e fazê-lo funcionar normalmente quando for importado para o ambiente PowerShell de outro host. Para que isso aconteça, certifique-se de que o módulo não dependa de nenhum arquivo fora da pasta do módulo que é compactada quando o módulo é importado para a automação.

Seu módulo não deve depender de nenhuma configuração de registro exclusiva em um host. Exemplos são as configurações que são feitas quando um produto é instalado.

Caminhos de arquivo de módulo

Certifique-se de que todos os arquivos no módulo têm caminhos com menos de 140 caracteres. Qualquer caminho com mais de 140 caracteres de comprimento causa problemas com a importação de runbooks. A automação não pode importar um arquivo com tamanho de caminho superior a 140 caracteres para a sessão do PowerShell com Import-Module.

Importar módulos

Esta seção define várias maneiras de importar um módulo para sua conta de automação.

Importar módulos no portal do Azure

Para importar um módulo no portal do Azure:

1. No portal, procure e selecione Contas de Automatização.
2. Na página Contas de Automatização, selecione a sua conta de Automatização a partir da lista de contas de Automatização.
3. Em Recursos Partilhados, selecione Módulos.
4. Selecione Adicionar um módulo.
5. Selecione o ficheiro .zip que contém o módulo.
6. Selecione OK para começar o processo de importação.

Importar módulos usando o PowerShell

Você pode usar o cmdlet New-AzAutomationModule para importar um módulo para sua conta de automação. O cmdlet usa uma URL para um módulo .zip pacote.

New-AzAutomationModule -Name <ModuleName> -ContentLinkUri <ModuleUri> -ResourceGroupName <ResourceGroupName> -AutomationAccountName <AutomationAccountName>

Você também pode usar o mesmo cmdlet para importar um módulo diretamente da Galeria do PowerShell. Certifique-se de pegar ModuleName e ModuleVersion da Galeria do PowerShell.

$moduleName = <ModuleName>
$moduleVersion = <ModuleVersion>
New-AzAutomationModule -AutomationAccountName <AutomationAccountName> -ResourceGroupName <ResourceGroupName> -Name $moduleName -ContentLinkUri "https://www.powershellgallery.com/api/v2/package/$moduleName/$moduleVersion"

Importar módulos da Galeria do PowerShell

Você pode importar módulos da Galeria do PowerShell diretamente da Galeria ou da sua conta de Automação.

Para importar um módulo diretamente da Galeria do PowerShell:

1. Vá e https://www.powershellgallery.com procure o módulo a ser importado.
2. Em Opções de Instalação, na guia Automação do Azure, selecione Implantar na Automação do Azure. Esta ação abre o portal do Azure.
3. Na página Importar, selecione sua conta de automação e selecione OK.

Para importar um módulo da Galeria do PowerShell diretamente da sua conta de automação:

1. No portal, procure e selecione Contas de Automatização.
2. Na página Contas de Automatização, selecione a sua conta de Automatização a partir da lista de contas de Automatização.
3. Em Recursos Partilhados, selecione Módulos.
4. Selecione Procurar galeria e, em seguida, procure um módulo na Galeria.
5. Selecione o módulo a ser importado e selecione Importar.
6. Selecione OK para iniciar o processo de importação.

Excluir módulos

Se você tiver problemas com um módulo ou precisar reverter para uma versão anterior de um módulo, poderá excluí-lo da sua conta de automação. Não é possível excluir as versões originais dos módulos padrão que são importados quando você cria uma conta de automação. Se o módulo a ser excluído for uma versão mais recente de um dos módulos padrão, ele será revertido para a versão que foi instalada com sua conta de automação. Caso contrário, qualquer módulo excluído da sua conta de automação será removido.

Eliminar módulos no portal do Azure

Para remover um módulo no portal do Azure:

1. No portal, procure e selecione Contas de Automatização.
2. Na página Contas de Automatização, selecione a sua conta de Automatização a partir da lista de contas de Automatização.
3. Em Recursos Partilhados, selecione Módulos.
4. Selecione o módulo que pretende remover.
5. Na página Módulo, selecione Eliminar. Se este módulo for um dos módulos padrão, ele será revertido para a versão que existia quando a conta de automação foi criada.

Excluir módulos usando o PowerShell

Para remover um módulo por meio do PowerShell, execute o seguinte comando:

Remove-AzAutomationModule -Name <moduleName> -AutomationAccountName <automationAccountName> -ResourceGroupName <resourceGroupName>

Próximos passos

• Para obter mais informações sobre como usar módulos do Azure PowerShell, consulte Introdução ao Azure PowerShell.

• Para saber mais sobre como criar módulos do PowerShell, consulte Escrevendo um módulo do Windows PowerShell.