Spouštění runbooků ve službě Azure Automation

  • Článek

Automatizace procesů ve službě Azure Automation umožňuje vytvářet a spravovat PowerShell, pracovní postup PowerShellu a grafické runbooky. Podrobnosti najdete v runboocích Azure Automation.

Automatizace spouští runbooky na základě logiky, která je v nich definovaná. Pokud se runbook přeruší, restartuje se na začátku. Toto chování vyžaduje, abyste napsali runbooky, které podporují restartování, pokud dojde k přechodným problémům.

Spuštění runbooku ve službě Azure Automation vytvoří úlohu, což je jedna instance spuštění runbooku. Každá úloha přistupuje k prostředkům Azure tak, že vytvoří připojení k vašemu předplatnému Azure. Úloha má přístup k prostředkům ve vašem datacentru jenom v případě, že jsou tyto prostředky přístupné z veřejného cloudu.

Azure Automation přiřadí pracovní proces ke spuštění každé úlohy během provádění runbooku. Zatímco pracovní procesy sdílí mnoho účtů Automation, úlohy z různých účtů Automation jsou navzájem izolované. Nemůžete řídit, které služby pracovního procesu vaše žádosti o úlohy.

Když zobrazíte seznam runbooků na webu Azure Portal, zobrazí se stav každé úlohy, která byla spuštěna pro jednotlivé runbooky. Azure Automation ukládá protokoly úloh maximálně po dobu 30 dnů.

Následující diagram znázorňuje životní cyklus úlohy runbooku pro runbooky PowerShellu, runbooky pracovního postupu PowerShellu a grafické runbooky.

Job Statuses - PowerShell Workflow

Poznámka:

Informace o zobrazení nebo odstranění osobních údajů najdete v tématu věnovaném žádostem subjektů údajů Azure podle GDPR. Další informace o GDPR najdete v části GDPR v Centru zabezpečení Microsoftu a v části GDPR na portálu Service Trust Portal.

Spouštěcí prostředí runbooku

Runbooky ve službě Azure Automation se můžou spouštět buď v sandboxu Azure, nebo v procesu Hybrid Runbook Worker.

Pokud jsou runbooky navržené tak, aby se ověřily a spouštěly na prostředcích v Azure, běží v sandboxu Azure. Azure Automation přiřadí pracovní proces ke spuštění každé úlohy během provádění runbooku v sandboxu. Zatímco pracovní procesy sdílí mnoho účtů Automation, úlohy z různých účtů Automation jsou navzájem izolované. Úlohy používající stejný sandbox jsou vázané na omezení prostředků sandboxu. Prostředí sandboxu Azure nepodporuje interaktivní operace. Zabraňuje přístupu ke všem neprocesovým serverům COM a nepodporuje volání rozhraní WMI pro poskytovatele Win32 ve vašem runbooku.  Tyto scénáře jsou podporovány pouze spuštěním runbooku v procesu Hybrid Runbook Worker systému Windows.

Funkci Hybrid Runbook Worker můžete také použít ke spouštění runbooků přímo na počítači, který je hostitelem role a proti místním prostředkům v prostředí. Azure Automation ukládá a spravuje runbooky a pak je dodává do jednoho nebo více přiřazených počítačů.

Povolení služby Azure Firewall ve službě Azure Storage, Azure Key Vault nebo Azure SQL blokuje přístup z runbooků Azure Automation pro tyto služby. Přístup se zablokuje i v případě, že je povolená výjimka brány firewall pro povolení důvěryhodných služby Microsoft, protože služba Automation není součástí seznamu důvěryhodných služeb. S povolenou bránou firewall je možné přístup vytvořit pouze pomocí funkce Hybrid Runbook Worker a koncového bodu služby virtuální sítě.

Poznámka:

  • Pokud chcete spustit funkci Hybrid Runbook Worker s Linuxem, musí být skripty podepsané a pracovní proces se odpovídajícím způsobem nakonfiguruje. Případně musí být ověření podpisu vypnuté.
  • Spouštění runbooků by nemělo záviset na časovém pásmu sandboxu.

Následující tabulka uvádí některé úlohy provádění runbooků s doporučeným spouštěcím prostředím uvedeným pro každý z nich.

Úkol Doporučení Notes
Integrace s prostředky Azure Azure Sandbox Hostované v Azure, ověřování je jednodušší. Pokud na virtuálním počítači Azure používáte funkci Hybrid Runbook Worker, můžete použít ověřování runbooků se spravovanými identitami.
Získání optimálního výkonu pro správu prostředků Azure Azure Sandbox Skript se spouští ve stejném prostředí, což má menší latenci.
Minimalizace provozních nákladů Azure Sandbox Není k dispozici žádná režie na výpočetní prostředky a virtuální počítač není potřeba.
Spuštění dlouhotrvajícího skriptu Hybrid Runbook Worker Sandboxy Azure mají limity prostředků.
Interakce s místními službami Hybrid Runbook Worker Přímý přístup k hostitelskému počítači nebo prostředkům v jiných cloudových prostředích nebo v místním prostředí.
Vyžadování softwaru a spustitelných souborů třetích stran Hybrid Runbook Worker Operační systém spravujete a můžete nainstalovat software.
Monitorování souboru nebo složky pomocí runbooku Hybrid Runbook Worker Použijte úlohu Watcheru v procesu Hybrid Runbook Worker.
Spuštění skriptu náročného na prostředky Hybrid Runbook Worker Sandboxy Azure mají limity prostředků.
Použití modulů s konkrétními požadavky Hybrid Runbook Worker Mezi příklady patří:
WinSCP – závislost na správě služby winscp.exe
IIS – závislost na povolení nebo správě služby IIS
Instalace modulu pomocí instalačního programu Hybrid Runbook Worker Moduly sandboxu musí podporovat kopírování.
Používejte runbooky nebo moduly, které vyžadují verzi rozhraní .NET Framework, která se liší od verze 4.7.2. Hybrid Runbook Worker Sandboxy Azure podporují rozhraní .NET Framework 4.7.2 a upgrade na jinou verzi se nepodporuje.
Spouštění skriptů, které vyžadují zvýšení oprávnění Hybrid Runbook Worker Sandboxy neumožňují zvýšení oprávnění. Pomocí funkce Hybrid Runbook Worker můžete nástroj Řízení uživatelských účtů vypnout a při spuštění příkazu, který vyžaduje zvýšení oprávnění, použít příkaz Invoke-Command .
Spouštění skriptů, které vyžadují přístup k rozhraní WMI (Windows Management Instrumentation) Hybrid Runbook Worker Úlohy spuštěné v sandboxech v cloudu nemají přístup k poskytovateli rozhraní WMI.

Dočasné úložiště v sandboxu

Pokud potřebujete v logice runbooku vytvořit dočasné soubory, můžete pro runbooky spuštěné v Azure použít složku Temp (tj $env:TEMP. ) v sandboxu Azure. Jediným omezením je, že nemůžete použít více než 1 GB místa na disku, což je kvóta pro každý sandbox. Při práci s pracovními postupy PowerShellu může tento scénář způsobit problém, protože pracovní postupy PowerShellu používají kontrolní body a skript se může opakovat v jiném sandboxu.

S hybridním sandboxem můžete použít C:\temp na základě dostupnosti úložiště v hybrid Runbook Worker. Na základě doporučení pro virtuální počítače Azure byste ale neměli používat dočasný disk ve Windows nebo Linuxu pro data, která je potřeba zachovat.

Zdroje informací

Vaše runbooky musí obsahovat logiku pro řešení prostředků, například virtuálních počítačů, sítě a prostředků v síti. Prostředky jsou svázané s předplatným Azure a runbooky vyžadují pro přístup k libovolnému prostředku odpovídající přihlašovací údaje. Příklad zpracování prostředků v runbooku najdete v tématu Zpracování prostředků.

Zabezpečení

Azure Automation používá Microsoft Defender for Cloud k zajištění zabezpečení vašich prostředků a detekci ohrožení zabezpečení v systémech Linux. Zabezpečení se poskytuje napříč vašimi úlohami bez ohledu na to, jestli jsou prostředky v Azure, nebo ne. Viz Úvod k ověřování ve službě Azure Automation.

Defender for Cloud má omezení pro uživatele, kteří můžou na virtuálním počítači spouštět jakékoli skripty podepsané nebo nepodepsané. Pokud jste uživatel s kořenovým přístupem k virtuálnímu počítači, musíte počítač explicitně nakonfigurovat pomocí digitálního podpisu nebo ho vypnout. V opačném případě můžete spustit skript, který použije aktualizace operačního systému po vytvoření účtu Automation a povolení příslušné funkce.

Předplatná

Předplatné Azure je smlouva s Microsoftem o používání jedné nebo více cloudových služeb, za které se vám účtují poplatky. Pro Azure Automation je každé předplatné propojené s účtem Azure Automation a v účtu můžete vytvořit více předplatných .

Přihlašovací údaje

Runbook vyžaduje odpovídající přihlašovací údaje pro přístup k libovolnému prostředku, ať už pro systémy Azure nebo jiného výrobce. Tyto přihlašovací údaje se ukládají ve službě Azure Automation, Key Vault atd.

Azure Monitor

Azure Automation využívá Azure Monitor k monitorování operací počítače. Operace vyžadují pracovní prostor služby Log Analytics a agenta Log Analytics.

Agent Log Analytics pro Windows

Agent Log Analytics pro Windows spolupracuje se službou Azure Monitor na správě virtuálních počítačů a fyzických počítačů s Windows. Počítače můžou běžet v Azure nebo v prostředí mimo Azure, například v místním datacentru.

Poznámka:

Agent Log Analytics pro Windows se dříve označoval jako Microsoft Monitoring Agent (MMA).

Agent Log Analytics pro Linux

Agent Log Analytics pro Linux funguje podobně jako agent pro Windows, ale připojuje počítače s Linuxem ke službě Azure Monitor. Agent se instaluje s určitými účty služeb, které spouštějí příkazy vyžadující kořenová oprávnění. Další informace najdete v tématu Účty služeb.

Protokol agenta Log Analytics se nachází na /var/opt/microsoft/omsagent/log/omsagent.logadrese .

Oprávnění runbooků

Runbook potřebuje oprávnění pro ověřování v Azure prostřednictvím přihlašovacích údajů. Podívejte se na přehled ověřování Azure Automation.

Moduly

Azure Automation zahrnuje následující moduly PowerShellu:

  • Orchestrator.AssetManagement.Cmdlets – obsahuje několik interních rutin, které jsou k dispozici pouze při spouštění runbooků v prostředí sandboxu Azure nebo v procesu Hybrid Runbook Worker pro Windows. Tyto rutiny jsou navržené tak, aby se používaly místo Azure PowerShell rutin k interakci s prostředky účtu Automation.
  • Az.Automation – doporučený modul PowerShellu pro interakci se službou Azure Automation, který nahrazuje modul AzureRM Automation. Modul Az.Automation se při vytváření účtu Automation automaticky nezahrne a musíte ho importovat ručně.
  • AzureRM.Automation – ve výchozím nastavení se instaluje při vytváření účtu Automation.

Podporují se také instalovatelné moduly na základě rutin, které vyžadují vaše runbooky a konfigurace DSC. Podrobnosti o modulech dostupných pro runbooky a konfigurace DSC najdete v tématu Správa modulů ve službě Azure Automation.

Certifikáty

Azure Automation používá certifikáty k ověřování do Azure nebo je přidává do prostředků Azure nebo jiných výrobců. Certifikáty jsou bezpečně uložené pro přístup pomocí runbooků a konfigurací DSC.

Vaše runbooky můžou používat certifikáty podepsané svým držitelem, které nejsou podepsané certifikační autoritou (CA). Viz Vytvoření nového certifikátu.

Úlohy

Azure Automation podporuje prostředí pro spouštění úloh ze stejného účtu Automation. Jeden runbook může mít najednou spuštěných mnoho úloh. Čím více úloh spustíte současně, tím častěji se dají odeslat do stejného sandboxu. V sandboxu může běžet maximálně 10 úloh. Sandbox se odebere, když se v něm nespouštějí žádné úlohy; proto by se nemělo používat k ukládání souborů.

Úlohy spuštěné ve stejném procesu sandboxu můžou vzájemně ovlivnit. Jedním z příkladů je spuštění rutiny Disconnect-AzAccount . Spuštění této rutiny odpojí každou úlohu runbooku ve sdíleném procesu sandboxu. Příklad práce s tímto scénářem najdete v tématu Zabránění souběžným úlohám.

Poznámka:

Úlohy PowerShellu spuštěné z runbooku, který běží v sandboxu Azure, nemusí běžet v úplném režimu jazyka PowerShellu.

Stavy úloh

Následující tabulka popisuje stavy, které jsou pro úlohu možné. Můžete zobrazit souhrn stavu pro všechny úlohy runbooku nebo přejít k podrobnostem konkrétní úlohy runbooku na webu Azure Portal. Integraci s pracovním prostorem služby Log Analytics můžete také nakonfigurovat tak, aby předávala stav úlohy runbooku a datové proudy úloh. Další informace o integraci s protokoly služby Azure Monitor najdete v tématu Předávání stavu úloh a datových proudů úloh z Automation do protokolů služby Azure Monitor. Podívejte se také na získání stavů úloh, například práce se stavy v runbooku.

Průběh Popis
Aktivace Úloha se aktivuje.
Dokončená Úloha byla úspěšně dokončena.
Nezdařilo se Nepovedlo se zkompilovat grafický runbook nebo runbook pracovního postupu PowerShellu. Runbook PowerShellu se nepovedlo spustit nebo došlo k výjimce úlohy. Viz typy runbooků Azure Automation.
Selhání, čekání na prostředky Úloha selhala, protože třikrát dosáhla limitu spravedlivého sdílení a spustila se ze stejného kontrolního bodu nebo od začátku runbooku pokaždé.
Zařazeno do fronty Úloha čeká na zpřístupnění prostředků na pracovním procesu Automation, aby bylo možné ji spustit.
Obnovení Systém po pozastavení obnoví úlohu.
Spuštěno Úloha je spuštěná.
Spuštěno, čekání na prostředky Úloha byla uvolněna, protože dosáhla limitu spravedlivého sdílení. Zanedlouho bude pokračovat z posledního kontrolního bodu.
Spouštění Úloha byla přiřazena pracovnímu procesu a systém ji spouští.
Zastaveno Úloha byla zastavena uživatelem před dokončením.
Zastavování Systém zastavuje úlohu.
Odloženo Platí jenom pro grafické runbooky a runbooky pracovního postupu PowerShellu. Úloha byla pozastavena uživatelem, systémem nebo příkazem v runbooku. Pokud runbook nemá kontrolní bod, začíná od začátku. Pokud má kontrolní bod, může znovu začít a pokračovat z posledního kontrolního bodu. Systém pozastaví runbook pouze v případě, že dojde k výjimce. Ve výchozím nastavení ErrorActionPreference je proměnná nastavená na Continue (Pokračovat), což značí, že úloha stále běží na chybě. Pokud je proměnná předvoleb nastavená na Zastavit, úloha se pozastaví při chybě.
Pozastavení Platí jenom pro grafické runbooky a runbooky pracovního postupu PowerShellu. Systém se pokouší pozastavit úlohu na žádost uživatele. Aby bylo možné runbook pozastavit, musí se připojit k dalšímu kontrolnímu bodu. Pokud už uplynul poslední kontrolní bod, dokončí se, než bude možné ho pozastavit.

Protokolování aktivity

Při provádění runbooků ve službě Azure Automation se zapisují podrobnosti do protokolu aktivit daného účtu Automation. Podrobnosti o použití protokolu najdete v tématu Načtení podrobností z protokolu aktivit.

Výjimky

Tato část popisuje některé způsoby zpracování výjimek nebo občasných problémů v runboocích. Příkladem je výjimka WebSocket. Správné zpracování výjimek zabraňuje přechodným selháním sítě, aby runbooky selhaly.

ErrorActionPreference

Proměnná ErrorActionPreference určuje, jak PowerShell reaguje na neukončující chybu. Ukončující chyby vždy ukončují a nejsou ovlivněny ErrorActionPreference.

Pokud runbook používá ErrorActionPreference, obvykle neukončující chybu, například PathNotFound z rutiny Get-ChildItem zastaví dokončení runbooku. Následující příklad ukazuje použití ErrorActionPreference. Konečný příkaz Write-Output se nikdy nespustí, protože skript se zastaví.

$ErrorActionPreference = 'Stop'
Get-ChildItem -path nofile.txt
Write-Output "This message will not show"

Try Catch Finally

Try Catch Finally se používá ve skriptech PowerShellu ke zpracování ukončování chyb. Skript může tento mechanismus použít k zachycení konkrétních výjimek nebo obecných výjimek. Příkaz catch by se měl použít ke sledování nebo pokusu o zpracování chyb. Následující příklad se pokusí stáhnout soubor, který neexistuje. Zachytí System.Net.WebException výjimku a vrátí poslední hodnotu pro jakoukoli jinou výjimku.

try
{
   $wc = new-object System.Net.WebClient
   $wc.DownloadFile("http://www.contoso.com/MyDoc.doc")
}
catch [System.Net.WebException]
{
    "Unable to download MyDoc.doc from http://www.contoso.com."
}
catch
{
    "An error occurred that could not be resolved."
}

Throw

K vygenerování ukončovací chyby lze použít throw . Tento mechanismus může být užitečný při definování vlastní logiky v runbooku. Pokud skript splňuje kritérium, které by ho mělo zastavit, může tento příkaz použít throw k zastavení. Následující příklad používá tento příkaz k zobrazení požadovaného parametru funkce.

function Get-ContosoFiles
{
  param ($path = $(throw "The Path parameter is required."))
  Get-ChildItem -Path $path\*.txt -recurse
}

Chyby

Vaše runbooky musí zpracovávat chyby. Azure Automation podporuje dva typy chyb PowerShellu, ukončování a neukončování.

Ukončení chyb zastaví provádění runbooku, když dojde k jejich výskytu. Runbook se zastaví se stavem úlohy Selhání.

Neukončující chyby umožňují skriptu pokračovat i po jejich výskytu. Příkladem neukončující chyby je chyba, která nastane, když runbook používá rutinu Get-ChildItem s cestou, která neexistuje. PowerShell zjistí, že cesta neexistuje, vyvolá chybu a pokračuje do další složky. Chyba v tomto případě nenastaví stav úlohy runbooku na Selhání a úloha může být dokonce dokončena. Pokud chcete vynutit zastavení runbooku při neukončující chybě, můžete ji použít ErrorAction Stop v rutině.

Volání procesů

Runbooky, které běží v sandboxech Azure, nepodporují volání procesů, jako jsou spustitelné soubory (soubory .exe ) nebo podprocesy. Důvodem je, že sandbox Azure je sdílený proces spuštěný v kontejneru, který nemusí mít přístup ke všem základním rozhraním API. V případě scénářů vyžadujících software třetích stran nebo volání podprocesů byste měli spustit runbook v procesu Hybrid Runbook Worker.

Charakteristiky zařízení a aplikací

Úlohy runbooků v sandboxech Azure nemají přístup k žádným charakteristikám zařízení ani aplikací. Nejběžnějším rozhraním API používaným k dotazování metrik výkonu ve Windows je rozhraní WMI s některými běžnými metrikami využití paměti a procesoru. Nezáleží ale na tom, jaké rozhraní API se používá, protože úlohy spuštěné v cloudu nemají přístup k implementaci služby WBEM (Web-Based Enterprise Management) od Microsoftu. Tato platforma je založená na modelu CIM (Common Information Model), který poskytuje oborové standardy pro definování charakteristik zařízení a aplikací.

Webhooky

Externí služby, například Azure DevOps Services a GitHub, můžou spustit runbook ve službě Azure Automation. K tomuto typu spuštění služba používá webhook prostřednictvím jednoho požadavku HTTP. Použití webhooku umožňuje spuštění runbooků bez implementace úplné funkce Azure Automation.

Sdílené prostředky

K sdílení prostředků mezi všemi runbooky v cloudu používá Azure koncept označovaný jako spravedlivé sdílení. Pomocí spravedlivého sdílení Azure dočasně uvolní nebo zastaví jakoukoli úlohu, která běží déle než tři hodiny. Úlohy runbooků PowerShellu a runbooků Pythonu se zastaví a nerestartují a stav úlohy se změní na Zastaveno.

U dlouhotrvajících úloh Služby Azure Automation se doporučuje použít funkci Hybrid Runbook Worker. Hybridní funkce Runbook Worker nejsou omezené spravedlivým sdílením a nemají omezení, jak dlouho může runbook běžet. Ostatní limity úloh platí pro sandboxy Azure i hybrid Runbook Worker. Hybridní pracovní procesy Runbook Worker nejsou omezeny limitem 3hodinového spravedlivého sdílení, měli byste vyvíjet runbooky pro spouštění na pracovních procesech, které podporují restartování z neočekávaných problémů s místní infrastrukturou.

Další možností je optimalizovat runbook pomocí podřízených runbooků. Runbook může například procházet stejnou funkcí u několika prostředků, například s operací databáze na několika databázích. Tuto funkci můžete přesunout do podřízeného runbooku a volat ji pomocí runbooku Start-AzAutomationRunbook. Podřízené runbooky se spouští paralelně v samostatných procesech.

Použití podřízených runbooků snižuje celkovou dobu dokončení nadřazeného runbooku. Runbook může pomocí rutiny Get-AzAutomationJob zkontrolovat stav úlohy podřízeného runbooku, pokud má i po dokončení podřízeného runbooku další operace.

Další kroky