Konfigurowanie sieci zarządzanych pul DevOps

Artykuł
12/20/2024

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 i Network 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.

Zrzut ekranu przedstawiający uprawnienia roli niestandardowej.

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/actionMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action jest przypisany dostęp i Microsoft.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.

Zrzut ekranu przedstawiający konfigurowanie delegowania podsieci.

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/poolsprogramu 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 usługi , a następnie wybierz przycisk OK.Microsoft.DevOpsInfrastructure/pools

Po zakończeniu aktualizacji sieciowej nowo utworzony zasób w puli będzie używać delegowanej podsieci.

Jeśli używasz szablonów usługi ARM, dodaj networkProfile właściwość, jeśli jeszcze nie istnieje, a następnie dodaj subnetId właściwość pod networkProfile identyfikatorem zasobu podsieci.

{
    "name": "MyManagedDevOpsPool",
    "type": "Microsoft.DevOpsInfrastructure/pools",
    "apiVersion": "2024-10-19",
    "location": "eastus",
    "properties": {
        ...
        "networkProfile": {
          "subnetId":"/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetwork/subnets/mySubnet",
        }
        ...
    }
}

Sieć jest konfigurowana przy użyciu networkProfile właściwości w fabricProfile sekcji podczas tworzenia lub aktualizowania puli. W przypadku izolowanej sieci pomiń networkProfile właściwość podczas tworzenia puli.

az mdp pool create \
   --fabric-profile fabric-profile.json
   # other parameters omitted for space

Poniższy przykład przedstawia sekcję networkProfilepliku fabric-profile.json .

{
  "vmss": {
    "sku": {...},
    "images": [...],
    "osProfile": {...},
    "storageProfile": {...},
    "networkProfile": {
        "subnetId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetwork/subnets/mySubnet"
    }
  }
}

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 DevOps
- rmprodbuilds.azureedge.net — Pliki binarne procesów roboczych
- vstsagentpackage.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 DevOps
- server.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 HTTPS
- www.microsoft.com - Aprowizowanie maszyn z systemem Linux
- security.ubuntu.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 Linux
  - ppa.launchpad.net — Aprowizowanie maszyn z systemem Ubuntu
  - dl.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.
Powiązane z platformą Azure punkty końcowe: maszyny wirtualne platformy Azure mogą kierować ruch do niektórych funkcji platformy Azure za pośrednictwem podsieci. W przypadku tych żądań masz możliwość bezpośredniego kierowania żądań za pośrednictwem platformy Azure lub włączania dostępu za pośrednictwem sieci.
1. Konfigurowanie ruchu Azure do przepuszczania przez punkty końcowe usługi
  
  Kierowanie ruchu bezpośrednio przez platformę Azure pozwala uniknąć dodawania obciążenia do grup zabezpieczeń sieciowych lub zapór i nie wymaga, aby umieścić na liście dozwolonych domeny wymienione w opcji poniżej.
  
  Na przykład użycie funkcji dysku danych będzie obejmować wywołania sieciowe do usługi Azure Storage. Włączenie punktu końcowego usługi Microsoft.Storage w Twojej sieci skieruje ruch bezpośrednio przez platformę Azure, omijając reguły sieciowe i zmniejszając obciążenie.
2. Jeśli chcesz uniknąć przekierowywania ruchu za pośrednictwem punktów końcowych usługi, są to domeny, które należy dodać do listy dozwolonych dla określonych funkcji.
  - md-*.blob.storage.azure.net — wymagane do skonfigurowania dysku danych

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 za
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, 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.

Zobacz też

Konfigurowanie ustawień puli

Udostępnij za pośrednictwem