Konfigurieren von Netzwerknetzwerken für verwaltete DevOps-Pools

Artikel
11/14/2024

Verwaltete DevOps-Pools-Agents können so konfiguriert werden, dass sie in einem isolierten virtuellen Netzwerk oder in einem vorhandenen virtuellen Netzwerk ausgeführt werden. In diesem Artikel wird beschrieben, wie Sie Ihren verwalteten DevOps-Pool so konfigurieren, dass Agents in Ihrem virtuellen Netzwerk ausgeführt werden.

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.

Gewähren des Lese- und Netzwerkmitwirkendenzugriffs auf devOpsInfrastructure-Dienstprinzipal

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-10-19",
    "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.

Konfigurieren des Azure DevOps-Agents für die Ausführung hinter einem Proxy

Wenn Sie einen Proxydienst auf Ihrem Image konfiguriert haben und möchten, dass Ihre Workloads im Verwalteten DevOps-Pool hinter diesem Proxy ausgeführt werden, müssen Sie die folgenden Umgebungsvariablen zu Ihrem Image hinzufügen.

VSTS_AGENT_INPUT_PROXYURL – Die URL des konfigurierten Proxys, der hinter dem Hintergrund ausgeführt werden soll
VSTS_AGENT_INPUT_PROXYUSERNAME - Der Benutzername, der für die Verwendung des Proxys erforderlich ist
VSTS_AGENT_INPUT_PROXYPASSWORD - Das Kennwort für die Verwendung des Proxys.

Bei Windows sollten diese Umgebungsvariablen Systemumgebungsvariablen sein, und für Linux sollten sich diese Variablen in der Datei "/etc/environment " befinden. Das Falsche Festlegen dieser Systemvariablen oder ohne einen konfigurierten Proxydienst auf dem Image führt dazu, dass die Bereitstellung neuer Agents mit Netzwerkkonnektivitätsproblemen fehlschlägt.

Wenn Sie von Azure Virtual Machine Scale Set-Agents migrieren und bereits die Proxyumgebungsvariablen auf Ihrem Image verwenden, wie in Azure Virtual Machine Scale Set Agents beschrieben: Anpassen der Pipeline-Agent-Konfiguration sollten keine Änderungen erforderlich sein.

Siehe auch

Konfigurieren von Pooleinstellungen

Freigeben über