Nätverksalternativ för Azure VM Image Builder

Gäller för: ✔️ Flexibla skalningsuppsättningar för virtuella Linux-datorer ✔️

Azure VM Image Builder (AIB) distribuerar en Azure Container Instance (ACI) i mellanlagringsresursgruppen i din prenumeration. ACI:n måste associeras med ett undernät i ett virtuellt Azure-nätverk (VNet). AIB-tjänstkoden som körs i ACI:n distribuerar en virtuell build-dator (skapa virtuell dator) i resursgruppen för mellanlagring för att anpassa avbildningen, och den virtuella byggdatorn måste placeras i ett separat undernät. För att kunna anpassa och verifiera avbildningen måste ACI ha nätverksanslutning till den virtuella byggdatorn. Baserat på dina nätverkskrav och organisationsprinciper kan du konfigurera AIB att använda olika nätverkstopologier. Du kan välja att ta med båda undernäten, ett undernät eller inget. Rekommendationer finns i Metodtips för Azure VM Image Builder.

Nätverkstopologier

Ta inte med ditt eget build VM-undernät eller ACI-undernätet

  • Du kan välja den här topologin vnetConfig genom att inte ange fältet i bildmallen eller genom att ange fältet men utan subnetId och containerInstanceSubnetId underfält.
  • Om du inte anger några undernät distribuerar AIB ett virtuellt Azure-nätverk (VNet) i mellanlagringsresursgruppen med två undernät: ett för Azure Container Instance och ett för den virtuella byggdatorn. Båda undernäten är associerade med en nätverkssäkerhetsgrupp (NSG) som innehåller standardregler, samtidigt som det fortfarande tillåter den direktanslutning som behövs för anpassning. Den virtuella byggdatorn distribueras också med en nätverksgränssnittsresurs (och andra resurser som inte är direkt relaterade till nätverk, till exempel hanterad disk). När bygget är klart tas den virtuella datorn och nätverksresurserna bort.

Ta med ditt eget build VM-undernät och ta med ditt eget ACI-undernät

  • Du kan välja den här topologin vnetConfig genom att ange fältet med delfälten subnetId och containerInstanceSubnetId i avbildningsmallen. Det här alternativet, inklusive containerInstanceSubnetId underfältet, är tillgängligt från och med API-version 2024-02-01. Du kan också uppdatera befintliga mallar för att använda den här topologin.
  • I den här topologin distribuerar AIB den virtuella byggdatorn till det angivna build VM-undernätet och ACI:n till det angivna ACI-undernätet. Eftersom undernäten redan har angetts distribuerar AIB inte ett virtuellt nätverk, undernät eller en nätverkssäkerhetsgrupp. Den här topologin är användbar när kvotbegränsningar eller principer förhindrar distribution av dessa resurser. Den virtuella byggdatorn kan komma åt resurser som kan nås från ditt virtuella nätverk och du kan också skapa ett siloed virtuellt nätverk som inte är anslutet till något annat virtuellt nätverk. ACI-undernätet måste uppfylla kraven för isolerade avbildningsbyggen. Mer information om dessa fält finns i mallreferensen.
  • Den här topologin är det rekommenderade alternativet för de flesta scenarier eftersom den ger dig fullständig kontroll över båda undernäten, förenklar konfigurationen och nätverkskonfigurationen, kan minska de totala distributionskostnaderna och bidra till att anpassa nätverken till organisationens säkerhets- och styrningskrav.

Använd ditt eget undernät för bygg-VM men inte ditt eget ACI-underlätet

  • Du kan välja den här topologin vnetConfig genom att ange fältet med subnetId underfältet medan du utelämnar containerInstanceSubnetId underfältet i avbildningsmallen.
  • I den här topologin distribuerar AIB ett tillfälligt virtuellt nätverk i mellanlagringsresursgruppen med två undernät, var och en associerad med en nätverkssäkerhetsgrupp (NSG). Ett undernät är värd för ACI och det andra är värd för den privata slutpunktsresursen. Den virtuella byggdatorn distribueras i det angivna undernätet. För att möjliggöra kommunikation mellan ACI-undernätet och undernätet för din virtuella byggdator distribuerar AIB också en kommunikationsväg baserad på Private Link i mellanlagringsresursgruppen. Denna väg inkluderar en privat slutpunkt, Private Link Service, Azure Load Balancer, nätverksgränssnitt och en virtuell proxydator. De exakta resurserna och konfigurationerna varierar något beroende på om du anpassar en Windows-avbildning eller en Linux-avbildning.
  • Den här topologin rekommenderas vanligtvis inte för de flesta scenarier eftersom den kan öka distributionskostnaderna, kräva mer konfiguration och driftkonfiguration och introducera ytterligare komponenter som kan göra pipelinen från slutpunkt till slutpunkt mer känslig för fel.

Exempel på den här topologin finns i följande artiklar:

Azure Private Link tillhandahåller privata anslutningar från ett virtuellt nätverk till Azure Platform as a Service (PaaS) eller till kundägda eller Microsoft-partnertjänster. Det förenklar nätverksarkitekturen och skyddar anslutningen mellan Azure-slutpunkter genom att eliminera dataexponering för det offentliga Internet. Private Link kräver en IP-adress från det angivna virtuella nätverket och undernätet. Azure stöder för närvarande inte nätverksprinciper på dessa IP-adresser, så du måste inaktivera nätverksprinciper i undernätet. Mer information finns i Private Link-dokumentationen.

Varför distribuerar du en virtuell proxydator?

När en virtuell dator utan en offentlig IP-adress ligger bakom en intern lastbalanserare har den inte internetåtkomst. Lastbalanseraren som används för det virtuella nätverket är intern. Den virtuella proxydatorn tillåter internetåtkomst för den virtuella byggdatorn under bygget, och AIB använder den virtuella proxydatorn för att skicka kommandon mellan tjänsten och den virtuella byggdatorn. Du kan använda de associerade nätverkssäkerhetsgrupperna för att begränsa åtkomsten till den virtuella datorn. Trafik från ACI:et går via den privata länken till lastbalanseraren. Lastbalanseraren kommunicerar med den virtuella proxydatorn på port 60001 för Linux eller port 60000 för Windows. Proxyn vidarebefordrar kommandon till den virtuella byggdatorn på port 22 för Linux eller port 5986 för Windows. Som standard är storleken på den distribuerade virtuella proxydatorn Standard A1_v2, men du kan ändra storleken. Mer information finns i mallreferensen.

Checklista för att använda ditt virtuella nätverk

  1. Tillåt att Azure Load Balancer kommunicerar med den virtuella proxydatorn i en nätverkssäkerhetsgrupp.
  2. Inaktivera principen för privat tjänst i undernätet.
  3. Tillåt att VM Image Builder skapar en lastbalanserare och lägger till virtuella datorer i det virtuella nätverket.
  4. Tillåt att VM Image Builder läser och skriver källavbildningar och skapar avbildningar.
  5. Se till att du använder ett virtuellt nätverk i samma region som tjänstregionen för VM Image Builder.

Ytterligare överväganden

Nödvändiga behörigheter för ett befintligt virtuellt nätverk

Vm Image Builder kräver specifika behörigheter för att använda ett befintligt virtuellt nätverk. Mer information finns i Konfigurera Azure VM Image Builder-behörigheter med hjälp av Azure CLI eller Konfigurera Azure VM Image Builder-behörigheter med hjälp av PowerShell.

Anmärkning

Det virtuella nätverket måste finnas i samma region som vm Image Builder-tjänstregionen.

Viktigt!

Azure VM Image Builder-tjänsten ändrar WinRM-anslutningskonfigurationen i alla Windows-versioner för att använda HTTPS på port 5986 i stället för http-standardporten på 5985. Den här konfigurationsändringen kan påverka arbetsflöden som förlitar sig på WinRM-kommunikation.

Anslutningsmodell

AIB distribuerar inte en offentlig IP-adress för direktanslutning och den AIB-tjänstkomponent som körs i plattformsprenumerationen har inte nätverksanslutning till ACI eller den virtuella byggdatorn. Endast AIB-komponenten som körs i ACI:n har anslutning till den virtuella byggdatorn för att utföra anpassning.

Kombinationer av undernät som stöds

Du kan konfigurera båda undernäten (subnetId och containerInstanceSubnetId) eller endast undernätet för den virtuella datorns bygge (subnetId). En konfiguration som endast anger ACI-undernätet (containerInstanceSubnetId) stöds inte.

Nästa steg

Översikt över Azure VM Image Builder