Vanliga frågor och svar om Azure App Service on Linux

Dessa kommandon eller skript körs när den inbyggda Docker-containern har startats, men innan programkoden startas.

Den här åtgärden är samma som en Docker-omstart.

Ja, du kan göra det via platsen för källkontrollhantering (SCM).

Ange det reserverade fältet för apptjänsten till true.

Ja, för att konfigurera kontinuerlig integrering/distribution för Azure Container Registry eller DockerHub genom att följa Kontinuerlig distribution med Web App for Containers. För privata register kan du uppdatera containern genom att stoppa och sedan starta webbappen. Du kan också ändra eller lägga till en dummy-programinställning för att framtvinga en uppdatering av containern.

Ja.

Ja, du måste ange en appinställning som heter WEBSITE_WEBDEPLOY_USE_SCM false.

Om Git-distributionen misslyckas med linux-webbappen väljer du något av följande alternativ för att distribuera programkoden:

• Använd funktionen Kontinuerlig leverans (förhandsversion): Du kan lagra appens källkod i en Azure DevOps Git-lagringsplats eller GitHub-lagringsplats för att använda Azure Continuous Delivery. Mer information finns i Konfigurera kontinuerlig leverans för Linux-webbapp.

• Använd ZIP-distributions-API:et: Om du vill använda det här API:et går du till webbappen och går till mappen där du vill distribuera koden. Kör följande kod:

  curl -X POST -u <user> --data-binary @<zipfile> https://{your-sitename}.scm.azurewebsites.net/api/zipdeploy
  

  Om du får ett felmeddelande om att curl kommandot inte hittas kontrollerar du att du installerar curl med hjälp apt-get install curl av innan du kör föregående curl kommando.

Ja, inaktivera perMessageDeflate i Node.js kod på serversidan. Om du till exempel använder socket.io använder du följande kod:

const io = require('socket.io')(server,{
  perMessageDeflate :false
});

Ja.

Ja, under en Git-distribution bör Kudu identifiera att du distribuerar ett PHP-program (tack vare förekomsten av en composer.lock-fil) och Kudu utlöser sedan en kompositörsinstallation.

Ja, den här funktionen är tillgänglig från Azure CLI. Du kan använda systemtilldelade eller användartilldelade identiteter. Den här funktionen stöds för närvarande inte i Azure Portal.

Om WEBSITES_ENABLE_APP_SERVICE_STORAGE inställningen är ospecificerad eller inställd på false/home/ delas inte katalogen mellan skalningsinstanser och filer som skrivs bevaras inte i omstarter. Om du uttryckligen anger WEBSITES_ENABLE_APP_SERVICE_STORAGE true aktiveras monteringen. Om du vill inaktivera monteringen när detta är inställt på sant måste du uttryckligen ange WEBSITES_ENABLE_APP_SERVICE_STORAGE falskt.

App Service på Linux använder två olika typer av lagring:

• Lagring av filsystem: Filsystemlagringen ingår i App Service-plankvoten. Den används när filer sparas i den beständiga lagring som är rotad i /home katalogen.
• Värddiskutrymme: Värddiskutrymmet används för att lagra containeravbildningar. Den hanteras av plattformen via Docker-lagringsdrivrutinen.

Värddiskutrymmet är separat från lagringskvoten för filsystemet. Den kan inte expanderas och det finns en gräns på 15 GB för varje instans. Den används för att lagra anpassade avbildningar på arbetaren. Du kanske kan använda större än 15 GB beroende på den exakta tillgängligheten för värddiskutrymmet, men detta är inte garanterat.

Om containerns skrivbara lager sparar data utanför /home katalogen eller en monterad Azure Storage-sökväg används även värddiskutrymmet.

Plattformen rensar rutinmässigt värddiskutrymmet för att ta bort oanvända containrar. Om containern skriver en stor mängd data utanför /home katalogen eller BYOS (Bring Your Own Storage) resulterar det i startfel eller körningsundatag när diskutrymmesgränsen för värddisken överskrids.

Vi rekommenderar att du håller dina containeravbildningar så små som möjligt och skriver data till den beständiga lagringen eller BYOS när de körs i Linux App Service. Om det inte är möjligt måste du dela Upp App Service-planen eftersom värddiskutrymmet är fast och delat mellan alla containrar i App Service-planen.

Du kan ange hur lång tid plattformen ska vänta innan den startar om containern. Om du vill göra det anger du appinställningen WEBSITES_CONTAINER_START_TIME_LIMIT till önskat värde. Standardvärdet är 230 sekunder och det maximala värdet är 1 800 sekunder.

Ange den fullständiga register-URL:en, inklusive http:// eller https://.

Lägg till det fullständiga avbildningsnamnet, inklusive url:en för det privata registret (till exempel myacr.azurecr.io/dotnet:latest). Det går inte att ange bildnamn som använder en anpassad port via portalen. Om du vill ange docker-custom-image-nameanvänder du az kommandoradsverktyget.

Vi har inte stöd för att exponera fler än en port.

Ja, bring your own storage är i förhandsversion.

SCM-platsen körs i en separat container. Du kan inte kontrollera filsystemet eller köra processer i appcontainern.

Nej, plattformen hanterar HTTPS-avslutning i delade klientdelar.

Ja, detta krävs för anpassade containrar. Om du vill konfigurera en anpassad port manuellt använder du instruktionen EXPOSE i Dockerfile och appinställningen WEBSITES_PORT med ett portvärde som ska bindas på containern.

Ja, skriv över miljövariabeln innan .NET Core-appen startar. T.ex. I init.sh skriptet: exportera ASPNETCORE_URLS={Ditt värde}

För att kunna använda ACR med flera containrar måste alla containeravbildningar finnas på samma ACR-registerserver. När de finns på samma registerserver måste du skapa programinställningar och sedan uppdatera Docker Compose-konfigurationsfilen så att den innehåller ACR-avbildningsnamnet.

Skapa följande programinställningar:

• DOCKER_REGISTRY_SERVER_USERNAME
• DOCKER_REGISTRY_SERVER_URL (fullständig URL, till exempel ) https://<server-name>.azurecr.io
• DOCKER_REGISTRY_SERVER_PASSWORD (aktivera administratörsåtkomst i ACR-inställningar)

I konfigurationsfilen refererar du till ACR-avbildningen som i följande exempel:

image: <server-name>.azurecr.io/<image-name>:<tag>

• Endast en container kan vara öppen för åtkomst
• Endast port 80 och 8080 är tillgängliga (exponerade portar)

Här följer reglerna för att avgöra vilken container som är tillgänglig – i prioritetsordning:

• Programinställningen WEBSITES_WEB_CONTAINER_NAME inställd på containernamnet
• Den första containern som definierar port 80 eller 8080
• Om inget av ovanstående är sant kommer den första containern som definierats i filen att vara tillgänglig (exponerad)

Alternativet depends_on stöds inte i App Service och ignoreras. Precis som rekommendationen för start och avstängning av kontroll från Docker bör App Service Multi-container-appar kontrollera beroenden via programkod – både vid start och frånkoppling. Exempelkoden nedan visar en Python-app som kontrollerar om en Redis-container körs.

import time
import redis
from flask import Flask
app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)
def get_hit_count():
    retries = 5
    while True:
        try:
            return cache.incr('hits')
        except redis.exceptions.ConnectionError as exc:
            if retries == 0:
                raise exc
            retries -= 1
            time.sleep(0.5)
@app.route('/')
def hello():
    count = get_hit_count()
    return 'Hello from Azure App Service team! I have been seen {} times.\n'.format(count)
if __name__ == "__main__":
    app.run(host="0.0.0.0", port=80, debug=True)

Web Sockets

Web Sockets stöds i Linux-appar. webSocketsEnabled ARM-inställningen gäller inte för Linux-appar eftersom Web Sockets alltid är aktiverade för Linux.

Priserna varierar beroende på SKU och region, men du kan se mer information på vår prissida: Priser för App Service.

När Azure App Services startar containern skickar uppvärmningsbegäran en HTTP-begäran till slutpunkten /robots933456.txt för ditt program. Det här är helt enkelt en dummyslutpunkt, men ditt program måste svara med valfri statuskod som inte är 5XX. Om din programlogik inte svarar med någon HTTP-statuskod på obefintliga slutpunkter kan uppvärmningsbegäran inte ta emot något svar och den startar ständigt om containern. Uppvärmningsbegäran kan också misslyckas på grund av felkonfiguration av porten.

Se frågan Hur gör jag för att ange port i min Linux-container för att säkerställa att porten är korrekt konfigurerad i Azure App Services?

Uppvärmningsbegäran misslyckas som standard efter att ha väntat i 240 sekunder på ett svar från containern. Du kan öka tidsgränsen för containerns uppvärmningsbegäran genom att lägga till programinställningen WEBSITES_CONTAINER_START_TIME_LIMIT med ett värde mellan 240 och 1 800 sekunder.

Filsystemet i ditt program är en monterad nätverksresurs. På så sätt kan du skala ut scenarier där koden måste köras över flera värdar. Tyvärr blockerar detta användningen av filbaserade databasprovidrar som SQLite eftersom det inte går att hämta exklusiva lås på databasfilen. Vi rekommenderar en hanterad databastjänst: Azure SQL, Azure Database for MySQL eller Azure Database for PostgreSQL

Du kan bara använda bokstäver (A-Z, a-z), siffror (0-9) och understreckstecknet (_) för programinställningar.

Du kan skicka in din idé på feedbackforumet för Web Apps. Lägg till "[Linux]" i namnet på din idé.

Nästa steg

• Vad är Azure App Service på Linux?
• Konfigurera mellanlagringsmiljöer i Azure App Service
• Kontinuerlig distribution med Web App for Containers
• Saker du bör känna till: Web Apps och Linux
• Referens för miljövariabler och appinställningar

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.