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:

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

Diagram met een ingressconfiguratie die het inkomend verkeer verdeelt over 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 binnenkomende IP-adres van de Container Apps-omgeving. Als de omgeving gebruikmaakt van een openbaar binnenkomend IP-adres, kan de app verkeer ontvangen van het openbare internet en is deze ook bereikbaar vanuit andere container-apps in dezelfde omgeving.

  • Intern: Maakt de volledig gekwalificeerde domeinnaam (FQDN) van de app alleen bereikbaar vanuit dezelfde Container Apps-omgeving, zoals vanuit andere containerapps. De FQDN van de app is niet direct toegankelijk vanaf het openbare internet. De app kan echter nog steeds extern verkeer 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 is opgenomen in een HTTP-routeconfiguratie, of plaats deze in een aparte omgeving. Voor meer informatie, zie Gebruik regelgebaseerde routing met Azure Container Apps.

Elke container-app in een omgeving kan worden geconfigureerd met verschillende instellingen voor inkomend verkeer. Als u bijvoorbeeld in een scenario met meerdere microservice-apps de beveiliging wilt verhogen, hebt u mogelijk één container-app die openbare aanvragen ontvangt en de aanvragen doorgeeft aan een achtergrondservice. In dit scenario configureert u de openbare container-app met extern inkomend verkeer en de interne container-app met intern inkomend verkeer.

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.

Toegankelijkheidsniveau van de omgeving App-ingang extern
(Verkeer van overal accepteren)
App ingress intern
(Beperkt tot de omgeving voor Container Apps)
Extern Bereikbaar vanaf het openbare internet en via andere apps in de omgeving. Alleen bereikbaar vanuit andere apps in dezelfde omgeving.
interne Bereikbaar vanaf het virtuele netwerk via de interne load balancer, en vanuit andere apps in de omgeving. Niet bereikbaar vanaf het openbare internet. Alleen bereikbaar vanuit andere apps in dezelfde omgeving. Clients elders in het virtuele netwerk ontvangen een HTTP 404-antwoord.

Important

De instellingen voor de app beschrijven de relatie van de app tot zijn omgeving, niet tot het internet. In een interne omgeving publiceert het accepteren van verkeer van overal je app niet op het internet, omdat de omgeving geen openbaar eindpunt heeft. In plaats daarvan publiceert het de app via de interne load balancer van de omgeving, zodat klanten in je virtuele netwerk er toegang toe kunnen krijgen.

Het selecteren van Beperkt tot Container Apps-omgeving voor een interne omgeving is beperkter dan u misschien zou verwachten. Het verbergt de app zowel voor de rest van je virtuele netwerk als voor het internet.

Notitie

Een app met interne ingang kan nog steeds verkeer van buiten de omgeving ontvangen als deze als doel wordt aangeduid in een omgevingsniveau HTTP-routeconfiguratie. Voor meer informatie, zie Gebruik regelgebaseerde routing met Azure Container Apps.

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:

Koptekst Beschrijving Waarden
X-Forwarded-Proto Protocol dat door de client wordt gebruikt om verbinding te maken met de Container Apps-service. http of https. Deze waarde wordt overschreven als deze door de client wordt verzonden.
X-Forwarded-For De IP-adressen van de client en/of tussenliggende proxy's die de aanvraag hebben verzonden. IP-adressen van de afzenders. Als deze is opgegeven in de eerste aanvraag, wordt deze toegevoegd aan. Alleen het rechtst geplaatste IP-adres wordt geleverd door Azure Container Apps. Andere waarden moeten door de gebruiker worden gevalideerd om IP-adresvervalsing te voorkomen.
X-Forwarded-Client-Cert Het clientcertificaat als clientCertificateMode is ingesteld. Door puntkomma's gescheiden lijst met hash, certificaat en keten. Voorbeeld: Hash=....;Cert="...";Chain="...";. Deze waarde wordt overschreven als deze door de client wordt verzonden.

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.

Notitie

Extern TCP-inkomend verkeer wordt alleen ondersteund voor Container Apps-omgevingen die gebruikmaken van een virtueel netwerk.

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.

Notitie

Als u deze functie wilt gebruiken, moet u de CLI-extensie voor container-apps hebben. Voer az extension add -n containerapp deze opdracht uit om de nieuwste versie van de CLI-extensie voor container-apps te installeren.

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.

  • 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