Ingress in Azure Container Apps

Azure Container Apps kunt u uw container-app beschikbaar maken voor het openbare web, uw virtuele netwerk (VNET) en andere container-apps in uw omgeving door inkomend verkeer in te schakelen. Instellingen voor inkomend verkeer worden afgedwongen via een set regels waarmee de routering van extern en intern verkeer naar uw container-app wordt beheerd. Wanneer u inkomend verkeer inschakelt, hoeft u geen Azure Load Balancer, openbaar IP-adres of andere Azure resources te maken om binnenkomend HTTP-aanvragen of TCP-verkeer (Transmission Control Protocol) in te schakelen.

Inkomend verkeer ondersteunt:

• Extern en intern inkomend verkeer
• HTTP- en TCP-ingressietypen
• Domeinnamen
• IP-beperkingen
• Verificatie
• Dataverkeer splitsen tussen revisies
• Sessieaffiniteit

Voorbeeld van de configuratie van inkomend verkeer met de splitsing van inkomend verkeer tussen twee revisies:

Zie Ingress configureren voor configuratiegegevens.

Externe en interne toegang

Wanneer u inkomend verkeer inschakelt, kunt u kiezen tussen twee typen inkomend verkeer:

• Extern: Maakt de app beschikbaar via het inkomende IP-adres van de Container Apps-omgeving en maakt de app bereikbaar vanuit andere container-apps in dezelfde omgeving. Of de app publiekelijk of privé bereikbaar is via het inkomende IP, hangt af van de netwerkconfiguratie van de omgeving. Als de omgeving een openbaar inkomend IP gebruikt en publieke netwerktoegang is ingeschakeld, kan de app verkeer ontvangen van het publieke internet. Als de omgeving een intern inkomend IP gebruikt, kan de app via de interne load balancer van de omgeving verkeer ontvangen vanuit het verbonden virtuele netwerk, maar niet vanaf het publieke internet.

• Intern: Maakt de eigen volledig gekwalificeerde domeinnaam (FQDN) van de app direct bereikbaar alleen vanuit dezelfde Container Apps-omgeving, zoals vanuit andere container-apps. De app wordt niet blootgesteld via het inkomende IP-adres van de Container Apps-omgeving. Bijvoorbeeld, in een interne omgeving geeft een verzoek dat naar de interne load balancer van de omgeving wordt gestuurd voor een app met internal ingress een HTTP 404-antwoord terug. De app kan echter nog steeds verkeer van buiten de omgeving ontvangen als deze als doel wordt aangeduid in een omgevingsniveau HTTP-routeconfiguratie. Om een app volledig te isoleren van extern verkeer, zorg ervoor dat deze niet als target wordt opgenomen in een HTTP-routeconfiguratie, of plaats je hem in een aparte omgeving. Voor meer informatie, zie Gebruik regelgebaseerde routing met Azure Container Apps.

De app ingress-instelling beschrijft de zichtbaarheid van de app ten opzichte van de Container Apps-omgeving. Het bepaalt op zichzelf niet of de app toegankelijk is vanaf het openbare internet. Internettoegankelijkheid hangt ook af van de virtuele IP- en openbare netwerkconfiguratie van de omgeving.

Hoe ingress-zichtbaarheid interacteert met het omgevingstype

Twee aparte instellingen bepalen wie je container-app kan bereiken:

• Toegankelijkheidsniveau van de omgeving: Stel in wanneer je de omgeving creëert. Een interne omgeving (gemaakt met --internal-only) heeft helemaal geen openbaar eindpunt. Het is alleen bereikbaar via een interne load balancer in je virtuele netwerk. Voor meer informatie, zie Toegankelijkheidsniveau.

• Zichtbaarheid van app-ingress: de eigenschap external per app, ingesteld met --type external of --type internal, en weergegeven in het portaal als Ingress-verkeer.

Het toegankelijkheidsniveau van de omgeving definieert de buitenste netwerkgrens. De zichtbaarheid van de ingang van de app bepaalt of de app aan die grens wordt gepubliceerd, of binnen de omgeving wordt gehouden.

Beperk een app tot alleen virtuele netwerktoegang

Een veelvoorkomende vereiste is een app die niet bereikbaar is vanaf het openbare internet, maar wel vanaf virtuele machines, privé-eindpunten, gekoppelde netwerken en on-premises netwerken die zijn verbonden via een VPN of Azure ExpressRoute. Deze configuratie vereist dat je zowel het toegankelijkheidsniveau van de omgeving als de zichtbaarheid van de app instelt.

1. Maak de omgeving intern aan, zodat de omgeving geen publiek eindpunt heeft. Internetisolatie komt voort uit deze instelling, en je kunt het niet veranderen nadat je de omgeving hebt aangemaakt. Voor meer informatie, zie Gebruik een virtueel netwerk met Azure Container Apps.

   az containerapp env create \
       --name <ENVIRONMENT_NAME> \
       --resource-group <RESOURCE_GROUP> \
       --infrastructure-subnet-resource-id <SUBNET_RESOURCE_ID> \
       --internal-only true
   

2. Stel de ingang van de app in op extern, zodat de app wordt gepubliceerd via de interne load balancer van de omgeving en clients in het virtuele netwerk deze kunnen bereiken.

   az containerapp ingress enable \
       --name <APP_NAME> \
       --resource-group <RESOURCE_GROUP> \
       --target-port <PORT_NUMBER> \
       --type external
   

Gebruik interne app-ingress alleen voor apps die andere containerapps in dezelfde omgeving aanroepen, zoals een backend-service in een microservices-applicatie.

Protocoltypen

Container Apps ondersteunt twee protocollen voor inkomend verkeer: HTTP en TCP.

HTTP

Als HTTP-inkomend verkeer is ingeschakeld, heeft uw container-app het volgende:

• Ondersteuning voor beëindiging van TLS (Transport Layer Security)
• Ondersteuning voor HTTP/1.1 en HTTP/2
• Ondersteuning voor WebSocket en gRPC
• HTTPS-eindpunten die altijd GEBRUIKMAKEN van TLS 1.2 of 1.3, beëindigd op het ingangspunt
• Eindpunten die poorten 80 (voor HTTP) en 443 (voor HTTPS) beschikbaar maken
  • HTTP-aanvragen naar poort 80 worden standaard automatisch omgeleid naar HTTPS op 443
• Een volledig gekwalificeerde domeinnaam (FQDN)
• De time-out voor de aanvraag is 240 seconden.

HTTP-kopteksten

HTTP-inkomend verkeer voegt headers toe om metagegevens over de clientaanvraag door te geven aan uw container-app. De header wordt bijvoorbeeld X-Forwarded-Proto gebruikt om het protocol te identificeren dat de client heeft gebruikt om verbinding te maken met de Container Apps-service. De volgende tabel bevat de HTTP-headers die relevant zijn voor inkomend verkeer in Container Apps:

TCP

Container Apps ondersteunt andere TCP-protocollen dan HTTP of HTTPS. U kunt bijvoorbeeld TCP-inkomend verkeer gebruiken om een container-app beschikbaar te maken die gebruikmaakt van het Redis-protocol.

Als TCP-inkomend verkeer is ingeschakeld, wordt uw container-app:

• Is toegankelijk voor andere container-apps in dezelfde omgeving via de naam (gedefinieerd door de eigenschap in de name Container Apps-resource) en het weergegeven poortnummer.
• Is extern toegankelijk via de volledig gekwalificeerde domeinnaam (FQDN) en het weergegeven poortnummer als het inkomend verkeer is ingesteld op external.

Aanvullende TCP-poorten

Naast de belangrijkste HTTP/TCP-poort voor uw container-apps, kunt u extra TCP-poorten beschikbaar maken om toepassingen in te schakelen die TCP-verbindingen op meerdere poorten accepteren.

Het volgende is van toepassing op extra TCP-poorten:

• Meer TCP-poorten kunnen alleen extern zijn als de app zelf is ingesteld als extern en de container-app een virtueel netwerk gebruikt.

• Alle extern blootgestelde extra TCP-poorten moeten uniek zijn in de hele Container Apps-omgeving. Dit omvat alle externe extra TCP-poorten, externe hoofd-TCP-poorten en 80/443-poorten die worden gebruikt door ingebouwde HTTP-ingangen. Als de extra poorten intern zijn, kunt u dezelfde poort delen in meerdere apps.

• Voor capaciteitsplanning gebruik een theoretisch maximum van 290 extern blootgestelde aangepaste TCP-poorten per Container Apps-omgeving. Tel zowel de hoofd-TCP-ingresspoorten als extra externe TCP-poorten bij alle apps mee. Als elke TCP-app één externe poort blootlegt, komt dit aantal overeen met 290 TCP-apps. Deze richtlijn geldt ook voor externe app-ingress in een interne omgeving.

• Als er geen beschikbare poort is opgegeven, komt de standaardwaarde van de weergegeven poort overeen met de doelpoort.

• Elke doelpoort moet uniek zijn en dezelfde doelpoort kan niet worden weergegeven op verschillende weergegeven poorten.

• Er zijn maximaal vijf extra poorten per app. Als er extra poorten vereist zijn, opent u een ondersteuningsaanvraag.

• Alleen de hoofdpoort voor inkomend verkeer ondersteunt ingebouwde HTTP-functies zoals CORS en sessieaffiniteit. Wanneer u HTTP boven op de extra TCP-poorten uitvoert, worden deze ingebouwde functies niet ondersteund.

• Poortnummer 36985 is gereserveerd voor interne statuscontroles en is niet beschikbaar voor TCP-toepassingen of extra beschikbare poorten in HTTP-toepassingen.

Zie Inkomend verkeer configureren voor uw app voor meer informatie over hoe u extra poorten kunt inschakelen.

Domeinnamen

U kunt uw app op de volgende manieren openen:

• De standaard FQDN (Fully Qualified Domain Name Name): aan elke app in een Container Apps-omgeving wordt automatisch een FQDN toegewezen op basis van het DNS-achtervoegsel (Domain Name System) van de omgeving. Dit achtervoegsel wordt bepaald door de CONTAINER_APP_ENV_DNS_SUFFIX omgevingsvariabele. Voor het aanpassen van het DNS-achtervoegsel van een omgeving, zie Aangepast DNS-achtervoegsel van de omgeving.

• Een aangepaste domeinnaam: u kunt een aangepast DNS-domein configureren voor uw Container Apps-omgeving. Zie Aangepaste domeinnamen en certificaten voor meer informatie.

• De naam van de app: u kunt de app-naam gebruiken voor communicatie tussen apps in dezelfde omgeving.

Als u de FQDN voor uw app wilt ophalen, raadpleegt u de locatie van de container-app (FQDN).

IP-beperkingen

Container Apps ondersteunt IP-beperkingen voor inkomend verkeer. U kunt regels maken om IP-adressen te configureren die toegang tot uw container-app toestaan of weigeren. Zie IP-beperkingen configureren voor meer informatie.

Verificatie

Azure Container Apps biedt ingebouwde verificatie- en autorisatiefuncties om uw externe container-app met inkomend verkeer te beveiligen. Zie Authentication and authorization in Azure Container Apps voor meer informatie.

U kunt uw app configureren ter ondersteuning van clientcertificaten (mTLS) voor verificatie en verkeersversleuteling. Zie Clientcertificaten configureren voor meer informatie.

Zie de netwerkconfiguratie voor meer informatie over het gebruik van netwerkversleuteling op peer-to-peer-omgevingsniveau.

Opsplitsen van verkeer

Met Containers Apps kunt u binnenkomend verkeer splitsen tussen actieve revisies. Wanneer u een splitsregel definieert, wijst u het percentage inkomend verkeer toe dat naar verschillende revisies gaat. Zie Verkeer splitsen voor meer informatie.

Sessieaffiniteit

Sessieaffiniteit, ook wel plaksessies genoemd, is een functie waarmee u alle HTTP-aanvragen van een client kunt routeren naar dezelfde replica van de container-app. Deze functie is handig voor stateful toepassingen die een consistente verbinding met dezelfde replica vereisen. Zie Sessieaffiniteit voor meer informatie.

Cors (Cross Origin Resource Sharing)

Aanvragen die via de browser worden gedaan vanaf een pagina naar een domein dat niet overeenkomt met het oorspronkelijke domein van de pagina, worden standaard geblokkeerd. Om deze beperking te voorkomen voor services die zijn geïmplementeerd in Container Apps, kunt u CROSS-Origin Resource Sharing (CORS) inschakelen.

Zie Configure CORS in Azure Container Apps voor meer informatie.

Volgende stappen