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

Kod błędu opis
PoolProvisioningFailed Tworzenie puli nie powiodło się z powodu uprawnień organizacji Azure DevOps
UnauthorizedAccessToVirtualNetwork Niepowodzenie tworzenia puli z powodu uprawnień VNet

Nie udało się utworzyć 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 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:

Zalogowany użytkownik nie ma uprawnień zarządzanie w organizacji 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:

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:

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ą.

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

Agenci zarządzanych pul DevOps są traktowani jako agenci self-hosted przez Azure DevOps i wymagają zadań równoległych na hostach własnych. 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.

Uwaga

Maksymalna liczba agentów konfiguruje maksymalną liczbę agentów, które można aprowizować w tym samym czasie, ale liczba samodzielnie hostowanych zadań równoległych w organizacji określa liczbę zadań, które mogą być uruchamiane współbieżnie. Upewnij się, że masz wystarczające zadania równoległe hostowane samodzielnie w organizacji, aby umożliwić agentom uruchamianie zadań. Aby uzyskać więcej informacji, zobacz cennik zadań równoległych usług Azure DevOps Services.

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ądzane pule DevOps używają historycznych danych użycia puli, aby ułatwić przewidywanie skalowania w trybie automatycznym w trybie rezerwowym . 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 Windows i jeden obraz Ubuntu, a obciążenie używa Windows 75% czasu, upewnij się, że obraz Windows jest skonfigurowany z procentem agenta rezerwowego równym 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.

    Zrzut ekranu przedstawiający uruchomienia 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.

    Zrzut ekranu przedstawiający szczegóły przebiegu potoku.

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

    Zrzut ekranu przedstawiający wersję obrazu przebiegu potoku.

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 Azure Pipelines images, Należy użyć szablonów ARM lub Azure CLI aby określić wersję, ponieważ obrazy Azure Pipelines skonfigurowane przy użyciu portalu Azure zawsze używa najnowszej wersji.
    • Jeśli używasz obrazów Selected marketplace lub obrazów galerii Azure Compute, możesz określić wersję przy użyciu portalu Azure, a także szablonów ARM i Azure CLI.

Zarządzane pule DevOps przechowują 20 najnowszych obrazów dostępnych dla wybranych obrazów z Marketplace oraz 10 najnowszych obrazów dostępnych dla obrazów Azure Pipelines. Poprzednie wersje obrazów z Azure Compute Gallery są zarządzane przez właścicieli tych galerii.

Treści powiązane

  • Last updated on