Delen via


Statustests en respijtperioden configureren voor apps die worden gehost in Azure Spring Apps

Notitie

De Basic-, Standard- en Enterprise-abonnementen worden afgeschaft vanaf medio maart 2025, met een pensioenperiode van 3 jaar. We raden u aan om over te stappen naar Azure Container Apps. Zie de aankondiging over buitengebruikstelling van Azure Spring Apps voor meer informatie.

Het standaardverbruik en het speciale abonnement worden vanaf 30 september 2024 afgeschaft, met een volledige afsluiting na zes maanden. We raden u aan om over te stappen naar Azure Container Apps. Zie Azure Spring Apps Standard-verbruik en toegewezen abonnement migreren naar Azure Container Apps voor meer informatie.

Dit artikel is van toepassing op: ✔️ Java ✔️ C#

Dit artikel is van toepassing op: ✔️ Basic/Standard ✔️ Enterprise

In dit artikel leest u hoe u apps kunt aanpassen die worden uitgevoerd in Azure Spring Apps met statustests en respijtperioden.

Een test is een diagnostische activiteit die periodiek wordt uitgevoerd door Azure Spring Apps op een app-exemplaar. Voor het uitvoeren van een diagnose voert Azure Spring Apps een van de volgende acties uit:

  • Voert een willekeurige opdracht van uw keuze uit binnen het app-exemplaar.
  • Hiermee wordt een TCP-socketverbinding tot stand gebracht.
  • Hiermee wordt een HTTP-aanvraag ingediend.

Azure Spring Apps biedt standaardregels voor statustests voor elke toepassing. In dit artikel leest u hoe u uw toepassing kunt aanpassen met drie soorten statustests:

  • Liveness-tests bepalen wanneer een toepassing opnieuw moet worden opgestart. Liveness-tests kunnen bijvoorbeeld een impasse identificeren, bijvoorbeeld wanneer een toepassing wordt uitgevoerd, maar geen voortgang kan maken. Als u de toepassing opnieuw start in een impasse, kan de toepassing beschikbaar worden gesteld ondanks fouten.

  • Gereedheidstests bepalen wanneer een app-exemplaar gereed is om verkeer te accepteren. Gereedheidstests kunnen bijvoorbeeld bepalen welke app-exemplaren worden gebruikt als back-ends voor de toepassing. Wanneer een app-exemplaar niet gereed is, wordt deze verwijderd uit kubernetes-servicedetectie. Zie Uw Spring Boot-toepassingen ontdekken en registreren voor meer informatie. Zie Tanzu Service Registry gebruiken voor meer informatie over servicedetectie met het Enterprise-abonnement.

  • Opstarttests bepalen wanneer een toepassing is gestart. Een opstarttest schakelt liveness- en gereedheidscontroles uit totdat het opstarten slaagt, zodat liveness- en gereedheidstests geen invloed hebben op het opstarten van toepassingen. U kunt opstarttests gebruiken om livenesscontroles uit te voeren op trage starttoepassingen, waardoor de app niet kan worden beëindigd voordat deze actief is.

Vereisten

  • Azure CLI met de Azure Spring Apps-extensie. Gebruik de volgende opdracht om eerdere versies te verwijderen en de nieuwste extensie te installeren. Als u de spring-cloud-extensie eerder hebt geïnstalleerd, verwijdert u deze om te voorkomen dat de configuratie en versie niet overeenkomen.

    az extension remove --name spring
    az extension add --name spring
    az extension remove --name spring-cloud
    

Statustests en respijtelijke beëindiging voor toepassingen configureren

In de volgende secties wordt beschreven hoe u statustests en respijtloze beëindiging configureert met behulp van de Azure CLI.

Respijtende beëindiging

In de volgende tabel wordt de terminationGracePeriodSeconds eigenschap beschreven die u kunt gebruiken om respijtvolle beëindiging te configureren.

Eigenschapsnaam Beschrijving
terminationGracePeriodSeconds De duur in seconden nadat processen die in het app-exemplaar worden uitgevoerd, worden een beëindigingssignaal verzonden voordat ze geforceerd worden gestopt. Stel deze waarde langer in dan de verwachte opschoontijd voor uw proces. De waarde moet een niet-negatief geheel getal zijn. Als u de respijtperiode instelt op 0 , stopt het app-exemplaar onmiddellijk via het kill-signaal, zonder de mogelijkheid om af te sluiten. Als de waarde nil is, gebruikt Azure Spring Apps de standaard respijtperiode. De standaardwaarde is 90.

Eigenschappen van statustest

In de volgende tabel worden de eigenschappen beschreven die u kunt gebruiken om statustests te configureren.

Eigenschapsnaam Beschrijving
initialDelaySeconds Het aantal seconden nadat het app-exemplaar is gestart voordat tests worden gestart. De standaardwaarde is 0, de minimumwaarde.
periodSeconds De frequentie in seconden om de test uit te voeren. De standaardwaarde is 10. De minimumwaarde is 1.
timeoutSeconds Het aantal seconden totdat er een time-out optreedt voor de test. De standaardwaarde is 1, de minimumwaarde.
failureThreshold Het minimale aantal opeenvolgende fouten voor de test dat als mislukt moet worden beschouwd nadat de test is geslaagd. De standaardwaarde is 3. De minimumwaarde is 1.
successThreshold Het minimale aantal opeenvolgende geslaagde tests nadat de test is mislukt. De standaardwaarde is 1. De waarde moet 1 zijn voor leven en opstarten. De minimumwaarde is 1.

Eigenschappen van testactie

Er zijn drie manieren waarop u een app-exemplaar kunt controleren met behulp van een test. Elke test moet een van de volgende testacties definiëren:

  • HTTPGetAction

    Voert een HTTP GET-aanvraag uit op het app-exemplaar op een opgegeven pad. De diagnose wordt als geslaagd beschouwd als het antwoord een statuscode heeft die groter is dan of gelijk is aan 200 en kleiner dan 400.

    Eigenschapsnaam Beschrijving
    scheme Het schema dat moet worden gebruikt om verbinding te maken met de host. De standaardwaarde is HTTP.
    path Het pad naar toegang op de HTTP-server van het app-exemplaar, zoals /healthz.
  • ExecAction

    Hiermee wordt een opgegeven opdracht uitgevoerd in het app-exemplaar. De diagnose wordt als geslaagd beschouwd als de opdracht wordt afgesloten met een statuscode van 0.

    Eigenschapsnaam Beschrijving
    command De opdracht die moet worden uitgevoerd in het app-exemplaar. De werkmap voor de opdracht is de hoofdmap (/) in het bestandssysteem van het app-exemplaar. Omdat de opdracht wordt uitgevoerd met behulp van exec in plaats van in een shell, werken shell-instructies niet. Als u een shell wilt gebruiken, roept u expliciet aan bij de shell. Een afsluitstatus van 0 wordt behandeld als live/gezond en niet-nul is beschadigd.
  • TCPSocketAction

    Voert een TCP-controle uit op het app-exemplaar.

    Er zijn geen beschikbare eigenschappen voor de TCPSocketAction actie.

Uw toepassing aanpassen

Gebruik de volgende stappen om uw toepassing aan te passen met behulp van Azure Portal.

  1. Selecteer onder Instellingen de optie Apps en selecteer vervolgens de toepassing in de lijst.

    Schermopname van Azure Portal met de pagina Apps.

  2. Selecteer Configuratie in het linkernavigatiedeelvenster, selecteer Statustests en geef vervolgens de statustesteigenschappen op.

    Schermopname van de azure-portalconfiguratiepagina met het tabblad Statustests.

  3. Als u de respijtperiode voor beëindiging wilt instellen, selecteert u Algemene instellingen en geeft u een waarde op in het vak Respijtperiode voor beëindiging.

    Schermopname van de pagina Configuratie van Azure Portal met het tabblad Algemene instellingen.

Aanbevolen procedures

Gebruik de volgende aanbevolen procedures bij het toevoegen van statustests aan Azure Spring Apps:

  • Gebruik liveness- en gereedheidstests samen. Azure Spring Apps biedt twee benaderingen voor servicedetectie tegelijk. Wanneer de gereedheidstest mislukt, wordt het app-exemplaar alleen verwijderd uit kubernetes-servicedetectie. Een correct geconfigureerde livenesstest kan het uitgegeven app-exemplaar verwijderen uit de Eureka-servicedetectie om onverwachte gevallen te voorkomen. Zie Uw Spring Boot-toepassingen detecteren en registreren voor meer informatie over servicedetectie. Zie Tanzu Service Registry gebruiken voor meer informatie over servicedetectie met het Enterprise-abonnement.

  • Wanneer een app-exemplaar wordt gestart, wordt de eerste controle uitgevoerd na de vertraging die is opgegeven door initialDelaySeconds. Daaropvolgende controles worden periodiek uitgevoerd volgens de periodelengte die is opgegeven door periodSeconds. Als de app niet meerdere keren reageert op de aanvragen zoals opgegeven door failureThreshold, wordt het app-exemplaar opnieuw gestart. Zorg ervoor dat uw toepassing snel genoeg kan worden gestart of werk deze parameters bij, zodat de totale time-out initialDelaySeconds + periodSeconds * failureThreshold langer is dan de begintijd van uw toepassing.

  • Voor Spring Boot-toepassingen wordt Spring Boot geleverd met de ondersteuning voor statusgroepen , zodat ontwikkelaars een subset van statusindicatoren kunnen selecteren en ze kunnen groeperen onder één, gecorreleerde status. Zie Liveness and Readiness Probes with Spring Boot (Liveness and Readiness Probes) (Liveness and Readiness Probes met Spring Boot ) op de Spring Blog voor meer informatie.

    In het volgende voorbeeld ziet u een livenesstest met Spring Boot:

    "probe": {
           "initialDelaySeconds": 30,
           "periodSeconds": 10,
           "timeoutSeconds": 1,
           "failureThreshold": 30,
           "successThreshold": 1,
           "probeAction": {
               "type": "HTTPGetAction",
               "scheme": "HTTP",
               "path": "/actuator/health/liveness"
           }
       }
    

    In het volgende voorbeeld ziet u een gereedheidstest met Spring Boot:

    "probe": {
           "initialDelaySeconds": 0,
           "periodSeconds": 10,
           "timeoutSeconds": 1,
           "failureThreshold": 3,
           "successThreshold": 1,
           "probeAction": {
               "type": "HTTPGetAction",
               "scheme": "HTTP",
               "path": "/actuator/health/readiness"
           }
       }
    

Veelgestelde vragen

In deze sectie vindt u antwoorden op veelgestelde vragen over het gebruik van statustests met Azure Spring Apps.

  • Ik heb een 400-antwoord ontvangen toen ik toepassingen heb gemaakt met aangepaste statustests. Wat betekent dit?

    In het foutbericht wordt opgegeven welke test verantwoordelijk is voor de inrichtingsfout. Zorg ervoor dat de statustestregels juist zijn en dat de time-out lang genoeg is voordat de toepassing de status Actief heeft.

  • Wat zijn de standaardtestinstellingen voor een bestaande toepassing?

    In het volgende voorbeeld ziet u de standaardinstellingen:

    "startupProbe": null,
    "livenessProbe": {
        "disableProbe": false,
        "failureThreshold": 3,
        "initialDelaySeconds": 300,
        "periodSeconds": 10,
        "probeAction": {
            "type": "TCPSocketAction"
        },
        "successThreshold": 1,
        "timeoutSeconds": 3
    },
    "readinessProbe": {
        "disableProbe": false,
        "failureThreshold": 3,
        "initialDelaySeconds": 0,
        "periodSeconds": 5,
        "probeAction": {
            "type": "TCPSocketAction"
        },
        "successThreshold": 1,
        "timeoutSeconds": 3
    }
    

Volgende stappen