Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel enthält Lösungen für allgemeine Probleme mit verwalteten DevOps-Pools.
Fehler bei der Poolerstellung
| Fehlercode | BESCHREIBUNG |
|---|---|
PoolProvisioningFailed |
Fehler bei der Poolerstellung aufgrund von Azure DevOps-Organisationsberechtigungen |
UnauthorizedAccessToVirtualNetwork |
Fehler bei der Poolerstellung aufgrund von VNet-Berechtigungen |
Fehler bei der Poolerstellung aufgrund von Azure DevOps-Organisationsberechtigungen
Die Poolerstellung schlägt mit einem Fehler fehl, der einer der folgenden Fehlermeldungen ähnelt.
Der angemeldete Benutzer wurde in der Azure DevOps-Organisation nicht gefunden.
Validation failure "PoolProvisioningFailed": "Failed to provision agent pool. Exception: The logged in user, <your user>, was not found in the Azure DevOps organization provided, <your Azure DevOps organization>."
So lösen Sie das Problem:
- Ihre Azure DevOps-Organisation muss mit der Microsoft Entra-ID verbunden sein, und Ihr angemeldeter Azure-Benutzer muss Mitglied (und kein Gast) dieses Mandanten sein. Sehen Sie sich die Voraussetzungen für verwaltete DevOps-Pools an – Verbinden Sie Ihre Azure DevOps-Organisation mit der Microsoft Entra-ID, und überprüfen Sie die Mitgliedschaft.
Der angemeldete Benutzer verfügt nicht über Die Berechtigung "Verwalten" in der Azure DevOps-Organisation.
Validation failure "PoolProvisioningFailed": "Failed to provision agent pool. Exception: The logged in user, <your user>, does not have Manage permissions in the Azure DevOps organization provided, <your Azure DevOps organization>."
So lösen Sie das Problem:
- Ihr angemeldeter Azure-Benutzer muss über die richtigen Azure DevOps-Berechtigungen zum Erstellen eines Pools verfügen. Siehe Azure DevOps-Voraussetzungen – Überprüfen der Azure DevOps-Berechtigungen.
Fehler bei der Poolerstellung aufgrund von VNet-Berechtigungen
Fehler bei der UnauthorizedAccessToVirtualNetwork Poolerstellung, ähnlich dem folgenden Fehler: Validation failure "UnauthorizedAccessToVirtualNetwork": "DevOpsInfrastructure service principal does not have Read access to virtual network <your VNet> in resource group <your resource group>. Give Reader and Network Contributor access to DevOpsInfrastructure service principal and try again.
So beheben Sie dieses Problem:
- Verwaltete DevOps-Pools erfordern Zugriff auf Ihr virtuelles Netzwerk. Weitere Informationen finden Sie unter Grant Reader and Network Contributor access to DevOpsInfrastructure service principal.
- Das virtuelle Netzwerk-Subnetz muss an delegiert werden.
Microsoft.DevOpsInfrastructure/poolsSiehe Delegieren des Subnetzes an Microsoft.DevOpsInfrastructure/pools.
Verzögerungen beim Pipelinestart
Bei der Verwendung von verwalteten DevOps-Pools können Situationen auftreten, in denen eine lange Verzögerung auftritt, bevor eine Pipeline nach dem Auslösen gestartet wird. In diesem Abschnitt des Handbuchs zur Problembehandlung werden allgemeine Elemente beschrieben, die sich auf die Leistung Ihrer Pools auswirken können. Weitere Informationen finden Sie unter Verwalten von Kosten und Leistung.
- Suchen nach unzureichenden parallelen Aufträgen
- Überprüfen Sie die Konfiguration der Maximalanzahl von Agenten
- Erwägen Sie die Vorbereitstellung von Agents mithilfe eines Standby-Agent-Zeitplans
- Erwägen Sie die Verwendung von Stateful-Pools mit einer Nachfrist, um die Agenten online zu halten
- Überprüfen Sie die Time-out-Fehlercodes
Überprüfen auf unzureichende parallele Aufträge
Verwaltete DevOps-Pools-Agenten werden von Azure DevOps als selbstgehostete Agenten betrachtet und erfordern parallele Jobs, die selbst gehostet werden. Wenn die Anzahl der parallel selbstgehosteten Pipelines Ihrer Organisation beispielsweise 10 beträgt, kann Ihre Organisation nur 10 Pipeline-Jobs gleichzeitig ausführen. Wenn mehr als 10 Pipelines in die Warteschlange gestellt werden, können nur 10 gleichzeitig ausgeführt werden.
Überprüfen Sie die Anzahl Ihrer selbst gehosteten parallelen Aufträge, um sicherzustellen, dass Sie genügend Kapazität haben, um die gleichzeitigen Anforderungen an die Pipeline Ihrer Arbeitslast zu erfüllen. Weitere Informationen finden Sie unter Konfigurieren und Bezahlen für parallele Aufträge.
Maximale Agenten-Konfiguration überprüfen
Die einstellung Maximale Anzahl von Agents konfiguriert die maximale Anzahl der ausgeführten Agents in Ihrem verwalteten DevOps-Pool. Wenn die Einstellung Maximum Agents auf 5 gesetzt ist, können Managed DevOps-Pools maximal fünf gleichzeitige Pipelines ausführen. Wenn mehr als fünf Pipelines in die Warteschlange gestellt werden, werden die zusätzlichen Pipelines erst gestartet, wenn einer der fünf verfügbaren Agents verfügbar ist.
Anmerkung
Maximale Anzahl an Agents konfiguriert die maximale Anzahl an Agents, die gleichzeitig bereitgestellt werden können, aber die Anzahl der selbst gehosteten parallelen Aufträge Ihrer Organisation gibt die Anzahl der Aufträge an, die gleichzeitig ausgeführt werden können. Stellen Sie sicher, dass In Ihrer Organisation genügend selbst gehostete parallele Aufträge verfügbar sind, damit Ihre Agents Aufträge ausführen können. Weitere Informationen finden Sie unter Preisgestaltung für parallele Jobs bei Azure DevOps Services.
Erwägen Sie Vorbereitstellungs-Agents mit einem Standby-Agent-Zeitplan
Wenn der Standby-Agentmodus deaktiviert ist, werden Agents für verwaltete DevOps-Pools bei Bedarf gestartet, wenn eine Pipeline in die Warteschlange eingereiht wird. Normalerweise dauert es nur wenige Augenblicke, bis ein neuer Agent gestartet ist, allerdings kann es manchmal bis zu 15 Minuten dauern.
Wenn Standby-Agentmodus aktiviert ist, können Sie einen Zeitplan und eine Anzahl von Agents angeben, um die Anforderungen Ihrer Workload zu erfüllen.
Weitere Informationen finden Sie unter Verwalten von Kosten und Leistung – Vorabbereitstellung mit Standby-Agents.
Automatischer Standbymodus für neue Pools
Das Management von DevOps-Pools nutzt historische Poolnutzungsdaten, um Vorhersagen zur Skalierung des automatischen Standby-Modus zu treffen. Neue Pools verfügen nicht über historische Daten, daher können Agents bei Bedarf erstellt werden. Um die Leistung zu verbessern, können Sie zum manuellen Standbymodus für den ersten Monat wechseln und zum automatischen Standbymodus wechseln, nachdem verwaltete DevOps-Pools Zeit hatten, die Nutzung Ihres Pools zu beobachten.
Prüfen Sie den Prozentsatz der Standby-Agenten bei der Verwendung von Standby-Agenten mit mehreren Images.
Wenn Sie Standby-Agenten mit mehreren Bildern verwenden, überprüfen Sie den Verlauf der Nutzung pro Bild und vergleichen Sie diesen mit der Einstellung des Prozentsatzes des Standby-Agenten Ihrer Bilder, um sicherzustellen, dass Ihr Standby-Verhältnis Ihrer Nutzung entspricht. Wenn Sie beispielsweise über ein Windows-Image und ein Ubuntu-Image verfügen und Ihre Workload Windows 75% der Zeit verwendet, stellen Sie sicher, dass Ihr Windows-Image mit einem Standby-Agent-Prozentsatz von 75 konfiguriert ist.
Erwägen Sie die Verwendung von Stateful-Pools mit einer Nachfrist, um Agents online zu halten
Eine Möglichkeit zur Verbesserung der Leistung der Agenten ohne Verwendung von Standby-Agenten besteht darin, zustandsbehaftete Agenten mit einer kurzen Nachfrist zu verwenden. Wenn ein zustandsbehafteter Agent mit einer Nachfrist einen Auftrag abgeschlossen hat, bleibt er für die durch die Nachfrist angegebene Dauer online und wartet auf weitere Aufträge. Wenn Ihre Workload in Brüchen kommt, können Sie eine Karenzzeit konfigurieren, die Agents online hält, wenn Aufträge stabil sind, und sie während langsamerer Zeiträume von Grund auf neu beginnen.
Weitere Informationen finden Sie unter Standby-Agents und Stateful Pools.
Zeitüberschreitungsfehlercodes überprüfen
Wenn die Zuweisung Ihres Agenten zeitlich überschritten wird, können Sie den Fehlercode im Abschnitt Fehlercodes der Seite Übersicht überprüfen.
Die Pipeline konnte nicht erfolgreich abgeschlossen werden.
Überprüfen Sie, ob ein Bildupdate vorhanden ist.
Wenn ihre Pipelines nach einem Imageupdate fehlschlagen, können Sie Ihre Pipelines vorübergehend so konfigurieren, dass die vorherige Imageversion verwendet wird. Sie können Ihre fehlerhaften Pipelines so konfigurieren, dass die vorherige Imageversion pro Pipeline verwendet wird, oder Sie können die vorherige Imageversion für alle Pipelines in Ihrem verwalteten DevOps-Pool konfigurieren, die dieses Image verwenden.
Um festzustellen, ob ihre Pipelines aufgrund einer Änderung der Imageversion fehlschlagen, vergleichen Sie die Imageversion einer fehlgeschlagenen Pipelineausführung mit der Imageversion der letzten erfolgreichen Pipelineausführung.
Wechseln Sie zu Ihrer Pipeline , und überprüfen Sie den Pipelineausführungsverlauf für Ihre Pipeline.
Zeigen Sie die Ausführungsdetails für die beiden Pipelineausführungen an, die Sie vergleichen möchten, und wählen Sie den Pipelineauftrag aus, um Diagnoseinformationen anzuzeigen, die diesem Auftrag zugeordnet sind. Wenn Ihre Pipeline über mehrere Aufträge verfügt, wählen Sie den Auftrag aus, der mit Ihrem verwalteten DevOps-Pool ausgeführt wird.
Wählen Sie "Auftrag initialisieren" aus, und rufen Sie die Bildversion aus dem Abschnitt " Aktuelle Bildversion " ab.
Wenn sich die Imageversionen zwischen der letzten fehlgeschlagenen Pipelineausführung und der vorherigen erfolgreichen Ausführung unterscheiden, kann der Fehler durch ein Imageupdate verursacht werden. Sie haben zwei Optionen, um vorübergehend auf die vorherige Bildversion zurückgesetzt zu werden, während Sie die Ursache beheben.
- Um nur die fehlerhafte Pipeline mit der vorherigen Imageversion auszuführen, fügen Sie Ihrer Pipeline eine
ImageVersionOverrideAnforderung hinzu, um die vorherige Version anzugeben. Weitere Informationen finden Sie unter ImageVersionOverride. - Um die Pooleinstellungen so zu aktualisieren, dass alle Pipelines, die das Image verwenden, mit der vorherigen Version ausgeführt werden, aktualisieren Sie Ihre Imageeinstellungen , und geben Sie die gewünschte Version an.
- Wenn Sie Azure Pipelines-Images verwenden, müssen Sie ARM-Vorlagen oder Azure CLI verwenden, um die Version anzugeben, da Azure Pipelines-Images, die mit dem Azure-Portal konfiguriert sind, immer die neueste Version verwendet.
- Wenn Sie ausgewählte Marketplace-Images oder Azure Compute Gallery-Images verwenden, können Sie die Version über das Azure-Portal sowie ARM-Vorlagen und Azure CLI angeben.
Verwaltete DevOps-Pools halten die letzten 20 Images für ausgewählte Marketplace-Images und die letzten 10 Images für Azure Pipelines-Images zur Verfügung. Frühere Versionen von Azure Compute Gallery-Images werden von den Besitzern dieser Azure Compute Gallerys verwaltet.