Agents für Azure-VM-Skalierungsgruppen

  • Artikel

Azure DevOps Services

Agents für Azure-VM-Skalierungsgruppen, im Folgenden als „Skalierungsgruppen-Agents“ bezeichnet, sind eine Form von selbstgehosteten Agents, die automatisch skaliert werden können, um Ihre Anforderungen zu erfüllen. Diese Flexibilität verringert die Notwendigkeit, jederzeit dedizierte Agents auszuführen. Im Gegensatz zu von Microsoft gehosteten Agents können Sie Größe und Image von Computern, auf denen Agents ausgeführt werden, flexibel bestimmen.

Wenn Sie gerne von Microsoft gehostete Agents nutzen, aber die angebotenen Möglichkeiten nicht ausreichen, sollten Sie Skalierungsgruppen-Agents in Betracht ziehen. Im Folgenden finden Sie einige Beispiele:

  • Sie benötigen mehr Arbeitsspeicher, mehr Prozessorleistung, mehr Speicher oder mehr E/A, als native, von Microsoft gehostete Agents bieten.
  • Sie benötigen eine NCv2-VM mit bestimmten Anweisungssätzen für Machine Learning.
  • Sie müssen die Bereitstellung in einem privaten Azure App Service in einem privaten VNet ohne eingehende Konnektivität durchführen.
  • Sie müssen eine Unternehmensfirewall für bestimmte IP-Adressen öffnen, damit von Microsoft gehostete Agents mit Ihren Servern kommunizieren können.
  • Sie müssen die Netzwerkkonnektivität von Agentcomputern einschränken und zulassen, dass sie nur genehmigte Standorte erreichen können.
  • Sie können nicht genügend Agents von Microsoft erhalten, um Ihre Anforderungen zu erfüllen.
  • Ihre Aufträge überschreiten das Timeout der von Microsoft gehosteten Agents.
  • Sie können von Microsoft gehostete parallele Aufträge nicht in einzelne Projekte oder Teams in Ihrer Organisation partitionieren.
  • Sie möchten mehrere aufeinanderfolgende Aufträge auf einem Agent ausführen, um Caches für inkrementelle Quellpakete und Pakete auf Computerebene zu nutzen.
  • Sie möchten eine zusätzliche Konfiguration oder Cacheaufwärmung ausführen, bevor ein Agent damit beginnt, Aufträge anzunehmen.

Wenn Sie gerne selbstgehostete Agents verwenden, deren Verwaltung aber vereinfachen möchten, sollten Sie Skalierungsgruppen-Agents in Betracht ziehen. Im Folgenden finden Sie einige Beispiele:

  • Sie möchten nicht rund um die Uhr dedizierten Agents ausführen. Sie möchten die Bereitstellung von Agentcomputern aufheben, die nicht zum Ausführen von Aufträgen verwendet werden.
  • Sie führen nicht vertrauenswürdigen Code in Ihrer Pipeline aus und möchten nach jedem Auftrag ein Reimaging der Agentcomputer durchführen.
  • Sie möchten die regelmäßige Aktualisierung des Basisimages für Ihre Agents vereinfachen.

Hinweis

  • Mac-Agents können nicht mithilfe von Skalierungsgruppen ausgeführt werden. Sie können nur Windows- oder Linux-Agents auf diese Weise ausführen.

  • Die Verwendung von VMSS-Agentpools für Azure DevOps Services wird ausschließlich für Azure Public Cloud (globaler Dienst) unterstützt. Derzeit unterstützen VMSS-Agentpools keine weiteren nationalen Cloudangebote.

  • Sie sollten eine VM-Skalierungsgruppe nicht mehreren Pools zuordnen.

Erstellen der Skalierungsgruppe

Zur Vorbereitung der Erstellung von Skalierungsgruppen-Agents müssen Sie zunächst eine VM-Skalierungsgruppe im Azure-Portal erstellen. Sie müssen die VM-Skalierungsgruppe auf eine bestimmte Weise erstellen, damit Sie von Azure Pipelines verwaltet werden kann. Insbesondere müssen Sie die automatische Skalierungdeaktivieren, damit Azure Pipelines anhand der Anzahl der eingehenden Pipelineaufträge bestimmen kann, wie die Skalierung erfolgen soll. Es wird empfohlen, zur Erstellung der Skalierungsgruppe die folgenden Schritte zu befolgen.

Im folgenden Beispiel werden mit Azure Cloud Shell unter Verwendung des UbuntuLTS-VM-Images eine neue Ressourcengruppe und eine VM-Skalierungsgruppe erstellt.

Hinweis

In diesem Beispiel wird das UbuntuLTS-VM-Image für die Skalierungsgruppe verwendet. Wenn Sie ein benutzerdefiniertes VM-Image als Grundlage für Ihren Agent benötigen, erstellen Sie das benutzerdefinierte Image vor der Erstellung der Skalierungsgruppe, indem Sie die Schritte unter Erstellen einer Skalierungsgruppe mit benutzerdefiniertem Image, benutzerdefinierter Software oder benutzerdefinierter Festplattengröße befolgen.

  1. Navigieren Sie über https://shell.azure.com/ zu Azure Cloud Shell.

  2. Führen Sie den folgenden Befehl aus, um Ihr standardmäßiges Azure-Abonnement zu überprüfen.

    az account list -o table

    Wenn das gewünschte Abonnement nicht als Standardabonnement aufgeführt ist, wählen Sie das gewünschte Abonnement aus.

    az account set -s <your subscription ID>

  3. Erstellen Sie eine Ressourcengruppe für Ihre VM-Skalierungsgruppe.

    az group create \
--location westus \
--name vmssagents

  4. Erstellen Sie eine VM-Skalierungsgruppe in Ihrer Ressourcengruppe. In diesem Beispiel wird das Ubuntu2204-VM-Image angegeben.

    az vmss create \
--name vmssagentspool \
--resource-group vmssagents \
--image Ubuntu2204 \
--vm-sku Standard_D2_v4 \
--storage-sku StandardSSD_LRS \
--authentication-type SSH \
--generate-ssh-keys \
--instance-count 2 \
--disable-overprovision \
--upgrade-policy-mode manual \
--single-placement-group false \
--platform-fault-domain-count 1 \
--load-balancer "" \
--orchestration-mode Uniform

    Hinweis

    Azure Pipelines unterstützt keine Überbereitstellung und automatische Skalierung für Skalierungsgruppen. Vergewissern Sie sich, dass beide Features für Ihre Skalierungsgruppe deaktiviert sind.

    Da die Skalierungsgruppe von Azure Pipelines verwaltet wird, sind die folgenden Einstellungen erforderlich bzw. empfehlenswert:

    • --disable-overprovision: erforderlich
    • --upgrade-policy-mode manual: erforderlich
    • --load-balancer "": Azure Pipelines erfordert keinen Lastenausgleich, um Aufträge an die Agents im Agentpool der Skalierungsgruppe weiterzuleiten. Die Konfiguration eines Lastenausgleichs ist jedoch eine Möglichkeit, eine IP-Adresse für Ihren Skalierungsgruppe-Agent zu erhalten, die Sie für Firewallregeln verwenden können. Eine weitere Möglichkeit zum Erhalt einer IP-Adresse für Ihre Skalierungsgruppen-Agents besteht darin, Ihre Skalierungsgruppe mit den --public-ip-address-Optionen zu erstellen. Weitere Informationen zum Konfigurieren Ihrer Skalierungsgruppe mit einem Lastenausgleich oder einer öffentlichen IP-Adresse finden Sie in der Virtual Machine Scale Sets-Dokumentation und unter az vmss create.
    • --instance-count 2: Diese Einstellung ist nicht erforderlich, mit ihrer Hilfe können Sie jedoch vor der Erstellung eines Agentpools überprüfen, ob die Skalierungsgruppe einwandfrei funktioniert. Die Erstellung der beiden VMs kann einige Minuten in Anspruch nehmen. Wenn Sie später den Agentpool erstellen, löscht Azure Pipelines diese beiden virtuellen Computer und erstellt neue VMs.

    Wichtig

    Wenn Sie dieses Skript mit der Azure CLI unter Windows ausführen, müssen Sie die "" in --load-balancer "" wie folgt in einfache Anführungszeichen einschließen: --load-balancer '""'

    Wenn Ihre VM-Größe kurzlebige Betriebssystemdatenträger unterstützt, sind die folgenden Parameter zur Aktivierung kurzlebiger Betriebssystemdatenträger optional, werden aber empfohlen, um die Reimagingzeiten der VM zu verbessern.

    • --ephemeral-os-disk true
    • --os-disk-caching readonly

    Wichtig

    Kurzlebige Betriebssystemdatenträger werden nicht für alle VM-Größen unterstützt. Eine Liste der unterstützten VM-Größen finden Sie unter Kurzlebige Betriebssystemdatenträger für Azure-VMs.

    Wählen Sie ein beliebiges Linux- oder Windows-Image – entweder ein Image aus dem Azure Marketplace oder ein eigenes benutzerdefiniertes Image – aus, um die Skalierungsgruppe zu erstellen. Führen Sie keine Vorinstallation des Azure Pipelines-Agents im Image durch. Azure Pipelines installiert den Agent automatisch, wenn es neue VMs bereitstellt. Im obigen Beispiel wurde ein einfaches UbuntuLTS-Image verwendet. Anweisungen zum Erstellen und Verwenden eines benutzerdefinierten Images finden Sie in den häufig gestellten Fragen.

    Wählen Sie eine beliebige VM- und Speicher-SKU aus.

    Hinweis

    Aus lizenzrechtlichen Gründen können wir keine von Microsoft gehosteten Images bereitstellen. Es ist uns nicht möglich, diese Images zur Verwendung in Ihren Skalierungsgruppen-Agents zur Verfügung zu stellen. Aber die zum Generieren dieser Images verwendeten Skripts sind Open-Source-Skripts. Es steht Ihnen frei, diese Skripts zu nutzen und eigene benutzerdefinierte Images zu erstellen.

  5. Navigieren Sie nach der Erstellung Ihrer Skalierungsgruppe im Azure-Portal zu Ihrer Skalierungsgruppe, und überprüfen Sie die folgenden Einstellungen:

    • Upgraderichtlinie: Manuell

      Verify upgrade policy.

      Sie können diese Einstellung auch überprüfen, indem Sie den folgenden Azure CLI-Befehl ausführen.

      az vmss show --resource-group vmssagents --name vmssagentspool --output table

Name            ResourceGroup    Location    Zones    Capacity    Overprovision    UpgradePolicy
--------------  ---------------  ----------  -------  ----------  ---------------  ---------------
vmssagentspool  vmssagents       westus               0           False            Manual

    • Skalierung: Manuelle Skalierung

      Verify manual scale policy.

Wichtig

Azure Pipelines unterstützt keinen Instanzschutz. Stellen Sie sicher, dass Sie die Instanzschutzfunktionen Abskalieren und Aktionen für Skalierungsgruppen deaktiviert haben.

Orchestrierungsmodi

Azure-VM-Skalierungsgruppen können mit zwei Orchestrierungsmodi konfiguriert werden: Uniform und Flexible. Die Azure Pipelines-Unterstützung für den einheitlichen Orchestrierungsmodus ist für alle Kunden allgemein verfügbar.

Der flexible Orchestrierungsmodus ermöglicht es Azure Pipelines, mehrere Skalierungsgruppenvorgänge parallel in die Warteschlange zu stellen. Die Azure Pipelines-Unterstützung für flexible Orchestrierung ist auf Anfrage verfügbar und unterliegt der Auswertung. Die Nutzungsmuster der Kunden müssen auf einen erheblichen Nutzen daraus hinweisen. Solche Kunden verfügen über große Skalierungsgruppen, verwenden keine Agents für mehrere Aufträge wieder, führen mehrere kurzlebige Aufträge parallel aus und gebrauchen ausschließlich kurzlebige Datenträger in ihren VMs. Wenn Sie dieses Feature verwenden möchten, wenden Sie sich an unser Supportteam.

Erstellen des Skalierungsgruppen-Agentpools

  1. Navigieren Sie zu Ihren Azure DevOps-Projekteinstellungen, wählen Sie unter Pipelines die Option Agentpools und dann Pool hinzufügen aus, um einen neuen Agentpool zu erstellen.

    Create agent pool.

    Wichtig

    Sie können Ihren Skalierungsgruppenpool in den Projekteinstellungen oder in den Organisationseinstellungen erstellen, aber wenn Sie einen Skalierungsgruppenpool löschen, müssen Sie ihn aus den Organisationseinstellungen löschen, nicht aus den Projekteinstellungen.

  2. Wählen Sie als Pooltyp die Option Azure-VM-Skalierungsgruppe aus. Wählen Sie das Azure-Abonnement aus, in dem die Skalierungsgruppe enthalten ist, wählen Sie Autorisieren und anschließend die gewünschte VM-Skalierungsgruppe aus dem Abonnement aus. Wenn bereits eine Dienstverbindung besteht, können Sie diese anstelle des Abonnements aus der Liste auswählen.

    Wichtig

    • Zum Konfigurieren eines Skalierungsgruppen-Agentpools müssen Sie entweder über Berechtigungen als Besitzer oder Benutzerzugriffsadministrator für das ausgewählte Abonnement verfügen. Wenn Ihnen eine dieser Rollen zugewiesen ist, Sie aber beim Auswählen von Autorisieren eine Fehlermeldung erhalten, finden Sie weitere Informationen unter Problembehandlung.

    • Die einzige Dienstverbindung, die derzeit unterstützt wird, ist eine Azure Resource Manager-Dienstverbindung (ARM), die auf einem Dienstprinzipalschlüssel basiert. ARM-Dienstverbindungen, die auf einer Zertifikatberechtigung oder einer verwalteten Identität basieren, schlagen fehl. Wenn Sie versuchen, die vorhandenen Skalierungsgruppen in Ihrem Abonnement aufzulisten, erhalten Sie eine Fehlermeldung wie diese:

      Invalid Service Endpoint with Id <guid> and Scope <guid>

  3. Wählen Sie die gewünschte VM-Skalierungsgruppe aus diesem Abonnement aus.

  4. Geben Sie einen Namen für Ihren Agentpool an.

  5. Konfigurieren Sie die folgenden Optionen:

    • Virtuelle Computer nach jeder Verwendung automatisch entfernen: Für jeden Auftrag wird eine neue VM-Instanz verwendet. Die VM wird nach der Ausführung eines Auftrags offline geschaltet und per Reimaging neu erstellt, bevor ein weiterer Auftrag angenommen wird.
    • Fehlerhaften Agent zur Untersuchung speichern: Gibt an, ob fehlerhafte Agent-VMs zur Problembehandlung gespeichert werden sollen, anstatt sie zu löschen.
    • Maximale Anzahl virtueller Computer in der Skalierungsgruppe: Azure Pipelines sorgt für ein automatisches Aufskalieren der Agentanzahl, überschreitet diesen Grenzwert jedoch nicht.
    • Anzahl von Agents, die im Standbymodus gehalten werden sollen: Azure Pipelines sorgt für ein automatisches Abskalieren der Agentanzahl, stellt aber sicher, dass immer die hier angegebene Anzahl von Agents für die Auftragsausführung zur Verfügung steht. Wenn Sie die Anzahl von Agents, die im Standbymodus gehalten werden sollen auf 0 festlegen, z. B. zur Kosteneinsparung bei einem geringen Auftragsvolumen, startet Azure Pipelines eine VM nur dann, wenn ihr ein Auftrag zugewiesen wurde.
    • Verzögerung in Minuten vor dem Löschen überschüssiger Leerlauf-Agents: Um Schwankungen der Buildlast im Laufe des Tages zu berücksichtigen, wartet Azure Pipelines die angegebene Zeitspanne ab, bevor ein überschüssiger inaktiver Agent gelöscht wird.
    • VMs zum Ausführen interaktiver Tests konfigurieren (nur Windows Server-Betriebssysteme): Windows-Agents können entweder so konfiguriert werden, dass sie ohne Berechtigung mit automatischer Anmeldung und interaktiver Benutzeroberfläche ausgeführt werden, oder sie können zur Ausführung mit erhöhten Rechten konfiguriert werden. Aktivieren Sie dieses Kontrollkästchen, um einen Agent mit interaktiver Benutzeroberfläche auszuführen. In beiden Fällen sind die Agentbenutzer*innen Mitglieder der Gruppe „Administratoren“.

  6. Wenn Ihre Einstellungen konfiguriert sind, wählen Sie Erstellen aus, um den Agentpool zu erstellen.

Verwenden des Skalierungsgruppen-Agentpools

Ein Skalierungsgruppen-Agentpool wird ähnlich verwendet wie jeder andere Agentpool. Sie können ihn in klassischen Build-, Release- oder YAML-Pipelines verwenden. Benutzerberechtigungen, Pipelineberechtigungen, Genehmigungen und andere Überprüfungen funktionieren genauso wie in jedem anderen Agentpool. Weitere Informationen finden Sie unter Agentpools.

Wichtig

Gehen Sie mit Bedacht vor, wenn Sie direkte Änderungen an der Skalierungsgruppe im Azure-Portal vornehmen.

  • Viele der Konfigurationseinstellungen der Skalierungsgruppe können im Azure-Portal nicht geändert werden. Azure Pipelines aktualisiert die Konfiguration der Skalierungsgruppe. Jegliche manuellen Änderungen, die Sie an der Skalierungsgruppe vornehmen, können den Betrieb von Azure Pipelines beeinträchtigen.
  • Sie dürfen eine Skalierungsgruppe erst umbenennen oder löschen, nachdem Sie den Skalierungsgruppenpool in Azure Pipelines gelöscht haben.

Verwalten der Skalierungsgruppe durch Azure Pipelines

Sobald der Skalierungsgruppen-Agentpool erstellt wurde, skaliert Azure Pipelines die Agent-VMs automatisch.

Azure Pipelines überprüft alle 5 Minuten den Zustand der Agents im Pool und der VMs in der Skalierungsgruppe. Die Entscheidung für oder gegen das Auf- oder Abskalieren wird anhand der Anzahl der Agents getroffen, die sich zu diesem Zeitpunkt im Leerlauf befinden. Ein Agent befindet sich im Leerlauf, wenn er online ist und keinen Pipelineauftrag ausführt. Azure Pipelines skaliert auf, wenn eine der folgenden Bedingungen erfüllt ist:

  • Die Anzahl der im Leerlauf befindlichen Agents unterschreitet die Anzahl der von Ihnen angegebenen Standby-Agents.
  • Es sind keine im Leerlauf befindlichen Agents vorhanden, die Pipelineaufträge in der Warteschlange verarbeiten können.

Wenn eine dieser Bedingungen erfüllt ist, erhöht Azure Pipelines die Anzahl der VMs. Das Aufskalieren erfolgt in Schritten eines bestimmten Prozentsatzes der maximalen Poolgröße. Es dauert bis zu 20 Minuten, bis die VMs für jeden Schritt erstellt sind.

Azure Pipelines skaliert ab, wenn die Anzahl der Agents im Leerlauf die Anzahl der Agents im Standbymodus mehr als 30 Minuten lang übersteigt (konfigurierbar mit Verzögerung in Minuten vor dem Löschen überschüssiger Leerlauf-Agents).

Um all dies in einem Beispiel zu verdeutlichen, betrachten Sie einen Skalierungsgruppen-Agentpool, der mit zwei Standby-Agents und maximal vier Agents konfiguriert ist. Nehmen wir an, Sie möchten die VM nach jeder Verwendung entfernen. Nehmen wir außerdem an, dass in der Skalierungsgruppe keine VMs vorhanden sind, mit denen Sie beginnen können.

  • Da die Anzahl der im Leerlauf befindlichen Agents 0 beträgt und die Anzahl der im Leerlauf befindlichen Agents unter der Standbyanzahl von 2 liegt, skaliert Azure Pipelines auf und fügt der Skalierungsgruppe zwei VMs hinzu. Sobald diese Agents online gehen, liegen zwei Agents im Leerlauf vor.

  • Angenommen, es geht ein Pipelineauftrag ein und wird einem der Agents zugewiesen.

  • Zu diesem Zeitpunkt beträgt die Anzahl der Agents im Leerlauf 1, womit die Anzahl der Standby-Agents von 2 unterschritten wird. Azure Pipelines skaliert also auf und fügt 2 weitere VMs hinzu (die in diesem Beispiel verwendete Inkrementgröße). Jetzt verfügt der Pool über drei Agents im Leerlauf und einen ausgelasteten Agent.

  • Nehmen wir an, der Auftrag für den ersten Agent ist abgeschlossen. Azure Pipelines nimmt diesen Agent offline, um ein Reimaging für die VM durchzuführen. Nach einigen Minuten wird sie mit einem neuen Image wieder online geschaltet. Zu diesem Zeitpunkt verfügen wir über vier Agents im Leerlauf.

  • Wenn innerhalb von 30 Minuten keine weiteren Aufträge eingehen (konfigurierbar mit Verzögerung in Minuten vor dem Löschen überschüssiger Leerlauf-Agents), stellt Azure Pipelines fest, dass sich mehr Agents als nötig im Leerlauf befinden. Daher wird der Pool auf zwei Agents abskaliert.

Während des gesamten Vorgangs besteht das Ziel von Azure Pipelines darin, die gewünschte Anzahl von Standby-Agents im Leerlauf zu erreichen. Pools werden langsam auf- und abskaliert. Im Laufe eines Tages wird der Pool vergrößert, wenn am Morgen Anforderungen in die Warteschlange eingereiht werden, und verkleinert, wenn die Auslastung am Abend sinkt. Es kann vorkommen, dass sich zu bestimmten Zeiten mehr Agents im Leerlauf befinden als gewünscht. Dies ist zu erwarten, da sich Azure Pipelines schrittweise an die von Ihnen festgelegten Einschränkungen anpasst.

Hinweis

Es kann eine Stunde oder länger dauern, bis Azure Pipelines die VMs auf- oder abskaliert. Azure Pipelines führt eine schrittweise Aufskalierung durch, überwacht die Vorgänge auf Fehler und reagiert, indem im weiteren Verlauf nicht nutzbare VMs gelöscht und neue erstellt werden. Dieser Korrekturen können mehr als eine Stunde in Anspruch nehmen.

Zur Erzielung maximaler Stabilität werden die Skalierungsvorgänge nacheinander durchgeführt. Wenn der Pool beispielsweise aufskaliert werden muss und zudem fehlerhafte VMs gelöscht werden müssen, skaliert Azure Pipelines den Pool zunächst auf. Sobald der Pool die gewünschte Anzahl von Agents im Standbymodus erreicht hat, werden die fehlerhaften VMs abhängig von der Einstellung Fehlerhaften Agent zur Untersuchung speichern gelöscht. Weitere Informationen finden Sie unter Fehlerhafte Agents.

Da die Stichprobenentnahme alle 5 Minuten erfolgt, kann es vorkommen, dass für einen kurzen Zeitraum alle Agents Pipelineaufträge ausführen, ohne dass eine Aufskalierung durchgeführt wird.

Anpassen der Pipeline-Agentkonfiguration

Sie können die Konfiguration des Azure Pipelines-Agents anpassen, indem Sie in Ihrem benutzerdefinierten Betriebssystemimage Umgebungsvariablen für Ihre Skalierungsgruppe definieren. Beispielsweise ist das Arbeitsverzeichnis des Skalierungsgruppen-Agents unter Windows standardmäßig auf „C:\a“ und unter Linux auf „/agent/_work“ festgelegt. Wenn Sie das Arbeitsverzeichnis ändern möchten, legen Sie eine Umgebungsvariable namens VSTS_AGENT_INPUT_WORK mit dem gewünschten Arbeitsverzeichnis fest. Weitere Informationen finden Sie in der Dokumentation zur unbeaufsichtigten Konfiguration des Pipelines-Agents. Beispiele hierfür sind:

  • VSTS_AGENT_INPUT_WORK
  • VSTS_AGENT_INPUT_PROXYURL
  • VSTS_AGENT_INPUT_PROXYUSERNAME
  • VSTS_AGENT_INPUT_PROXYPASSWORD

Wichtig

Beim Anpassen des Pipelines-Agents ist Vorsicht geboten. Einige Einstellungen stehen in Konflikt mit anderen erforderlichen Einstellungen, wodurch der Agent nicht registriert werden kann und die VM gelöscht wird. Die folgenden Einstellungen sollten weder festgelegt noch geändert werden:

  • VSTS_AGENT_INPUT_URL
  • VSTS_AGENT_INPUT_AUTH
  • VSTS_AGENT_INPUT_TOKEN
  • VSTS_AGENT_INPUT_USERNAME
  • VSTS_AGENT_INPUT_PASSWORD
  • VSTS_AGENT_INPUT_POOL
  • VSTS_AGENT_INPUT_AGENT
  • VSTS_AGENT_INPUT_RUNASSERVICE
  • ... sowie alle Einstellungen im Zusammenhang mit Bereitstellungsgruppen.

Anpassen des VM-Startvorgangs über die benutzerdefinierte Skripterweiterung

Die Benutzer*innen möchten möglicherweise Startskripts auf ihren Skalierungsgruppen-Agent-VMs ausführen, bevor diese VMs mit der Ausführung von Pipelineaufträgen beginnen. Einige gängige Anwendungsfälle für Startskripts sind die Installation von Software, die Cacheaufwärmung oder das Abrufen von Repositorys. Sie können Startskripts ausführen, indem Sie die benutzerdefinierte Skripterweiterung für Windows oder die benutzerdefinierte Skripterweiterung für Linux installieren.

Die Erweiterung wird auf jeder VM in der Skalierungsgruppe sofort nach ihrer Erstellung oder nach einem Reimaging ausgeführt. Die benutzerdefinierte Skripterweiterung wird vor Ausführung der Azure Pipelines-Agenterweiterung ausgeführt.

Das folgende Beispiel zeigt, wie Sie eine benutzerdefinierte Skripterweiterung für Linux erstellen.

az vmss extension set \
--vmss-name <scaleset name> \
--resource-group <resource group> \
--name CustomScript \
--version 2.0 \
--publisher Microsoft.Azure.Extensions \
--settings '{ \"fileUris\":[\"https://<myGitHubRepoUrl>/myScript.sh\"], \"commandToExecute\": \"bash ./myScript.sh /myArgs \" }'

Das folgende Beispiel zeigt, wie Sie eine benutzerdefinierte Skripterweiterung für Windows erstellen.

az vmss extension set \
--vmss-name <scaleset name> \
--resource-group <resource group> \
--name CustomScriptExtension \
--version 1.9 \
--publisher Microsoft.Compute \
--settings '{ \"FileUris\":[\"https://<myGitHubRepoUrl>/myscript.ps1\"], \"commandToExecute\": \"Powershell.exe -ExecutionPolicy Unrestricted -File myscript.ps1 -myargs 0 \" }'

Wichtig

Die in der benutzerdefinierten Skripterweiterung ausgeführten Skripts müssen den Exitcode 0 zurückgeben, damit die VM den VM-Erstellungsprozess abschließen kann. Wenn die benutzerdefinierte Skripterweiterung eine Ausnahme auslöst oder einen Exitcode ungleich 0 zurückgibt, wird die Azure Pipelines-Erweiterung nicht ausgeführt, und die VM wird nicht beim Azure DevOps-Agentpool registriert.

Es kann vorkommen, dass Ihre Erweiterung ausgeführt wird, bevor alle VM-Ressourcen bereitgestellt wurden. In diesem Fall erhalten Sie eine Fehlermeldung der Art „Fehler beim Installieren der erforderlichen Basiskomponenten“. Sie können dies beheben, indem Sie am Anfang Ihres Skripts einen sleep-Befehl hinzufügen, zum Beispiel sleep 30.

Lebenszyklus eines Skalierungsgruppen-Agents

Nachfolgend wird der Arbeitsablauf für einen Azure Pipelines-VMSS-Agent beschrieben.

  1. Der Auftrag zur Größenanpassung des Azure DevOps-Skalierungsgruppen-Agentpools stellt fest, dass der Pool nicht genügend Agents im Leerlauf aufweist und aufskaliert werden muss. Azure Pipelines ruft Azure Scale Sets auf, um die Kapazität der Skalierungsgruppe zu erhöhen.

  2. Azure Scale Sets beginnt damit, neue VMs zu erstellen. Sobald die VMs ausgeführt werden, führt Azure Scale Sets nacheinander alle installierten VM-Erweiterungen aus.

  3. Wenn die benutzerdefinierte Skripterweiterung installiert ist, wird sie vor der Azure Pipelines-Agenterweiterung ausgeführt. Wenn die benutzerdefinierte Skripterweiterung einen Exitcode ungleich 0 zurückgibt, wird der VM-Erstellungsprozess abgebrochen und gelöscht.

  4. Die Azure Pipelines-Agenterweiterung wird ausgeführt. Diese Erweiterung lädt die neueste Version des Azure Pipelines-Agents und die neueste Version des Konfigurationsskripts herunter. Die Konfigurationsskripts stehen unter URLs mit den folgenden Formaten zur Verfügung:

    • Linux: https://vstsagenttools.blob.core.windows.net/tools/ElasticPools/Linux/<script_version>/enableagent.sh, z. B. Version 15
    • Windows: https://vstsagenttools.blob.core.windows.net/tools/ElasticPools/Windows/<script_version>/enableagent.ps1, z. B. Version 17

  5. Das Konfigurationsskript erstellt ein lokales Benutzerkonto namens AzDevOps, wenn als Betriebssystem Windows Server oder Linux verwendet wird. Bei Windows 10-Clientbetriebssystemen wird der Agent als „LocalSystem“ ausgeführt. Anschließend entpackt, installiert und konfiguriert das Skript den Azure Pipelines-Agent. Im Rahmen der Konfiguration wird der Agent beim Azure DevOps-Agentpool registriert und in der Liste des Agentpools mit dem Zustand „Offline“ angezeigt.

  6. In den meisten Szenarien startet das Konfigurationsskript den Agent dann sofort, damit er mit dem lokalen Benutzerkonto AzDevOps ausgeführt wird. Der Agent geht online und kann Pipelineaufträge ausführen.

    Wenn der Pool für die interaktive Benutzeroberfläche konfiguriert ist, wird die VM neu gestartet, sobald der Agent konfiguriert wurde. Nach dem Neustart wird das lokale Benutzerkonto automatisch angemeldet und der Pipelines-Agent gestartet. Anschließend geht der Agent online und kann Pipelineaufträge ausführen.

Erstellen einer Skalierungsgruppe mit benutzerdefiniertem Image, benutzerdefinierter Software oder benutzerdefinierter Festplattengröße

Wenn Sie lediglich eine Skalierungsgruppe mit dem standardmäßigen 128-GB-Betriebssystemdatenträger unter Verwendung eines öffentlich verfügbaren Azure-Images erstellen möchten, wechseln Sie direkt zu Schritt 10, und verwenden Sie den Namen des öffentlichen Images (UbuntuLTS, Win2019DataCenter usw.), um die Skalierungsgruppe zu erstellen. Befolgen Sie andernfalls diese Schritte, um Ihr VM-Image anzupassen.

  1. Erstellen Sie eine VM mit dem gewünschten Betriebssystemimage, und vergrößern Sie optional den Betriebssystemdatenträger von 128 GB auf <myDiskSizeGb>.

    • Wenn Sie mit einem verfügbaren Azure-Image beginnen, zum Beispiel <myBaseImage> = (Win2019DataCenter, UbuntuLTS):

      az vm create --resource-group <myResourceGroup> --name <MyVM> --image <myBaseImage> --os-disk-size-gb <myDiskSize>  --admin-username myUserName --admin-password myPassword

    • Wenn Sie mit einer generalisierten VHD beginnen:

      1. Erstellen Sie die VM zunächst mit einem nicht verwalteten Datenträger der gewünschten Größe, und konvertieren Sie diesen dann in einen verwalteten Datenträger:

        az vm create --resource-group <myResourceGroup> --name <MyVM> --image <myVhdUrl> --os-type windows --os-disk-size-gb <myDiskSizeGb> --use-unmanaged-disk --admin-username <myUserName> --admin-password <myPassword> --storage-account <myVhdStorageAccount>

      2. Herunterfahren des virtuellen Computers

        az vm stop --resource-group <myResourceGroup> --name <MyVM>

      3. Aufheben der Zuordnung der VM

        az vm deallocate --resource-group <myResourceGroup> --name <MyVM>

      4. Konvertierung in einen verwalteten Datenträger

        az vm convert --resource-group <myResourceGroup> --name <MyVM>

      5. Neustarten der VM

        az vm start --resource-group <myResourceGroup> --name <MyVM>

  2. Stellen Sie per Remotedesktop (oder SSH) eine Verbindung mit der öffentlichen IP-Adresse der VM her, um das Image anzupassen. Möglicherweise müssen Sie Ports in der Firewall öffnen, um die Blockierung der RDP- (3389) oder SSH-Ports (22) aufzuheben.

    1. Windows: Wenn <MyDiskSizeGb> mehr als 128 GB beträgt, vergrößern Sie den Betriebssystemdatenträger auf die in <MyDiskSizeGb> angegebene Datenträgergröße.

      Öffnen Sie das DiskPart-Tool als Administrator*in, und führen Sie die folgenden DiskPart-Befehle aus:

      1. list volume (zur Anzeige der Volumes)
      2. select volume 2 (je nachdem, welches Volume das Betriebssystemlaufwerk ist)
      3. extend size 72000 ( zum Erweitern des Laufwerks um 72 GB, von 128 GB auf 200 GB)

  3. Installieren Sie gegebenenfalls zusätzliche Software auf der VM.

  4. Um die Berechtigungen des Benutzerkontos für den Pipeline-Agent anzupassen, können Sie Benutzerkonto mit dem Namen AzDevOps erstellen und diesem Benutzerkonto die gewünschten Berechtigungen erteilen. Dieses Benutzerkonto wird vom Startskript des Skalierungsgruppen-Agents erstellt, sofern es noch nicht vorhanden ist.

  5. Starten Sie die VM neu, wenn Sie alle gewünschten Anpassungen vorgenommen haben.

  6. Generalisieren der VM

    • Windows: Über ein Verwaltungskonsolenfenster: 
      C:\Windows\System32\sysprep\sysprep.exe /generalize /oobe /shutdown
    • Linux: 
      sudo waagent -deprovision+user -force

    Wichtig

    Warten Sie, bis die VM die Generalisierung abgeschlossen hat, und fahren Sie sie herunter. Fahren Sie erst fort, wenn die VM beendet wurde. Warten Sie 60 Minuten.

  7. Aufheben der Zuordnung der VM

    az vm deallocate --resource-group <myResourceGroup> --name <MyVM>

  8. Kennzeichnen Sie den virtuellen Computer als generalisierte VM.

    az vm generalize --resource-group <myResourceGroup> --name <MyVM>

  9. Erstellen Sie ein VM-Image auf der Grundlage des generalisierten Images. Wenn Sie diese Schritte ausführen, um ein vorhandenes Skalierungsgruppenimage zu aktualisieren, notieren Sie sich die Image-ID-URL in der Ausgabe.

    az image create  --resource-group <myResourceGroup> --name <MyImage> --source <MyVM>

  10. Erstellen Sie die Skalierungsgruppe basierend auf dem benutzerdefinierten VM-Image.

    az vmss create --resource-group <myResourceGroup> --name <myScaleSet> --image <MyImage> --admin-username <myUsername> --admin-password <myPassword> --instance-count 2 --disable-overprovision --upgrade-policy-mode manual --load-balancer '""'

  11. Vergewissern Sie sich, dass beide in der Skalierungsgruppe erstellten VMs online geschaltet wurden, unterschiedliche Namen aufweisen und den Zustand „Erfolgreich“ erreichen.

Sie können nun mithilfe dieser Skalierungsgruppe einen Agentpool erstellen.

Aktualisieren einer vorhandenen Skalierungsgruppe mit einem neuen benutzerdefinierten Image

Wenn Sie das Image einer vorhandenen Skalierungsgruppe aktualisieren möchten, befolgen Sie die Schritte im vorherigen Abschnitt Erstellen einer Skalierungsgruppe mit benutzerdefiniertem Image, benutzerdefinierter Software oder benutzerdefinierter Festplattengröße bis zum Schritt az image create, um das benutzerdefinierte Betriebssystemimage zu erstellen. Notieren Sie sich die ID-Eigenschaften-URL, die über den az image create-Befehl ausgegeben wird. Aktualisieren Sie anschließend die Skalierungsgruppe mit dem neuen Image, wie im folgenden Beispiel gezeigt. Nachdem das Image für die Skalierungsgruppe aktualisiert wurde, werden alle zukünftigen VMs in der Skalierungsgruppe mit dem neuen Image erstellt.

az vmss update --resource-group <myResourceGroup> --name <myScaleSet> --set virtualMachineProfile.storageProfile.imageReference.id=<id url>

Unterstützte Betriebssysteme

Skalierungsgruppen-Agents unterstützen derzeit Ubuntu Linux, Windows Server/DataCenter 2016/2019 und Windows 10-Clients.

Bekannte Probleme

  • Debian- oder RedHat-Linux-Distributionen werden nicht unterstützt. Es wird ausschließlich Ubuntu unterstützt.
  • Ein Windows 10-Client bietet keine Unterstützung für die Ausführung des Pipeline-Agents mit einem lokalen Benutzerkonto, deshalb kann der Agent nicht mit der Benutzeroberfläche interagieren. Der Agent wird stattdessen als lokaler Dienst ausgeführt.

Fragen zur Problembehandlung

Navigieren Sie zu Ihren Azure DevOps-Projekteinstellungen, wählen Sie unter Pipelines die Option Agentpools und dann Ihren Agentpool aus. Wählen Sie die Registerkarte Diagnose aus.

Auf der Registerkarte „Diagnose“ werden alle von Azure DevOps ausgeführten Aktionen zur Erstellung, Löschung oder zum Reimaging von VMs in Ihrer Azure-Skalierungsgruppe angezeigt. Auf der Registerkarte „Diagnose“ werden auch alle Fehler protokolliert, die beim Ausführen dieser Aktionen auftreten. Überprüfen Sie die Fehler, um sicherzustellen, dass Ihre Skalierungsgruppe über ausreichende Ressourcen für die Skalierung verfügt. Wenn Ihr Azure-Abonnement das Ressourcenlimit in Bezug auf VMs, CPU-Kerne, Datenträger oder IP-Adressen erreicht hat, werden die entsprechenden Fehler hier angezeigt.

Fehlerhafte Agents

Wenn Agents oder VMs nicht starten, keine Verbindung mit Azure DevOps herstellen können oder unerwartet offline gehen, protokolliert Azure DevOps die Fehler auf der Registerkarte Diagnose des Agentpools und versucht, die zugehörige VM zu löschen. Die genannten Probleme können durch Netzwerkkonfigurationen, Imageanpassungen und anstehende Neustarts verursacht werden. Bei der Untersuchung von Fehlern kann es hilfreich sein, sich mit der VM zu verbinden, um ein Debugging durchzuführen und Protokolle zu erfassen.

Wenn Sie möchten, dass Azure DevOps eine fehlerhafte Agent-VM zur Untersuchung speichert und nicht automatisch löscht, wenn ein fehlerhafter Zustand erkannt wird, navigieren Sie zu Ihren Azure DevOps-Projekteinstellungen, wählen Sie unter Pipelines die Option Agentpools und dann Ihren Agentpool aus. Wählen Sie Einstellungen, Fehlerhaften Agent zur Untersuchung speichern und dann Speichern aus.

Save unhealthy agent setting.

Wenn jetzt ein fehlerhafter Agent in der Skalierungsgruppe erkannt wird, speichert Azure DevOps diesen Agent und die zugehörige VM. Der gespeicherte Agent wird auf der Registerkarte Diagnose der Agentpool-Benutzeroberfläche angezeigt. Navigieren Sie zu Ihren Azure DevOps-Projekteinstellungen, wählen Sie unter Pipelines die Option Agentpools und dann Ihren Agentpool aus. Klicken Sie auf Diagnose, und notieren Sie sich den Namen des Agents.

Saved agents card.

Suchen Sie im Azure-Portal in der Liste Instanzen nach der zugehörigen VM in Ihrer Azure-VM-Skalierungsgruppe.

Azure portal Virtual Machine Scale Set instances.

Wählen Sie die Instanz und dann Verbinden aus, und führen Sie ihre Untersuchung durch.

Connect to virtual machine instance.

Um den gespeicherten Agent nach Abschluss Ihrer Untersuchung zu löschen, navigieren Sie zu Ihren Azure DevOps-Projekteinstellungen, wählen Sie unter Pipelines die Option Agentpools und anschließend Ihren Agentpool aus. Wählen Sie die Registerkarte Diagnose aus. Suchen Sie auf der Karte Zur Untersuchung gespeicherte Agents nach dem betreffenden Agent, und wählen Sie Löschen aus. Dadurch wird der Agent aus dem Pool entfernt und die zugehörige VM gelöscht.

Saved agents card delete button.

Häufig gestellte Fragen

Wo finde ich die Images, die für von Microsoft gehostete Agents verwendet werden?

Aus lizenzrechtlichen Gründen können wir keine von Microsoft gehosteten Images bereitstellen. Es ist uns nicht möglich, diese Images zur Verwendung in Ihren Skalierungsgruppen-Agents zur Verfügung zu stellen. Aber die zum Generieren dieser Images verwendeten Skripts sind Open-Source-Skripts. Es steht Ihnen frei, diese Skripts zu nutzen und eigene benutzerdefinierte Images zu erstellen.

Wie konfiguriere ich Skalierungsgruppen-Agents zum Durchführen von UI-Tests?

Erstellen Sie eine Skalierungsgruppe mit einem Windows Server-Betriebssystem, und wählen Sie beim Erstellen des Agentpools die Option „VMs zum Ausführen interaktiver Tests konfigurieren“ aus.

Wie kann ich Agents löschen?

Navigieren Sie zu Ihren Azure DevOps-Projekteinstellungen, wählen Sie unter Pipelines die Option Agentpools und dann Ihren Agentpool aus. Wählen Sie die Registerkarte Agents aus. Klicken Sie auf die Umschaltfläche „Aktiviert“, um den Agent zu deaktivieren. Der deaktivierte Agent schließt die derzeit ausgeführte Pipeline ab und nimmt keine weiteren Arbeitsaufträge an. Wenige Minuten nach Beendigung des aktuellen Pipelineauftrags wird der Agent gelöscht.

Kann ich den Skalierungsgruppen-Agentpool so konfigurieren, dass er keine Agents im Standbymodus aufweist?

Ja. Wenn Sie die Anzahl von Agents, die im Standbymodus gehalten werden sollen auf 0 festlegen, z. B. zur Kosteneinsparung bei einem geringen Auftragsvolumen, startet Azure Pipelines eine VM nur dann, wenn ihr ein Auftrag zugewiesen wurde.

Wie viel kosten Skalierungsgruppen-Agents?

Die Preise für Skalierungsgruppen-Agents sind vergleichbar mit denen anderer selbstgehosteter Agents. Sie stellen die Infrastruktur zum Ausführen der Agentsoftware und der -aufträge bereit und zahlen für die gewünschte Anzahl von Aufträgen, die gleichzeitig ausgeführt werden können, indem Sie parallele Aufträge erwerben.

Für Skalierungsgruppen-Agents wird als Infrastruktur zum Ausführen der Agentsoftware und der Aufträge Azure Virtual Machine Scale Sets verwendet. Die geltenden Preise finden Sie unter Virtual Machine Scale Sets – Preise.

Informationen zum Kauf paralleler Aufträge finden Sie unter Konfigurieren und Bezahlen von parallelen Aufträgen.

Welche Probleme treten häufig auf, und wie können sie gelöst werden?

Sie beobachten zu verschiedenen Zeiten mehr Agents im Leerlauf als gewünscht

Informationen dazu, warum dies geschieht, finden Sie unter Verwalten der Skalierungsgruppe durch Azure Pipelines. Während des gesamten Skalierungsvorgangs besteht das Ziel von Azure Pipelines darin, die gewünschte Anzahl von Agents im Leerlauf zu erreichen. Pools werden langsam auf- und abskaliert. Über einen Tag hinweg wird der Pool aufskaliert, wenn morgens Anforderungen in die Warteschlange gestellt werden, und er wird abskaliert, wenn die Last am Abend sinkt. Dies ist ein erwartetes Verhalten, da Azure Pipelines sich schrittweise an die von Ihnen angegebenen Einschränkungen anpasst.

Die VMSS-Skalierung erfolgt nicht im erwarteten 5-Minuten-Intervall

Der Skalierungsauftrag wird alle fünf Minuten ausgeführt, wenn aber nur ein Vorgang verarbeitet wird, stellen Sie möglicherweise fest, dass das Hochskalieren nicht innerhalb von fünf Minuten erfolgt. Dies ist derzeit beabsichtigt.

Die Azure DevOps-VM-Skalierungsgruppe für Linux kann häufig die Pipeline nicht starten

Wenn Probleme mit Skalierungsgruppen-Agents auftreten, sollten Sie zunächst auf der Registerkarte Diagnose im Agentpool nachsehen.

Erwägen Sie außerdem, die fehlerhafte VM zu Debugzwecken zu speichern. Weitere Informationen finden Sie unter Fehlerhafte Agents.

Gespeicherte Agents bleiben erhalten, bis Sie sie löschen. Wenn der Agent nicht innerhalb von 10 Minuten online geht, wird er als fehlerhaft markiert und nach Möglichkeit gespeichert. Es wird nur eine VM im gespeicherten Zustand beibehalten. Wenn der Agent unerwartet offline geht (aufgrund eines VM-Neustarts oder eines Problems mit dem Image), wird er nicht für eine Untersuchung gespeichert.

Es werden nur VMs gespeichert, deren Agents nicht gestartet werden können. Wenn eine VM bei der Erstellung einen fehlerhaften Zustand aufweist, wird sie nicht gespeichert. In diesem Fall lautet die Meldung auf der Registerkarte „Diagnose“ nicht „Fehler beim Starten“, sondern „Fehlerhafter Computer wird gelöscht“.

Sie aktivieren die Option zum automatischen Entfernen von VMs nach jeder Nutzung des Agentpools, stellen aber fest, dass für die VMs nicht wie vorgesehen ein Reimaging erfolgt und sie lediglich neue Aufträge aufnehmen, wenn sie in die Warteschlange eingereiht werden

Die Option zum Entfernen der VM nach jedem Build funktioniert nur für Windows Server-Images sowie unterstützte Linux-Images. Sie wird nicht für Windows-Clientimages unterstützt.

VMSS zeigt den Agent als offline an, wenn die VM neu startet

Die Anzeige der Agents als offline bei einem Neustart der VM ist das erwartete Verhalten. Der Agentdienst wird nur im Systemkontext ausgeführt. Wenn der Computer jedoch aus irgendeinem Grund neu gestartet wird, wird er als fehlerhafte VM betrachtet und gelöscht. Weitere Informationen finden Sie unter Fehlerhafte Agents.

Wenn Agents oder VMs nicht starten, keine Verbindung mit Azure DevOps herstellen können oder unerwartet offline gehen, protokolliert Azure DevOps die Fehler auf der Registerkarte Diagnose des Agentpools und versucht, die zugehörige VM zu löschen. Die genannten Probleme können durch Netzwerkkonfigurationen, Imageanpassungen und anstehende Neustarts verursacht werden. Um das Problem zu vermeiden, deaktivieren Sie das Softwareupdate für das Image. Sie können auch eine Verbindung mit dem virtuellen Computer herstellen, um zu debuggen und Protokolle zu sammeln, um das Problem zu untersuchen.

In der Kostenverwaltung werden für VMSS mehrere Tags (wie etwa „_AzureDevOpsElasticPoolTimeStamp“) angezeigt

Wenn der Pool erstellt wird, wird der Skalierungsgruppe ein Tag hinzugefügt, um die Skalierungsgruppe als in Verwendung zu markieren (um zu vermeiden, dass zwei Pools dieselbe Skalierungsgruppe verwenden), und ein weiteres Tag wird für den Zeitstempel hinzugefügt, der bei jeder Ausführung des Konfigurationsauftrags aktualisiert wird (alle zwei Stunden).

Sie können keinen neuen Skalierungsgruppen-Agentpool erstellen und erhalten eine Fehlermeldung, dass bereits ein gleichnamiger Pool vorhanden ist

Möglicherweise erhalten Sie eine Fehlermeldung wie This virtual machine scale set is already in use by pool <pool name>, da das Tag auch nach dem Löschen noch in der Skalierungsgruppe vorhanden ist. Wenn ein Agentpool gelöscht wird, wird versucht, das Tag aus der Skalierungsgruppe zu löschen. Dies ist jedoch ein Vorgang nach dem Best-Effort-Prinzip, der nach drei Wiederholungsversuchen abgebrochen wird. Außerdem kann es eine maximal zweistündige Lücke geben, innerhalb derer eine von keinem Agentpool genutzte VM-Skalierungsgruppe keinem neuen Pool zugewiesen werden kann. Die Lösung hierfür besteht darin, auf das Verstreichen dieses Zeitintervalls zu warten oder das Tag für die Skalierungsgruppe manuell aus dem Azure-Portal zu löschen. Wenn Sie die Skalierungsgruppe im Azure-Portal anzeigen, wählen Sie links den Link Tags aus, und löschen Sie das Tag mit der Bezeichnung _AzureDevOpsElasticPool.

Der VMSS-Wartungsauftrag wird auf den Agents nicht ausgeführt oder erfasst keine Protokolle

Der Wartungsauftrag wird alle 24 Stunden einmal ausgeführt. Es ist möglich, dass VMs vor diesem Zeitpunkt bereits aufgefüllt sind. Erwägen Sie, die Datenträgergröße auf dem virtuellen Computer zu erhöhen und in der Pipeline ein Skript hinzuzufügen, um den Inhalt zu löschen.

Wenn Sie in Ihrem Skript für VMSS AzDevOps als primäres Administratorkonto angeben, können Probleme mit den Agentkonfigurationen für Skalierungsgruppeninstanzen auftreten

Wenn Sie AzDevOps als primäres Administratorkonto in Ihrem Skript für die VM-Skalierungsgruppe angeben, können Probleme mit den Agentkonfigurationen für Skalierungsgruppeninstanzen auftreten (das Benutzerkennwort wird geändert, falls es bereits vorhanden ist).

Dieses Problem tritt auf, weil Agenterweiterungsskripts versuchen, das Benutzerkonto AzDevOps zu erstellen und das zugehörige Kennwort zu ändern.

Hinweis

Es ist kein Problem, das Benutzerkonto anzulegen und ihm zusätzliche Berechtigungen zu erteilen, aber es sollte nicht das primäre Administratorkonto verwendet werden, und es dürfen keine Abhängigkeiten vom Kennwort vorliegen, da das Kennwort geändert wird. Um das Problem zu vermeiden, wählen Sie beim Erstellen der Skalierungsgruppe anstelle von AzDevOps ein anderes Benutzerkonto als das primäre Administratorkonto aus.

Die Installation der Agenterweiterung schlägt für Skalierungsgruppeninstanzen aufgrund der Konfiguration von Netzwerksicherheit und Firewall fehl

Die Erweiterung muss in der Lage sein, die Build-Agentdateien von https://vstsagentpackage.azureedge.net/agent herunterzuladen, und der Build-Agent muss in der Lage sein, sich bei Azure DevOps Services zu registrieren. Stellen Sie sicher, dass diese URL und Azure DevOps Services-bezogene IP-Adressen und URLs in der Instanz geöffnet sind. Informationen zu IP-Adressen und URLs, die in Ihrer Firewall freigegeben werden müssen, finden Sie unter Zulässige IP-Adressen und Domänen-URLs.

Warum ruft mein Skalierungsgruppen-Agent-Konfigurationsskript Add-MpPreference auf und konfiguriert Windows Defender auf dem Agent?

Um die Leistung und Zuverlässigkeit zu verbessern, rufen die Konfigurationsskripts Add-MpPreference mit einem ExclusionPathauf, der C:\ undD:\ enthält und die geplante Prüfung sowie die Echtzeitüberprüfung von Windows Defender für Dateien in diesen Ordnern im Agent deaktiviert. Um das Standardverhalten zu ändern, legen Sie eine Umgebungsvariable mit dem Namen ELASTIC_POOLS_SKIP_DEFENDER_EXCLUSION auf true fest.

Ich möchte meinen Pool vergrößern. Was sollte ich beachten?

Bevor Sie Ihren Pool vergrößern, vergewissern Sie sich, dass das für Ihren VM-Skalierungsgruppenpool konfigurierte virtuelle Azure-Netzwerk über einen ausreichend großen Adressraum verfügt, um alle neuen Agents aufzunehmen. Andernfalls wird möglicherweise eine Fehlermeldung wie Fehler beim Erhöhen der Kapazität. Das Subnetz „azure-devops-agent-pool-fabrikam-fiber“ mit dem Adresspräfix 12.123.45.224/28 weist nicht genügend Kapazität für 5 IP-Adressen auf.