Konfigurieren von Netzwerknetzwerken für verwaltete DevOps-Pools

Artikel
10/18/2024

Wichtig

Verwaltete DevOps-Pools befinden sich derzeit in der VORSCHAU. Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Hinzufügen von Agents zu Ihrem eigenen virtuellen Netzwerk

Sie können Agents aus verwalteten DevOps-Pools zu Ihrem eigenen virtuellen Netzwerk hinzufügen, z. B.:

Ihre CI/CD-Agents müssen über einen Dienst wie Express Route auf Ressourcen zugreifen, die nur in Ihrem Unternehmensnetzwerk verfügbar sind.
Ihre CI/CD-Agents müssen auf Ressourcen zugreifen, die für private Endpunkte isoliert sind.
Sie möchten Ihre CI/CD-Infrastruktur netzwerkisolieren, indem Sie Ihr eigenes VNet mit unternehmensspezifischen Firewallregeln bereitstellen.
Alle anderen eindeutigen Anwendungsfälle, die nicht durch sofort einsatzbereite verwaltete DevOps Pools netzwerkbezogene Features erreicht werden können

Sie können die Agents Ihres Pools zu Ihrem virtuellen Netzwerk hinzufügen, indem Sie die folgenden Schritte ausführen.

Erstellen oder Mitbringen ihres virtuellen Netzwerks und Subnetzes
Delegieren des Subnetzes an Microsoft.DevOpsInfrastructure/pools
Zuordnen des Subnetzes zu Ihrem verwalteten DevOps-Pool

Die vorherigen Schritte delegieren das Subnetz für den exklusiven Zugriff durch den Pool und das Subnetz kann nicht von anderen Pools oder Ressourcen verwendet werden. Um mehrere Pools mit demselben virtuellen Netzwerk zu verbinden, können mehrere Subnetze verwendet werden, die jeweils delegiert und ihrem eigenen Pool zugeordnet sind.

Erstellen oder Mitbringen ihres virtuellen Netzwerks und Subnetzes

Das Subnetz muss über genügend Adressraum verfügen, um die maximale Poolgröße des Pools aufzunehmen, den Sie zuordnen möchten (schließen Sie die 5 IP-Adress-Azure-Reserven in das Subnetz ein). Wenn Sie Express Route verwenden, müssen Sie die Verwaltungssperre für die Ressourcengruppe vorübergehend ablegen oder ändern, um Schreibvorgänge zuzulassen.

Wichtig

Der verwaltete DevOps-Pool und das virtuelle Netzwerk müssen sich in derselben Region befinden, oder Sie erhalten eine Fehlermeldung wie die folgende, wenn Sie versuchen, den Pool zu erstellen oder die Netzwerkkonfiguration zu aktualisieren. Virtual network MDPVN is in region eastus, but pool mdpnonprodsub is in region australiaeast. These must be in the same region.

Stellen Sie sicher, dass der DevOpsInfrastructure-Prinzipal den folgenden Zugriff auf das virtuelle Netzwerk hat:

Reader und Network Contributor
ODER fügen Sie einer benutzerdefinierten Rolle die folgende Berechtigung hinzu:
- 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

Erstellen Sie eine benutzerdefinierte Rolle für den Zugriff auf den Dienstzuordnungslink . Eine Beispielrolle kann auf Ressourcengruppen- oder Abonnementebene auf der Registerkarte "Zugriffssteuerung" erstellt werden, wie im folgenden Beispiel gezeigt.

Screenshot der benutzerdefinierten Rollenberechtigungen.

So überprüfen Sie den DevOpsInfrastructure-Prinzipalzugriff

Wählen Sie access control (IAM) für das virtuelle Netzwerk aus, und wählen Sie "Zugriff überprüfen" aus.
Suchen Sie nach DevOpsInfrastructure , und wählen Sie sie aus.
Überprüfen Des Lesezugriffs . Überprüfen Sie, Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action ob Microsoft.Network/virtualNetworks/subnets/join/actionund Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write der Zugriff zugewiesen ist. Ihre benutzerdefinierte Rolle sollte hier angezeigt werden.
Wenn DevOpsInfrastructure nicht über diese Berechtigungen verfügt, fügen Sie sie hinzu, indem Sie access control (IAM) für das virtuelle Netzwerk auswählen, und wählen Sie "Zugriff auf diese Ressource gewähren" aus, und fügen Sie sie hinzu.

Delegieren des Subnetzes an Microsoft.DevOpsInfrastructure/pools

Das Subnetz muss an die Microsoft.DevOpsInfrastructure/pools zu verwendende Subnetz delegiert werden. Öffnen Sie die Subnetzeigenschaften im Portal, und wählen Sie unter dem Abschnitt "Subnetzdelegierung" die Option Microsoft.DevOpsInfrastructure/pools " Speichern" aus.

Screenshot der Konfiguration der Subnetzdelegierung.

Dadurch wird das Subnetz für den exklusiven Zugriff auf den Pool delegiert, und das Subnetz kann nicht von anderen Pools oder Ressourcen verwendet werden. Um mehrere Pools mit demselben virtuellen Netzwerk zu verbinden, müssen mehrere Subnetze verwendet werden, die jeweils delegiert und ihrem eigenen Pool zugeordnet sind. Weitere Informationen zur Subnetzdelegierung finden Sie hier.

Sobald das Subnetz an Microsoft.DevOpsInfrastructure/poolsdas Subnetz delegiert wurde, kann der Pool aktualisiert werden, um das Subnetz zu verwenden.

Zuordnen des Subnetzes zu Ihrem verwalteten DevOps-Pool

Wenn Sie einen neuen Pool erstellen, wechseln Sie zur Registerkarte "Netzwerk". Um einen vorhandenen Pool zu aktualisieren, wechseln Sie zu "Netzwerkeinstellungen>", und wählen Sie "Agents" aus, die in ein vorhandenes virtuelles Netzwerk eingefügt wurden, "Konfigurieren".
Wählen Sie das Abonnement, das virtuelle Netzwerk und das Subnetz aus, an das Microsoft.DevOpsInfrastructure/poolsSie delegiert haben, und wählen Sie "OK" aus.

Nach Abschluss der Netzwerkaktualisierung wird die neu erstellte Ressource im Pool das delegierte Subnetz verwenden.

Wenn Sie ARM-Vorlagen verwenden, fügen Sie eine networkProfile Eigenschaft hinzu, falls sie noch nicht vorhanden ist, und fügen Sie dann eine subnetId Eigenschaft mit networkProfile der Ressourcen-ID Ihres Subnetzes hinzu.

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

Netzwerk wird mithilfe der networkProfile Eigenschaft im fabricProfile Abschnitt beim Erstellen oder Aktualisieren eines Pools konfiguriert. Für ein isoliertes Netzwerk lassen Sie die networkProfile Eigenschaft beim Erstellen eines Pools aus.

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

Das folgende Beispiel zeigt den networkProfile Abschnitt der fabric-profile.json Datei.

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

Einschränken der ausgehenden Konnektivität

Wenn Sie Über Systeme in Ihrem Netzwerk (NSG, Firewall usw.) verfügen, die die ausgehende Konnektivität einschränken, müssen Sie sicherstellen, dass auf die folgenden Domänen zugegriffen werden kann, andernfalls ist Ihr verwalteter DevOps-Pool nicht funktionsfähig. Alle davon sind HTTPS, sofern nicht anders angegeben.

Hochsichere Endpunkte, von denen unser Dienst abhängt:
- *.prod.manageddevops.microsoft.com – Endpunkt für verwaltete DevOps-Pools
- rmprodbuilds.azureedge.net - Arbeitsbinärdateien
- vstsagentpackage.azureedge.net – Speicherort des Azure DevOps-Agent-CDN
- *.queue.core.windows.net – Arbeitswarteschlange für die Kommunikation mit dem Dienst für verwaltete DevOps-Pools
- server.pipe.aria.microsoft.com – Allgemeine clientseitige Telemetrielösung (und wird unter anderem von der AgentPool-Validierungserweiterung verwendet)
- azure.archive.ubuntu.com – Bereitstellen von Linux-Computern – dies ist HTTP, nicht HTTPS
- www.microsoft.com – Bereitstellen von Linux-Computern
Weniger sichere, offenere Endpunkte, von denen unser Dienst abhängt:
- Benötigt von unserem Service:
  - packages.microsoft.com – Bereitstellen von Linux-Computern
  - ppa.launchpad.net - Bereitstellen von Ubuntu-Computern
  - dl.fedoraproject.org – Bereitstellen bestimmter Linux-Distributionen
- Erforderlich vom Azure DevOps-Agent:
  - dev.azure.com
  - *.services.visualstudio.com
  - *.vsblob.visualstudio.com
  - *.vssps.visualstudio.com
  - *.visualstudio.com Diese Einträge sind die Mindestdomänen, die erforderlich sind. Wenn Probleme auftreten, lesen Sie die Azure DevOps-Zulassungsliste für die vollständige Liste der erforderlichen Domänen.

Wenn Sie Ihre Azure DevOps-Pipeline für die Ausführung innerhalb eines Containers konfigurieren, müssen Sie auch die Quelle des Containerimages (Docker oder ACR) zulassen.

Siehe auch

Konfigurieren von Pooleinstellungen

Freigeben über