Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Potrzebujesz co najmniej jednego agenta do skompilowania kodu lub wdrożenia oprogramowania przy użyciu usługi Azure Pipelines. W miarę rozwoju bazy kodu i zespołu potrzebujesz wielu agentów.
Po uruchomieniu potoku system rozpoczyna jedno lub więcej zadań. Agent to infrastruktura obliczeniowa z zainstalowanym oprogramowaniem agenta, które uruchamia jedno zadanie naraz.
Usługa Azure Pipelines udostępnia kilka różnych typów agentów.
| Typ agenta | opis | Dostępność |
|---|---|---|
| Agenci hostowani przez firmę Microsoft | Agenci hostowani i zarządzani przez firmę Microsoft. | Azure DevOps Services |
| Samodzielnie hostowani agenci | Agenci, których konfigurujesz i zarządzasz, hostowani na twoich maszynach wirtualnych (VM). | Azure DevOps Services, Azure DevOps Server |
| Agenty zarządzające pulami DevOps | Zarządzane pule DevOps to w pełni zarządzana usługa. Maszyny wirtualne lub kontenery, które zasilają agentów, mieszkają w subskrypcji platformy Microsoft Azure, a nie w ramach własnej subskrypcji platformy Azure. | Azure DevOps Services |
| Agenci usługi Azure Virtual Machine Scale Sets | Forma własnych agentów korzystających z zestawów skalowania maszyn wirtualnych platformy Azure i może być skalowana automatycznie w celu spełnienia wymagań. Jeśli rozważasz korzystanie z pul agentów z możliwością automatycznego skalowania, hostowanych lokalnie, zalecamy rozważenie Zarządzanych Puli DevOps. Aby uzyskać więcej informacji, zobacz Porównanie zarządzanych pul DevOps z agentami usługi Azure Virtual Machine Scale Sets i Omówienie zarządzanych pul DevOps. |
Azure DevOps Services |
Zadania można uruchamiać bezpośrednio na maszynie hosta agenta lub w kontenerze.
Agenci hostowani przez firmę Microsoft
Jeśli potoki znajdują się w usłudze Azure Pipelines, możesz wygodnie uruchamiać zadania przy użyciu agenta hostowanego przez firmę Microsoft. W przypadku agentów hostowanych przez firmę Microsoft konserwacja i uaktualnienia są wykonywane automatycznie.
Zawsze masz najnowszą wersję obrazu maszyny wirtualnej, którą określasz w swoim potoku. Za każdym razem, uruchamiając potok, otrzymujesz nową maszynę wirtualną dla każdego etapu w potoku. Maszyna wirtualna zostanie odrzucona po jednym zadaniu. Wszelkie zmiany, które zadanie wykonuje w systemie plików maszyny wirtualnej, takie jak wyewidencjonowywanie kodu, są niedostępne w następnym zadaniu.
Agenci hostowani przez firmę Microsoft mogą uruchamiać zadania bezpośrednio na maszynie wirtualnej lub w kontenerze.
Usługa Azure Pipelines udostępnia wstępnie zdefiniowaną pulę agentów o nazwie Azure Pipelines z agentami hostowanymi przez Microsoft.
W przypadku wielu zespołów ten proces jest najprostszym sposobem uruchamiania zadań. Możesz spróbować najpierw sprawdzić, czy działa w przypadku kompilacji lub wdrożenia. Jeśli nie, możesz użyć agentów usługi Virtual Machine Scale Sets lub własnego agenta.
Napiwek
Możesz wypróbować agenta hostowanego przez firmę Microsoft bez opłat.
Dowiedz się więcej o agentach hostowanych przez firmę Microsoft.
Samodzielnie hostowani agenci
Agent hostowany lokalnie to agent, który konfigurujesz samodzielnie do uruchamiania zadań i zarządzania nimi. Możesz użyć własnych agentów w usłudze Azure Pipelines lub usłudze Azure DevOps Server. Agenty działające lokalnie dają większą kontrolę nad instalacją oprogramowania potrzebnego do kompilacji i wdrożeń. Ponadto pamięci podręczne na poziomie maszyny i konfiguracja są utrwalane pomiędzy uruchomieniami, co może zwiększyć szybkość.
Mimo że na maszynę można zainstalować wielu agentów, zdecydowanie zalecamy zainstalowanie tylko jednego agenta na maszynę. Podczas instalacji dwóch lub więcej agentów może to mieć negatywny wpływ na wydajność i wynik działania potoków.
Agent można zainstalować na komputerach z systemami Linux, macOS i Windows. Agenta można również zainstalować w kontenerze platformy Docker. Aby uzyskać więcej informacji na temat instalowania własnego agenta, zobacz:
W systemie macOS należy wyczyścić atrybut specjalny w archiwum pobierania, aby zapobiec wyświetlaniu ochrony programu Gatekeeper dla każdej części w pliku TAR podczas uruchamiania ./config.sh. Następujące polecenie czyści atrybut rozszerzony w pliku:
xattr -c vsts-agent-osx-x64-V.v.v.tar.gz ## replace V.v.v with the version in the filename downloaded.
# then unpack the gzip tar file normally:
tar xvfz vsts-agent-osx-x64-V.v.v.tar.gz
Po zainstalowaniu agenta na maszynie można zainstalować dowolne inne oprogramowanie na tym komputerze, którego wymagają zadania.
Uwaga
Agenci są generalnie zgodni z poprzednimi wersjami. Każda wersja agenta powinna być zgodna z dowolną wersją usługi Azure DevOps, o ile usługa Azure DevOps nie wymaga wyższej wersji agenta.
Obsługujemy tylko najnowszą wersję agenta, ponieważ jest to jedyna wersja gwarantowana, że zawiera wszystkie najnowsze poprawki i naprawy błędów.
wersje modułu uruchamiającego Node.js
Agent jest dostarczany z kilkoma wersjami bibliotek Node.js do obsługi zadań docelowych korzystających z różnych programów obsługi Node.js.
Wszystkie oficjalne zadania usługi Azure DevOps używają biblioteki Node.js w wersji 20 jako uniwersalnego mechanizmu obsługi. Jednak klienci mogą nadal używać niestandardowych zadań, które korzystają z wersji Node.js, dla których wsparcie się zakończyło. Autorzy zadań rozszerzeń/niestandardowych powinni aktualizować/testować swoje zadania przy użyciu bieżących wersji Node.js.
Aby uzyskać więcej informacji na temat cyklu życia runnera Node.js w usłudze Azure Pipelines, zobacz Node.js runnery w agencie Azure Pipelines.
Agenci usługi Azure Virtual Machine Scale Sets
Agenty usługi Azure Virtual Machine Scale Sets są formą samodzielnie hostowanych agentów, które mogą być automatycznie skalowane, aby zaspokoić Twoje potrzeby. Ta elastyczność zmniejsza potrzebę korzystania z dedykowanych agentów przez cały czas. W przeciwieństwie do agentów hostowanych przez firmę Microsoft masz elastyczność w zakresie rozmiaru i obrazu maszyn, na których działają agenci.
Usługa Azure Pipelines zarządza skalowaniem agentów. Określ następujące czynniki:
- Zestaw skalowania maszyn wirtualnych
- Liczba agentów do utrzymania w gotowości
- Maksymalna liczba maszyn wirtualnych w zestawie skalowania
Aby uzyskać więcej informacji, zobacz Agenci usługi Azure Virtual Machine Scale Sets.
Agenci pul DevOps zarządzanych
Zarządzane pule devOps umożliwiają zespołom deweloperów szybkie i łatwe tworzenie pul agentów usługi Azure DevOps dostosowanych do konkretnych potrzeb zespołu.
Zarządzane pule DevOps:
- Implementuje najlepsze rozwiązania w zakresie zabezpieczeń.
- Zapewnia sposoby równoważenia kosztów i wydajności.
- Udostępnia ścieżki dla najbardziej typowych scenariuszy.
- Znacznie skraca czas tworzenia i obsługi pul niestandardowych.
Zarządzane pule DevOps to rozwinięcie pul agentów Azure Virtual Machine Scale Sets. Upraszcza tworzenie puli niestandardowej jeszcze bardziej, zwiększając skalowalność i niezawodność pul niestandardowych. Zarządzane pule DevOps to w pełni zarządzana usługa. Maszyny wirtualne lub kontenery, które zasilają agentów, znajdują się w subskrypcji platformy Microsoft Azure, a nie w ramach własnej subskrypcji platformy Azure, podobnie jak pule agentów usługi Azure Virtual Machine Scale Sets. Aby uzyskać więcej informacji, zobacz dokumentację zarządzanych pul DevOps.
Zadania równoległe
Koncepcja zadań równoległych reprezentuje liczbę zadań, które można uruchomić w tym samym czasie w organizacji. Jeśli twoja organizacja ma jedno zadanie równoległe, możesz uruchomić pojedyncze zadanie jednocześnie w organizacji. Wszystkie inne współbieżne zadania są kolejkowane do momentu zakończenia pierwszego zadania. Aby uruchomić dwa zadania w tym samym czasie, potrzebne są dwa zadania równoległe. W usłudze Azure Pipelines można uruchamiać zadania równoległe w infrastrukturze hostowanej przez Microsoft lub we własnej infrastrukturze (self-hosted).
Firma Microsoft domyślnie udostępnia bezpłatną warstwę usługi w każdej organizacji, która zawiera co najmniej jedno zadanie równoległe. W zależności od liczby współbieżnych potoków, które należy uruchomić, może być konieczne użycie większej liczby zadań równoległych do korzystania z wielu agentów hostowanych przez Microsoft lub własnych w tym samym czasie. Aby uzyskać więcej informacji na temat zadań równoległych i różnych warstw bezpłatnych usługi, zobacz Parallel jobs in Azure Pipelines (Zadania równoległe w usłudze Azure Pipelines).
Może być konieczne użycie większej liczby zadań równoległych w celu jednoczesnego używania wielu agentów:
Ważne
Począwszy od Azure DevOps Server 2019, nie płacisz za samodzielnie hostowane zadania współbieżne w wydaniach. Ogranicza cię tylko liczba posiadanych agentów.
Możliwości
Każdy samodzielnie hostowany agent ma zestaw możliwości, które wskazują, co może zrobić. Możliwości to pary złożone z nazwy i wartości, które są:
- Możliwości, które oprogramowanie agenta odkrywa, nazywane możliwościami systemowymi.
- Definiowane możliwości nazywane możliwościami użytkownika.
Oprogramowanie agenta automatycznie określa różne możliwości systemowe. Te możliwości obejmują nazwę maszyny, typ systemu operacyjnego i wersje określonego oprogramowania zainstalowanego na maszynie. Ponadto zmienne środowiskowe zdefiniowane na maszynie są automatycznie wyświetlane na liście możliwości systemowych.
W przypadku przechowywania zmiennych środowiskowych jako możliwości przechowywane wartości możliwości są używane do ustawiania zmiennych środowiskowych podczas uruchamiania agenta. Ponadto w przypadku wprowadzania zmian w zmiennych środowiskowych podczas działania agenta nie są one pobierane i używane przez żadne zadanie. Jeśli nie chcesz, aby poufne zmienne środowiskowe, które się zmieniają, były przechowywane jako zdolności, możesz nakazać agentowi ich ignorowanie. Ustaw zmienną VSO_AGENT_IGNORE środowiskową z rozdzielaną przecinkami listą zmiennych, które mają być ignorowane. Na przykład PATH to zmienna krytyczna, którą można zignorować, jeśli instalujesz oprogramowanie.
Podczas tworzenia pipeline'u określasz wymagania agenta. System przekazuje zadanie wyłącznie agentom, którzy mają możliwości zgodne z wymaganiami określonymi w potoku przetwarzania. W związku z tym możliwości agenta umożliwiają kierowanie zadań do określonych agentów.
Wymagania i możliwości są przeznaczone do użytku z własnymi agentami, dzięki czemu zadania mogą być dopasowane do agenta spełniającego wymagania zadania. W przypadku korzystania z agentów hostowanych przez firmę Microsoft wybierasz obraz agenta, który spełnia wymagania zadania. Chociaż istnieje możliwość dodania możliwości do agenta hostowanego przez firmę Microsoft, nie musisz używać funkcji z agentami hostowanymi przez firmę Microsoft.
Konfigurowanie żądań
Aby dodać żądanie do potoku kompilacji YAML, dodaj linię demands: do sekcji pool.
pool:
name: Default
demands: SpecialSoftware # exists check for SpecialSoftware
Możesz sprawdzić istnienie możliwości lub porównać wartość możliwości. Aby uzyskać więcej informacji, zobacz schemat YAML — wymagania.
Konfigurowanie możliwości agenta
Możesz wyświetlić szczegóły agenta, w tym możliwości wersji i systemu oraz zarządzać jego możliwościami użytkownika. Przejdź do pozycji Pule agentów i wybierz kartę Możliwości odpowiedniego agenta.
W przeglądarce internetowej przejdź do Pul agentów:
Przejdź do karty Możliwości :
Na karcie Pule agentów wybierz wybraną pulę agentów.
Wybierz pozycję Agenci i wybierz żądanego agenta.
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.
Z karty "Pule agentów" wybierz odpowiednią pulę.
Wybierz pozycję Agenci i wybierz żądanego agenta.
Wybierz kartę Możliwości .
Aby zarejestrować nową funkcję za pomocą agenta, wybierz pozycję Dodaj nową funkcję.
Napiwek
Po zainstalowaniu nowego oprogramowania na agencie typu self-hosted, należy ponownie uruchomić agenta, aby nowa funkcja była widoczna. Aby uzyskać więcej informacji, zobacz Ponowne uruchamianie agenta systemu Windows, Ponowne uruchamianie agenta systemu Linux i Ponowne uruchamianie agenta komputera Mac.
Komunikacja
Komunikacja za pomocą usługi Azure Pipelines
Komunikacja z usługą Azure DevOps Server
Agent komunikuje się z usługą Azure Pipelines lub usługą Azure DevOps Server. Określa, które zadanie musi uruchomić i zgłasza dzienniki oraz stan zadania. Agent zawsze inicjuje tę komunikację.
Wszystkie komunikaty od agenta do usług Azure Pipelines lub Azure DevOps Server są przesyłane za pośrednictwem protokołu HTTP lub HTTPS, w zależności od konfiguracji agenta. Ten model ściągania umożliwia skonfigurowanie agenta do różnych topologii, jak pokazano w poniższych przykładach.
Oto typowy wzorzec komunikacji między agentem a usługą Azure Pipelines lub usługą Azure DevOps Server:
Użytkownik rejestruje agenta w usłudze Azure Pipelines lub usłudze Azure DevOps Server, dodając go do puli agentów. Aby zarejestrować agenta w tej puli agentów, musisz mieć rolę administratora puli agentów . Rola administratora puli agentów jest wymagana tylko w momencie rejestracji i nie jest utrwalana w agencie. Nie jest on używany w żadnej dalszej komunikacji między agentem a usługą Azure Pipelines ani usługą Azure DevOps Server.
Po zakończeniu rejestracji agent pobiera element
listener OAuth tokeni używa go do nasłuchiwania kolejki zadań.Agent monitoruje, czy nowe żądanie zadania zostało umieszczone w kolejce zadań w Azure Pipelines lub Azure DevOps Server, wykorzystując długie sondowanie HTTP. Gdy zadanie jest dostępne, agent pobiera zadanie i
job-specific OAuth token. Usługa Azure Pipelines lub azure DevOps Server generuje krótkotrwały token dla tożsamości o określonym zakresie w potoku.Agent używa tokenu do uzyskiwania dostępu do zasobów lub modyfikowania ich w usłudze Azure Pipelines lub azure DevOps Server w ramach tego zadania. Na przykład używa tokenu, aby uzyskać dostęp do kodu źródłowego lub przekazać wyniki testu.
Agent odrzuca token specyficzny dla zadania
OAuthpo zakończeniu zadania, a następnie przy użyciu tokenu OAuth odbiornika sprawdza, czy istnieje nowe żądanie zadania.
Ładunek komunikatów wymienianych między agentem a usługą Azure Pipelines lub usługą Azure DevOps Server jest zabezpieczony przy użyciu szyfrowania asymetrycznego.
Każdy agent ma parę kluczy publicznego i prywatnego. Ten klucz publiczny jest wymieniany z serwerem podczas rejestracji. Serwer używa klucza publicznego do szyfrowania ładunku zadania przed wysłaniem go do agenta. Agent odszyfrowuje zawartość zadania przy użyciu klucza prywatnego.
Ta metoda zabezpiecza tajemnice przechowywane w potokach lub grupach zmiennych podczas wymiany z agentem.
Uwaga
Agent zapewnia obsługę wyjściowego kodowania UTF-8 dla klienta. Jeśli jednak system nie używa kodowania UTF-8, mogą wystąpić problemy z danymi wyjściowymi dziennika. Na przykład dzienniki mogą zawierać znaki, których kodowanie systemu nie rozpoznaje, przez co mogą wydawać się zniekształcone lub brakować symboli.
Przesyłanie danych w celu wdrożenia na serwery docelowe
Gdy używasz agenta do wdrażania artefaktów na grupie serwerów, musi on mieć bezpośrednią łączność z tymi serwerami. Pule agentów hostowanych przez firmę Microsoft domyślnie mają łączność z witrynami internetowymi i serwerami platformy Azure uruchomionymi na platformie Azure.
Jeśli zasoby platformy Azure działają w sieci wirtualnej platformy Azure, możesz uzyskać zakresy adresów IP agenta , w których są wdrażani agenci hostowani przez firmę Microsoft. Następnie można skonfigurować reguły zapory dla sieci wirtualnej platformy Azure, aby zezwolić na dostęp przez agenta.
Jeśli środowiska lokalne nie mają łączności z pulą agentów hostowanych przez firmę Microsoft, co jest zwykle spowodowane pośrednimi zaporami, należy ręcznie skonfigurować własnych agentów na komputerach lokalnych. Agenci muszą mieć łączność z docelowymi środowiskami lokalnymi oraz dostęp do Internetu w celu nawiązania połączenia z usługą Azure Pipelines lub usługą Azure DevOps Server. Ten proces przedstawiono w następującym schemacie:
Uwierzytelnianie
Aby zarejestrować agenta, musisz być członkiem roli administratora w puli agentów. Tożsamość administratora puli agentów jest wymagana tylko w momencie rejestracji i nie jest utrwalana na agencie. Nie jest ona używana w żadnej kolejnej komunikacji między agentem a usługą Azure Pipelines ani usługą Azure DevOps Server. Aby skonfigurować agenta, musisz również być administratorem lokalnym na serwerze.
Podczas rejestrowania agenta wybierz spośród następujących typów uwierzytelniania. Proces konfiguracji agenta monituje o podanie określonych dodatkowych informacji wymaganych dla każdego typu uwierzytelniania. Aby uzyskać więcej informacji, zobacz Opcje uwierzytelniania dla agenta hostowanego samodzielnie.
- Osobisty token dostępu.
- Alternatywna: połącz się z serwerem Azure DevOps Server przy użyciu uwierzytelniania podstawowego. Po wybraniu pozycji Alternatywne zostanie wyświetlony monit o podanie poświadczeń.
Ponadto agenci systemu Windows mają następujące dwie opcje uwierzytelniania na serwerze Azure DevOps Server.
- Negocjuj: połącz się z serwerem Usługi Azure DevOps jako użytkownik inny niż zalogowany użytkownik za pośrednictwem schematu uwierzytelniania systemu Windows (na przykład New Technology LAN Manager (NTLM) lub Kerberos). Po wybraniu pozycji Negocjuj zostanie wyświetlony monit o podanie poświadczeń.
- Zintegrowane: (Ustawienie domyślne) Łączenie agenta systemu Windows z usługą Azure DevOps Server przy użyciu poświadczeń zalogowanego użytkownika za pośrednictwem schematu uwierzytelniania systemu Windows (na przykład NTLM lub Kerberos). Po wybraniu tej metody nie zostanie wyświetlony monit o podanie poświadczeń.
Ważne
Serwer należy skonfigurować 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 na temat sposobu komunikowania się agentów z usługą Azure Pipelines po rejestracji, zobacz Komunikacja z usługą Azure Pipelines lub azure DevOps Server.
Proces interaktywny a usługa
Własnego agenta możesz uruchomić jako usługę lub proces interaktywny.
Po skonfigurowaniu agenta zalecamy najpierw wypróbowanie go w trybie interaktywnym, aby upewnić się, że działa. Następnie w celu użycia w środowisku produkcyjnym zalecamy uruchomienie agenta w jednym z następujących trybów, aby niezawodnie pozostał w stanie uruchomienia. Te tryby zapewniają też automatyczne włączenie agenta po ponownym uruchomieniu maszyny.
Jako usługa: możesz użyć menedżera usług systemu operacyjnego do zarządzania cyklem życia agenta. Doświadczenie związane z automatyczną aktualizacją agenta jest lepsze, gdy uruchamiasz agenta jako usługę.
Jako interaktywny proces z włączonym automatycznym logowaniem: w niektórych przypadkach może być konieczne interaktywne uruchomienie agenta do użytku produkcyjnego (na przykład w celu uruchomienia testów interfejsu użytkownika). Podczas konfigurowania agenta do uruchamiania w tym trybie wygaszacz ekranu jest wyłączony. Niektóre zasady domeny mogą uniemożliwić włączenie automatycznego logowania lub wyłączenie wygaszacza ekranu. W takich przypadkach może być konieczne uzyskanie wykluczenia z zasad domeny lub uruchomienie agenta na komputerze grupy roboczej, na którym zasady domeny nie mają zastosowania.
Uwaga
Podczas włączania automatycznego logowania lub wyłączania wygaszacza ekranu występują zagrożenia bezpieczeństwa. Inni użytkownicy mogą mieć dostęp do komputera i korzystać z konta, które automatycznie się loguje. W przypadku skonfigurowania agenta w taki sposób należy upewnić się, że komputer jest fizycznie chroniony (na przykład w bezpiecznym obiekcie).
Jeśli używasz pulpitu zdalnego do uzyskiwania dostępu do komputera, na którym działa agent z automatycznym logowaniem, zamknięcie pulpitu zdalnego powoduje zablokowanie komputera. Wszystkie testy interfejsu użytkownika uruchamiane na tym agencie mogą zakończyć się niepowodzeniem. Aby uniknąć tego problemu, użyj polecenia
tscon, aby odłączyć się od pulpitu zdalnego. Na przykład:%windir%\System32\tscon.exe 1 /dest:console
Konto agenta
Niezależnie od tego, czy uruchamiasz agenta jako usługę, czy interaktywnie, możesz wybrać konto komputera używane do uruchamiania agenta. Wybór konta agenta zależy wyłącznie od potrzeb zadań uruchamianych podczas kompilacji oraz wdrażania.
Aby na przykład uruchamiać zadania przy użyciu uwierzytelniania systemu Windows w celu uzyskania dostępu do usługi zewnętrznej, agent musi działać przy użyciu konta z dostępem do tej usługi. Jeśli jednak uruchamiasz testy interfejsu użytkownika, takie jak selenium lub kodowane testy interfejsu użytkownika, które wymagają przeglądarki, przeglądarka zostanie otwarta w kontekście konta agenta.
W systemie Windows zalecamy użycie konta usługi, takiego jak usługa sieciowa lub usługa lokalna. Te uprawnienia kont są ograniczone, a ich hasła nie wygasają, więc agent wymaga mniejszego zarządzania w czasie.
Te poświadczenia różnią się od poświadczeń używanych podczas rejestrowania agenta w usłudze Azure Pipelines lub azure DevOps Server.
Wersja agenta i uaktualnienia
Aktualizujemy oprogramowanie agenta co kilka tygodni w usłudze Azure Pipelines. Wskazujemy wersję agenta w formacie {major}.{minor}. Jeśli na przykład wersja agenta to 2.1, wersja główna to 2 , a wersja pomocnicza to 1.
Utrzymujemy aktualność agentów hostowanych przez firmę Microsoft. Jeśli nowsza wersja agenta różni się tylko w wersji pomniejszej, usługa Azure Pipelines może automatycznie aktualizować agentów własnego hostingu. Ustawienie domyślne jest włączone. To ustawienie można skonfigurować w pulach agentów , wybierając agenta, a następnie wybierając pozycję Ustawienia. Żądanie uaktualnienia następuje, gdy funkcja platformy lub jedno z zadań w kolejce zadań wymaga nowszej wersji agenta.
Jeśli uruchamiasz agenta hostowanego samodzielnie lub jest dostępna nowsza wersja główna agenta, może być konieczne ręczne uaktualnienie agentów. Agentów można uaktualnić na karcie Pule agentów w organizacji. Rurociągi nie mogą działać bez zgodnego agenta.
Aby zaktualizować samodzielnie hostowanych agentów
Przejdź do Project settings>Agent pools.
Wybierz pulę agentów, a następnie wybierz pozycję Aktualizuj wszystkich agentów.
Agentów można również aktualizować indywidualnie, wybierając pozycję Aktualizuj agenta z menu ... .
Wybierz pozycję Aktualizuj, aby potwierdzić.
Żądanie aktualizacji jest kolejkowane dla każdego agenta w puli i zostanie uruchomione po zakończeniu któregokolwiek z aktualnie uruchomionych zadań. Uaktualnienie zwykle trwa tylko kilka chwil. Ten czas jest wystarczająco długi, aby pobrać najnowszą wersję oprogramowania agenta (około 200 MB), rozpakuj go i uruchom ponownie agenta przy użyciu nowej wersji. Stan agentów można monitorować na karcie Agenci .
Aktualizujemy oprogramowanie agenta przy użyciu każdej aktualizacji usługi Azure DevOps Server. Wskazujemy wersję agenta w formacie {major}.{minor}. Na przykład, jeśli wersja agenta to 2.1, to wersja główna to 2, a wersja drugorzędna to 1.
Jeśli Azure DevOps Server ma nowszą wersję agenta, a nowszy agent różni się tylko w wersji pomniejszej, zwykle może być automatycznie zaktualizowany. Należy złożyć żądanie uaktualnienia, gdy funkcja platformy lub jedno z zadań używanych w potoku wymaga nowszej wersji agenta. Począwszy od usługi Azure DevOps Server 2019, nie musisz czekać na nową wersję serwera. Możesz przesłać nową wersję agenta do warstwy aplikacji w twojej aplikacji, a ta wersja jest oferowana jako aktualizacja.
Jeśli agent jest uruchamiany interaktywnie lub nowsza wersja główna agenta jest dostępna, może być konieczne ręczne uaktualnienie agentów. Agenta można łatwo uaktualnić z zakładki Pule agentów w ramach kolekcji projektu. Rurociągi nie mogą działać bez zgodnego agenta.
Możesz wyświetlić wersję agenta. Przejdź do pul agentów i wybierz kartę Możliwości odpowiedniego agenta zgodnie z opisem w temacie Konfigurowanie możliwości agenta.
Aby programowo wyzwolić aktualizację agenta, możesz użyć interfejsu API aktualizacji agenta zgodnie z opisem w sekcji Jak można programowo wyzwalać aktualizacje agenta dla określonej puli agentów?.
W przypadku serwerów bez dostępu do Internetu ręcznie skopiuj plik ZIP agenta do następującego folderu, aby użyć go jako pliku lokalnego. Utwórz folder Agenci , jeśli nie jest obecny:
- Windows:
%ProgramData%\Microsoft\Azure DevOps\Agents - Linux:
usr/share/Microsoft/Azure DevOps/Agents - Macos:
usr/share/Microsoft/Azure DevOps/Agents
Struktura katalogu agenta
Gdy zadania potoku są uruchamiane na agentach, tworzona jest struktura katalogów do przechowywania kodu źródłowego, plików binarnych i artefaktów.
Katalog główny agenta to katalog, w którym jest zainstalowany agent. Katalog jest zwykle zlokalizowany:
-
Agenci hostowani przez firmę Microsoft:
C:\agents\<agent version>w systemie Windows,/Users/runner/runners/<agent version>w systemie macOS i/home/vsts/agents/<agent version>w systemie Linux. -
Agenci self-hosted:
C:\agentna Windows,Users/<username>/agent(~/agent) na macOS i/home/vsts/agentna Linux.
Katalog roboczy agenta zawiera przestrzeń roboczą, w której przechowywane są wyniki źródłowe i zadania. Katalog roboczy jest zwykle zlokalizowany:
-
Agent hostowany przez firmę Microsoft:
C:\aw systemie Windows,/Users/runner/workw systemie macOS i/home/vsts/workw systemie Linux. -
Własny agent:
C:\agent\_workw systemie Windows,~/agent/workw systemie macOS i/home/agent/_workw systemie Linux.
Struktura katalogu roboczego to:
- /work directory
- /1 build directory/pipeline workspace
- /s source/working directory
- /b binaries directory
- /a artifacts staging directory
- /TestResults Test results directory
| Katalog | opis | Przykłady | Wstępnie zdefiniowane zmienne |
|---|---|---|---|
| Katalog główny agenta | Miejsce instalacji agenta. | Agent hostowany przez firmę Microsoft: Windows: C:\agents\3.248.0Linux: /home/vsts/agents/3.248.0Macos: /Users/runner/runners/3.248.0Agent hostowany lokalnie Windows: C:\agentLinux: home/agent Macos: ~/agent |
Agent.HomeDirectory |
| Katalog służbowy | Gdzie agent przechowuje kod źródłowy, pliki binarne i artefakty. | Agent hostowany przez firmę Microsoft: Windows: C:\aLinux: /home/vsts/workMacos: /Users/runner/workAgent hostowany lokalnie Windows: C:\agent\_workLinux: /home/agent/_work Macos: ~/agent/work |
Agent.WorkFolderAgent.RootDirectory System.WorkFolder |
| Budowanie katalogu lub obszaru roboczego | Gdzie działa zadanie potoku. | Agent hostowany przez firmę Microsoft: Windows: C:\a\1Linux: /home/vsts/work/1Macos: /Users/runner/work/1Agent hostowany lokalnie Windows: C:\agent\_work\1Linux: /home/agent/_work/1 Macos: ~/agent/work/1 |
Agent.BuildDirectoryPipeline.Workspace |
s - Źródło lub katalog roboczy |
Zawiera kod źródłowy wyewidencjonowany z repozytorium. Jeśli w zadaniu znajduje się wiele checkout kroków, kod źródłowy jest wyewidencjonowany w katalogach nazwanych na podstawie repozytoriów jako podfolder s. |
Agent hostowany przez firmę Microsoft: Windows: C:\a\1\sLinux: /home/vsts/work/1/sMacos: /Users/runner/work/1/sAgent hostowany lokalnie Windows: C:\agent\_work\1\sLinux: /home/agent/_work/1/s Macos: ~/agent/work/1/s |
Build.SourcesDirectory Build.RepositoryLocalPathSystem.DefaultWorkingDirectory |
b — katalog plików binarnych |
Zawiera dane wyjściowe kompilacji. | Agent hostowany przez firmę Microsoft: Windows: C:\a\1\bLinux: /home/vsts/work/1/bMacos: /Users/runner/work/1/bAgent hostowany lokalnie Windows: C:\agent\_work\1\bLinux: /home/agent/_work/1/bMacos: ~/agent/work/1/b |
Build.BinariesDirectory |
a — katalog tymczasowy artefaktów |
Zawiera artefakty kompilacji. Elementy są czyszczone między przebiegami na serwerach z własnym hostingiem. | Agent hostowany przez firmę Microsoft: Windows: C:\a\1\aLinux: /home/vsts/work/1/aMacos: /Users/runner/work/1/aAgent hostowany lokalnie Windows: C:\agent\_work\1\aLinux: /home/agent/_work/1/a Macos: ~/agent/work/1/a |
Build.StagingDirectoryBuild.ArtifactStagingDirectory System.ArtifactsDirectory |
TestResults katalog |
Zawiera wyniki testu. Elementy są czyszczone między przebiegami na serwerach z własnym hostingiem. | Agent hostowany przez firmę Microsoft: Windows: C:\a\1\TestResultsLinux: /home/vsts/work/1/TestResultsMacos: /Users/runner/work/1/TestResultsAgent hostowany lokalnie Windows: C:\agent\_work\1\TestResultsLinux: /home/agent/_work/1/TestResults Macos: ~/agent/work/1/TestResults |
Common.TestResultsDirectory |
W przypadku agentów hostowanych przez firmę Microsoft inny agent jest używany w każdym uruchomieniu, więc katalog roboczy nie jest zachowywany między uruchomieniami. W przypadku własnych agentów tylko katalog przejściowy artefaktów i katalogi wyników testów są domyślnie czyszczone między przebiegami. Aby uzyskać więcej informacji na temat opcji czyszczenia obszaru roboczego, zobacz Workspace.
Aby uzyskać więcej informacji na temat wstępnie zdefiniowanych zmiennych, zobacz wstępnie zdefiniowane zmienne.
Często zadawane pytania
Jak mogę upewnić się, że mam najnowszą wersję agenta?
Przejdź do zakładki Pule agentów
Wybierz pulę zawierającą agenta.
Upewnij się, że agent jest włączony.
Przejdź do karty możliwości:
Na karcie Pule agentów wybierz wybraną pulę agentów.
Wybierz pozycję Agenci i wybierz żądanego agenta.
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.
Z karty "Pule agentów" wybierz odpowiednią pulę.
Wybierz pozycję Agenci i wybierz żądanego agenta.
Wybierz kartę Możliwości .
Agent.VersionPoszukaj możliwości. Tę wartość można porównać z najnowszą opublikowaną wersją agenta na stronie Agent usługi Azure Pipelines .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ę, a następnie 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 pakietów agenta na dysku lokalnym. Ta konfiguracja zastępuje 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.
Z komputera z dostępem do Internetu pobierz najnowszą wersję plików pakietu agenta (w formacie .zip lub .tar.gz) ze strony wydania agenta Azure Pipelines na GitHub.
Przenieś pobrane pliki pakietu do każdej warstwy aplikacji serwera Usługi Azure DevOps przy użyciu wybranej metody (na przykład dysku USB, transferu sieciowego itd.). Umieść pliki agenta w folderze
%ProgramData%\Microsoft\Azure DevOps\Agents. Jeśli nie ma folderu z etykietą Agenci, utwórz go.Wszystko gotowe! Serwer Usługi Azure DevOps używa teraz 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.
Czy agenci hostowani samodzielnie mają jakiekolwiek korzyści w zakresie wydajności w stosunku do agentów hostowanych przez firmę Microsoft?
W wielu przypadkach tak. Jeśli używasz własnego agenta, możesz uruchamiać kompilacje przyrostowe. Jeśli na przykład zdefiniujesz potok zadań, który nie czyści repozytorium i nie wykonuje czystej kompilacji, kompilacje zwykle działają szybciej. Nie uzyskujesz tych korzyści z agenta hostowanego przez firmę Microsoft, chyba że używasz funkcji takich jak buforowanie, ponieważ agent zostanie zniszczony po zakończeniu potoku.
Uruchomienie kompilacji przez agenta hostowanego przez firmę Microsoft może potrwać dłużej. Chociaż zadanie przydzielone do agenta hostowanego przez firmę Microsoft często trwa kilka sekund, czasami może upłynąć kilka minut, aby agent został przydzielony, w zależności od obciążenia systemu.
Czy mogę zainstalować kilka samodzielnie hostowanych agentów na tej samej maszynie?
Tak. Takie podejście może działać dobrze w przypadku agentów, którzy uruchamiają zadania, które nie korzystają z wielu udostępnionych zasobów. Możesz na przykład wypróbować to dla agentów, które uruchamiają wydania, w większości organizujące wdrożenia i nie wymagające zbyt wiele pracy nad samym agentem.
Może się okazać, że w innych przypadkach nie zyskujesz większej wydajności, uruchamiając wielu agentów na tym samym komputerze. Może to nie być na przykład opłacalne dla agentów, którzy uruchamiają kompilacje, które zużywają dużo miejsca na dysku i zasobów wejściowych/wyjściowych.
Mogą również wystąpić problemy, jeśli równoległe zadania kompilacji korzystają z tej samej instancji narzędzia singleton (na przykład pakietów npm). Jedna kompilacja może zaktualizować zależność, gdy inna kompilacja używa jej, co może spowodować zawodne wyniki i błędy.
Co robią agenci, gdy zadania w kanale przetwarzania są anulowane?
W przypadku agentów hostowanych przez firmę Microsoft agent jest usuwany i zwracany do puli usługi Azure Pipelines.
"W przypadku agentów hostowanych lokalnie:"
- Po zatrzymaniu potoku agent przekazuje sekwencję poleceń do procesu, który wykonuje aktualny krok.
- Pierwsze polecenie jest wysyłane z limitem czasu 7,5 sekundy.
- Jeśli proces nie zakończy się, drugie polecenie zostanie wysłane z limitem czasu 2,5 sekundy.
- Jeśli proces nie zakończy się, agent wyda polecenie jego zakończenia.
- Jeśli proces ignoruje dwa początkowe żądania zakończenia, zostanie wymuszone.
Czas od początkowego żądania do zakończenia wynosi około 10 sekund.
Polecenia wydane dla procesu anulowania potoku różnią się w zależności od systemu operacyjnego agenta:
- macOS i Linux: wysyłane polecenia to
SIGINT, a następnieSIGTERM, a następnieSIGKILL. - Windows: polecenia wysyłane do procesu to
Ctrl+C, a następnieCtrl+Break, a następnieProcess.Kill.
Jak programowo wyzwalać aktualizacje agenta dla określonej puli agentów?
Aktualizacje agenta dla puli można zainicjować za pomocą następującego API:
POST https://dev.azure.com/{organization}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0
POST https://{server url}/tfs/{collection}/_apis/distributedtask/pools/{poolId}/messages?agentId={agentId}&api-version=6.0
Uwaga
Aby uzyskać więcej informacji, zobacz Api and Azure DevOps Server version mapping (Mapowanie wersji usługi Azure DevOps Server).
Parametry identyfikatora URI
| Nazwisko | W | Wymagane | Typ | opis |
|---|---|---|---|---|
agentId |
kwerenda | False |
ciąg | Agent do aktualizacji. Jeśli nie jest określone, zostanie uruchomiona aktualizacja dla wszystkich agentów. |
organization |
ścieżka | True |
ciąg | Nazwa organizacji usługi Azure DevOps. |
poolId |
ścieżka | True |
liczba całkowita int32 | Zestaw agentów do użycia. |
api-version |
kwerenda | False |
ciąg | Wersja interfejsu API do użycia. Aby użyć tej wersji interfejsu API, należy ustawić wartość na 6.0. |
Aby uruchomić aktualizację agenta, treść żądania musi być pusta.
Agent usługi Azure Pipelines jest oprogramowaniem open source w usłudze GitHub.
Treści powiązane
Aby uzyskać więcej informacji na temat agentów, zobacz następujące moduły ze ścieżki szkoleniowej Tworzenie aplikacji za pomocą usługi Azure DevOps :