Delen via

Uitvoering van runbooks in Azure Automation

  • Artikel

Met procesautomatisering in Azure Automation kunt u PowerShell, PowerShell Workflow en grafische runbooks maken en beheren. Zie Azure Automation-runbooks voor meer informatie.

Automation voert uw runbooks uit op basis van de logica die erin is gedefinieerd. Als een runbook wordt onderbroken, wordt het opnieuw gestart aan het begin. Voor dit gedrag moet u runbooks schrijven die ondersteuning bieden voor opnieuw opstarten als er tijdelijke problemen optreden.

Als u een runbook in Azure Automation start, wordt een taak gemaakt. Dit is één uitvoeringsexemplaren van het runbook. Elke taak heeft toegang tot Azure-resources door verbinding te maken met uw Azure-abonnement. De taak heeft alleen toegang tot resources in uw datacenter als deze resources toegankelijk zijn vanuit de openbare cloud.

Azure Automation wijst een werkrol toe om elke taak uit te voeren tijdens de uitvoering van het runbook. Terwijl werknemers worden gedeeld door veel Automation-accounts, worden taken van verschillende Automation-accounts geïsoleerd van elkaar. U kunt niet bepalen welke werkrolservices uw taakaanvragen aanvragen.

Wanneer u de lijst met runbooks in Azure Portal bekijkt, wordt de status weergegeven van elke taak die voor elk runbook is gestart. Azure Automation slaat taaklogboeken maximaal 30 dagen op.

In het volgende diagram ziet u de levenscyclus van een runbooktaak voor PowerShell-runbooks, PowerShell Workflow-runbooks en grafische runbooks.

Taakstatussen - PowerShell-werkstroom

Notitie

Voor informatie over het weergeven of verwijderen van persoonlijke gegevens raadpleegt u algemene verzoeken van betrokkenen voor de AVG, Azure-verzoeken van betrokkenen voor de AVG of Verzoeken van Betrokkenen van Windows voor de AVG, afhankelijk van uw specifieke gebied en behoeften. Zie de AVG-sectie van het Microsoft Trust Center en de AVG-sectie van de Service Trust Portal voor algemene informatie over de AVG.

Uitvoeringsomgeving runbook

Runbooks in Azure Automation kunnen worden uitgevoerd op een Azure-sandbox of een Hybrid Runbook Worker.

Wanneer runbooks zijn ontworpen om te verifiëren en uit te voeren op resources in Azure, worden ze uitgevoerd in een Azure-sandbox. Azure Automation wijst een werkrol toe om elke taak uit te voeren tijdens de uitvoering van het runbook in de sandbox. Terwijl werknemers worden gedeeld door veel Automation-accounts, worden taken van verschillende Automation-accounts geïsoleerd van elkaar. Taken die dezelfde sandbox gebruiken, zijn afhankelijk van de resourcebeperkingen van de sandbox. De Azure-sandboxomgeving biedt geen ondersteuning voor interactieve bewerkingen. Het voorkomt toegang tot alle niet-verwerkte COM-servers en biedt geen ondersteuning voor het plaatsen van WMI-aanroepen naar de Win32-provider in uw runbook.  Deze scenario's worden alleen ondersteund door het runbook uit te voeren op een Windows Hybrid Runbook Worker.

U kunt ook een Hybrid Runbook Worker gebruiken om runbooks rechtstreeks uit te voeren op de computer die als host fungeert voor de rol en voor lokale resources in de omgeving. Azure Automation slaat runbooks op en beheert deze en levert deze vervolgens aan een of meer toegewezen computers.

Als u de Azure Firewall inschakelt in Azure Storage, Azure Key Vault of Azure SQL, blokkeert u de toegang vanuit Azure Automation-runbooks voor deze services. De toegang wordt geblokkeerd, zelfs als de firewall-uitzondering om vertrouwde Microsoft-services toe te staan is ingeschakeld, omdat Automation geen deel uitmaakt van de lijst met vertrouwde services. Met een ingeschakelde firewall kan alleen toegang worden gemaakt met behulp van een Hybrid Runbook Worker en een service-eindpunt voor een virtueel netwerk.

Notitie

  • Als u wilt uitvoeren op een Linux Hybrid Runbook Worker, moeten uw scripts zijn ondertekend en moet de werkrol dienovereenkomstig zijn geconfigureerd. U kunt ook handtekeningvalidatie uitschakelen.
  • Runbookuitvoering mag niet afhankelijk zijn van de tijdzone van de sandbox.

De volgende tabel bevat enkele runbookuitvoeringstaken met de aanbevolen uitvoeringsomgeving die voor elke omgeving wordt vermeld.

Opdracht Aanbeveling Opmerkingen
Integreren met Azure-bronnen Azure Sandbox Gehost in Azure is eenvoudigere verificatie. Als u een Hybrid Runbook Worker op een Azure-VM gebruikt, kunt u runbookverificatie gebruiken met beheerde identiteiten.
Verkrijg optimale prestaties voor het beheren van Azure-bronnen Azure Sandbox Script wordt uitgevoerd in dezelfde omgeving, die minder wachttijd heeft.
Minimaliseren operationele kosten Azure Sandbox Er is geen rekenoverhead en er is geen VM nodig.
Langdurig script uitvoeren Hybrid Runbook Worker Azure-sandboxes hebben resourcelimieten.
Interactie met lokale services Hybrid Runbook Worker Rechtstreeks toegang tot de hostcomputer of bronnen in andere cloudomgevingen of de on-premises omgeving.
Software en uitvoerbare bestanden van derden vereist Hybrid Runbook Worker U beheert het besturingssysteem en kunt software installeren.
Een bestand of map bewaken met een runbook Hybrid Runbook Worker Gebruik een Watcher-taak op een Hybrid Runbook Worker.
Een resource-intensief script uitvoeren Hybrid Runbook Worker Azure-sandboxes hebben resourcelimieten.
Modules gebruiken met specifieke vereisten Hybrid Runbook Worker Enkele voorbeelden zijn:
WinSCP - afhankelijk van winscp.exe
IIS-beheer - afhankelijk van het inschakelen of beheren van IIS
Een module installeren met een installatieprogramma Hybrid Runbook Worker Modules voor sandbox moeten ondersteuning bieden voor kopiëren.
Runbooks of modules gebruiken waarvoor de .NET Framework-versie anders is dan 4.7.2 Hybrid Runbook Worker Azure-sandboxes ondersteunen .NET Framework 4.7.2 en het upgraden naar een andere versie wordt niet ondersteund.
Scripts uitvoeren waarvoor benodigde bevoegdheden zijn vereist Hybrid Runbook Worker Sandboxes staan geen uitbreiding toe. Met een Hybrid Runbook Worker kunt u UAC uitschakelen en Aanroepen gebruiken bij het uitvoeren van de opdracht waarvoor uitbreiding is vereist.
Scripts uitvoeren waarvoor toegang tot Windows Management Instrumentation (WMI) is vereist Hybrid Runbook Worker Taken die worden uitgevoerd in sandboxes in de cloud, hebben geen toegang tot WMI-provider.

Tijdelijke opslag in een sandbox

Als u tijdelijke bestanden wilt maken als onderdeel van uw runbooklogica, kunt u de map Temp (dat wil $env:TEMPgezegd) gebruiken in de Azure-sandbox voor runbooks die worden uitgevoerd in Azure. De enige beperking is dat u niet meer dan 1 GB schijfruimte kunt gebruiken. Dit is het quotum voor elke sandbox. Wanneer u met PowerShell-werkstromen werkt, kan dit scenario een probleem veroorzaken omdat PowerShell-werkstromen controlepunten gebruiken en het script opnieuw kan worden geprobeerd in een andere sandbox.

Met de hybride sandbox kunt u gebruikmaken C:\temp van de beschikbaarheid van opslag op een Hybrid Runbook Worker. U moet echter niet de tijdelijke schijf in Windows of Linux gebruiken voor gegevens die moeten worden bewaard volgens de aanbevelingen van azure-VM's.

Resources

Uw runbooks moeten logica bevatten om te kunnen omgaan met resources, zoals VM's, het netwerk en resources in het netwerk. Resources zijn gekoppeld aan een Azure-abonnement en runbooks vereisen de juiste referenties voor toegang tot elke resource. Zie Resources verwerken voor een voorbeeld van het verwerken van resources in een runbook.

Beveiliging

Azure Automation maakt gebruik van de Microsoft Defender voor Cloud om uw resources te beveiligen en inbreuk in Linux-systemen te detecteren. Beveiliging wordt geboden voor uw workloads, ongeacht of resources zich in Azure bevinden of niet. Zie Inleiding tot verificatie in Azure Automation.

Defender voor Cloud worden beperkingen gesteld voor gebruikers die scripts, ondertekend of niet-ondertekend, kunnen uitvoeren op een virtuele machine. Als u een gebruiker bent met hoofdtoegang tot een virtuele machine, moet u de computer expliciet configureren met een digitale handtekening of deze uitschakelen. Anders kunt u alleen een script uitvoeren om updates van het besturingssysteem toe te passen nadat u een Automation-account hebt gemaakt en de juiste functie hebt ingeschakeld.

Abonnementen

Een Azure-abonnement is een overeenkomst met Microsoft voor het gebruik van een of meer cloudservices waarvoor kosten in rekening worden gebracht. Voor Azure Automation is elk abonnement gekoppeld aan een Azure Automation-account en kunt u meerdere abonnementen in het account maken.

Referentie

Voor een runbook zijn de juiste referenties vereist voor toegang tot elke resource, ongeacht of het gaat om systemen van Azure of derden. Deze referenties worden opgeslagen in Azure Automation, Key Vault, enzovoort.

Azure Monitor

Azure Automation maakt gebruik van Azure Monitor voor het bewaken van de machinebewerkingen. Voor de bewerkingen zijn een Log Analytics-werkruimte en een Log Analytics-agent vereist.

Log Analytics-agent voor Windows

De Log Analytics-agent voor Windows werkt met Azure Monitor om Virtuele Windows-machines en fysieke computers te beheren. De machines kunnen worden uitgevoerd in Azure of in een niet-Azure-omgeving, zoals een lokaal datacenter.

Notitie

De Log Analytics-agent voor Windows werd voorheen bekend als de Microsoft Monitoring Agent (MMA).

Log Analytics-agent voor Linux

De Log Analytics-agent voor Linux werkt op dezelfde manier als de agent voor Windows, maar verbindt Linux-computers met Azure Monitor. De agent wordt geïnstalleerd met bepaalde serviceaccounts die opdrachten uitvoeren waarvoor hoofdmachtigingen zijn vereist. Zie Serviceaccounts voor meer informatie.

Het Log Analytics-agentlogboek bevindt zich op /var/opt/microsoft/omsagent/log/omsagent.log.

Runbookmachtigingen

Een runbook heeft machtigingen nodig voor verificatie bij Azure via referenties. Zie het overzicht van Azure Automation-verificatie.

Modules

Azure Automation bevat de volgende PowerShell-modules:

  • Orchestrator.AssetManagement.Cmdlets: bevat verschillende interne cmdlets die alleen beschikbaar zijn wanneer u runbooks uitvoert in de Azure-sandboxomgeving of op een Windows Hybrid Runbook Worker. Deze cmdlets zijn ontworpen om te worden gebruikt in plaats van Azure PowerShell-cmdlets om te communiceren met uw Automation-accountresources.
  • Az.Automation: de aanbevolen PowerShell-module voor interactie met Azure Automation die de AzureRM Automation-module vervangt. De Az.Automation-module wordt niet automatisch opgenomen wanneer u een Automation-account maakt en u dient deze handmatig te importeren.
  • AzureRM.Automation: standaard geïnstalleerd wanneer u een Automation-account maakt.

Ook worden ondersteunde modules geïnstalleerd, op basis van de cmdlets die uw runbooks en DSC-configuraties vereisen. Zie Modules beheren in Azure Automation voor meer informatie over de modules die beschikbaar zijn voor uw runbooks en DSC-configuraties.

Certificaten

Azure Automation maakt gebruik van certificaten voor verificatie bij Azure of voegt deze toe aan Azure- of externe resources. De certificaten worden veilig opgeslagen voor toegang door runbooks en DSC-configuraties.

Uw runbooks kunnen zelfondertekende certificaten gebruiken, die niet zijn ondertekend door een certificeringsinstantie (CA). Zie Een nieuw certificaat maken.

Projecten

Azure Automation ondersteunt een omgeving voor het uitvoeren van taken vanuit hetzelfde Automation-account. Eén runbook kan veel taken tegelijk uitvoeren. Hoe meer taken u tegelijkertijd uitvoert, hoe vaker ze naar dezelfde sandbox kunnen worden verzonden. Maximaal 10 taken kunnen worden uitgevoerd in een sandbox. Er wordt een sandbox verwijderd wanneer er geen taken worden uitgevoerd; daarom mag het niet worden gebruikt om bestanden op te slaan.

Taken die in hetzelfde sandboxproces worden uitgevoerd, kunnen van invloed zijn op elkaar. Een voorbeeld is het uitvoeren van de cmdlet Disconnect-AzAccount . De uitvoering van deze cmdlet verbreekt elke runbooktaak in het gedeelde sandboxproces. Zie Gelijktijdige taken voorkomen voor een voorbeeld van het werken met dit scenario.

Notitie

PowerShell-taken die zijn gestart vanuit een runbook dat wordt uitgevoerd in een Azure-sandbox, worden mogelijk niet uitgevoerd in de volledige PowerShell-taalmodus.

Taakstatussen

In de volgende tabel worden de statussen beschreven die mogelijk zijn voor een taak. U kunt een statusoverzicht voor alle runbooktaken bekijken of details analyseren van een specifieke runbooktaak in Azure Portal. U kunt ook integratie met uw Log Analytics-werkruimte configureren om de status van runbooktaak en taakstromen door te sturen. Zie Taakstatus en taakstromen doorsturen van Automation naar Azure Monitor-logboeken voor meer informatie over de integratie met Azure Monitor-logboeken. Zie ook Taakstatussen verkrijgen voor een voorbeeld van het werken met statussen in een runbook.

-Status Beschrijving
Activering De taak wordt geactiveerd.
Voltooid De taak is voltooid
Mislukt Het compileren van een grafisch of PowerShell Workflow-runbook mislukt. Het starten van een PowerShell-runbook mislukt of de taak had een uitzondering. Zie Azure Automation-runbooktypen.
Mislukt, wachten op resources De taak is mislukt omdat de limiet voor evenredige verdeling drie keer is bereikt en elke keer vanaf hetzelfde controlepunt of vanaf het begin van het runbook is gestart.
In wachtrij geplaatst De taak wacht tot resources op een Automation-werkrol beschikbaar zijn, zodat deze kan worden gestart.
Hervatten Het systeem hervat de taak nadat deze tijdelijk is geblokkeerd.
Wordt uitgevoerd De taak wordt uitgevoerd
Word uitgevoerd, wachten op resources De taak is verwijderd omdat deze de limiet voor eerlijke verdeling heeft bereikt. Deze wordt spoedig hervat vanaf het laatste controlepunt.
Starten De taak is toegewezen aan een werkrol en het systeem start deze.
Gestopt De taak is gestopt door de gebruiker voordat deze is voltooid.
Stoppen Het systeem stopt de taak.
Onderbroken Alleen van toepassing op grafische en PowerShell Workflow-runbooks. De taak is onderbroken door de gebruiker, door het systeem of door een opdracht in het runbook. Als een runbook geen controlepunt heeft, begint het vanaf het begin. Als het een controlepunt heeft, kan het opnieuw worden gestart en hervat vanaf het laatste controlepunt. Het systeem blokkeert alleen tijdelijk het runbook wanneer er een uitzondering optreedt. De variabele is standaard ErrorActionPreference ingesteld op Doorgaan, wat aangeeft dat de taak wordt uitgevoerd op een fout. Als de voorkeursvariabele is ingesteld op Stoppen, wordt de taak onderbroken bij een fout.
Tijdelijk blokkeren Alleen van toepassing op grafische en PowerShell Workflow-runbooks. Het systeem probeert de taak tijdelijk te blokkeren op verzoek van de gebruiker. Het runbook moet het volgende controlepunt bereiken voordat het tijdelijk kan worden onderbroken. Als het laatste controlepunt al is doorgegeven, wordt het voltooid voordat het tijdelijk kan worden geblokkeerd.
Nieuw De taak is onlangs ingediend, maar is nog niet geactiveerd.

Activiteitenregistratie

Bij uitvoering van runbooks in Azure Automation worden details in een activiteitenlogboek voor het Automation-account geschreven. Zie Details ophalen uit het activiteitenlogboek voor meer informatie over het gebruik van het logboek.

Uitzonderingen

In deze sectie worden enkele manieren beschreven om uitzonderingen of onregelmatige problemen in uw runbooks af te handelen. Een voorbeeld is een WebSocket-uitzondering. De juiste uitzonderingsafhandeling voorkomt dat tijdelijke netwerkfouten ervoor zorgen dat uw runbooks mislukken.

ErrorActionPreference

De variabele ErrorActionPreference bepaalt hoe PowerShell reageert op een niet-afsluitfout. Afsluitfouten worden altijd beëindigd en worden niet beïnvloed door ErrorActionPreference.

Wanneer het runbook wordt gebruikt ErrorActionPreference, stopt een normaal niet-afsluitfout, zoals PathNotFound uit de cmdlet Get-ChildItem , dat het runbook niet kan worden voltooid. In het volgende voorbeeld ziet u het gebruik van ErrorActionPreference. De laatste opdracht Write-Output wordt nooit uitgevoerd, omdat het script stopt.

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

Probeer catch eindelijk

Try Catch Finally wordt gebruikt in PowerShell-scripts voor het afhandelen van afsluitfouten. Het script kan dit mechanisme gebruiken om specifieke uitzonderingen of algemene uitzonderingen te ondervangen. De catch instructie moet worden gebruikt om fouten bij te houden of te verwerken. In het volgende voorbeeld wordt geprobeerd een bestand te downloaden dat niet bestaat. De uitzondering wordt onderschept System.Net.WebException en retourneert de laatste waarde voor een andere uitzondering.

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."
}

Werpen

Throw kan worden gebruikt om een afsluitfout te genereren. Dit mechanisme kan handig zijn bij het definiëren van uw eigen logica in een runbook. Als het script voldoet aan een criterium dat het moet stoppen, kan het de throw instructie gebruiken om te stoppen. In het volgende voorbeeld wordt deze instructie gebruikt om een vereiste functieparameter weer te geven.

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

Fouten

Uw runbooks moeten fouten afhandelen. Azure Automation ondersteunt twee typen PowerShell-fouten, het beëindigen en niet-beëindigen.

Afsluitfouten stoppen de uitvoering van runbooks wanneer ze optreden. Het runbook stopt met de taakstatus Mislukt.

Niet-afsluitfouten zorgen ervoor dat een script kan worden voortgezet, zelfs nadat deze zijn opgetreden. Een voorbeeld van een niet-afsluitfout is een fout die optreedt wanneer een runbook de Get-ChildItem cmdlet gebruikt met een pad dat niet bestaat. PowerShell ziet dat het pad niet bestaat, genereert een fout en gaat door naar de volgende map. De fout in dit geval stelt de status van de runbooktaak niet in op Mislukt en de taak kan zelfs worden voltooid. Als u wilt afdwingen dat een runbook stopt op een niet-afsluitfout, kunt u deze gebruiken ErrorAction Stop voor de cmdlet.

Aanroepende processen

Runbooks die worden uitgevoerd in Azure-sandboxes bieden geen ondersteuning voor aanroepende processen, zoals uitvoerbare bestanden (.exe bestanden) of subprocessen. De reden hiervoor is dat een Azure-sandbox een gedeeld proces is dat wordt uitgevoerd in een container die mogelijk geen toegang heeft tot alle onderliggende API's. Voor scenario's waarvoor software van derden of aanroepen naar subprocessen zijn vereist, moet u een runbook uitvoeren op een Hybrid Runbook Worker.

Apparaat- en toepassingskenmerken

Runbooktaken in Azure-sandboxes hebben geen toegang tot apparaat- of toepassingskenmerken. De meest voorkomende API die wordt gebruikt voor het opvragen van metrische prestatiegegevens in Windows is WMI, waarbij een aantal algemene metrische gegevens geheugen en CPU-gebruik zijn. Het maakt echter niet uit welke API wordt gebruikt, omdat taken die in de cloud worden uitgevoerd, geen toegang hebben tot de Microsoft-implementatie van Web-Based Enterprise Management (WBEM). Dit platform is gebaseerd op het Common Information Model (CIM), dat de industriestandaarden biedt voor het definiëren van apparaat- en toepassingskenmerken.

Webhooks

Externe services, bijvoorbeeld Azure DevOps Services en GitHub, kunnen een runbook starten in Azure Automation. Om dit type opstartproces uit te voeren, gebruikt de service een webhook via één HTTP-aanvraag. Met het gebruik van een webhook kunnen runbooks worden gestart zonder implementatie van een volledige Azure Automation-functie.

Gedeelde resources

Om resources te delen tussen alle runbooks in de cloud, maakt Azure gebruik van een concept met de naam fair share. Met evenredige verdeling wordt elke taak die langer dan drie uur is uitgevoerd, tijdelijk uit azure verwijderd of gestopt. Taken voor PowerShell-runbooks en Python-runbooks worden gestopt en niet opnieuw opgestart en de taakstatus wordt gestopt.

Voor langlopende Azure Automation-taken is het raadzaam om een Hybrid Runbook Worker te gebruiken. Hybrid Runbook Workers worden niet beperkt door evenredige verdeling en hebben geen beperking voor hoe lang een runbook kan worden uitgevoerd. De andere taaklimieten zijn van toepassing op zowel Azure-sandboxes als Hybrid Runbook Workers. Hoewel Hybrid Runbook Workers niet wordt beperkt door de limiet voor evenredige verdeling van drie uur, moet u runbooks ontwikkelen om uit te voeren op de werkrollen die ondersteuning bieden voor opnieuw opstarten van onverwachte problemen met de lokale infrastructuur.

Een andere optie is om een runbook te optimaliseren met behulp van onderliggende runbooks. Het runbook kan bijvoorbeeld dezelfde functie doorlopen op verschillende resources, bijvoorbeeld met een databasebewerking op verschillende databases. U kunt deze functie verplaatsen naar een onderliggend runbook en het runbook laten aanroepen met behulp van Start-AzAutomationRunbook. Onderliggende runbooks worden parallel uitgevoerd in afzonderlijke processen.

Als u onderliggende runbooks gebruikt, wordt de totale hoeveelheid tijd voor het voltooien van het bovenliggende runbook verlaagd. Uw runbook kan de Cmdlet Get-AzAutomationJob gebruiken om de taakstatus van een onderliggend runbook te controleren als het nog steeds meer bewerkingen heeft nadat het onderliggende item is voltooid.

Volgende stappen