Konfigurowanie sieci zarządzanych pul DevOps
Agenci zarządzanych pul DevOps można skonfigurować do uruchamiania w izolowanej sieci wirtualnej lub w istniejącej sieci wirtualnej. W tym artykule opisano sposób konfigurowania zarządzanej puli DevOps do uruchamiania agentów w sieci wirtualnej.
Dodawanie agentów do własnej sieci wirtualnej
Możesz dodać agentów z zarządzanych pul DevOps do własnej sieci wirtualnej w scenariuszach, takich jak:
- Agenci ciągłej integracji/ciągłego wdrażania muszą uzyskiwać dostęp do zasobów, które są dostępne tylko w sieci firmowej za pośrednictwem usługi, takiej jak Express Route
- Agenci ciągłej integracji/ciągłego wdrażania muszą uzyskiwać dostęp do zasobów odizolowanych od prywatnych punktów końcowych
- Chcesz odizolować infrastrukturę ciągłej integracji/ciągłego wdrażania w sieci, wprowadzając własną sieć wirtualną z regułami zapory specyficznymi dla firmy
- Inne unikatowe przypadki użycia, których nie można osiągnąć za pomocą wbudowanych funkcji związanych z siecią zarządzanych pul DevOps
Agentów puli można dodać do sieci wirtualnej, wykonując następujące kroki.
- Tworzenie lub przenoszenie sieci wirtualnej i podsieci
- Delegowanie podsieci do elementu Microsoft.DevOpsInfrastructure/pools
- Kojarzenie podsieci z zarządzaną pulą DevOps
Poprzednie kroki delegować podsieć w celu uzyskania wyłącznego dostępu przez pulę, a podsieć nie może być używana przez inne pule ani zasoby. Aby połączyć wiele pul z tą samą siecią wirtualną, można użyć wielu podsieci, z których każdy jest delegowany i skojarzony 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ć (uwzględnij 5 adresów IP rezerw platformy Azure w podsieci). Jeśli używasz usługi Express Route, musisz tymczasowo usunąć lub zmienić blokadę zarządzania w grupie zasobów, aby zezwolić na zapisy.
Ważne
Zarządzana pula DevOps i sieć wirtualna muszą znajdować się w tym samym regionie lub podczas próby utworzenia puli lub zaktualizowania konfiguracji sieci wystąpi błąd podobny do poniższego. Virtual network MDPVN is in region eastus, but pool mdpnonprodsub is in region australiaeast. These must be in the same region.
Udzielanie dostępu czytelnika i współautora sieci do jednostki usługi DevOpsInfrastructure
Upewnij się, że jednostka devOpsInfrastructure ma następujący dostęp w sieci wirtualnej:
Reader
iNetwork Contributor
- Możesz też dodać następujące uprawnienie do roli niestandardowej:
Microsoft.Network/virtualNetworks/*/read
Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action
Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write
Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/delete
Utwórz rolę niestandardową dla dostępu linku 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.
Aby sprawdzić dostęp podmiotu zabezpieczeń 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 pozycję DevOpsInfrastructure i wybierz ją.
Zweryfikuj dostęp czytelnika . Sprawdź, czy
Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action
jest przypisany dostęp iMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write
. W tym miejscu powinna zostać wyświetlona rola niestandardowa.Jeśli usługa DevOpsInfrastructure nie ma tych uprawnień, dodaj je, wybierając pozycję Kontrola dostępu (IAM) dla sieci wirtualnej, a następnie wybierz pozycję Udziel dostępu do tego zasobu i dodaj je.
Delegowanie podsieci do elementu Microsoft.DevOpsInfrastructure/pools
Do użycia należy delegować podsieć Microsoft.DevOpsInfrastructure/pools
.
Otwórz właściwości podsieci w portalu i wybierz pozycję Microsoft.DevOpsInfrastructure/pools
W sekcji Delegowanie podsieci i wybierz pozycję Zapisz.
To deleguje podsieć w celu uzyskania wyłącznego dostępu do puli, a podsieć nie może być używana przez inne pule ani zasoby. Aby połączyć wiele pul z tą samą siecią wirtualną, należy użyć wielu podsieci, z których każdy jest delegowany i skojarzony z własną pulą. Więcej informacji na temat delegowania podsieci można znaleźć tutaj.
Po delegowaniu podsieci do Microsoft.DevOpsInfrastructure/pools
programu można zaktualizować pulę w celu korzystania z podsieci.
Kojarzenie podsieci z zarządzaną pulą DevOps
Jeśli tworzysz 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 wirtualnej, Skonfiguruj.
Wybierz subskrypcję, sieć wirtualną i podsieć delegowana do
Microsoft.DevOpsInfrastructure/pools
usługi , a następnie wybierz przycisk OK.
Po zakończeniu aktualizacji sieciowej nowo utworzony zasób w puli będzie używać delegowanej podsieci.
Ograniczanie łączności wychodzącej
Jeśli masz systemy w sieci (sieciowa grupa zabezpieczeń, zapora itp.), które ograniczają łączność wychodzącą, musisz upewnić się, że dostęp do następujących domen będzie można uzyskać, w przeciwnym razie zarządzana pula DevOps nie będzie działać. Wszystkie z nich to HTTPS, chyba że określono inaczej.
- Wysoce bezpieczne punkty końcowe, od których zależy nasza usługa:
*.prod.manageddevops.microsoft.com
— Punkt końcowy zarządzanych pul DevOpsrmprodbuilds.azureedge.net
— Pliki binarne procesów roboczychvstsagentpackage.azureedge.net
— Lokalizacja usługi CDN agenta usługi Azure DevOps*.queue.core.windows.net
— Kolejka procesów roboczych do komunikowania się z usługą Zarządzanych pul DevOpsserver.pipe.aria.microsoft.com
— Typowe rozwiązanie telemetrii po stronie klienta (i używane między innymi przez rozszerzenie weryfikacji puli agentów)azure.archive.ubuntu.com
- Aprowizowanie maszyn z systemem Linux — jest to protokół HTTP, a nie HTTPSwww.microsoft.com
- Aprowizowanie maszyn z systemem Linux
- Mniej bezpieczne, bardziej otwarte punkty końcowe, od których zależy nasza usługa:
- Wymagane przez naszą usługę:
packages.microsoft.com
- Aprowizowanie maszyn z systemem Linuxppa.launchpad.net
— Aprowizowanie maszyn z systemem Ubuntudl.fedoraproject.org
- Aprowizowanie niektórych dystrybucji systemu Linux
- Wymagane przez agenta usługi Azure DevOps:
dev.azure.com
*.services.visualstudio.com
*.vsblob.visualstudio.com
*.vssps.visualstudio.com
*.visualstudio.com
Te wpisy są minimalnymi wymaganymi domenami. Jeśli masz jakiekolwiek problemy, zobacz Lista dozwolonych usługi Azure DevOps, aby uzyskać pełną listę wymaganych domen.
- Wymagane przez naszą usługę:
Jeśli skonfigurujesz potok usługi Azure DevOps do uruchamiania wewnątrz kontenera, musisz również dodać źródło obrazu kontenera (Docker lub ACR).
Konfigurowanie agenta usługi Azure DevOps do uruchamiania za serwerem proxy
Jeśli skonfigurowano usługę proxy na obrazie i chcesz, aby obciążenia uruchomione w puli zarządzanych devOps 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 do uruchomienia zaVSTS_AGENT_INPUT_PROXYUSERNAME
— Nazwa użytkownika wymagana do korzystania z serwera proxyVSTS_AGENT_INPUT_PROXYPASSWORD
- Hasło do korzystania z serwera proxy.
W przypadku systemu Windows te zmienne środowiskowe powinny być zmiennymi środowiskowymi systemu, a w przypadku systemu Linux te zmienne powinny znajdować się w pliku /etc/environment . Ustawienie tych zmiennych systemowych niepoprawnie lub bez skonfigurowanej usługi serwera proxy na obrazie powoduje niepowodzenie aprowizacji nowych agentów z problemami z łącznością sieciową.
Jeśli przeprowadzasz migrację z agentów zestawu skalowania maszyn wirtualnych platformy Azure i używasz już zmiennych środowiskowych serwera proxy na obrazie, zgodnie z opisem w temacie Agenci zestawu skalowania maszyn wirtualnych platformy Azure — dostosowywanie konfiguracji agenta potoku nie powinno być wymagane.