Netwerkopties voor Azure VM Image Builder

Van toepassing op: ✔️ Flexibele schaalsets voor Linux-VM's ✔️

Azure VM Image Builder (AIB) implementeert een Azure Container Instance (ACI) in de faseringsresourcegroep in uw abonnement. De ACI moet zijn gekoppeld aan een subnet in een virtueel Azure-netwerk (VNet). De AIB-servicecode die wordt uitgevoerd in de ACI implementeert een virtuele buildmachine (build-VM) in de faseringsresourcegroep om uw installatiekopieën aan te passen en de build-VM moet op een afzonderlijk subnet worden geplaatst. Om uw image aan te passen en te valideren, moet de ACI netwerkconnectiviteit hebben met de build-VM. Op basis van uw netwerkvereisten en organisatiebeleid kunt u AIB configureren voor het gebruik van verschillende netwerktopologieën. U kunt ervoor kiezen om beide subnetten, één subnet of geen subnetten mee te nemen. Zie voor aanbevelingen Best practices voor Azure VM Image Builder.

Netwerktopologieën

Gebruik geen eigen build-VM-subnet of een ACI-subnet

  • U kunt deze topologie selecteren door het vnetConfig veld in de afbeeldingssjabloon niet op te geven of door het veld op te geven, maar zonder subnetId en containerInstanceSubnetId subvelden.
  • Als u geen subnetten opgeeft, implementeert AIB een virtueel Azure-netwerk (VNet) in de faseringsresourcegroep met twee subnetten: één voor de Azure Container Instance en één voor de build-VM. Beide subnetten zijn gekoppeld aan een netwerkbeveiligingsgroep (NSG) die standaardregels bevat, terwijl er nog steeds directe line-of-sight-connectiviteit is vereist voor aanpassing. De build-VM wordt ook uitgerold met een netwerkinterface resource (en andere resources die niet direct verband houden met netwerken, zoals beheerde disks). Nadat de build is voltooid, worden de build-VM en netwerkresources verwijderd.

Gebruik uw eigen build-VM-subnet en gebruik uw eigen ACI-subnet

  • U kunt deze topologie selecteren door het vnetConfig veld op te geven met de subnetId en containerInstanceSubnetId subvelden in de afbeeldingssjabloon. Deze optie, inclusief het containerInstanceSubnetId subveld, is beschikbaar vanaf API-versie 2024-02-01. U kunt ook bestaande sjablonen bijwerken om deze topologie te gebruiken.
  • In deze topologie implementeert AIB de build-VM in het opgegeven subnet van de build-VM en de ACI naar het opgegeven ACI-subnet. Omdat de subnetten al zijn opgegeven, implementeert AIB geen virtueel netwerk, subnetten of een netwerkbeveiligingsgroep. Deze topologie is handig wanneer quotumbeperkingen of beleidsregels de implementatie van deze resources voorkomen. De build-VM heeft toegang tot resources die bereikbaar zijn vanuit uw virtuele netwerk en u kunt ook een virtueel silonetwerk maken dat niet is verbonden met een ander virtueel netwerk. Het ACI-subnet moet voldoen aan de vereisten voor geïsoleerde image builds. Zie de sjabloonreferentie voor meer informatie over deze velden.
  • Deze topologie is de aanbevolen optie voor de meeste scenario's, omdat u hiermee volledige controle hebt over beide subnetten, de installatie en netwerkconfiguratie vereenvoudigt, de totale implementatiekosten kunt verlagen en netwerken kunt afstemmen op de beveiligings- en governancevereisten van uw organisatie.

Gebruik een eigen build-VM-subnet, maar geen eigen ACI-subnet.

  • U kunt deze topologie selecteren door het vnetConfig veld met het subnetId subveld op te geven terwijl u het containerInstanceSubnetId subveld weglaat in de afbeeldingssjabloon.
  • In deze topologie implementeert AIB een tijdelijk virtueel netwerk in de faseringsresourcegroep met twee subnetten, elk gekoppeld aan een netwerkbeveiligingsgroep (NSG). Het ene subnet fungeert als host voor de ACI en de andere als host voor de privé-eindpuntresource. De build-VM wordt geïmplementeerd in het opgegeven subnet. Om communicatie mogelijk te maken tussen het ACI-subnet en uw build-VM-subnet, implementeert AIB ook een op Private Link gebaseerd communicatiepad in de faseringsresourcegroep met een privé-eindpunt, Private Link-service, Azure Load Balancer, netwerkinterfaces en een virtuele proxymachine. De exacte resources en configuraties variëren enigszins, afhankelijk van of u een Windows-afbeelding of een Linux-afbeelding wilt aanpassen.
  • Deze topologie wordt over het algemeen niet aanbevolen voor de meeste scenario's, omdat het de implementatiekosten kan verhogen, meer configuratie en operationele configuratie kan vereisen en aanvullende onderdelen introduceert die de end-to-end-pijplijn gevoeliger kunnen maken voor fouten.

Zie de volgende artikelen voor voorbeelden van deze topologie:

Azure Private Link biedt privéconnectiviteit van een virtueel netwerk naar Azure PaaS (Platform as a Service) of services van klanten of Microsoft-partners. Het vereenvoudigt de netwerkarchitectuur en beveiligt de connectiviteit tussen Azure-eindpunten door gegevensblootstelling op het openbare internet te elimineren. Private Link vereist een IP-adres van het opgegeven virtuele netwerk en subnet. Azure biedt momenteel geen ondersteuning voor netwerkbeleid op deze IP-adressen, dus u moet netwerkbeleid op het subnet uitschakelen. Zie de Documentatie van Private Link voor meer informatie.

Waarom een proxy-VM implementeren?

Wanneer een virtuele machine zonder een openbaar IP-adres zich achter een interne load balancer bevindt, heeft deze geen internettoegang. De load balancer die wordt gebruikt voor het virtuele netwerk, is intern. De proxy-VM biedt internettoegang voor de build-VM tijdens builds en AIB gebruikt de proxy-VM om opdrachten tussen de service en de build-VM te verzenden. U kunt de gekoppelde netwerkbeveiligingsgroepen gebruiken om de toegang tot build-VM's te beperken. Verkeer van de ACI gaat via de privékoppeling naar de load balancer. De load balancer communiceert met de proxy-VM op poort 60001 voor Linux of poort 60000 voor Windows. De proxy stuurt opdrachten door naar de build-VM op poort 22 voor Linux of poort 5986 voor Windows. De grootte van de geïmplementeerde proxy-VM is standaard A1_v2, maar u kunt de grootte wijzigen. Zie de sjabloonreferentie voor meer informatie.

Controlelijst voor het gebruik van uw virtuele netwerk

  1. Toestaan dat Azure Load Balancer communiceert met de proxy-VM in een netwerkbeveiligingsgroep.
  2. Schakel het beleid voor de privéservice in het subnet uit.
  3. Sta VM Image Builder toe om een load balancer te maken en VM's toe te voegen aan het virtuele netwerk.
  4. Sta VM Image Builder toe om bron-afbeeldingen te lezen en te schrijven en afbeeldingen te maken.
  5. Zorg ervoor dat u een virtueel netwerk gebruikt in dezelfde regio als de VM Image Builder-serviceregio.

Aanvullende overwegingen

Vereiste machtigingen voor een bestaand virtueel netwerk

VM Image Builder vereist specifieke machtigingen voor het gebruik van een bestaand virtueel netwerk. Zie Machtigingen voor Azure VM Image Builder configureren met behulp van de Azure CLI of Machtigingen voor Azure VM Image Builder configureren met behulp van PowerShell voor meer informatie.

Opmerking

Het virtuele netwerk moet zich in dezelfde regio bevinden als de VM Image Builder-serviceregio.

Belangrijk

De Azure VM Image Builder-service wijzigt de WinRM-verbindingsconfiguratie op alle Windows-builds om HTTPS te gebruiken op poort 5986 in plaats van de standaard-HTTP-poort op 5985. Deze configuratiewijziging kan van invloed zijn op werkstromen die afhankelijk zijn van WinRM-communicatie.

Connectiviteitsmodel

AIB implementeert geen openbaar IP-adres voor directe connectiviteit en het AIB-serviceonderdeel dat wordt uitgevoerd in het platformabonnement heeft geen netwerkverbinding met de ACI of de build-VM. Alleen het AIB-onderdeel dat in de ACI wordt uitgevoerd, heeft verbinding met de build-VM om aanpassingen uit te voeren.

Ondersteunde subnetcombinaties

U kunt zowel subnetten (subnetId als containerInstanceSubnetId) configureren of alleen het subnet van de build-VM (subnetId). Een configuratie die alleen het ACI-subnet (containerInstanceSubnetId) aangeeft, wordt niet ondersteund.

Volgende stappen 

Overzicht van Azure VM Image Builder

  • Last updated on