Udostępnij za pośrednictwem


Samodzielnie hostowani agenci systemu Windows

Azure DevOps Services

Do kompilowania i wdrażania systemu Windows, platformy Azure i innych rozwiązań programu Visual Studio potrzebny jest co najmniej jeden agent systemu Windows. Agenci systemu Windows mogą również tworzyć aplikacje Java i Android.

Ten artykuł zawiera wskazówki dotyczące korzystania z oprogramowania agenta 3.x z usługami Azure DevOps Services i bieżącymi wersjami serwera Azure DevOps Server. Aby uzyskać listę wersji serwera Azure DevOps Server, które obsługują agenta 3.x, zobacz Czy usługa Azure DevOps Server obsługuje agenta 3.x.

Uwaga

W tym artykule opisano sposób konfigurowania agenta umieszczonego lokalnie . Jeśli używasz usług Azure DevOps Services i agenta hostowanego przez firmę Microsoft spełnia twoje potrzeby, możesz pominąć konfigurowanie własnego agenta systemu Windows.

Dowiedz się więcej o agentach

Jeśli już wiesz, czym jest agent i jak działa, możesz przejść bezpośrednio do poniższych sekcji. Jeśli jednak chcesz uzyskać więcej informacji o tym, co robią i jak działają, zobacz Agenci usługi Azure Pipelines.

Sprawdzanie wymagań wstępnych

Upewnij się, że maszyna ma następujące wymagania wstępne:

  • Wersja systemu operacyjnego
    • System operacyjny klienta
      • Windows 7 z pakietem Service Pack 1 ESU
      • Windows 8.1
      • Windows 10
      • Windows 11
    • System operacyjny serwera
      • Windows Server 2012 lub nowszy
  • Oprogramowanie agenta instaluje własną wersję platformy .NET, więc nie ma wymagań wstępnych platformy .NET.
  • Program PowerShell w wersji 3.0 lub nowszej
  • Subversion — jeśli tworzysz z repozytorium Subversion, musisz zainstalować klienta Subversion na maszynie.
  • Zalecane — narzędzia kompilacji programu Visual Studio (wersja 2015 lub nowsza)

Należy uruchomić instalatora agenta ręcznie po raz pierwszy. Po zapoznaniu się z działaniem agentów lub zautomatyzowaniu konfigurowania wielu agentów rozważ użycie nienadzorowanej konfiguracji.

Specyfikacje sprzętowe

Specyfikacje sprzętowe agentów różnią się w zależności od potrzeb, rozmiaru zespołu itp. Nie można utworzyć ogólnego zalecenia, które będzie miało zastosowanie do wszystkich. Jako punkt odniesienia zespół usługi Azure DevOps tworzy kod hostowanych agentów przy użyciu potoków korzystających z hostowanych agentów. Z drugiej strony większość kodu usługi Azure DevOps jest tworzona przez 24-rdzeniowe maszyny klasy serwerowej, na których działa czterech własnych agentów.

Przygotuj uprawnienia

Zabezpieczenie informacji dla samodzielnie hostowanych agentów

Użytkownik, który konfiguruje agenta, wymaga uprawnień administratora puli, ale użytkownik uruchamiający agenta nie wymaga takich uprawnień.

Foldery kontrolowane przez agenta powinny być ograniczone do jak najmniejszej liczby użytkowników, ponieważ zawierają wpisy tajne, które można odszyfrować lub eksfiltrować.

Agent usługi Azure Pipelines to oprogramowanie przeznaczone do wykonywania kodu pobieranego ze źródeł zewnętrznych. Z założenia może to być element docelowy ataków zdalnego wykonywania kodu (RCE).

Dlatego ważne jest, aby rozważyć model zagrożeń związany z każdym indywidualnym użyciem agentów Pipelines do wykonania pracy i zdecydować, jakie są minimalne uprawnienia, które można przyznać użytkownikowi uruchamiającemu agenta, maszynie, na której działa agent, użytkownikom, którzy mają dostęp do edycji definicji Pipelines, repozytoriów git, w których jest przechowywany yaml, lub grupie użytkowników, którzy kontrolują dostęp do puli dla nowych Pipelines.

Najlepszym rozwiązaniem jest, aby tożsamość używana do uruchamiania agenta różniła się od tożsamości z uprawnieniami do połączenia agenta z pulą. Użytkownik generujący poświadczenia (i inne pliki związane z agentem) różni się od użytkownika, który musi je odczytać. Dlatego bezpieczniej jest dokładnie rozważyć dostęp przyznany samej maszynie agenta oraz foldery agentów zawierające poufne pliki, takie jak dzienniki i artefakty.

Logiczne jest, aby udzielić dostępu do folderu agenta wyłącznie administratorom DevOps oraz tożsamości użytkownika uruchamiającej proces agenta. Administratorzy mogą chcieć zbadać system plików, aby zrozumieć błędy kompilacji lub pobrać pliki dziennika, aby móc zgłaszać błędy usługi Azure DevOps.

Zdecyduj, którego użytkownika użyjesz

W ramach jednorazowego kroku należy zarejestrować agenta. Osoba z uprawnieniami do administrowania kolejką agentów musi wykonać te kroki. Agent nie będzie używać poświadczeń tej osoby w codziennych czynnościach, ale poświadczenia te są wymagane do ukończenia rejestracji. Dowiedz się więcej o tym, jak agenci komunikują się.

Potwierdzanie, że użytkownik ma uprawnienia

Upewnij się, że konto użytkownika, którego zamierzasz użyć, ma uprawnienia do rejestrowania agenta.

Czy użytkownik jest właścicielem organizacji w usłudze Azure DevOps, czy administratorem serwera TFS lub usługi Azure DevOps Server? Zatrzymaj się tutaj, masz uprawnienia.

W przeciwnym razie:

  1. Otwórz przeglądarkę i przejdź do zakładki Pul Agentów dla organizacji usługi Azure Pipelines lub serwera Azure DevOps Server lub serwera TFS.

    1. Zaloguj się do swojej organizacji (https://dev.azure.com/{yourorganization}).

    2. Wybierz pozycję Azure DevOps, Ustawienia organizacji.

      Wybierz Ustawienia organizacji.

    3. Wybierz pule agentów.

      Wybierz zakładkę Pule agentów.

    1. Zaloguj się do kolekcji projektów (http://your-server/DefaultCollection).

    2. Wybierz Azure DevOps, Ustawienia kolekcji.

      Wybierz ustawienia kolekcji.

    3. Wybierz pule agentów.

      Wybierz pule agentów.

  2. Wybierz pulę po prawej stronie strony, a następnie kliknij opcję Zabezpieczenia.

  3. Jeśli konto użytkownika, którego zamierzasz użyć, nie jest wyświetlane, pobierz administratora, aby go dodać. Administrator może być administratorem puli agentów, właścicielem organizacji usługi Azure DevOps lub administratorem serwera TFS lub Azure DevOps Server.

    Jeśli jest to agent grupy wdrożeń, administrator może być administratorem grupy wdrożeń, właścicielem organizacji Azure DevOps lub administratorem serwera TFS lub Azure DevOps Server.

    Możesz dodać użytkownika do roli administratora grupy wdrażania na karcie Bezpieczeństwo na stronie Grupy wdrożeniowe w usłudze Azure Pipelines.

Uwaga

Jeśli zostanie wyświetlony komunikat podobny do następującego: Niestety, nie można dodać tożsamości. Spróbuj użyć innej tożsamości. Prawdopodobnie wykonano powyższe kroki dla właściciela organizacji lub administratora serwera TFS lub Azure DevOps Server. Nie musisz nic robić; Masz już uprawnienia do administrowania pulą agentów.

Pobieranie i konfigurowanie agenta

Azure Pipelines (narzędzie do automatyzacji procesów w chmurze Azure)

  1. Zaloguj się na maszynie przy użyciu konta, dla którego przygotowano uprawnienia zgodnie z powyższym wyjaśnieniem.

  2. W przeglądarce internetowej zaloguj się do usługi Azure Pipelines i przejdź do karty Pule agentów :

    1. Zaloguj się do swojej organizacji (https://dev.azure.com/{yourorganization}).

    2. Wybierz pozycję Azure DevOps, Ustawienia organizacji.

      Wybierz Ustawienia organizacji.

    3. Wybierz pule agentów.

      Wybierz zakładkę Pule agentów.

    1. Zaloguj się do kolekcji projektów (http://your-server/DefaultCollection).

    2. Wybierz Azure DevOps, Ustawienia kolekcji.

      Wybierz ustawienia kolekcji.

    3. Wybierz pule agentów.

      Wybierz pule agentów.

  3. Wybierz pulę Domyślną, wybierz kartę Agenci, a następnie wybierz Nowy agent.

  4. W oknie dialogowym Pobieranie agenta wybierz pozycję Windows.

  5. W okienku po lewej stronie wybierz architekturę procesora zainstalowanej wersji systemu operacyjnego Windows na maszynie. Wersja agenta x64 jest przeznaczona dla 64-bitowego systemu Windows, natomiast wersja x86 jest przeznaczona dla 32-bitowego systemu Windows. Jeśli nie masz pewności, która wersja systemu Windows jest zainstalowana, postępuj zgodnie z tymi instrukcjami, aby dowiedzieć się.

  6. W okienku po prawej stronie kliknij przycisk Pobierz .

  7. Postępuj zgodnie z instrukcjami na stronie, aby pobrać agenta.

  8. Rozpakuj agenta do katalogu według własnego wyboru. Upewnij się, że ścieżka do katalogu nie zawiera spacji, ponieważ narzędzia i skrypty nie zawsze prawidłowo unikną spacji. Zalecanym folderem jest C:\agents. Wyodrębnianie w folderze 'Pobrane' lub innych folderach użytkownika może powodować problemy z uprawnieniami.

Ważne

Zdecydowanie zalecamy skonfigurowanie agenta w oknie programu PowerShell z podwyższonym poziomem uprawnień. Jeśli chcesz skonfigurować go jako usługę, jest to wymagane.

Do skonfigurowania agenta nie można użyć środowiska Windows PowerShell ISE .

Ważne

Ze względów bezpieczeństwa zdecydowanie zalecamy upewnienie się, że folder agentów (C:\agents) jest edytowalny tylko przez administratorów.

Uwaga

Unikaj używania powłok opartych na mintty, takich jak git-bash, na potrzeby konfiguracji agenta. Mintty nie jest w pełni zgodna z natywnym interfejsem API systemu Windows Input/Output (oto niektóre informacje o nim) i nie możemy zagwarantować, że skrypt konfiguracji będzie działał poprawnie w tym przypadku.

Instalowanie agenta

  1. Uruchom okno z podwyższonym poziomem uprawnień (PowerShell) i ustaw lokalizację tam, gdzie rozpakowałeś agenta.

    cd C:\agents 
    
    
  2. Uruchom config.cmd. To zada Ci serię pytań, aby skonfigurować agenta.

    .\config.cmd
    
    

Adres URL serwera

Gdy instalator wyświetli monit o adres URL serwera, w przypadku usługi Azure DevOps Services odpowiedz na adres https://dev.azure.com/{your-organization}.

Gdy instalator wyświetli monit o adres URL serwera, w przypadku usługi Azure DevOps Server odpowiedz https://{my-server}/{my-collection}.

Typ uwierzytelniania agenta przy konfiguracji

Podczas rejestrowania agenta wybierz spośród następujących typów uwierzytelniania, a instalator wyświetli monit o podanie określonych dodatkowych informacji wymaganych dla każdego typu uwierzytelniania. Aby uzyskać więcej informacji, zobacz Opcje uwierzytelniania dla agenta hostowanego samodzielnie.

Agenci systemu Windows mają następujące dwie dodatkowe opcje uwierzytelniania na serwerze Azure DevOps Server i serwerze TFS.

  • Negocjować Połącz się z programem TFS jako użytkownik inny niż zalogowany użytkownik za pośrednictwem schematu uwierzytelniania systemu Windows, takiego jak NTLM lub Kerberos. Po wybraniu pozycji Negocjuj zostanie wyświetlony monit o podanie poświadczeń.
  • Zintegrowane (domyślne) Łączenie agenta systemu Windows z programem TFS przy użyciu poświadczeń zalogowanego użytkownika za pośrednictwem schematu uwierzytelniania systemu Windows, takiego jak NTLM lub Kerberos. Po wybraniu tej metody nie zostanie wyświetlony monit o podanie poświadczeń.

Ważne

Serwer musi być skonfigurowany tak, aby obsługiwał metodę uwierzytelniania w celu używania alternatywnego, negocjowanego lub zintegrowanego uwierzytelniania.

Metoda uwierzytelniania używana do rejestrowania agenta jest używana tylko podczas rejestracji agenta. Aby dowiedzieć się więcej o tym, jak agenci komunikują się z usługą Azure Pipelines po rejestracji, zobacz Komunikacja z usługą Azure Pipelines lub TFS.

Wybieranie trybu interaktywnego lub trybu usługi

Aby uzyskać wskazówki dotyczące uruchamiania agenta w trybie interaktywnym lub jako usługa, zobacz Agenci: interaktywny czy usługa.

Jeśli zdecydujesz się uruchomić jako usługa (co zalecamy), nazwa użytkownika, z którą uruchomisz, powinna mieć maksymalnie 20 znaków.

Uruchamianie agenta

Uruchom interaktywnie

Jeśli agent został skonfigurowany do uruchamiania interakcyjnego, uruchom następujące polecenie, aby uruchomić agenta.

.\run.cmd

Aby ponownie uruchomić agenta, naciśnij Ctrl+C, aby zatrzymać agenta, a następnie uruchom polecenie run.cmd , aby go ponownie uruchomić.

Uwaga

Jeśli używasz agenta w PowerShell Core do wykonywania zadań programu Windows PowerShell, potok może zakończyć się błędem takim jak Error in TypeData "System.Security.AccessControl.ObjectSecurity": The member is already present. Dzieje się tak, ponieważ program Windows PowerShell dziedziczy zmienną PSModulePath środowiskową, która obejmuje lokalizacje modułów programu PowerShell Core z procesu nadrzędnego.

Aby obejść ten problem, możesz ustawić pokrętło AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL agenta na true w potoku. Umożliwi to agentowi zresetowanie PSModulePath przed wykonaniem zadań.

variables:
 AZP_AGENT_CLEANUP_PSMODULES_IN_POWERSHELL: "true"

Jeśli to obejście nie rozwiąże problemu lub jeśli musisz użyć niestandardowych lokalizacji modułów, możesz ustawić zmienną $Env:PSModulePath zgodnie z potrzebami w oknie programu PowerShell Core przed uruchomieniem agenta.

Uruchom jednorazowo

Możesz również zdecydować, że agent akceptuje tylko jedno zadanie, a następnie opuści program. Aby uruchomić polecenie w tej konfiguracji, użyj następującego polecenia.

.\run.cmd --once

Agenci w tym trybie będą akceptować tylko jedno zadanie, a następnie przechodzić w stan spoczynku w kontrolowany sposób (przydatne do uruchamiania w Dockerze na usłudze, takiej jak Azure Container Instances).

Uruchom jako usługę

Jeśli agent został skonfigurowany do uruchamiania jako usługa, zostanie uruchomiony automatycznie. Możesz kontrolować i wyświetlać stan działania agenta za pomocą przystawki usług. Uruchom services.msc i poszukaj jednego z:

  • Agent usługi Azure Pipelines (nazwa twojego agenta)
  • "Agent usługi VSTS (nazwa agenta)"
  • "vstsagent. (nazwa organizacji). (nazwa agenta)"

Uwaga

Aby zapewnić większą elastyczność z kontrolą dostępu agenta uruchomionego jako usługa, można skonfigurować typ SID usługi agenta jako [SERVICE_SID_TYPE_UNRESTRICTED] za pomocą flagi lub monitu podczas interaktywnego przepływu konfiguracji. Domyślnie usługa agenta jest skonfigurowana za pomocą polecenia SERVICE_SID_TYPE_NONE.

Aby uzyskać więcej informacji na temat typów identyfikatorów SID , zapoznaj się z tą dokumentacją.

Aby ponownie uruchomić agenta, kliknij prawym przyciskiem myszy wpis i wybierz polecenie Uruchom ponownie.

Uwaga

Jeśli musisz zmienić konto logowania agenta, nie rób tego z przystawki zarządzania Usługami. Zamiast tego zapoznaj się z poniższymi informacjami, aby ponownie skonfigurować agenta.

Aby użyć agenta, uruchom zadanie korzystając z puli agenta. Jeśli nie wybrano innej puli, agent będzie znajdować się w puli Domyślnej.

Zastępowanie agenta

Aby zastąpić agenta, wykonaj ponownie kroki pobierania i konfigurowania agenta .

Podczas konfigurowania agenta przy użyciu takiej samej nazwy jak agent, który już istnieje, zostanie wyświetlony monit o zastąpienie istniejącego agenta. Jeśli odpowiesz na Y, upewnij się, że usuniesz agenta (patrz poniżej), którego zastępujesz. W przeciwnym razie po kilku minutach konfliktów jeden z agentów zostanie wyłączony.

Usuwanie i ponowne konfigurowanie agenta

Aby usunąć agenta:

.\config remove

Po usunięciu agenta można go ponownie skonfigurować.

Konfiguracja nienadzorowana

Agenta można skonfigurować na podstawie skryptu bez interwencji człowieka. Musisz przekazać zarówno --unattended, jak i odpowiedzi na wszystkie pytania.

Aby skonfigurować agenta, musi on znać adres URL Twojej organizacji lub kolekcji oraz poświadczenia osoby upoważnionej do konfigurowania agentów. Wszystkie inne odpowiedzi są opcjonalne. Można określić dowolny parametr wiersza polecenia przy użyciu zmiennej środowiskowej: umieść jego nazwę wielkimi literami, poprzedzając ją znakiem VSTS_AGENT_INPUT_. Na przykład VSTS_AGENT_INPUT_PASSWORD zamiast określenia --password.

Wymagane opcje

  • --unattended — Instalator agenta nie wyświetli monitu o podanie informacji, a wszystkie ustawienia muszą być podane w wierszu polecenia
  • --url <url> — adres URL serwera. Na przykład: https://dev.azure.com/myorganization lub http://my-azure-devops-server:8080/tfs
  • --auth <type> — typ uwierzytelniania. Prawidłowe wartości to:
    • pat (Osobisty token dostępu)
    • SP (Service Principal) (Wymaga agenta w wersji 3.227.1 lub nowszej)
    • negotiate (Kerberos lub NTLM)
    • alt (uwierzytelnianie podstawowe)
    • integrated (Poświadczenia domyślne systemu Windows)

Opcje uwierzytelniania

  • W przypadku wybrania opcji --auth pat:
    • --token <token> — określa osobisty token dostępu
    • Możesz również przekazać token OAuth 2.0 jako --token parametr.
  • Jeśli wybrałeś --auth negotiate lub --auth alt:
    • --userName <userName> — określa nazwę użytkownika systemu Windows w formacie domain\userName lub userName@domain.com
    • --password <password> - określa hasło
  • W przypadku wybrania opcji --auth SP:
    • --clientID <clientID> — określa identyfikator klienta głównego użytkownika usługi z dostępem do rejestrowania agentów
    • --tenantId <tenantID> - określa identyfikator dzierżawcy, w którym jednostka usługi została zarejestrowana
    • --clientSecret <clientSecret> - określa klucz tajny klienta jednostki usługi
    • Aby uzyskać więcej informacji, zobacz Rejestrowanie agenta przy użyciu jednostki usługi

Nazwy puli i agentów

  • --pool <pool> - nazwa puli, do której agent ma dołączyć
  • --agent <agent> — nazwa agenta
  • --replace — wymień agenta w puli. Jeśli inny agent nasłuchuje pod tą samą nazwą, dojdzie do konfliktu.

Konfiguracja agenta

  • --work <workDirectory> — katalog służbowy, w którym są przechowywane dane zadania. Wartość domyślna to _work w katalogu głównym agenta. Katalog roboczy jest własnością danego agenta i nie powinien być współużytkowany między wieloma agentami.
  • --acceptTeeEula — zaakceptuj umowę licencyjną użytkownika oprogramowania Team Explorer Everywhere (tylko system macOS i Linux)
  • --disableloguploads — nie przesyłaj strumieniowo ani nie wysyłaj danych wyjściowych dziennika konsoli do serwera. Zamiast tego można pobrać je z systemu plików hosta agenta po zakończeniu zadania.

Uruchamianie tylko systemu Windows

  • --runAsService — konfigurowanie agenta do uruchamiania jako usługa systemu Windows (wymaga uprawnień administratora)
  • --runAsAutoLogon — konfigurowanie automatycznego logowania i uruchamianie agenta podczas uruchamiania (wymaga uprawnień administratora)
  • --windowsLogonAccount <account> - używane z --runAsService lub --runAsAutoLogon do określania nazwy użytkownika systemu Windows w formacie domain\userName lub userName@domain.com
  • --windowsLogonPassword <password> — używane z --runAsService lub --runAsAutoLogon do określania hasła logowania systemu Windows (nie jest wymagane dla grupowych kont zarządzanych przez usługę i wbudowanych kont systemu Windows, na przykład 'NT AUTHORITY\NETWORK SERVICE')
  • --enableservicesidtypeunrestricted — używane wraz z --runAsService do konfigurowania agenta z typem identyfikatora SID usługi jako SERVICE_SID_TYPE_UNRESTRICTED (wymaga uprawnień administratora)
  • --overwriteAutoLogon — używany z --runAsAutoLogon do zastępowania istniejącego automatycznego logowania na komputerze
  • --noRestart — jest używany razem z --runAsAutoLogon aby zapobiec ponownemu uruchamianiu hosta po zakończeniu konfiguracji agenta

Rozwiązywanie problemów z konfigurowaniem agenta przy użyciu runAsAutoLogon opcji

Skonfigurowanie agenta przy runAsAutoLogon użyciu opcji powoduje uruchomienie agenta za każdym razem po ponownym uruchomieniu maszyny. Wykonaj następne kroki, jeśli agent nie zostanie uruchomiony po ponownym uruchomieniu maszyny.

Jeśli agent został już skonfigurowany na maszynie

Przed ponownym skonfigurowaniem agenta należy usunąć starą konfigurację agenta, dlatego spróbuj uruchomić to polecenie z folderu agenta:

.\config.cmd remove --auth 'PAT' --token '<token>'

Sprawdź, czy agent został usunięty z puli agentów po wykonaniu polecenia:

<Azure DevOps organization> / <Project> / Settings / Agent pools / <Agent Pool> / Agents

Jeśli agent nie został usunięty po uruchomieniu polecenia, usuń go ręcznie z puli agentów.

Następnie spróbuj ponownie skonfigurować agenta, uruchamiając to polecenie z folderu agenta:

.\config.cmd --unattended --agent '<agent-name>' --pool '<agent-pool-name>' --url '<azure-dev-ops-organization-url>' --auth 'PAT' --token '<token>' --runAsAutoLogon --windowsLogonAccount '<domain\user-name>' --windowsLogonPassword '<windows-password>'

Określ nazwę agenta (dowolną unikatową nazwę) i sprawdź, czy ten agent pojawił się w puli agentów po ponownym skonfigurowaniu.

Znacznie lepiej będzie rozpakować archiwum agenta (które można pobrać tutaj) i uruchomić to polecenie z nowego rozpakowanego folderu agenta.

Sprawdź, czy klucz rejestru systemu Windows jest zarejestrowany i zapisany poprawnie

Uruchom polecenie whoami /user, aby uzyskać <sid>. Otwórz Registry Editor plik i postępuj zgodnie ze ścieżką:

Computer\HKEY_USERS\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Sprawdź, czy istnieje VSTSAgent klucz. Usuń ten klucz, jeśli istnieje, a następnie zamknij Registry Editor i skonfiguruj agenta, uruchamiając .\config.cmd polecenie (bez args) z folderu agenta. Przed udzieleniem odpowiedzi na pytanie Enter Restart the machine at a later time?otwórz Registry Editor ponownie i sprawdź, czy VSTSAgent klucz został wyświetlony. Naciśnij Enter , aby odpowiedzieć na pytanie i sprawdzić, czy VSTSAgent klucz pozostaje w jego miejscu po ponownym uruchomieniu maszyny.

Sprawdź, czy klucze rejestru systemu Windows działają prawidłowo na maszynie

autorun.cmd Utwórz plik zawierający następujący wiersz: echo "Hello from AutoRun!". Otwórz Registry Editor i utwórz na powyższej ścieżce nową parę klucz-wartość z kluczem AutoRun i wartością

C:\windows\system32\cmd.exe /D /S /C start "AutoRun" "D:\path\to\autorun.cmd"

Uruchom ponownie komputer. Jeśli nie widzisz okna konsoli z komunikatem Hello from AutoRun! , występuje problem z kluczami rejestru systemu Windows.

Tylko grupa wdrożeniowa

  • --deploymentGroup — konfigurowanie agenta jako agenta grupy wdrożeń
  • --deploymentGroupName <name> — używane z --deploymentGroup do określenia grupy wdrożeniowej, do której agent ma dołączyć
  • --projectName <name> — używane razem z --deploymentGroup do ustawienia nazwy projektu
  • --addDeploymentGroupTags — używane z --deploymentGroup do oznaczenia, że należy dodać tagi grupy wdrożeniowej
  • --deploymentGroupTags <tags> — używane z --addDeploymentGroupTags do określenia listy tagów oddzielonych przecinkami dla agenta grupy wdrożeniowej — na przykład „web, db”

Tylko środowiska

  • --addvirtualmachineresourcetags — służy do wskazywania, że należy dodać tagi zasobów środowiska
  • --virtualmachineresourcetags <tags> — jest używany wraz z --addvirtualmachineresourcetags do określania listy tagów oddzielonych przecinkami dla agenta zasobów środowiska — na przykład "web, db"

.\config --help zawsze wyświetla listę najnowszych wymaganych i opcjonalnych odpowiedzi.

Diagnostyka

Jeśli masz problemy ze swoim agentem samodzielnie hostowanym, możesz spróbować uruchomić diagnostykę. Po skonfigurowaniu agenta:

.\run --diagnostics

Spowoduje to uruchomienie pakietu diagnostycznego, który może pomóc w rozwiązaniu problemu. Funkcja diagnostyki jest dostępna od wersji 2.165.0 agenta.

Diagnostyka sieci dla samodzielnie hostowanych agentów

Ustaw wartość Agent.Diagnostic na true, aby zebrać dodatkowe dzienniki, których można użyć do rozwiązywania problemów z siecią dla agentów hostowanych lokalnie. Aby uzyskać więcej informacji, zobacz Diagnostyka sieci dla agentów hostowanych samodzielnie

Pomoc dotycząca innych opcji

Aby dowiedzieć się więcej o innych opcjach:

.\config --help

Pomoc zawiera informacje na temat alternatyw uwierzytelniania i konfiguracji nienadzorowanej.

Możliwości

Możliwości agenta są katalogowane i publikowane w ramach puli, tak aby przypisane do niego były tylko te kompilacje i wydania, które jest w stanie obsłużyć. Zobacz możliwości agenta kompilacji i wydania.

W wielu przypadkach po wdrożeniu agenta należy zainstalować oprogramowanie lub narzędzia. Ogólnie rzecz biorąc, powinieneś zainstalować na agentach oprogramowanie i narzędzia, które używasz na swojej maszynie do programowania.

Jeśli na przykład kompilacja zawiera zadanie npm, kompilacja nie zostanie uruchomiona, chyba że w puli jest zainstalowany agent kompilacji npm.

Ważne

Możliwości obejmują wszystkie zmienne środowiskowe i wartości ustawione podczas uruchamiania agenta. Jeśli którakolwiek z tych wartości zmieni się podczas działania agenta, należy ponownie uruchomić agenta, aby pobrać nowe wartości. Po zainstalowaniu nowego oprogramowania na agencie należy ponownie uruchomić agenta, aby nowa funkcjonalność pojawiła się w puli i umożliwiła uruchomienie kompilacji.

Jeśli chcesz wykluczyć zmienne środowiskowe jako możliwości, możesz je wyznaczyć, ustawiając zmienną środowiskową VSO_AGENT_IGNORE z rozdzielaną przecinkami listą zmiennych do ignorowania.

Często zadawane pytania

Jaka wersja usługi Git jest uruchamiana przez mojego agenta?

Domyślnie agent systemu Windows używa wersji narzędzia Git powiązanej z oprogramowaniem agenta. Firma Microsoft zaleca użycie wersji narzędzia Git powiązanej z agentem, ale istnieje kilka opcji zastąpienia tego domyślnego zachowania i użycia wersji usługi Git zainstalowanej na maszynie agenta w ścieżce.

Aby wyświetlić wersję Git używaną przez potok, możesz przejrzeć dzienniki dla kroku checkout w swoim potoku, jak pokazano w poniższym przykładzie.

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

Jak mogę sprawdzić, czy mam najnowszą wersję agenta?

  1. Przejdź do karty Pule agentów :

    1. Zaloguj się do swojej organizacji (https://dev.azure.com/{yourorganization}).

    2. Wybierz pozycję Azure DevOps, Ustawienia organizacji.

      Wybierz Ustawienia organizacji.

    3. Wybierz pule agentów.

      Wybierz zakładkę Pule agentów.

    1. Zaloguj się do kolekcji projektów (http://your-server/DefaultCollection).

    2. Wybierz Azure DevOps, Ustawienia kolekcji.

      Wybierz ustawienia kolekcji.

    3. Wybierz pule agentów.

      Wybierz pule agentów.

  2. Kliknij pulę, która zawiera agenta.

  3. Upewnij się, że agent jest włączony.

  4. Przejdź do karty możliwości:

    1. Na karcie Pule agentów wybierz preferowaną pulę agentów.

      z pul agentów wybierz żądaną pulę agentów.

    2. Wybierz pozycję Agenci i wybierz żądanego agenta.

      Wybierz Agentów i wskaż wybranego agenta.

    3. Wybierz kartę Możliwości .

      wybierz kartę Możliwości.

      Uwaga

      Agenci hostowani przez firmę Microsoft nie wyświetlają możliwości systemowych. Aby uzyskać listę oprogramowania zainstalowanego na agentach hostowanych przez firmę Microsoft, zobacz Używanie agenta hostowanego przez firmę Microsoft.

    1. Na karcie Pule agentów wybierz żądaną pulę.

      Wybierz żądaną pulę.

    2. Wybierz pozycję Agenci i wybierz żądanego agenta.

      Wybierz opcję „Agenci” i wybierz żądanego agenta.

    3. Wybierz kartę Możliwości .

      Karta Możliwości agenta.

  5. Poszukaj funkcji Agent.Version. Możesz sprawdzić tę wartość względem najnowszej wersji agenta, która została opublikowana. Zobacz Azure Pipelines Agent i sprawdź stronę, aby znaleźć najwyższy numer wersji na liście.

  6. Każdy agent automatycznie aktualizuje się, gdy uruchamia zadanie wymagające nowszej wersji agenta. Jeśli chcesz ręcznie zaktualizować niektórych agentów, kliknij prawym przyciskiem myszy pulę i wybierz polecenie Aktualizuj wszystkich agentów.

Czy mogę zaktualizować agentów będących częścią puli usługi Azure DevOps Server?

Tak. Począwszy od usługi Azure DevOps Server 2019, można skonfigurować serwer tak, aby szukał plików pakietu agenta na dysku lokalnym. Ta konfiguracja zastąpi domyślną wersję, która została udostępniona z serwerem w momencie jego wydania. Ten scenariusz ma również zastosowanie, gdy serwer nie ma dostępu do Internetu.

  1. Z komputera z dostępem do Internetu pobierz najnowszą wersję plików pakietu agenta (w formacie .zip lub .tar.gz) z strony wydania agenta Azure Pipelines na GitHubie.

  2. Przenieś pobrane pliki pakietu do każdej warstwy aplikacji serwera Usługi Azure DevOps przy użyciu wybranej metody (takiej jak dysk USB, transfer sieciowy itd.). Umieść pliki agenta w następującym folderze:

  • Windows: %ProgramData%\Microsoft\Azure DevOps\Agents
  • Linux: usr/share/Microsoft/Azure DevOps/Agents
  • macOS: usr/share/Microsoft/Azure DevOps/Agents

Utwórz folder Agenci, jeśli nie jest obecny.

  1. Wszystko jest gotowe! Serwer Usługi Azure DevOps będzie teraz używać plików lokalnych za każdym razem, gdy agenci są aktualizowani. Każdy agent automatycznie aktualizuje się, gdy uruchamia zadanie wymagające nowszej wersji agenta. Jeśli jednak chcesz ręcznie zaktualizować niektórych agentów, kliknij prawym przyciskiem myszy pulę, a następnie wybierz polecenie Aktualizuj wszystkich agentów.

Uruchamiam zaporę sieciową, a mój kod znajduje się w usłudze Azure Repos. Z jakimi adresami URL agent musi się komunikować?

Jeśli używasz agenta w bezpiecznej sieci za zaporą, upewnij się, że agent może zainicjować komunikację z następującymi adresami URL i adresami IP.

Adres URL domeny Opis
https://{organization_name}.pkgs.visualstudio.com Azure DevOps Packaging API dla organizacji korzystających z domeny {organization_name}.visualstudio.com
https://{organization_name}.visualstudio.com W przypadku organizacji korzystających z domeny {organization_name}.visualstudio.com
https://{organization_name}.vsblob.visualstudio.com Telemetria usługi Azure DevOps dla organizacji korzystających z domeny {organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com Usługi zarządzania wydaniami dla organizacji korzystających z domeny {organization_name}.visualstudio.com
https://{organization_name}.vssps.visualstudio.com Usługi Azure DevOps Platform Services dla organizacji korzystających z domeny {organization_name}.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com Usługi zarządzania testami usługi Azure DevOps dla organizacji korzystających z domeny {organization_name}.visualstudio.com
https://*.blob.core.windows.net Azure Artifacts
https://*.dev.azure.com W przypadku organizacji korzystających z domeny dev.azure.com
https://*.vsassets.io Usługa Azure Artifacts za pośrednictwem usługi CDN
https://*.vsblob.visualstudio.com Telemetria usługi Azure DevOps dla organizacji korzystających z domeny dev.azure.com
https://*.vssps.visualstudio.com Usługi Azure DevOps Platform Services dla organizacji korzystających z domeny dev.azure.com
https://*.vstmr.visualstudio.com Usługi zarządzania testami usługi Azure DevOps dla organizacji korzystających z domeny dev.azure.com
https://app.vssps.visualstudio.com W przypadku organizacji korzystających z domeny {organization_name}.visualstudio.com
https://dev.azure.com W przypadku organizacji korzystających z domeny dev.azure.com
https://login.microsoftonline.com Logowanie w usłudze Microsoft Entra
https://management.core.windows.net Interfejsy API zarządzania Azure
https://download.agent.dev.azure.com Pakiet agenta

Ważne

Usługa Edgio CDN dla usługi Azure DevOps została wycofana, co wymaga, aby nowy adres URL domeny został dodany do listy dozwolonych w regułach zapory na potrzeby pobierania oprogramowania agenta. Nowa domena do dodania na listę dozwolonych dla pobierania agentów to https://*.dev.azure.com. Jeśli reguły zapory nie zezwalają na symbole wieloznaczne, użyj https://download.agent.dev.azure.com.

Zespół usługi Azure DevOps zaleca wprowadzenie tej zmiany do następującej daty:

  • 1 maja 2025 r. dla usługi Azure DevOps Services
  • 15 maja 2025 r. dla usługi Azure DevOps Server

Więcej informacji znajdziesz w Zmiana adresu URL domeny usługi CDN dla agentów w potokach.

Aby upewnić się, że Twoja organizacja współpracuje z istniejącymi ograniczeniami zapory lub adresów IP, upewnij się, że dev.azure.com i *dev.azure.com są otwarte, a także zaktualizuj listę dozwolonych adresów IP, aby uwzględniała następujące adresy IP, w zależności od używanej wersji IP. Jeśli obecnie dodajesz do listy dozwolonych adresy IP 13.107.6.183 i 13.107.9.183, pozostaw je na miejscu, ponieważ nie musisz ich usuwać.


13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
150.171.22.0/24 
150.171.23.0/24 
150.171.73.0/24 
150.171.74.0/24 
150.171.75.0/24 
150.171.76.0/24

Uwaga

Aby uzyskać więcej informacji na temat dozwolonych adresów, zobacz Dozwolone listy adresów i połączenia sieciowe.

W jaki sposób mogę uruchomić agenta z certyfikatem podpisanym własnoręcznie?

Uwaga

Uruchomienie agenta z certyfikatem z podpisem własnym ma zastosowanie tylko do usługi Azure DevOps Server.

Uruchom agenta z samopodpisanym certyfikatem

Jak uruchomić agenta przez serwer proxy?

Uruchom agenta za pośrednictwem internetowego serwera proxy

Jak ponownie uruchomić agenta

Jeśli używasz agenta interaktywnie, zapoznaj się z instrukcjami ponownego uruchamiania w temacie Uruchamianie interakcyjne. Jeśli używasz agenta jako usługi, uruchom ponownie agenta, wykonując kroki opisane w temacie Uruchom jako usługę.

Jak mogę ustawić różne zmienne środowiskowe dla każdego pojedynczego agenta?

.env Utwórz plik w katalogu głównym agenta i umieść zmienne środowiskowe, które chcesz ustawić w pliku w następującym formacie, a następnie uruchom ponownie agenta.

MyEnv0=MyEnvValue0
MyEnv1=MyEnvValue1
MyEnv2=MyEnvValue2
MyEnv3=MyEnvValue3
MyEnv4=MyEnvValue4

Jak skonfigurować agenta, aby pominąć internetowy serwer proxy i nawiązać połączenie z usługą Azure Pipelines?

Jeśli chcesz, aby agent pominął serwer proxy i nawiązał bezpośrednie połączenie z usługą Azure Pipelines, należy skonfigurować internetowy serwer proxy, aby umożliwić agentowi dostęp do następujących adresów URL.

W przypadku organizacji korzystających z domeny *.visualstudio.com:

https://login.microsoftonline.com
https://app.vssps.visualstudio.com 
https://{organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com
https://{organization_name}.pkgs.visualstudio.com
https://{organization_name}.vssps.visualstudio.com

W przypadku organizacji korzystających z domeny dev.azure.com:

https://dev.azure.com
https://*.dev.azure.com
https://login.microsoftonline.com
https://management.core.windows.net
https://download.agent.dev.azure.com
https://vssps.dev.azure.com

Aby upewnić się, że Twoja organizacja współpracuje z istniejącymi ograniczeniami zapory lub adresów IP, upewnij się, że dev.azure.com i *dev.azure.com są otwarte, a także zaktualizuj listę dozwolonych adresów IP, aby uwzględniała następujące adresy IP, w zależności od używanej wersji IP. Jeśli obecnie dodajesz do listy dozwolonych adresy IP 13.107.6.183 i 13.107.9.183, pozostaw je na miejscu, ponieważ nie musisz ich usuwać.


13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
150.171.22.0/24 
150.171.23.0/24 
150.171.73.0/24 
150.171.74.0/24 
150.171.75.0/24 
150.171.76.0/24

Uwaga

Ta procedura umożliwia agentowi obejście internetowego serwera proxy. Twoja konfiguracja kompilacji i skrypty muszą nadal obsługiwać omijanie internetowego serwera proxy dla każdego zadania i narzędzia uruchamianych podczas kompilacji.

Jeśli na przykład używasz zadania NuGet, musisz skonfigurować internetowy serwer proxy w celu obsługi pomijania adresu URL serwera, który hostuje używany kanał informacyjny NuGet.

Używam serwera TFS, a adresy URL w powyższych sekcjach nie działają dla mnie. Gdzie mogę uzyskać pomoc?

Ustawienia i zabezpieczenia witryny sieci Web

Używam lokalnego serwera TFS i nie widzę niektórych z tych funkcji. Dlaczego nie?

Niektóre z tych funkcji są dostępne tylko w usłudze Azure Pipelines i nie są jeszcze dostępne lokalnie. Niektóre funkcje są dostępne lokalnie, jeśli przeprowadzono uaktualnienie do najnowszej wersji serwera TFS.

Czym jest włączenie SERVICE_SID_TYPE_UNRESTRICTED dla usługi agenta?

Podczas konfigurowania oprogramowania agenta w systemie Windows Server można określić identyfikator zabezpieczeń usługi z następującego monitu.

Enter enable SERVICE_SID_TYPE_UNRESTRICTED for agent service (Y/N) (press enter for N)

Poprzednie wersje oprogramowania agenta ustawiły typ identyfikatora zabezpieczeń usługi na wartość SERVICE_SID_TYPE_NONE, która jest domyślną wartością dla bieżących wersji agenta. Aby skonfigurować typ identyfikatora usługi zabezpieczeń na SERVICE_SID_TYPE_UNRESTRICTED, naciśnij Y.

Aby uzyskać więcej informacji, zobacz SERVICE_SID_INFO strukturę i identyfikatory zabezpieczeń.