Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Można skonfigurować agentów zarządzanych pul DevOps do uruchamiania w izolowanej sieci wirtualnej lub w istniejącej sieci wirtualnej. W tym artykule opisano sposób konfigurowania puli do uruchamiania agentów w sieci wirtualnej.
Wybierz typ sieci
Zarządzane pule DevOps obsługują dwa typy konfiguracji sieci:
- Izolowana sieć wirtualna: każda pula pobiera własną izolaną sieć wirtualną utworzoną i zarządzaną przez usługę Managed DevOps Pools.
-
Agenci wstrzyknięci do istniejącej sieci wirtualnej: możesz wprowadzić własną sieć wirtualną i podsieć. Wszystkie maszyny wirtualne utworzone dla puli będą używać tej podsieci, a żadne inne zasoby nie będą mogły korzystać z podsieci. Możesz dodać agentów z zarządzanych pul DevOps do własnej sieci wirtualnej w scenariuszach, takich jak:
- Agenci ciągłej integracji i ciągłego dostarczania (CI/CD) muszą uzyskiwać dostęp do zasobów, które są dostępne tylko w sieci firmowej za pośrednictwem usługi, takiej jak Azure ExpressRoute.
- Agenci ciągłej integracji/ciągłego wdrażania muszą uzyskiwać dostęp do zasobów, które są ograniczone do prywatnych końcowych punktów dostępu.
- Chcesz odizolować sieciowo infrastrukturę ciągłej integracji/ciągłego wdrażania poprzez stworzenie własnej sieci wirtualnej z regułami zapory dostosowanymi do potrzeb firmy.
- Wszystkie inne unikalne przypadki użycia, których nie można osiągnąć za pomocą standardowych funkcji sieciowych w zarządzanych pulach DevOps.
Izolowana sieć wirtualna
Domyślnie wszystkie pule używają sieci wirtualnej udostępnianej przez firmę Microsoft, która ogranicza cały ruch przychodzący i ma następujące opcje konfiguracji ruchu wychodzącego.
- Domyślna łączność dostępu wychodzącego jest bieżącą wartością domyślną, która zezwala na cały ruch wychodzący przy użyciu adresu IP dostarczonego przez firmę Microsoft. Domyślny dostęp wychodzący dla maszyn wirtualnych na platformie Azure ma zostać wycofany. Po wycofaniu domyślnego dostępu wychodzącego pule będą domyślnie konfigurowane przy użyciu jednego statycznego adresu IP.
- Zamiast używać domyślnego dostępu wychodzącego, możesz skonfigurować pulę tak, aby używała maksymalnie 16 statycznych wychodzących adresów IP. Zarządzane Pule DevOps utworzą bramę translatora adresów sieciowych w tym samym regionie co twoja pula w celu udostępnienia adresów IP. Ta konfiguracja umożliwia dodanie określonych adresów IP do listy dozwolonych w usługach zewnętrznych, do których potoki muszą uzyskiwać dostęp.
- Brama NAT wiąże się z dodatkowymi kosztami platformy Azure. Możesz modelować, ile będzie kosztować, korzystając z kalkulatora kosztów platformy Azure. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure NAT Gateway.
Ważne
Jeśli zmodyfikujesz liczbę statycznych adresów IP po utworzeniu puli, adresy IP podlegają zmianie i po zakończeniu operacji aktualizacji należy uzyskać nowe adresy IP i zaktualizować listę dozwolonych w usługach zewnętrznych.
Aby skonfigurować ustawienia adresów IP podczas tworzenia puli, przejdź do karty Sieć . Aby zaktualizować istniejącą pulę, przejdź do pozycji Ustawienia>Sieć.
Wybierz pozycję Brak dla opcji Routing za pośrednictwem publicznych adresów IP , aby użyć domyślnego dostępu wychodzącego.
Wybierz pozycję Adresy IP udostępnione przez firmę Microsoft , aby skonfigurować statyczne adresy IP ruchu wychodzącego i określić liczbę statycznych adresów IP, których chcesz użyć. Zarządzane pule DevOps tworzą bramę NAT i zarządzają adresami IP.
Uwaga / Notatka
Istnieje znany problem: jeśli pula jest skonfigurowana przy użyciu tożsamości zarządzanej, wywołania interfejsu API nie zwracają ipAddresses właściwości, chyba że jednostka usługi DevOpsInfrastructure ma przypisaną rolę Operator Tożsamości Zarządzanej. Aby uzyskać szczegółowe instrukcje, zobacz Przypisywanie ról platformy Azure przy użyciu witryny Azure Portal.
Przyznanie tej roli nie jest wymagane, aby statyczne adresy IP stały się funkcjonalne. Bez tego przypisania roli nadal można znaleźć przypisane adresy IP, wyświetlając je na stronie Sieć w witrynie Azure Portal.
Agenty wprowadzane do istniejącej sieci wirtualnej
Agentów puli można skonfigurować do korzystania z sieci wirtualnej, wykonując następujące kroki:
- Utwórz lub przełącz sieć wirtualną i podsieć.
-
Deleguj podsieć do
Microsoft.DevOpsInfrastructure/pools. - Skojarz podsieć z pulą.
Poprzednie kroki delegowały podsieć do wyłącznego dostępu przez pulę. Inne pule lub zasoby nie mogą używać podsieci.
Pula może używać wielu podsieci do łączenia wielu pul z tą samą siecią wirtualną. Każda podsieć jest delegowana i skojarzona z własną pulą.
Tworzenie lub przenoszenie sieci wirtualnej i podsieci
Podsieć musi mieć wystarczającą przestrzeń adresową, aby pomieścić maksymalny rozmiar puli, którą chcesz skojarzyć (w tym pięć adresów IP, które Azure rezerwuje w podsieci).
Jeśli używasz usługi ExpressRoute, musisz zezwolić na zapisy przez tymczasowe usunięcie lub zmianę blokady zarządzania w grupie zasobów.
Ważne
Pula i sieć wirtualna muszą znajdować się w tym samym regionie. W przeciwnym razie, podczas próby utworzenia puli lub aktualizacji konfiguracji sieci, pojawi się błąd podobny do: "Sieć wirtualna MDPVN znajduje się w regionie 'eastus', ale pula 'mdpnonprodsub' znajduje się w regionie 'australiaeast'. Muszą one znajdować się w tym samym regionie.
Udzielanie dostępu czytelnikowi i współautorowi sieci do jednostki usługi DevOpsInfrastructure
Upewnij się, że podmiot zabezpieczeń DevOpsInfrastructure ma dostęp typu Reader oraz Network Contributor do sieci wirtualnej.
Zamiast korzystać z wbudowanych ról, można utworzyć rolę niestandardową, która ma następujące uprawnienia:
Microsoft.Network/virtualNetworks/*/readMicrosoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/actionMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/writeMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/delete
Utwórz rolę niestandardową dla dostępu do połączenia Skojarzenia Usługi. Przykładową rolę można utworzyć na poziomie grupy zasobów lub subskrypcji na karcie Kontrola dostępu , jak pokazano w poniższym przykładzie.
Sprawdź główne uprawnienia dla DevOpsInfrastructure
Wybierz pozycję Kontrola dostępu (Zarządzanie dostępem i tożsamościami) dla sieci wirtualnej, a następnie wybierz pozycję Sprawdź dostęp.
Wyszukaj i wybierz DevOpsInfrastructure.
Sprawdź, czy masz dostęp na poziomie czytelnika . Sprawdź, czy przypisano dostęp do
Microsoft.Network/virtualNetworks/subnets/join/action,Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/actioniMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write. W tym miejscu powinna zostać wyświetlona rola niestandardowa.
Jeśli jednostka DevOpsInfrastructure nie ma tych uprawnień, dodaj je. Wybierz pozycję Kontrola dostępu (Zarządzanie dostępem i tożsamościami) dla sieci wirtualnej, a następnie wybierz pozycję Udziel dostępu do tego zasobu.
Deleguj podsieć do Microsoft.DevOpsInfrastructure/pools
W portalu otwórz właściwości podsieci i wybierz pozycję Microsoft.DevOpsInfrastructure/pools w Delegowanie podsieci. Wybierz Zapisz.
Ten proces deleguje podsieć w celu uzyskania wyłącznego dostępu do puli. Inne pule lub zasoby nie mogą używać podsieci. Aby połączyć wiele pul z tą samą siecią wirtualną, należy użyć wielu podsieci. Każda podsieć musi być delegowana i skojarzona z własną pulą. Więcej informacji na temat delegowania podsieci można znaleźć w tym omówieniu delegowania podsieci.
Po delegowaniu podsieci do Microsoft.DevOpsInfrastructure/poolsprogramu można zaktualizować pulę, aby korzystała z podsieci.
Połącz podsieć z pulą
Aby utworzyć nową pulę, przejdź do karty Sieć. Aby zaktualizować istniejącą pulę, przejdź do pozycji Ustawienia>Sieć, a następnie wybierz pozycję Agenci wstrzykiwani do istniejącej sieci> wirtualnejKonfiguruj.
Wybierz wartości Subskrypcja, Sieć wirtualna i Podsieć delegowane do
Microsoft.DevOpsInfrastructure/poolsusługi , a następnie wybierz przycisk OK.
Po zakończeniu aktualizacji sieci nowo utworzony zasób w puli będzie korzystał z delegowanej podsieci.
Ważne
Nie umieszczaj blokady Usuń w sieci wirtualnej podczas aktualizowania pul. Podczas operacji aktualizacji puli, Zarządzane pule DevOps tworzą łącze powiązania usługi w podsieci. Jeśli aktualizacja nie powiedzie się, zarządzana pula DevOps spróbuje wyczyścić skrócone skojarzenie usługi, ale jeśli istnieje blokada Usuwania, otrzymasz błąd InUseSubnetCannotBeDeleted. Zarządzane Pule DevOps nie mogą usunąć łącza skojarzonego z usługą, co pozostawia podsieć w stanie zablokowanym (nie można jej usunąć). Aby rozwiązać ten problem, usuń blokadę Usuń i ponów próbę wykonania operacji aktualizacji.
Aby uzyskać więcej informacji, zobacz Co należy wziąć pod uwagę przed zastosowaniem blokad do zasobów platformy Azure.
Ograniczanie łączności wychodzącej
Jeśli masz systemy w sieci (na przykład sieciowe grupy zabezpieczeń lub zapory), które ograniczają łączność wychodzącą, musisz dodać określone punkty końcowe do listy dozwolonych, aby w pełni obsługiwać zarządzane pule DevOps. Te punkty końcowe są podzielone na globalnie wymagane punkty końcowe (niezbędne na dowolnej maszynie przy użyciu zarządzanych pul DevOps) i punkty końcowe potrzebne w niektórych scenariuszach. Wszystkie punkty końcowe to HTTPS, chyba że określono inaczej.
Wymagane punkty końcowe do uruchamiania zarządzanych pul DevOps
Jeśli nie dodasz tych punktów końcowych do listy dozwolonych, maszyny nie będą w trybie online w ramach usługi Zarządzane pule DevOps i nie można uruchamiać potoków w puli:
-
*.prod.manageddevops.microsoft.com: punkt końcowy zarządzanych pul DevOps używany do komunikowania się z usługą Zarządzanych pul DevOps. -
rmprodbuilds.azureedge.net: Służy do pobierania plików binarnych i skryptów uruchamiania dla zarządzanych pul DevOps. Część bibliotek agenta roboczego jest pobierana zrm-agent.prod.manageddevops.microsoft.com(wcześniej pobierana zagent.prod.manageddevops.microsoft.com), który jest objęty poprzednim wymaganym zgłoszeniem*.prod.manageddevops.microsoft.com. -
*.queue.core.windows.net: kolejka zadań roboczych do komunikacji z zarządzanymi pulami DevOps.
Wymagane punkty końcowe do nawiązywania połączenia z usługą Azure DevOps
Jeśli nie dodasz tych punktów końcowych do listy dozwolonych, maszyny mogą przejść do trybu online, a nawet przejść do przydzielonego stanu, ale nie można nawiązać komunikacji z usługą Azure DevOps Services, ponieważ agent zadań usługi Azure DevOps Services nie może nawiązać połączenia lub nie można go uruchomić.
-
download.agent.dev.azure.com: Lokalizacja sieci dostarczania zawartości (CDN) agenta usługi Azure DevOps używana do pobierania agenta usługi Azure DevOps (dawniejvstsagentpackage.azureedge.net; aby uzyskać więcej informacji, zobacz Edgio CDN for Azure DevOps jest wycofywana). -
dev.azure.com: wymagane do obsługi komunikacji z usługą Azure DevOps.
Wymagane punkty końcowe dla maszyn z systemem Linux
Te punkty końcowe są wymagane do uruchamiania maszyn z systemem Ubuntu, ale nie są konieczne, jeśli pula korzysta tylko z systemu Windows. Po skonfigurowaniu agenta zadań usługi Azure DevOps dodawane są wymagane pakiety i uruchamiane jest polecenie apt-get. Ten proces kończy się niepowodzeniem, jeśli następujące punkty końcowe nie są dodawane do listy dozwolonych.
-
azure.archive.ubuntu.com: Aprowizowanie maszyn z systemem Linux. Ten punkt końcowy to HTTP (port 80), a nie HTTPS (port 443). -
www.microsoft.com: Aprowizowanie maszyn z systemem Linux. -
security.ubuntu.com: Aprowizowanie maszyn z systemem Linux. -
packages.microsoft.com: Aprowizowanie maszyn z systemem Linux. -
ppa.launchpad.net: Wdrażanie wybranych dystrybucji systemu Linux. -
dl.fedoraproject.org: Konfigurowanie niektórych dystrybucji systemu Linux.
Wymagane punkty końcowe dla niektórych funkcji usługi Azure DevOps
Te opcjonalne punkty końcowe są wymagane, aby określone funkcje usługi Azure DevOps działały w potokach. W poniższym zestawie symbol wieloznaczny można zastąpić określoną organizacją Azure DevOps hostującą potok. Jeśli na przykład organizacja ma nazwę contoso, możesz użyć polecenia contoso.services.visualstudio.com zamiast *.services.visualstudio.com.
*.services.visualstudio.com-
*.vsblob.visualstudio.com: używany do przesyłania i używania artefaktów. -
*.vssps.visualstudio.com: służy do uwierzytelniania za pomocą usługi Azure DevOps w przypadku niektórych funkcji. *.visualstudio.com
Uwaga / Notatka
Powyższe wpisy są minimalnymi wymaganymi domenami. Jeśli masz jakiekolwiek problemy, zapoznaj się z pełną listą wymaganych domen w temacie Dozwolone adresy IP i adresy URL domen usługi Azure DevOps.
Punkty końcowe związane z platformą Azure
Maszyny wirtualne platformy Azure mogą kierować ruch do niektórych funkcji platformy Azure za pośrednictwem podsieci. W przypadku tych żądań możesz kierować żądania bezpośrednio za pośrednictwem platformy Azure lub włączyć dostęp za pośrednictwem sieci.
Skonfiguruj ruch Azure, aby przebiegał przez punkty końcowe usługi:
Możesz kierować ruch bezpośrednio przez platformę Azure, aby uniknąć dodawania przepływności do sieciowych grup zabezpieczeń lub zapór. Nie musisz dodawać domen wymienionych w poniższej opcji do listy dozwolonych.
Możesz na przykład użyć funkcji dysku danych , aby zaangażować wywołania sieciowe do usługi Azure Storage. Po włączeniu punktu końcowego usługi Microsoft.Storage w sieci ruch jest kierowany bezpośrednio przez platformę Azure, co pozwala uniknąć reguł sieci i zmniejszyć obciążenie.
Aby uniknąć routingu ruchu za pośrednictwem punktów końcowych usługi, dodaj domenę
md-*.blob.storage.azure.netdo listy dozwolonych. Ta domena jest wymagana do konfigurowania dysku danych.
Adresy IP dostarczania usługi Akamai CDN
1 maja 2025 r. zasoby usługi Azure DevOps CDN zostały zastąpione rozwiązaniem obsługiwanym przez usługę Akamai i usługę Azure Front Door. Upewnij się, że sieć ma dostęp wychodzący do zakresów adresów IP usługi Akamai. Aby uzyskać więcej informacji, zobacz:
- Zmiana adresu URL domeny usługi CDN dla agentów w potokach
- FAQ dotyczące wycofania Azure CDN od Edgio
- Akamai TechDocs: Lista kontroli dostępu do adresów IP pochodzenia
Jeśli skonfigurujesz potok usługi Azure DevOps do uruchomienia wewnątrz kontenera, musisz również dodać źródło obrazu kontenera (Docker lub Azure Container Registry) do listy dozwolonych.
Weryfikowanie łączności punktu końcowego
Upewnij się, że możesz użyć podsieci z Managed DevOps Pools, uruchamiając następujący skrypt na zasobie w tej podsieci. Ten krok ułatwi sprawdzenie, czy przepływ sieciowy jest skonfigurowany tak, aby dotarł do wszystkich dostępnych punktów końcowych i zarządzanej płaszczyzny sterowania DevOps.
Ważne
Aby sprawdzić, czy ścieżka sieciowa jest otwarta z tej podsieci do wymaganych punktów końcowych, musisz uruchomić ten skrypt w zasobie w podsieci (np. maszynie wirtualnej lub kontenerze).
Aby uruchomić skrypt za pomocą programu PowerShell Core lub programu PowerShell 5 lub nowszego, zapisz następujący skrypt jako ValidateMDPEndpoints.ps1. Uruchom następujące polecenie programu PowerShell: .\ValidateMDPEndpoints.ps1 -organization "<your-organization>".
# ValidateMDPEndpoints.ps1
param (
[string]$organization
)
$azureDevOpsUris = @(
"https://dev.azure.com",
"https://vssps.dev.azure.com",
"https://vsrm.dev.azure.com",
"https://management.azure.com",
"https://login.microsoftonline.com",
"https://graph.microsoft.com",
"https://aadcdn.msftauth.net",
"https://${organization}.visualstudio.com",
"https://${organization}.vsrm.visualstudio.com",
"https://${organization}.vstmr.visualstudio.com",
"https://${organization}.pkgs.visualstudio.com",
"https://${organization}.vssps.visualstudio.com",
"https://download.agent.dev.azure.com",
"download.agent.dev.azure.com"
)
$managedDevOpsPoolsControlPlaneUris = @(
# List of agent queue endpoints - maps to *.queue.core.windows.net
"https://rmprodaedefaultcq.queue.core.windows.net",
"https://rmprodbrsdefaultcq.queue.core.windows.net",
"https://rmprodcncdefaultcq.queue.core.windows.net",
"https://rmprodcusdefaultcq.queue.core.windows.net",
"https://rmprodeus2defaultcq.queue.core.windows.net",
"https://rmprodgwcdefaultcq.queue.core.windows.net",
"https://rmprodincdefaultcq.queue.core.windows.net",
"https://rmprodneudefaultcq.queue.core.windows.net",
"https://rmprodseadefaultcq.queue.core.windows.net",
"https://rmprodszndefaultcq.queue.core.windows.net",
"https://rmproduksdefaultcq.queue.core.windows.net",
"https://rmprodwus3defaultcq.queue.core.windows.net",
# CDN for downloading the Managed DevOps Pools agent - maps to *.prod.managedevops.microsoft.com
"rm-agent.prod.manageddevops.microsoft.com"
# List of control plane endpoints - maps to *.manageddevops.microsoft.com
"default.ae.prod.manageddevops.microsoft.com",
"default.brs.prod.manageddevops.microsoft.com",
"default.cnc.prod.manageddevops.microsoft.com",
"default.cus.prod.manageddevops.microsoft.com",
"default.eus2.prod.manageddevops.microsoft.com",
"default.gwc.prod.manageddevops.microsoft.com",
"default.inc.prod.manageddevops.microsoft.com",
"default.neu.prod.manageddevops.microsoft.com",
"default.sea.prod.manageddevops.microsoft.com",
"default.szn.prod.manageddevops.microsoft.com",
"default.uks.prod.manageddevops.microsoft.com",
"default.wus3.prod.manageddevops.microsoft.com"
)
$unreachableUris = @()
foreach ($uri in $azureDevOpsUris) {
try {
$hostName = ($uri -replace "^https?://", "") -replace "/.*", ""
$connection = Test-NetConnection -ComputerName $hostName -Port 443 -WarningAction SilentlyContinue
if (-not $connection.TcpTestSucceeded) {
$unreachableUris += $uri
}
} catch {
$unreachableUris += $uri
}
}
if ($unreachableUris.Count -eq 0) {
Write-Output "All Azure DevOps endpoints are reachable."
} else {
Write-Output "The following Azure DevOps endpoints could not be reached:"
$unreachableUris | ForEach-Object { Write-Output $_ }
}
foreach ($uri in $managedDevOpsPoolsControlPlaneUris) {
try {
$hostName = ($uri -replace "^https?://", "") -replace "/.*", ""
$connection = Test-NetConnection -ComputerName $hostName -Port 443 -WarningAction SilentlyContinue
if (-not $connection.TcpTestSucceeded) {
$unreachableUris += $uri
}
} catch {
$unreachableUris += $uri
}
}
if ($unreachableUris.Count -eq 0) {
Write-Output "All Azure Managed DevOps Pools endpoints are reachable."
} else {
Write-Output "The following Managed DevOps Pools endpoints could not be reached:"
$unreachableUris | ForEach-Object { Write-Output $_ }
}
Skonfiguruj agenta Azure DevOps do działania za serwerem proxy
Jeśli skonfigurowano usługę proxy na obrazie i chcesz, aby obciążenia uruchamiane w puli działały za tym serwerem proxy, należy dodać następujące zmienne środowiskowe na obrazie:
-
VSTS_AGENT_INPUT_PROXYURL: adres URL skonfigurowanego serwera proxy, za którym działa usługa. -
VSTS_AGENT_INPUT_PROXYUSERNAME: nazwa użytkownika wymagana do korzystania z serwera proxy. -
VSTS_AGENT_INPUT_PROXYPASSWORD: hasło do korzystania z serwera proxy.
W przypadku systemu Windows te zmienne środowiskowe powinny być zmiennymi środowiskowymi systemu. W przypadku systemu Linux te zmienne powinny znajdować się w /etc/environment pliku . Jeśli te zmienne systemowe są niepoprawnie ustawione lub bez skonfigurowanej usługi proxy na obrazie, aprowizowanie nowych agentów nie powiedzie się z powodu problemów z łącznością sieciową.
Jeśli przeprowadzasz migrację z agentów Azure Virtual Machine Scale Sets i używasz już zmiennych środowiskowych proxy na obrazie, nie musisz wprowadzać żadnych zmian. Ten proces jest opisany w temacie Agenci zestawu skalowania maszyn wirtualnych platformy Azure: Dostosowywanie konfiguracji agenta potoku.