Rete nell'ambiente app Azure Container

Le app azure Container vengono eseguite nel contesto di un ambiente, con la propria rete virtuale( VNet).

Per impostazione predefinita, l'ambiente dell'app contenitore viene creato con una rete virtuale generata automaticamente. Per un controllo granulare sulla rete, è possibile fornire una rete virtuale esistente quando si crea un ambiente. Dopo aver creato un ambiente con una rete virtuale generata o esistente, il tipo di rete non può essere modificato.

Le reti virtuali generate assumono le caratteristiche seguenti.

Sono:

• inaccessibile all'utente durante la creazione nel tenant di Microsoft
• accessibile pubblicamente tramite Internet
• solo in grado di raggiungere gli endpoint accessibili da Internet

Inoltre, supportano solo un subset limitato di funzionalità di rete, ad esempio restrizioni IP in ingresso e controlli di ingresso a livello di app contenitore.

Usare una rete virtuale esistente se sono necessarie altre funzionalità di rete di Azure, ad esempio:

• Integrazione con gateway applicazione
• Gruppi di sicurezza di rete
• Comunicazione con le risorse dietro endpoint privati nella rete virtuale

Le funzionalità di rete virtuale disponibili dipendono dalla selezione dell'ambiente.

Selezione ambiente

App contenitore ha due tipi di ambiente diversi, che condividono molte delle stesse caratteristiche di rete con alcune differenze principali.

Tipo di ambiente	Descrizione	Tipi di piano supportati
Profili del carico di lavoro	Supporta route definite dall'utente (UDR) e in uscita tramite il gateway NAT. La dimensione minima richiesta della subnet è /27.	Consumo, Dedicato
Solo Consumo	Non supporta route definite dall'utente( UDR), in uscita tramite gateway NAT, peering tramite un gateway remoto o altri dati in uscita personalizzati. La dimensione minima richiesta della subnet è /23.	Consumo

Livelli di accessibilità

È possibile configurare se l'app contenitore consente l'ingresso pubblico o l'ingresso solo dall'interno della rete virtuale a livello di ambiente.

Livello di accessibilità	Descrizione
Esterno	Consente all'app contenitore di accettare richieste pubbliche. Gli ambienti esterni vengono distribuiti con un indirizzo IP virtuale in un indirizzo IP pubblico esterno.
Interno	Gli ambienti interni non hanno endpoint pubblici e vengono distribuiti con un indirizzo IP virtuale (VIP) mappato a un indirizzo IP interno. L'endpoint interno è un servizio di bilanciamento del carico interno di Azure e gli indirizzi IP vengono emessi dall'elenco di indirizzi IP privati della rete virtuale personalizzata.

Configurazione della rete virtuale personalizzata

Quando si crea una rete virtuale personalizzata, tenere presenti le situazioni seguenti:

• Se si vuole che l'app contenitore limiti tutti gli accessi esterni, creare un ambiente app contenitore interno.

• Se si usa la propria rete virtuale, è necessario fornire una subnet dedicata esclusivamente all'ambiente dell'app contenitore distribuita. Questa subnet non è disponibile per altri servizi.

• Gli indirizzi di rete vengono assegnati da un intervallo di subnet definito durante la creazione dell'ambiente.

  • È possibile definire l'intervallo di subnet usato dall'ambiente App contenitore.

  • È possibile limitare le richieste in ingresso all'ambiente esclusivamente alla rete virtuale distribuendo l'ambiente come interno.

Nota

Quando si specifica la propria rete virtuale, vengono create risorse gestite aggiuntive. Queste risorse comportano costi a tariffe associate.

Quando si inizia a progettare la rete intorno all'app contenitore, vedere Pianificare le reti virtuali.

Nota

Lo spostamento di reti virtuali tra gruppi di risorse o sottoscrizioni diversi non è consentito se la rete virtuale è in uso da un ambiente app contenitore.

Comportamento del proxy perimetrale HTTP

App Contenitore di Azure usa il proxy Envoy come proxy HTTP perimetrale. Transport Layer Security (TLS) viene terminato sul perimetro e le richieste vengono instradate in base alle regole di suddivisione del traffico e instrada il traffico all'applicazione corretta.

Le applicazioni HTTP si ridimensionano in base al numero di richieste e connessioni HTTP. Envoy instrada il traffico interno all'interno dei cluster.

Le connessioni downstream supportano HTTP1.1 e HTTP2 e Envoy rileva e aggiorna automaticamente le connessioni se la connessione client richiede un aggiornamento.

Le connessioni upstream vengono definite impostando la transport proprietà sull'oggetto in ingresso .

Configurazione in ingresso

Nella sezione in ingresso è possibile configurare le impostazioni seguenti:

• Livello di accessibilità: è possibile impostare l'app contenitore come esternamente o internamente accessibile nell'ambiente. Una variabile CONTAINER_APP_ENV_DNS_SUFFIX di ambiente viene usata per risolvere automaticamente il suffisso del nome di dominio completo (FQDN) per l'ambiente. Quando si comunica tra app contenitore nello stesso ambiente, è anche possibile usare il nome dell'app. Per altre informazioni su come accedere alle app, vedere Ingresso in App Azure Container.

• Regole di suddivisione del traffico: è possibile definire regole di suddivisione del traffico tra revisioni diverse dell'applicazione. Per altre informazioni, vedere Suddivisione del traffico.

Per altre informazioni sui diversi scenari di rete, vedere Ingresso nelle app contenitore di Azure.

Dipendenze per il portale

Per ogni app in App Azure Container sono disponibili due URL.

Il runtime di App contenitore genera inizialmente un nome di dominio completo (FQDN) usato per accedere all'app. Vedere l'URLdell'applicazione nella finestra Panoramica dell'app contenitore nella portale di Azure per il nome di dominio completo dell'app contenitore.

Viene generato anche un secondo URL. Questo percorso concede l'accesso al servizio di streaming dei log e alla console. Se necessario, potrebbe essere necessario aggiungere https://azurecontainerapps.dev/ all'elenco elementi consentiti del firewall o del proxy.

Porte e indirizzi IP

Le porte seguenti vengono esposte per le connessioni in ingresso.

Protocollo	Porte
HTTP/HTTPS	80, 443

Gli indirizzi IP sono suddivisi nei tipi seguenti:

Tipo	Descrizione
Indirizzo IP in ingresso pubblico	Usato per il traffico dell'applicazione in una distribuzione esterna e il traffico di gestione sia nelle distribuzioni interne che esterne.
IP pubblico in uscita	Usato come IP "from" per le connessioni in uscita che lasciano la rete virtuale. Queste connessioni non vengono instradate verso un VPN. Gli indirizzi IP in uscita possono cambiare nel tempo. L'uso di un gateway NAT o di un altro proxy per il traffico in uscita da un ambiente App contenitore è supportato solo in un ambiente di profili di carico di lavoro.
Indirizzo IP del servizio di bilanciamento del carico interno	Questo indirizzo esiste solo in un ambiente interno.

Subnet

L'integrazione della rete virtuale dipende da una subnet dedicata. La modalità di allocazione degli indirizzi IP in una subnet e le dimensioni delle subnet supportate dipendono dal piano usato in App Azure Container.

Selezionare attentamente le dimensioni della subnet. Le dimensioni delle subnet non possono essere modificate dopo aver creato un ambiente App contenitore.

I diversi tipi di ambiente hanno requisiti di subnet diversi:

Ambiente dei profili del carico di lavoro

• /27 è la dimensione minima della subnet necessaria per l'integrazione della rete virtuale.

• La subnet deve essere delegata a Microsoft.App/environments.

• Quando si usa un ambiente esterno con ingresso esterno, il traffico in ingresso viene instradato attraverso l'INDIRIZZO IP pubblico dell'infrastruttura anziché attraverso la subnet.

• App contenitore riserva automaticamente 12 indirizzi IP per l'integrazione con la subnet. Il numero di indirizzi IP necessari per l'integrazione dell'infrastruttura non varia in base alle esigenze di scalabilità dell'ambiente. Gli indirizzi IP aggiuntivi vengono allocati in base alle regole seguenti, a seconda del tipo di profilo del carico di lavoro in uso, vengono allocati più indirizzi IP a seconda del profilo del carico di lavoro dell'ambiente:

  • Profilo del carico di lavoro dedicato: quando l'app contenitore aumenta il numero di istanze, a ogni nodo è assegnato un indirizzo IP.

  • Profilo del carico di lavoro a consumo: ogni indirizzo IP può essere condiviso tra più repliche. Quando si pianifica il numero di indirizzi IP necessari per l'app, pianificare 1 indirizzo IP per 10 repliche.

• Quando si apporta una modifica a una revisione in modalità revisione singola, lo spazio degli indirizzi richiesto viene raddoppiato per un breve periodo di tempo per supportare distribuzioni senza tempi di inattività. Ciò influisce sulle repliche o sui nodi supportati reali e disponibili per una determinata dimensione della subnet. La tabella seguente illustra sia gli indirizzi disponibili massimi per ogni blocco CIDR che l'effetto sulla scala orizzontale.

  Dimensioni subnet	IndirizziIP disponibili 1	Numero massimo di nodi (profilo del carico di lavoro dedicato)2	Numero massimo di repliche (profilo carico di lavoro a consumo)2
  23/	500	250	2500
  /24	244	122	1,220
  /25	116	58	580
  /26	52	26	260
  /27	20	10	100

  ¹ Gli indirizzi IP disponibili sono le dimensioni della subnet meno i 12 indirizzi IP necessari per l'infrastruttura di App Contenitore di Azure.
  ² Questo è la contabilità per le app in modalità di revisione singola.

Ambiente solo consumo

• /23 è la dimensione minima della subnet necessaria per l'integrazione della rete virtuale.

• Il runtime di App contenitore riserva almeno 60 INDIRIZZI IP per l'infrastruttura nella rete virtuale. La quantità riservata può aumentare fino a 256 indirizzi man mano che le app nell'ambiente sono ridimensionate.

• Quando le app vengono ridimensionate, viene allocato un nuovo indirizzo IP per ogni nuova replica.

• Quando si apporta una modifica a una revisione in modalità revisione singola, lo spazio degli indirizzi richiesto viene raddoppiato per un breve periodo di tempo per supportare distribuzioni senza tempi di inattività. Ciò influisce sulle repliche supportate reali e disponibili per una determinata dimensione della subnet.

Restrizioni relative all'intervallo di indirizzi della subnet

Ambiente dei profili del carico di lavoro

Gli intervalli di indirizzi della subnet non possono sovrapporsi agli intervalli seguenti riservati da servizio Azure Kubernetes:

• 169.254.0.0/16
• 172.30.0.0/16
• 172.31.0.0/16
• 192.0.2.0/24

Inoltre, un ambiente dei profili di carico di lavoro riserva gli indirizzi seguenti:

• 100.100.0.0/17
• 100.100.128.0/19
• 100.100.160.0/19
• 100.100.192.0/19

Ambiente solo consumo

Gli intervalli di indirizzi della subnet non possono sovrapporsi agli intervalli seguenti riservati da servizio Azure Kubernetes:

• 169.254.0.0/16
• 172.30.0.0/16
• 172.31.0.0/16
• 192.0.2.0/24

Se è stato creato l'ambiente di app contenitore con un CIDR del servizio personalizzato, assicurarsi che la subnet dell'app contenitore (o qualsiasi subnet con peering) non sia in conflitto con l'intervallo CIDR del servizio personalizzato.

Configurazione della subnet con l'interfaccia della riga di comando

Quando viene creato un ambiente app contenitore, è possibile specificare gli ID risorsa per una singola subnet.

Se si usa l'interfaccia della riga di comando, il parametro per definire l'ID risorsa della subnet è infrastructure-subnet-resource-id. La subnet ospita i componenti dell'infrastruttura e i contenitori di app utente.

Se si usa l'interfaccia della riga di comando di Azure con un ambiente solo a consumo e viene definito l'intervallo platformReservedCidr , entrambe le subnet non devono sovrapporsi all'intervallo IP definito in platformReservedCidr.

Route

Route definite dall'utente

Le route definite dall'utente (UDR) e l'uscita controllata tramite il gateway NAT sono supportate nell'ambiente dei profili di carico di lavoro. Nell'ambiente Solo consumo tali funzionalità non sono supportate.

Nota

Quando si usa la route definita dall'utente con Firewall di Azure in App Azure Container, è necessario aggiungere determinati tag di servizio e FQDN all'elenco elementi consentiti per il firewall. Per altre informazioni, vedere Configurazione della route definita dall'utente con Firewall di Azure.

• È possibile usare la route definita dall'utente con gli ambienti dei profili di carico di lavoro per limitare il traffico in uscita dall'app contenitore tramite Firewall di Azure o altre appliance di rete.

• La configurazione della route definita dall'utente viene eseguita all'esterno dell'ambito dell'ambiente App contenitore.

Azure crea una tabella di route predefinita per le reti virtuali al momento della creazione. Implementando una tabella di route definita dall'utente, è possibile controllare il modo in cui il traffico viene instradato all'interno della rete virtuale. Ad esempio, è possibile creare una route definita dall'utente che instrada tutto il traffico al firewall.

Configurazione della route definita dall'utente con Firewall di Azure

Le route definite dall'utente sono supportate solo in un ambiente di profili di carico di lavoro. L'applicazione e le regole di rete seguenti devono essere aggiunte all'elenco elementi consentiti per il firewall a seconda delle risorse in uso.

Nota

Per una guida su come configurare la route definita dall'utente con App contenitore per limitare il traffico in uscita con Firewall di Azure, vedere la procedura per App contenitore e Firewall di Azure.

Regole di applicazione

Le regole dell'applicazione consentono o negano il traffico in base al livello dell'applicazione. Le regole dell'applicazione firewall in uscita seguenti sono necessarie in base allo scenario.

Scenari	Fqdn	Descrizione
Tutti gli scenari	mcr.microsoft.com, *.data.mcr.microsoft.com	Questi nomi di dominio completi per Registro Contenitori Microsoft (MCR) vengono usati dalle app Azure Container e queste regole dell'applicazione o le regole di rete per MCR devono essere aggiunte all'elenco degli elementi consentiti quando si usano app contenitore di Azure con Firewall di Azure.
Registro Azure Container	Indirizzo del Registro Azure Container, *.blob.core.windows.net, login.microsoft.com	Questi nomi di dominio completi sono necessari quando si usano app contenitore di Azure con Registro Azure Container e Firewall di Azure.
Azure Key Vault	Indirizzo-Azure-Key-Vault,Your-Azure-Key-Vault-address, login.microsoft.com	Questi FQDN sono necessari oltre al tag di servizio necessario per la regola di rete per Azure Key Vault.
Identità gestita	*.identity.azure.net, login.microsoftonline.com, *.login.microsoftonline.com*.login.microsoft.com	Questi FQDN sono necessari quando si usa l'identità gestita con Firewall di Azure in App Azure Container.
Registro di sistema dell'hub Docker	hub.docker.com, registry-1.docker.io, production.cloudflare.docker.com	Se si usa il Registro di sistema dell'hub Docker e si vuole accedervi tramite il firewall, è necessario aggiungere questi FQDN al firewall.

Regole di rete

Le regole di rete consentono o negano il traffico in base al livello di rete e trasporto. Le regole di rete del firewall in uscita seguenti sono necessarie in base allo scenario.

Scenari	Tag del servizio	Descrizione
Tutti gli scenari	MicrosoftContainerRegistry, AzureFrontDoorFirstParty	Questi tag di servizio per Registro Contenitori Microsoft (MCR) vengono usati dalle app contenitore di Azure e queste regole di rete o le regole dell'applicazione per MCR devono essere aggiunte all'elenco consenti quando si usano app contenitore di Azure con Firewall di Azure.
Registro Azure Container	AzureContainerRegistry, AzureActiveDirectory	Quando si usa Registro Azure Container con app Azure Container, è necessario configurare queste regole dell'applicazione usate da Registro Azure Container.
Azure Key Vault	AzureKeyVault, AzureActiveDirectory	Questi tag di servizio sono necessari oltre al nome di dominio completo per la regola dell'applicazione per Azure Key Vault.
Identità gestita	AzureActiveDirectory	Quando si usa l'identità gestita con app Azure Container, è necessario configurare queste regole dell'applicazione usate dall'identità gestita.

Nota

Per le risorse di Azure usate con Firewall di Azure non elencate in questo articolo, vedere la documentazione dei tag del servizio.

Integrazione del gateway NAT

È possibile usare il gateway NAT per semplificare la connettività in uscita per il traffico Internet in uscita nella rete virtuale in un ambiente dei profili di carico di lavoro.

Quando si configura un gateway NAT nella subnet, il gateway NAT fornisce un indirizzo IP pubblico statico per l'ambiente. Tutto il traffico in uscita dall'app contenitore viene instradato tramite l'indirizzo IP pubblico statico del gateway NAT.

Sicurezza dell'ambiente

È possibile proteggere completamente l'ambiente dei profili del carico di lavoro del traffico di rete in ingresso e in uscita eseguendo le azioni seguenti:

• Creare l'ambiente dell'app contenitore interno in un ambiente di profili di carico di lavoro. Per la procedura, vedere Gestire i profili di carico di lavoro con l'interfaccia della riga di comando di Azure.

• Integrare le app contenitore con un gateway applicazione.

• Configurare la route definita dall'utente per instradare tutto il traffico attraverso Firewall di Azure.

Crittografia di rete a livello di ambiente (anteprima)

App Azure Container supporta la crittografia di rete a livello di ambiente usando la sicurezza a livello di trasporto reciproco (mTLS). Quando è necessaria la crittografia end-to-end, mTLS crittografa i dati trasmessi tra applicazioni all'interno di un ambiente.

Le applicazioni all'interno di un ambiente app contenitore vengono autenticate automaticamente. Tuttavia, il runtime di App contenitore non supporta l'autorizzazione per il controllo di accesso tra le applicazioni usando mTLS predefinito.

Quando le app comunicano con un client esterno all'ambiente, è supportata l'autenticazione bidirezionale con mTLS. Per altre informazioni, vedere Configurare i certificati client.

Nota

L'abilitazione di mTLS per le applicazioni può aumentare la latenza di risposta e ridurre la velocità effettiva massima in scenari con carico elevato.

Interfaccia della riga di comando di Azure

È possibile abilitare mTLS usando i comandi seguenti.

In caso di creazione:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-mtls

Per un'app contenitore esistente:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-mtls

Modello ARM

È possibile abilitare mTLS nel modello di Resource Manager per gli ambienti app contenitore usando la configurazione seguente.

{
  ...
  "properties": {
       "peerAuthentication":{
            "mtls": {
                "enabled": "true|false"
            }
        }
  ...
}

DNS

• DNS personalizzato: se la rete virtuale usa un server DNS personalizzato anziché il server DNS predefinito fornito da Azure, configurare il server DNS per inoltrare query DNS non risolte a 168.63.129.16. I resolver ricorsivi di Azure usano questo indirizzo IP per risolvere le richieste. Quando si configura il gruppo di sicurezza di rete o il firewall, non bloccare l'indirizzo. In caso contrario, l'ambiente 168.63.129.16 app contenitore non funzionerà correttamente.

• Ingresso con ambito di rete virtuale: se si prevede di usare l'ingresso con ambito di rete virtuale in un ambiente interno, configurare i domini in uno dei modi seguenti:

  1. Domini non personalizzati: se non si prevede di usare un dominio personalizzato, creare una zona DNS privata che risolve il dominio predefinito dell'ambiente App contenitore nell'indirizzo IP statico dell'ambiente App contenitore. È possibile usare Azure DNS privato o il proprio server DNS. Se si usa Azure DNS privato, creare una zona DNS privata denominata come dominio predefinito dell'ambiente dell'app contenitore (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io), con un A record. Il A record contiene il nome *<DNS Suffix> e l'indirizzo IP statico dell'ambiente App contenitore.

  2. Domini personalizzati: se si prevede di usare domini personalizzati e si usa un ambiente app contenitore esterno, usare un dominio risolvibile pubblicamente per aggiungere un dominio personalizzato e un certificato all'app contenitore. Se si usa un ambiente app contenitore interno, non è disponibile alcuna convalida per l'associazione DNS, perché è possibile accedere al cluster solo dall'interno della rete virtuale. Creare inoltre una zona DNS privato che risolve il dominio apex nell'indirizzo IP statico dell'ambiente App contenitore. È possibile usare Azure DNS privato o il proprio server DNS. Se si usa Azure DNS privato, creare una zona DNS privato denominata come dominiopex, con un A record che punta all'indirizzo IP statico dell'ambiente App contenitore.

L'indirizzo IP statico dell'ambiente App contenitore è disponibile nella portale di Azure nel suffisso DNS personalizzato della pagina dell'app contenitore o tramite il comando dell'interfaccia della riga di comando di Azureaz containerapp env list.

Risorse gestite

Quando si distribuisce un ambiente interno o esterno nella propria rete, viene creato un nuovo gruppo di risorse nella sottoscrizione di Azure in cui è ospitato l'ambiente. Questo gruppo di risorse contiene i componenti dell'infrastruttura gestiti dalla piattaforma App contenitore di Azure. Non modificare i servizi in questo gruppo o il gruppo di risorse stesso.

Ambiente dei profili del carico di lavoro

Il nome del gruppo di risorse creato nella sottoscrizione di Azure in cui è ospitato l'ambiente è preceduto ME_ dal prefisso per impostazione predefinita e il nome del gruppo di risorse può essere personalizzato durante la creazione dell'ambiente dell'app contenitore.

Per gli ambienti esterni, il gruppo di risorse contiene un indirizzo IP pubblico usato in modo specifico per la connettività in ingresso all'ambiente esterno e un servizio di bilanciamento del carico. Per gli ambienti interni, il gruppo di risorse contiene solo un servizio di bilanciamento del carico.

Oltre alla fatturazione standard di App Contenitore di Azure, vengono addebitati i costi seguenti:

• Un indirizzo IP pubblico statico standard per l'uscita se si usa un ambiente interno o esterno, più un indirizzo IP pubblico statico standard per l'ingresso se si usa un ambiente esterno. Se sono necessari più indirizzi IP pubblici per l'uscita a causa di problemi SNAT, aprire un ticket di supporto per richiedere un override.

• Un servizio di bilanciamento del carico standard.

• Il costo dei dati elaborati (in GB) include sia l'ingresso che l'uscita per le operazioni di gestione.

Ambiente solo consumo

Il nome del gruppo di risorse creato nella sottoscrizione di Azure in cui è ospitato l'ambiente è preceduto MC_ dal prefisso per impostazione predefinita e il nome del gruppo di risorse non può essere personalizzato quando si crea un'app contenitore. Il gruppo di risorse contiene indirizzi IP pubblici usati in modo specifico per la connettività in uscita dall'ambiente e un servizio di bilanciamento del carico.

Oltre alla fatturazione standard di App Contenitore di Azure, vengono addebitati i costi seguenti:

• Un indirizzo IP pubblico statico standard per l'uscita. Se sono necessari più indirizzi IP per l'uscita a causa di problemi di SNAT (Source Network Address Translation), aprire un ticket di supporto per richiedere un override.

• Due servizi di bilanciamento del carico standard se si usa un ambiente interno o un servizio di bilanciamento del carico standard se si usa un ambiente esterno. Ogni servizio di bilanciamento del carico ha meno di sei regole. Il costo dei dati elaborati (in GB) include sia l'ingresso che l'uscita per le operazioni di gestione.

Passaggi successivi

• Eseguire la distribuzione con un ambiente esterno
• Eseguire la distribuzione con un ambiente interno