Konfigurer container-runtime-adfærd

  • 8 minutter

Container-runtime-indstillinger styrer, hvordan App Service udfører din container. Disse indstillinger påvirker containeropstart, netværkskonfiguration, filsystemadfærd og sundhedsovervågning. Korrekt konfiguration af disse indstillinger sikrer, at din applikation starter pålideligt og fungerer godt under belastning.

Opstartskommandoer

App Service kører containere ved hjælp af entrypoint og kommando, der er defineret i Dockerfile. Du kan tilsidesætte disse standardindstillinger med en brugerdefineret opstartskommando, når du skal sende runtime-argumenter, køre initialiseringsscripts eller ændre containerens standardadfærd.

Almindelige scenarier for brugerdefinerede opstartskommandoer inkluderer:

  • Overførsel af miljøspecifikke argumenter til applikationen
  • Kør databasemigreringer før opstart af applikationen
  • Start af flere processer i containeren
  • At overskrive standardrammeværkskonfigurationer

Konfigurér en opstartskommando ved hjælp af Azure CLI:

az webapp config set \
    --resource-group myResourceGroup \
    --name myDocumentProcessor \
    --startup-file "gunicorn --bind=0.0.0.0:8000 --workers=4 app:application"

Startkommandoen erstatter CMD-instruktionen fra din Dockerfile. ENTRYPOINT-funktionen forbliver uændret, medmindre du direkte ændrer containerkonfigurationen.

For containere, der kræver shell-behandling, præfikser kommandoen med shell:

az webapp config set \
    --resource-group myResourceGroup \
    --name myDocumentProcessor \
    --startup-file "/bin/bash -c 'python migrate.py && gunicorn app:application'"

Portkonfiguration

App Service skal vide, hvilken port inde i din container der modtager HTTP-forespørgsler. For brugerdefinerede containere kan App Service automatisk rute trafik, når din container lytter på port 80 eller 8080. Hvis din container lytter på en anden port, skal du konfigurere app-indstillingerne WEBSITES_PORT , så App Service videresender anmodninger til den korrekte port.

az webapp config appsettings set \
    --resource-group myResourceGroup \
    --name myDocumentProcessor \
    --settings WEBSITES_PORT=8000

App Service dirigerer al indkommende HTTP- og HTTPS-trafik til den angivne port. Platformen håndterer TLS-terminering, før trafikken når din container, så din container modtager HTTP-trafik, selv når klienter forbinder via HTTPS.

App Service understøtter kun at eksponere én port for HTTP-anmodninger til en brugerdefineret container.

Almindelige portkonfigurationer:

Framework Standardport Indstilling
Node.js (Express) 3000 WEBSITES_PORT=3000
Python (Gunicorn) 8000 WEBSITES_PORT=8000
Java (Spring Boot) 8080 WEBSITES_PORT=8080
ASP.NET Core 80 Ingen ændring er nødvendig

Vedvarende lager

Som standard er skrivninger til containerens filsystem flygtige. Data, der skrives til filsystemet, går tabt, når appen genstarter eller flytter til en anden infrastruktur. Denne adfærd matcher standardcontainerforventninger, men kræver eksplicit planlægning, når din applikation har brug for persistente filer.

App Service kan montere persistent lagring til /home Linux custom containers. Persistent lagring er som standard deaktiveret for Linux brugerdefinerede containere. Når denne lagring aktiveres, genstarter filer, der er skrevet til overlevelse /home af appen, og deles på tværs af alle instanser af en skaleret app.

Aktivér vedvarende lagring ved at sætte app-indstillingen WEBSITES_ENABLE_APP_SERVICE_STORAGE til true:

az webapp config appsettings set \
    --resource-group myResourceGroup \
    --name myDocumentProcessor \
    --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

Med denne indstilling aktiveret:

  • Mappen /home består ved genstarter af containere
  • Alle instanser i en skaleret app deler det samme /home indhold
  • Mappen /home/LogFiles gemmer container- og applikationslogfiler

Konfigurer din applikation til at skrive vedvarende data til /home eller en undermappe. For eksempel kan en dokumentbehandlingstjeneste skrive bearbejdet output til ./home/output/

Lagerkapaciteten afhænger af din App Service-plan. Lagerkvoten deles på tværs af alle apps i planen. For applikationer, der kræver store lagervolumer eller høj I/O-ydelse, bør du overveje at montere Azure Storage som et ekstra volumen.

Altid-på

App Service-apps kan blive inaktive efter cirka 20 minutters inaktivitet. Den næste anmodning udløser en kold start, hvilket betyder, at App Service skal starte appen forfra og vente på, at den er klar. Kolde starter kan tage flere sekunder til minutter afhængigt af billedstørrelse, afhængighedsinitialisering og applikationens opstartstid.

Aktiver altid tændt for at holde din applikation indlæst kontinuerligt:

az webapp config set \
    --resource-group myResourceGroup \
    --name myDocumentProcessor \
    --always-on true

Med always-on aktiveret sender App Service periodiske forespørgsler for at holde applikationen varm. Denne konfiguration eliminerer cold start-latens, men kræver Basic-prisniveauet eller højere.

Always-on anbefales til:

  • Produktionsapplikationer, hvor responstid er vigtig
  • Applikationer med lange opstartstider
  • Beholdere med store billeder, der tager tid at trække
  • Tjenester, der vedligeholder baggrundsprocesser eller forbindelser

Sundhedstjek

Sundhedstjek overvåger containerens responsivitet og genstarter automatisk usunde instanser. App Service sender HTTP-forespørgsler til en specificeret sti og evaluerer svaret for at bestemme containerens sundhed.

Konfigurér en sundhedstjeksti:

az webapp config set \
    --resource-group myResourceGroup \
    --name myDocumentProcessor \
    --generic-configurations '{"healthCheckPath": "/health"}'

Din applikation bør implementere et sundhedsendepunkt, der returnerer en HTTP 200-statuskode, når den er sund. Endepunktet kan udføre kontroller såsom:

  • Verificering af databaseforbindelsen
  • Bekræfter at de nødvendige tjenester er tilgængelige
  • Kontrol af tilgængelig hukommelse eller diskplads

App Service sender en ping til sundhedstjekkets sti hvert minut. Hvis en instans gentagne gange fejler (som standard efter 10 mislykkede pings), fjerner App Service den instans fra load balancer-rotationen. Hvis instansen forbliver usund i længere tid, kan App Service erstatte den.

Ændringer i sundhedstjekkets konfiguration genstart din app, så anvend ændringerne forsigtigt i produktionen.

En simpel implementering af sundhedsendepunkter returnerer en status på 200, når applikationen kan håndtere forespørgsler:

@app.route('/health')
def health_check():
    return {'status': 'healthy'}, 200

For mere avancerede kontroller, verificér afhængigheder og returner passende statuskoder:

@app.route('/health')
def health_check():
    try:
        # Check database connection
        db.execute('SELECT 1')
        # Check storage access
        storage.list_containers()
        return {'status': 'healthy'}, 200
    except Exception as e:
        return {'status': 'unhealthy', 'error': str(e)}, 503

Yderligere ressourcer