Rozwiązywanie problemów związanych z zarządzaniem pulami DevOps

Ten artykuł zawiera rozwiązania typowych problemów z zarządzanymi pulami DevOps.

Błędy tworzenia puli

Niepowodzenie utworzenia puli z powodu uprawnień organizacji Azure DevOps

Tworzenie puli kończy się niepowodzeniem z powodu błędu podobnego do jednego z poniższych komunikatów o błędach.

Nie można odnaleźć zalogowanego użytkownika w organizacji usługi Azure DevOps

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

W celu rozwiązania tego problemu:

• Twoja organizacja Azure DevOps musi być połączona z Microsoft Entra ID, a zalogowany użytkownik Azure musi być członkiem (a nie gościem) tej dzierżawy. Zobacz Wymagania wstępne dotyczące zarządzanych pul DevOps — łączenie organizacji usługi Azure DevOps z identyfikatorem Entra firmy Microsoft i weryfikowanie członkostwa.

Zalogowany użytkownik nie ma uprawnień do zarządzania w organizacji usługi Azure DevOps

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

W celu rozwiązania tego problemu:

• Zalogowany użytkownik platformy Azure musi mieć odpowiednie uprawnienia usługi Azure DevOps, aby utworzyć pulę. Zobacz Wymagania wstępne usługi Azure DevOps — weryfikowanie uprawnień usługi Azure DevOps.

Niepowodzenie utworzenia puli z powodu uprawnień VNet.

Tworzenie puli kończy się niepowodzeniem UnauthorizedAccessToVirtualNetwork z powodu błędu podobnego do następującego: 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..

Aby rozwiązać ten problem:

• Zarządzane pule DevOps wymagają dostępu do sieci wirtualnej. Zobacz Grant Reader and Network Contributor access to DevOpsInfrastructure service principal (Udzielanie dostępu czytelnikowi i współautorowi sieci do jednostki usługi DevOpsInfrastructure).
• Podsieć sieci wirtualnej musi być delegowana do Microsoft.DevOpsInfrastructure/pools. Zobacz Delegowanie podsieci w programie Microsoft.DevOpsInfrastructure/pools.

Opóźnienia uruchamiania rurociągu

W przypadku korzystania z zarządzanych pul DevOps mogą wystąpić sytuacje, w których przed uruchomieniem potoku po jego zainicjowaniu występuje duże opóźnienie. W tej sekcji przewodnika rozwiązywania problemów opisano typowe elementy, które mogą mieć wpływ na wydajność pul. Aby uzyskać więcej informacji, zobacz Zarządzanie kosztami i wydajnością.

• Sprawdź brak wystarczającej liczby zadań równoległych
• sprawdź maksymalną konfigurację agentów
• Rozważ wstępne przygotowywanie agentów na zapas przy użyciu harmonogramu agenta rezerwowego
  • tryb automatycznego czuwania dla nowych pul
  • sprawdź procent agentów rezerwowych, jeśli używane są agenci rezerwowi z wieloma obrazami
• Rozważ użycie stanowych pul z okresem karencji, aby utrzymać agentów online
• sprawdzanie kodów błędów przekroczenia limitu czasu

Sprawdzanie, czy nie ma wystarczających zadań równoległych

Agenci zarządzanych pul DevOps są traktowani jako agenci hostowani samodzielnie przez usługę Azure DevOps i wymagają uruchamiania własnych zadań równoległych. Na przykład, jeśli liczba równoległych zadań potoków hostowanych samodzielnie przez organizację wynosi 10, organizacja może jednocześnie uruchamiać tylko 10 takich zadań potoku. Jeśli kolejkowane są więcej niż 10 potoków, można uruchomić tylko 10 w danym momencie.

Sprawdź liczbę zadań równoległych hostowanych samodzielnie, aby upewnić się, że masz wystarczającą pojemność, aby spełnić wymagania równoczesnego potoku obciążenia. Aby uzyskać więcej informacji, zobacz Konfigurowanie zadań równoległych i płacenie za zadania równoległe.

Sprawdź konfigurację maksymalnej liczby agentów

Ustawienie Maksymalna liczba agentów konfiguruje maksymalną liczbę uruchomionych agentów w zarządzanej puli DevOps. Jeśli ustawienie Maksymalna liczba agentów wynosi 5, zarządzane pule DevOps mogą uruchamiać maksymalnie pięć współbieżnych potoków. Jeśli w kolejce znajduje się więcej niż pięć potoków, dodatkowe potoki nie zostaną uruchomione, dopóki jeden z pięciu dostępnych agentów nie stanie się aktywny.

Rozważ przydzielanie agentów z wyprzedzeniem, używając harmonogramu agenta rezerwowego

Jeśli tryb agenta rezerwowego jest wyłączony, agenci zarządzanych pul DevOps są uruchamiani na żądanie, gdy potok jest w kolejce, chociaż uruchomienie nowego agenta zwykle trwa tylko kilka chwil, jednak czasem może to zająć nawet do 15 minut.

Po włączeniu trybu czuwania agenta można określić harmonogram i liczbę agentów, aby byli gotowi na spełnienie wymagań obciążenia.

Aby uzyskać więcej informacji, zobacz Zarządzanie kosztami i wydajnością — wstępne aprowizowanie przy użyciu agentów rezerwowych.

Automatyczny tryb czuwania dla nowych pul

Zarządzanie pulami DevOps używa historycznych danych użycia puli, aby ułatwić automatyczny tryb rezerwowy przewidywania skalowania. Nowe pule nie mają żadnych danych historycznych, więc agenci mogą zostać utworzeni na żądanie. Aby poprawić wydajność, możesz przełączyć się na tryb ręcznego wstrzymania przez pierwszy miesiąc i przełączyć się do trybu automatycznego wstrzymania, gdy zarządzane pule DevOps miały czas na obserwowanie użycia puli.

Sprawdzanie procentu agenta rezerwowego w przypadku korzystania z agentów rezerwowych z wieloma obrazami

Jeśli używasz agentów rezerwowych z wieloma obrazami, sprawdź historię użycia dla każdego obrazu i porównaj ją z ustawieniem procentowym agenta rezerwowego dla Twoich obrazów, aby upewnić się, że stosunek gotowości odzwierciedla twoje użycie. Jeśli na przykład masz jeden obraz systemu Windows i jeden obraz z systemem Ubuntu, a obciążenie używa systemu Windows 75% czasu, upewnij się, że obraz systemu Windows jest skonfigurowany z procentem agenta rezerwowego 75.

Rozważ użycie pul stanowych z okresem karencji, aby utrzymać agentów online.

Jedną z opcji poprawy wydajności agenta bez używania agentów rezerwowych jest użycie agentów stanowych z krótkim okresem prolongaty. Gdy agent stanowy z okresem prolongaty kończy zadanie, pozostaje w trybie online przez czas określony przez okres prolongaty i czeka na dodatkowe zadania. Jeśli obciążenie występuje w okresach wzrostu, możesz skonfigurować okres prolongaty, który utrzymuje agentów w trybie online, gdy zadania są stałe, i uruchamia je od podstaw w wolniejszych okresach.

Aby uzyskać więcej informacji, zobacz Agenty rezerwowe i pule stanowe .

Sprawdzanie kodów błędów przekroczenia limitu czasu

Jeśli upłynie limit czasu przypisania agenta, możesz sprawdzić kod błędu w sekcji Kody błędów na stronie Przegląd.

Potok nie udaje się zakończyć poprawnie

Sprawdź, czy nastąpiła aktualizacja obrazu

Jeśli potoki zaczynają zawodzić po aktualizacji obrazu systemu, możesz tymczasowo skonfigurować potoki tak, aby korzystały z poprzedniej wersji obrazu systemu. Potoki, które kończą się niepowodzeniem, można skonfigurować tak, aby korzystały z poprzedniej wersji obrazu dla poszczególnych potoków, lub skonfigurować poprzednią wersję obrazu dla wszystkich potoków w zarządzanej puli DevOps, która używa tego obrazu.

Aby sprawdzić, czy potoki ulegają niepowodzeniu z powodu zmiany wersji obrazu, porównaj wersję obrazu w nieudanym uruchomieniu potoku z wersją obrazu z ostatniego pomyślnego uruchomienia potoku.

1. Przejdź do swojego potoku i przejrzyj historię uruchamiania tego potoku.

   

2. Wyświetl szczegóły przebiegu dla dwóch przebiegów potoku, które chcesz porównać, i wybierz zadanie potoku, aby wyświetlić informacje diagnostyczne na temat tego zadania. Jeśli Twój potok ma wiele zadań, wybierz zadanie, które jest uruchamiane przy użyciu zarządzanej puli DevOps.

   

3. Wybierz pozycję Zainicjuj zadanie i pobierz wersję obrazu z sekcji Bieżąca wersja obrazu .

   

Jeśli wersje obrazów różnią się między ostatnim nieudanym uruchomieniem konfiguracji a poprzednim pomyślnym uruchomieniem, niepowodzenie może być spowodowane zmianą wersji obrazu. Podczas rozwiązywania problemów z główną przyczyną są dostępne dwie opcje tymczasowego przywracania poprzedniej wersji obrazu.

• Aby uruchomić tylko potok kończący się niepowodzeniem przy użyciu poprzedniej wersji obrazu, dodaj ImageVersionOverride żądanie do potoku, aby określić poprzednią wersję. Aby uzyskać więcej informacji, zobacz ImageVersionOverride.
• Aby zaktualizować ustawienia puli w taki sposób, aby wszystkie potoki korzystające z obrazu były uruchamiane przy użyciu poprzedniej wersji, zaktualizuj ustawienia obrazu i określ żądaną wersję.
  • Jeśli używasz obrazów usługi Azure Pipelines, musisz użyć szablonów usługi ARM lub interfejsu wiersza polecenia platformy Azure , aby określić wersję, ponieważ obrazy usługi Azure Pipelines skonfigurowane przy użyciu witryny Azure Portal zawsze używają najnowszej wersji.
  • Jeśli używasz wybranych obrazów witryny Marketplace lub obrazów z galerii obliczeń platformy Azure, możesz określić wersję przy użyciu witryny Azure Portal, a także szablonów usługi ARM i interfejsu wiersza polecenia platformy Azure.

Zarządzane pule DevOps przechowują ostatnie 20 obrazów dostępnych dla obrazów z Selected marketplace i ostatnie 10 obrazów dostępnych dla obrazów usługi Azure Pipelines. Poprzednie wersje obrazów Galerii Obliczeniowej Azure są utrzymywane przez właścicieli tych galerii.

Zobacz też

• Wymagania wstępne dotyczące zarządzanych pul DevOps
• Konfigurowanie sieci zarządzanych pul DevOps
• Zarządzanie kosztami i wydajnością