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

Du hittar alla Docker-filer på GitHub.

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, det kan du göra 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. Eller så kan du ä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 med namnet WEBSITE_WEBDEPLOY_USE_SCMfalse.

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 på 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 använder du SSH i 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 curl att 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 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 de filer som skrivs bevaras inte mellan omstarter. Om du uttryckligen anger WEBSITES_ENABLE_APP_SERVICE_STORAGEtrue aktiveras monteringen. Om du vill inaktivera monteringen måste du uttryckligen ange false när detta är inställt WEBSITES_ENABLE_APP_SERVICE_STORAGE på true.

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

• Lagring av filsystem: Filsystemlagringen ingår i App Service plankvot. Den används när filer sparas till den beständiga lagring som rotas 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 filsystemets lagringskvot. 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örningsundundanter 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 du kör på 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 konfigurera hur lång tid plattformen ska vänta innan den startar om containern. Det gör du genom att ange 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 avbildningsnamn som använder en anpassad port via portalen. Om du vill ange docker-custom-image-nameanvänder du az kommandoradsverktyget.

Vi stöder inte exponering av fler än en port.

Ja, Bring Your Own Storage finns i förhandsversion.

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

Nej, plattformen hanterar HTTPS-avslutning på 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 till containern.

Ja, skriv över miljövariabeln innan .NET Core-appen startar. T.ex. I init.sh skriptet: export 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-avbildningens namn.

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 din ACR-avbildning 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 är 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 är den första containern som definierats i filen tillgänglig (exponerad)

Alternativet depends_onstöds inte på App Service och ignoreras. Precis som rekommendationen om start och avstängning av kontroll från Docker bör App Service appar med flera containrar 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.

Prissättningen varierar beroende på SKU och region, men du kan se mer information på vår prissida: App Service Prissättning.

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 bara en dummy-slutpunkt, men ditt program måste svara med statuskod som inte är 5XX. Om din programlogik inte svarar med någon HTTP-statuskod till 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 felaktig konfiguration av portar.

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 på 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 databasproviders 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 understreck (_) för programinställningar.

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

Nästa steg

• Vad är Azure App Service i 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.