Zarządzanie modułami w usłudze Azure Automation

Uwaga

Od 1 lutego 2025 r. usługa Azure Automation przestanie wykonywać wszystkie elementy Runbook korzystające z modułów AzureRM. Od 1 listopada 2024 r. nie będzie można tworzyć nowych elementów Runbook przy użyciu modułów AzureRM. Moduł AzureRM PowerShell został oficjalnie przestarzały od 29 lutego 2024 r. Zalecamy przeprowadzenie migracji z modułu AzureRM do modułu Az programu PowerShell, aby zapewnić ciągłą obsługę i aktualizacje. Moduł AzureRM może nadal działać, ale nie jest już obsługiwany i nadal korzysta z modułu AzureRM na własne ryzyko użytkownika. Aby uzyskać więcej informacji, zobacz zasoby migracji, aby uzyskać wskazówki dotyczące przejścia do modułu Az.

Usługa Azure Automation używa wielu modułów programu PowerShell do włączania poleceń cmdlet w elementach Runbook i zasobach DSC w konfiguracjach DSC. Obsługiwane moduły obejmują:

• Moduł Az.Automation programu Azure PowerShell.
• Azure PowerShell AzureRM.Automation.
• Inne moduły programu PowerShell.
• Moduł wewnętrzny Orchestrator.AssetManagement.Cmdlets .
• Moduły języka Python 2.
• Utworzone moduły niestandardowe.

Podczas tworzenia konta usługi Automation usługa Azure Automation domyślnie importuje niektóre moduły. Zobacz Moduły domyślne.

Ważne

Nowe środowisko środowiska uruchomieniowego umożliwia zarządzanie modułami i pakietami, umożliwiając skonfigurowanie środowiska wykonywania zadania. W nowym środowisku bloki Moduły i pakiety nie są dostępne. Aby zarządzać modułami i pakietami, zobacz Zarządzanie środowiskiem uruchomieniowym i skojarzonymi elementami Runbook.

Piaskownice

Gdy usługa Automation wykonuje zadania kompilacji elementów Runbook i DSC, ładuje moduły do piaskownic, w których można uruchamiać elementy Runbook, a konfiguracje DSC mogą być kompilowane. Usługa Automation automatycznie umieszcza również wszystkie zasoby DSC w modułach na serwerze ściągania DSC. Maszyny mogą ściągać zasoby podczas stosowania konfiguracji DSC.

Piaskownica chmury obsługuje maksymalnie 48 wywołań systemowych i ogranicza wszystkie inne wywołania ze względów bezpieczeństwa. Inne funkcje, takie jak zarządzanie poświadczeniami i niektóre sieci, nie są obsługiwane w piaskownicy chmury.

Ze względu na liczbę dołączonych modułów i poleceń cmdlet trudno wcześniej znać, które z poleceń cmdlet będą wykonywać nieobsługiwane wywołania. Ogólnie rzecz biorąc, widzieliśmy problemy z poleceniami cmdlet, które wymagają podwyższonego poziomu dostępu, wymagają poświadczeń jako parametru lub poleceń cmdlet związanych z siecią. Wszystkie polecenia cmdlet, które wykonują pełne operacje sieciowe stosu, nie są obsługiwane w piaskownicy, w tym Connect-AipService z modułu AIPService programu PowerShell i Resolve-DnsName z modułu DNSClient.

Są to znane ograniczenia dotyczące piaskownicy. Zalecanym obejściem jest wdrożenie hybrydowego procesu roboczego elementu Runbook lub użycie usługi Azure Functions.

Ważne

Nie dołączaj słowa kluczowego "AzureRm" do żadnego skryptu przeznaczonego do wykonania za pomocą modułu Az. Dołączenie słowa kluczowego, nawet w komentarzu, może spowodować załadowanie modułu AzureRm, a następnie konflikt z modułem Az.

Moduły domyślne

Wszystkie nowe konta usługi Automation mają domyślnie zaimportowaną najnowszą wersję modułu Az programu PowerShell. Moduł Az zastępuje moduł AzureRM i jest zalecanym modułem do użycia z platformą Azure. Moduły domyślne na nowym koncie usługi Automation obejmują istniejące moduły AzureRM 24 i moduły 60+ Az.

Istnieje natywna opcja aktualizowania modułów do najnowszego modułu Az przez użytkownika dla kont usługi Automation. Operacja będzie obsługiwać wszystkie zależności modułu w zapleczu, co eliminuje problemy z ręcznym aktualizowaniem modułów lub wykonywaniem elementu Runbook w celu zaktualizowania modułów platformy Azure.

Jeśli istniejące konto usługi Automation ma tylko moduły AzureRM, opcja Aktualizuj moduły Az zaktualizuje konto usługi Automation przy użyciu wybranej przez użytkownika wersji modułu Az.

Jeśli istniejące konto usługi Automation ma moduł AzureRM i niektóre moduły Az, opcja zaimportuje pozostałe moduły Az do konta usługi Automation. Istniejące moduły Az będą preferowane, a operacja aktualizacji nie zaktualizuje tych modułów. Ma to na celu zapewnienie, że operacja modułu aktualizacji nie prowadzi do niepowodzenia wykonywania elementu Runbook przez przypadkowo zaktualizowanie modułu używanego przez element Runbook. Zalecanym sposobem dla tego scenariusza jest najpierw usunięcie istniejących modułów Az, a następnie wykonanie operacji aktualizacji w celu pobrania najnowszego modułu Az zaimportowanego na konto usługi Automation. Takie typy modułów, które nie są domyślnie importowane, są określane jako Niestandardowe. Moduły niestandardowe zawsze przejmą preferencję nad modułami domyślnymi .

Na przykład: Jeśli masz Az.Aks już zaimportowany moduł z wersją 2.3.0, który jest dostarczany przez moduł Az 6.3.0, a następnie spróbujesz zaktualizować moduł Az do najnowszej wersji 6.4.0. Operacja aktualizacji zaimportuje wszystkie moduły Az z pakietu 6.4.0, z wyjątkiem Az.Aks. Aby mieć najnowszą wersję programu Az.Aks, najpierw usuń istniejący moduł, a następnie wykonaj operację aktualizacji lub możesz również zaktualizować ten moduł oddzielnie zgodnie z opisem w temacie Importowanie modułów Az w celu zaimportowania innej wersji określonego modułu.

W poniższej tabeli wymieniono moduły importowane przez usługę Azure Automation domyślnie podczas tworzenia konta usługi Automation. Usługa Automation może importować nowsze wersje tych modułów. Nie można jednak usunąć oryginalnej wersji z konta usługi Automation, nawet jeśli usuniesz nowszą wersję.

Moduły domyślne są również nazywane modułami globalnymi. W witrynie Azure Portal właściwość modułu globalnego będzie mieć wartość true podczas wyświetlania modułu zaimportowanego podczas tworzenia konta.

Uwaga

Nie zalecamy zmiany modułów i elementów Runbook na kontach usługi Automation używanych do wdrażania maszyn wirtualnych uruchamiania/zatrzymywania poza godzinami pracy

Nazwa modułu	Wersja
Az.*	Zobacz pełną listę w obszarze Szczegóły pakietu w Galeria programu 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
Orchestrator.AssetManagement.Cmdlets	1
PSDscResources	2.9.0.0
SecurityPolicyDsc	2.1.0.0
StateConfigCompositeResources	1
xDSCDomainjoin	1.1
xPowerShellExecutionPolicy	1.1.0.0
xRemoteDesktopAdmin	1.1.0.0

Wewnętrzne polecenia cmdlet

Usługa Azure Automation obsługuje wewnętrzne polecenia cmdlet, które są dostępne tylko podczas wykonywania elementów Runbook w środowisku piaskownicy platformy Azure lub w hybrydowym procesie roboczym elementu Runbook systemu Windows. Moduł wewnętrzny Orchestrator.AssetManagement.Cmdlets jest instalowany domyślnie na koncie usługi Automation, a gdy na maszynie jest zainstalowana rola hybrydowego procesu roboczego elementu Runbook systemu Windows.

W poniższej tabeli zdefiniowano wewnętrzne polecenia cmdlet. Te polecenia cmdlet są przeznaczone do użycia zamiast poleceń cmdlet usługi Azure PowerShell w celu interakcji z zasobami konta usługi Azure Automation. Mogą pobierać wpisy tajne z zaszyfrowanych zmiennych, poświadczeń i szyfrowanych połączeń.

Nazwa/nazwisko	opis
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>]

Należy pamiętać, że wewnętrzne polecenia cmdlet różnią się od nazw poleceń cmdlet Az i AzureRM. Nazwy wewnętrznych poleceń cmdlet nie zawierają wyrazów takich jak Azure lub Az w owniku, ale używają słowa Automation. Zalecamy korzystanie z poleceń cmdlet Az lub AzureRM podczas wykonywania elementu Runbook w piaskownicy platformy Azure lub w hybrydowym procesie roboczym elementu Runbook systemu Windows, ponieważ wymagają one mniejszej liczby parametrów i są uruchamiane w kontekście zadania podczas wykonywania.

Użyj poleceń cmdlet Az lub AzureRM do manipulowania zasobami usługi Automation poza kontekstem elementu Runbook.

Moduły języka Python

Elementy Runbook języka Python 2 można tworzyć w usłudze Azure Automation. Aby uzyskać informacje o module języka Python, zobacz Manage Python 2 packages in Azure Automation (Zarządzanie pakietami języka Python 2 w usłudze Azure Automation).

Moduły niestandardowe

Usługa Azure Automation obsługuje niestandardowe moduły programu PowerShell tworzone do użycia z elementami Runbook i konfiguracjami DSC. Jednym z typów modułu niestandardowego jest moduł integracji, który opcjonalnie zawiera plik metadanych w celu zdefiniowania niestandardowych funkcji poleceń cmdlet modułu. Przykład użycia modułu integracji znajduje się w artykule Dodawanie typu połączenia.

Usługa Azure Automation może zaimportować moduł niestandardowy, aby udostępnić jego polecenia cmdlet. W tle przechowuje moduł i używa go w piaskownicach platformy Azure, podobnie jak w przypadku innych modułów.

Migrowanie do modułów Az

W tej sekcji opisano sposób migracji do modułów Az w usłudze Automation. Aby uzyskać więcej informacji, zobacz Migrowanie programu Azure PowerShell z modułu AzureRM do modułu Az.

Nie zalecamy uruchamiania modułów AzureRM i modułów Az na tym samym koncie usługi Automation. Jeśli masz pewność, że chcesz przeprowadzić migrację z modułu AzureRM do modułu Az, najlepiej jest w pełni zaangażować się w pełną migrację. Usługa Automation często ponownie wykorzystuje piaskownice w ramach konta usługi Automation, aby zaoszczędzić czas uruchamiania. Jeśli nie wykonasz pełnej migracji modułów, możesz uruchomić zadanie, które używa tylko modułów AzureRM, a następnie uruchomić inne zadanie, które używa tylko modułów Az. Piaskownica wkrótce ulegnie awarii i zostanie wyświetlony komunikat o błędzie informujący, że moduły nie są kompatybilne. Ta sytuacja powoduje losowo występujące awarie dla dowolnego elementu Runbook lub konfiguracji.

Uwaga

Po utworzeniu nowego konta usługi Automation, nawet po migracji do modułów Az, usługa Automation będzie nadal domyślnie instalować moduły AzureRM.

Testowanie elementów Runbook i konfiguracji DSC przed migracją modułu

Przed migracją do modułów Az pamiętaj, aby dokładnie przetestować wszystkie elementy Runbook i konfiguracje DSC na osobnym koncie usługi Automation.

Zatrzymaj i anuluj harmonogram wszystkich elementów Runbook korzystających z modułów AzureRM

Aby upewnić się, że nie uruchomisz żadnych istniejących elementów Runbook ani konfiguracji DSC korzystających z modułów AzureRM, musisz zatrzymać i anulować harmonogram wszystkich elementów Runbook i konfiguracji, których dotyczy problem. Najpierw upewnij się, że przeglądasz każdą konfigurację elementu Runbook lub DSC i jej harmonogramy osobno, aby upewnić się, że w razie potrzeby możesz ponownie zaplanować element w przyszłości.

Gdy wszystko będzie gotowe do usunięcia harmonogramów, możesz użyć witryny Azure Portal lub polecenia cmdlet Remove-AzureRmAutomationSchedule . Zobacz Usuwanie harmonogramu.

Usuń moduły AzureRM

Istnieje możliwość usunięcia modułów AzureRM przed zaimportowaniem modułów AZ. Jeśli jednak to zrobisz, możesz przerwać synchronizację kontroli źródła i spowodować, że wszystkie skrypty, które nadal są zaplanowane, zakończą się niepowodzeniem. Jeśli zdecydujesz się usunąć moduły, zobacz Odinstaluj moduł AzureRM.

Importuj moduły Az

Importowanie modułu AZ do konta usługi Automation nie powoduje automatycznego zaimportowania go do sesji programu PowerShell używanej przez elementy runbook. Moduły są importowane do sesji programu PowerShell w następujących scenariuszach:

• Gdy element Runbook wywołuje polecenie cmdlet z modułu.
• Gdy element Runbook jawnie importuje moduł za pomocą polecenia cmdlet Import-Module .
• Gdy element Runbook jawnie importuje moduł za pomocą instrukcji using module . Instrukcja „using” jest obsługiwana od wersji Windows PowerShell 5.0 i obsługuje import klas i typów wyliczenia.
• Gdy element Runbook importuje inny moduł zależny.

Możesz zaimportować moduły Az do konta usługi Azure Automation z witryny Azure Portal. Ponieważ moduł Az.Accounts jest zależnością dla innych modułów Az, pamiętaj, aby zaimportować ten moduł przed innymi.

Uwaga

Wraz z wprowadzeniem obsługi programu PowerShell 7.1 (wersja zapoznawcza) opcja Przeglądaj galerię została zaktualizowana o następujące zmiany:

• Galeria przeglądania jest dostępna w bloku Moduły automatyzacji>procesów.
• Na stronie Moduły są wyświetlane dwie nowe kolumny — wersja modułu i wersja środowiska uruchomieniowego

1. Zaloguj się w witrynie Azure Portal.

2. Wyszukaj i wybierz pozycję Konta usługi Automation.

3. Na stronie Konta usługi Automation wybierz konto usługi Automation z listy.

4. Z poziomu konta usługi Automation wybierz w obszarze Współdzielone zasoby pozycję Moduły.

5. Wybierz pozycję Dodaj moduł. Na stronie Dodawanie modułu możesz wybrać jedną z następujących opcji:

   1. Przeglądaj pod kątem pliku — wybiera plik z komputera lokalnego.
   2. Przeglądaj z galerii — możesz przeglądać i wybierać istniejący moduł z galerii.

6. Kliknij pozycję Wybierz, aby wybrać moduł.

7. Wybierz pozycję Wersja uruchomieniowa i kliknij przycisk Importuj.

   

8. Na stronie Moduły możesz wyświetlić zaimportowany moduł na koncie usługi Automation.

Możesz również wykonać ten import za pomocą Galeria programu PowerShell, wyszukując moduł do zaimportowania. Po znalezieniu modułu wybierz go i wybierz kartę Azure Automation . Wybierz pozycję Wdróż w usłudze Azure Automation.

Testowanie elementów Runbook

Po zaimportowaniu modułów Az do konta usługi Automation możesz rozpocząć edytowanie elementów Runbook i konfiguracji DSC, aby używać nowych modułów. Jednym ze sposobów testowania modyfikacji elementu Runbook do używania nowych poleceń cmdlet jest użycie Enable-AzureRmAlias -Scope Process polecenia na początku elementu Runbook. Dodając to polecenie do elementu Runbook, skrypt może działać bez zmian.

Tworzenie modułów

Zalecamy zapoznanie się z zagadnieniami w tej sekcji podczas tworzenia niestandardowego modułu programu PowerShell do użycia w usłudze Azure Automation. Aby przygotować moduł do importowania, należy utworzyć co najmniej plik psd1, psm1 lub moduł programu PowerShell .dll plik o takiej samej nazwie jak folder modułu. Następnie spakujesz folder modułu, aby usługa Azure Automation mogła zaimportować go jako pojedynczy plik. Pakiet .zip powinien mieć taką samą nazwę jak folder zawartego modułu.

Aby dowiedzieć się więcej na temat tworzenia modułu programu PowerShell, zobacz How to Write a PowerShell Script Module (Jak napisać moduł skryptu programu PowerShell).

Folder wersji

Przechowywanie wersji modułu równoległego programu PowerShell umożliwia używanie więcej niż jednej wersji modułu w programie PowerShell. Może to być przydatne, jeśli masz starsze skrypty, które zostały przetestowane i działają tylko względem określonej wersji modułu programu PowerShell, ale inne skrypty wymagają nowszej wersji tego samego modułu programu PowerShell.

Aby skonstruować moduły programu PowerShell, aby zawierały wiele wersji, utwórz folder modułu, a następnie utwórz folder w tym folderze modułu dla każdej wersji modułu, której chcesz użyć. W poniższym przykładzie moduł o nazwie TestModule udostępnia dwie wersje: 1.0.0 i 2.0.0.

TestModule
   1.0.0
   2.0.0

W każdym folderze wersji skopiuj pliki programu PowerShell .psm1, psd1 lub PowerShell .dll plików tworzących moduł w odpowiednim folderze wersji. Spakuj folder modułu, aby usługa Azure Automation mogła zaimportować go jako pojedynczy plik .zip. Chociaż usługa Automation pokazuje tylko jedną z wersji zaimportowanego modułu, jeśli pakiet modułu zawiera wersje równoległe modułu, wszystkie są dostępne do użycia w konfiguracjach elementów Runbook lub DSC.

Usługa Automation obsługuje moduły zawierające wersje równoległe w ramach tego samego pakietu, ale nie obsługuje wielu wersji modułu w ramach importu pakietów modułów. Na przykład importujesz moduł A, który zawiera wersje 1 i 2 na koncie usługi Automation. Później zaktualizujesz moduł A , aby zawierał wersje 3 i 4, podczas importowania do konta usługi Automation, tylko wersje 3 i 4 można używać w ramach dowolnych elementów Runbook lub konfiguracji DSC. Jeśli wszystkie wersje — 1, 2, 3 i 4 mają być dostępne, plik .zip import powinien zawierać wersje 1, 2, 3 i 4.

Jeśli zamierzasz używać różnych wersji tego samego modułu między elementami Runbook, zawsze należy zadeklarować wersję, której chcesz użyć w elemecie Import-Module Runbook, używając polecenia cmdlet i dołączyć parametr -RequiredVersion <version>. Nawet jeśli wersja, której chcesz użyć, to najnowsza wersja. Dzieje się tak, ponieważ zadania elementu Runbook mogą być uruchamiane w tej samej piaskownicy. Jeśli piaskownica już jawnie załadowała moduł określonego numeru wersji, ponieważ poprzednie zadanie w tej piaskownicy powiedziało, że przyszłe zadania w tej piaskownicy nie będą automatycznie ładować najnowszej wersji tego modułu. Dzieje się tak, ponieważ niektóre wersje są już załadowane w piaskownicy.

W przypadku zasobu DSC użyj następującego polecenia, aby określić określoną wersję:

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

Informacje pomocy

Dołącz streszczenie, opis i identyfikator URI pomocy dla każdego polecenia cmdlet w module. W programie PowerShell można zdefiniować informacje pomocy dla poleceń cmdlet przy użyciu Get-Help polecenia cmdlet . W poniższym przykładzie pokazano, jak zdefiniować składnię i identyfikator URI pomocy w pliku modułu 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
  }
}
}

Podanie tych informacji zawiera tekst pomocy za pośrednictwem Get-Help polecenia cmdlet w konsoli programu PowerShell. Ten tekst jest również wyświetlany w witrynie Azure Portal.

Connection type

Jeśli moduł łączy się z usługą zewnętrzną, zdefiniuj typ połączenia przy użyciu niestandardowego modułu integracji. Każde polecenie cmdlet w module powinno akceptować wystąpienie tego typu połączenia (obiekt połączenia) jako parametr. Użytkownicy mapują parametry zasobu połączenia na odpowiednie parametry polecenia cmdlet za każdym razem, gdy wywołają polecenie cmdlet.

W poniższym przykładzie elementu Runbook użyto zasobu połączenia firmy Contoso o nazwie ContosoConnection w celu uzyskania dostępu do zasobów firmy Contoso i zwrócenia danych z usługi zewnętrznej. W tym przykładzie pola są mapowane na UserName właściwości PSCredential i Password obiektu, a następnie przekazywane do polecenia cmdlet.

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

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

Łatwiejszym i lepszym sposobem podejścia do tego zachowania jest bezpośrednie przekazanie obiektu połączenia do polecenia cmdlet:

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

Connect-Contoso -Connection $contosoConnection
}

Możesz włączyć podobne zachowanie poleceń cmdlet, zezwalając im na akceptowanie obiektu połączenia bezpośrednio jako parametru, zamiast tylko pól połączenia dla parametrów. Zazwyczaj chcesz ustawić parametr dla każdego z nich, aby użytkownik, który nie korzysta z usługi Automation, mógł wywołać polecenia cmdlet bez konstruowania tabeli skrótu, aby działał jako obiekt połączenia. Zestaw UserAccount parametrów służy do przekazywania właściwości pola połączenia. ConnectionObject umożliwia bezpośrednie przekazywanie połączenia.

Typ danych wyjściowych

Zdefiniuj typ danych wyjściowych dla wszystkich poleceń cmdlet w module. Definiowanie typu danych wyjściowych polecenia cmdlet umożliwia funkcji IntelliSense w czasie projektowania, aby ułatwić określenie właściwości wyjściowych polecenia cmdlet podczas tworzenia. Ta praktyka jest szczególnie przydatna podczas graficznego tworzenia elementów Runbook, dla których wiedza w czasie projektowania jest kluczem do łatwego środowiska użytkownika w module.

Dodaj [OutputType([<MyOutputType>])]element , gdzie MyOutputType jest prawidłowym typem. Aby dowiedzieć się więcej o OutputTypesystemie, zobacz About Functions OutputTypeAttribute (Informacje o funkcji OutputTypeAttribute). Poniższy kod to przykład dodawania OutputType do polecenia cmdlet:

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

To zachowanie jest podobne do funkcji "typ z wyprzedzeniem" danych wyjściowych polecenia cmdlet w środowisku usługi integracji programu PowerShell bez konieczności jego uruchamiania.

Stan polecenia cmdlet

Ustaw wszystkie polecenia cmdlet w module bezstanowe. Wiele zadań runbook może być jednocześnie uruchamianych w tym samym i tym AppDomain samym procesie i piaskownicy. Jeśli na tych poziomach jest udostępniony jakikolwiek stan, zadania mogą mieć wpływ na siebie. To zachowanie może prowadzić do sporadycznych i trudnych do zdiagnozowania problemów. Oto przykład tego, czego nie robić:

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

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

   $output
}

Zależność modułu

Upewnij się, że moduł jest w pełni zawarty w pakiecie, który można skopiować przy użyciu narzędzia xcopy. Moduły automatyzacji są dystrybuowane do piaskownic usługi Automation po wykonaniu elementów Runbook. Moduły muszą działać niezależnie od hosta, który je uruchamia.

Powinno być możliwe spakowanie i przeniesienie pakietu modułu oraz normalne działanie go podczas importowania do środowiska programu PowerShell innego hosta. Aby tak się stało, upewnij się, że moduł nie zależy od plików spoza folderu modułu, który jest spakowany po zaimportowaniu modułu do usługi Automation.

Moduł nie powinien zależeć od żadnych unikatowych ustawień rejestru na hoście. Przykłady to ustawienia, które są tworzone po zainstalowaniu produktu.

Ścieżki plików modułu

Upewnij się, że wszystkie pliki w module mają ścieżki zawierające mniej niż 140 znaków. Wszystkie ścieżki o długości powyżej 140 znaków powodują problemy z importowaniem elementów Runbook. Usługa Automation nie może zaimportować pliku o rozmiarze ścieżki powyżej 140 znaków do sesji programu PowerShell za pomocą polecenia Import-Module.

Importowanie modułów

W tej sekcji zdefiniowano kilka sposobów importowania modułu do konta usługi Automation.

Importowanie modułów w witrynie Azure Portal

Aby zaimportować moduł w witrynie Azure Portal:

1. W witrynie Azure Portal wyszukaj i wybierz pozycję Konta automatyzacji.
2. Na stronie Konta usługi Automation wybierz konto usługi Automation z listy.
3. W obszarze Zasoby udostępnione wybierz pozycję Moduły.
4. Wybierz pozycję Dodaj moduł.
5. Wybierz plik .zip, który zawiera Twój moduł.
6. Wybierz przycisk OK, aby rozpocząć proces importowania.

Importowanie modułów przy użyciu programu PowerShell

Aby zaimportować moduł do konta usługi Automation, możesz użyć polecenia cmdlet New-AzAutomationModule . Polecenie cmdlet przyjmuje adres URL dla pakietu .zip modułu.

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

Możesz również użyć tego samego polecenia cmdlet, aby zaimportować moduł bezpośrednio z Galeria programu PowerShell. Pamiętaj, aby chwycić ModuleName i ModuleVersion z Galeria programu PowerShell.

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

Importowanie modułów z Galeria programu PowerShell

Moduły Galeria programu PowerShell można zaimportować bezpośrednio z galerii lub z konta usługi Automation.

Aby zaimportować moduł bezpośrednio z Galeria programu PowerShell:

1. Przejdź do https://www.powershellgallery.com strony i wyszukaj moduł do zaimportowania.
2. W obszarze Opcje instalacji na karcie Azure Automation wybierz pozycję Wdróż w usłudze Azure Automation. Ta akcja spowoduje otwarcie witryny Azure Portal.
3. Na stronie Importowanie wybierz konto usługi Automation, a następnie wybierz przycisk OK.

Aby zaimportować moduł Galeria programu PowerShell bezpośrednio z konta usługi Automation:

1. W witrynie Azure Portal wyszukaj i wybierz pozycję Konta automatyzacji.
2. Na stronie Konta usługi Automation wybierz konto usługi Automation z listy.
3. W obszarze Zasoby udostępnione wybierz pozycję Moduły.
4. Wybierz pozycję Przeglądaj galerię, a następnie wyszukaj moduł Galeria.
5. Wybierz moduł do zaimportowania, a następnie wybierz pozycję Importuj.
6. Wybierz przycisk OK , aby rozpocząć proces importowania.

Usuwanie modułów

Jeśli masz problemy z modułem lub musisz przywrócić poprzednią wersję modułu, możesz usunąć go z konta usługi Automation. Nie można usunąć oryginalnych wersji modułów domyślnych importowanych podczas tworzenia konta usługi Automation. Jeśli moduł do usunięcia jest nowszą wersją jednego z modułów domyślnych, przywraca wersję zainstalowaną przy użyciu konta usługi Automation. W przeciwnym razie wszystkie moduły usunięte z konta usługi Automation zostaną usunięte.

Usuń moduły w witrynie Azure Portal

Aby usunąć moduł w witrynie Azure Portal:

1. W witrynie Azure Portal wyszukaj i wybierz pozycję Konta automatyzacji.
2. Na stronie Konta usługi Automation wybierz konto usługi Automation z listy.
3. W obszarze Zasoby udostępnione wybierz pozycję Moduły.
4. Wybierz moduł, który chcesz usunąć.
5. Na stronie Moduł wybierz pozycję Usuń. Jeśli ten moduł jest jednym z domyślnych modułów, przywraca wersję, która istniała podczas tworzenia konta usługi Automation.

Usuwanie modułów przy użyciu programu PowerShell

Aby usunąć moduł za pomocą programu PowerShell, uruchom następujące polecenie:

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

Następne kroki

• Aby uzyskać więcej informacji na temat korzystania z modułów programu Azure PowerShell, zobacz Rozpoczynanie pracy z programem Azure PowerShell.

• Aby dowiedzieć się więcej na temat tworzenia modułów programu PowerShell, zobacz Pisanie modułu programu Windows PowerShell.