Hoe u Azure Functions-runtimeversies doelgericht kunt gebruiken

Een functie-app wordt uitgevoerd op een specifieke versie van de Azure Functions-runtime. Standaard maakt u functie-apps in de nieuwste 4.x-versie van de Functions-runtime. Uw functie-apps worden alleen ondersteund wanneer ze worden uitgevoerd op een ondersteunde primaire versie. In dit artikel wordt uitgelegd hoe u een functie-app in Azure configureert om op een specifieke versie van de Functions-runtime te richten of vast te zetten, indien nodig.

Overwegingen

Houd rekening met deze overwegingen bij het gebruik van een specifieke runtime-versie:

  • Het Flex Consumption-abonnement wordt alleen uitgevoerd op versie 4.x van de runtime. Omdat het Flex Consumption-abonnement de FUNCTIONS_EXTENSION_VERSION-appinstelling niet ondersteunt, kan uw app geen specifieke runtimeversie gebruiken in dit abonnement.
  • De manier waarop u zich richt op een specifieke versie, is afhankelijk van of u Windows of Linux gebruikt.
  • Dit artikel is specifiek voor Windows of Linux. Kies uw besturingssysteem bovenaan het artikel.
  • Voer indien mogelijk uw app altijd uit op de meest recente ondersteunde runtimeversie. Maak uw app alleen vast aan een specifieke versie als u dit moet doen vanwege een probleem met de nieuwste versie. Ga altijd naar de nieuwste runtimeversie zodra uw functies correct kunnen worden uitgevoerd.
  • Tijdens lokale ontwikkeling moet uw geïnstalleerde versie van Azure Functions Core Tools overeenkomen met de primaire runtimeversie die wordt gebruikt door de functie-app in Azure. Zie Core Tools-versies voor meer informatie.

Uw runtimeversie bijwerken

Voer, indien mogelijk, altijd uw functie-apps uit op de meest recente ondersteunde versie van de Azure Functions-runtime. Als uw functie-app momenteel wordt uitgevoerd op een oudere versie van de runtime, migreert u uw app naar versie 4.x.

Wanneer uw app bestaande functies heeft, moet u voorzorgsmaatregelen nemen voordat u overstapt op een latere primaire runtimeversie. In de volgende artikelen worden brekende wijzigingen tussen hoofdversies beschreven, waaronder taalspecifieke brekende wijzigingen. Ze bieden u ook stapsgewijze instructies voor een geslaagde migratie van uw bestaande functie-app.

Zie De huidige runtimeversie weergeven om de huidige runtimeversie te bepalen.

De huidige runtimeversie weergeven

U kunt de huidige runtimeversie van uw functie-app op een van de volgende manieren bekijken:

Voer de volgende stappen uit om de runtimeversie weer te geven en bij te werken die momenteel wordt gebruikt door een functie-app:

  1. Blader in de Azure-portal naar uw functie-app.

  2. Vouw Instellingen uit en selecteer Vervolgens Configuratie.

  3. Noteer de runtime-versie op het tabblad Runtime-instellingen. In dit voorbeeld is de versie ingesteld op ~4.

    Schermafbeelding waarin wordt getoond hoe u de runtimeversie kunt bekijken.

Vastmaken aan een specifieke versie

Met Azure Functions kunt u de FUNCTIONS_EXTENSION_VERSION app-instelling gebruiken om de runtimeversie te targeten die wordt gebruikt door een bepaalde functie-app. Als u alleen de primaire versie (~4) opgeeft, wordt de functie-app automatisch bijgewerkt naar nieuwe secundaire versies van de runtime zodra deze beschikbaar komen. Secundaire versie-updates zijn automatisch omdat nieuwe secundaire versies waarschijnlijk geen wijzigingen introduceren die uw functies breken.

Linux-apps gebruiken de linuxFxVersion site-instelling samen FUNCTIONS_EXTENSION_VERSION om de juiste Linux-basisinstallatiekopieën te bepalen waarin u uw functies kunt uitvoeren. Wanneer u een nieuwe functie-app op Linux maakt, kiest de runtime automatisch de juiste basisimage voor u op basis van de runtimeversie van uw taalstack.

Het vastzetten van een specifieke runtimeversie herstart uw functie-app.

Wanneer u een specifieke secundaire versie (zoals 4.0.12345) opgeeft FUNCTIONS_EXTENSION_VERSION, maakt u de functie-app vast aan die specifieke versie van de runtime totdat u expliciet wilt terugkeren naar automatische versie-updates. Maak alleen vast aan een specifieke secundaire versie die lang genoeg is om eventuele problemen met uw functie-app op te lossen die voorkomen dat u zich richt op de primaire versie. Oudere secundaire versies worden regelmatig verwijderd uit de productieomgeving. Wanneer uw functie-app is vastgemaakt aan een secundaire versie die later wordt verwijderd, wordt uw functie-app uitgevoerd op de dichtstbijzijnde bestaande versie in plaats van de versie die is ingesteld in FUNCTIONS_EXTENSION_VERSION. App Service-aankondigingen kondigen kleine versieverwijderingen aan.

Notitie

Wanneer u vanuit Visual Studio probeert te publiceren naar een app die is vastgemaakt aan een specifieke secundaire versie van de runtime, wordt u gevraagd om bij te werken naar de nieuwste versie of de publicatie te annuleren. Als u deze controle wilt voorkomen wanneer u een specifieke secundaire versie moet gebruiken, voegt u de <DisableFunctionExtensionVersionUpdate>true</DisableFunctionExtensionVersionUpdate> eigenschap toe aan uw .csproj bestand.

Gebruik een van deze methoden om uw app tijdelijk vast te maken aan een specifieke versie van de runtime:

Voer de volgende stappen uit om de runtimeversie weer te geven en bij te werken die momenteel wordt gebruikt door een functie-app:

  1. Blader in de Azure-portal naar uw functie-app.

  2. Vouw Instellingen uit en selecteer Vervolgens Configuratie.

  3. Noteer de runtime-versie op het tabblad Runtime-instellingen. In dit voorbeeld is de versie ingesteld op ~4.

    Schermafbeelding waarin wordt getoond hoe u de runtimeversie kunt bekijken.

  1. Als u uw app wilt vastzetten op een specifieke minor-versie, vouwt u in het linkerdeelvenster Instellingen uit en selecteert u vervolgens Omgevingsvariabelen.

  2. Selecteer op het tabblad App settingsFUNCTIONS_EXTENSION_VERSION, wijzig Value naar de vereiste minor-versie en selecteer vervolgens Apply.

  3. Selecteer Toepassen en selecteer Bevestigen om de wijzigingen toe te passen en de app opnieuw op te starten.

De functie-app wordt opnieuw opgestart nadat de wijziging is aangebracht in de toepassingsinstelling.

Als u uw functie-app wilt vastmaken op een specifieke runtimeversie op Linux, stelt u een versiespecifieke basis-image-URL in de linuxFxVersion site-instellingen in het formaat DOCKER|<PINNED_VERSION_IMAGE_URI>in.

Belangrijk

Vastgemaakte functie-apps op Linux ontvangen geen regelmatige updates voor beveiliging en hostfunctionaliteit. Gebruik, tenzij aanbevolen door een ondersteuningsmedewerker, de FUNCTIONS_EXTENSION_VERSION instelling en een standaardwaarde linuxFxVersion voor uw taal en versie, zoals Python|3.12. Zie het linuxFxVersion naslagartikel voor geldige waarden.

Vastmaken aan een specifieke runtime wordt momenteel niet ondersteund voor Linux-functie-apps die worden uitgevoerd in een verbruiksabonnement.

In het volgende voorbeeld ziet u de waarde die is vereist voor het linuxFxVersion vastmaken van een Node.js 22-functie-app aan een specifieke runtimeversie van 4.14.0.3:

DOCKER|mcr.microsoft.com/azure-functions/node:4.14.0.3-node22

Indien nodig kan een supportmedewerker u een geldige basisimage-URI voor uw applicatie verstrekken.

Gebruik de volgende Azure CLI-opdrachten om de linuxFxVersionopdracht weer te geven en in te stellen. U kunt momenteel niet instellen linuxFxVersion in de portal of met behulp van Azure PowerShell:

  • Als u de huidige runtimeversie wilt weergeven, gebruikt u de opdracht az functionapp config show :

    az functionapp config show --name <function_app> \
    --resource-group <my_resource_group> --query 'linuxFxVersion' -o tsv
    

    Vervang in deze code door <function_app> de naam van uw functie-app. Vervang <my_resource_group> ook door de naam van de resourcegroep voor uw functie-app. De huidige waarde van linuxFxVersion wordt geretourneerd.

  • Als u de linuxFxVersion instelling in de functie-app wilt bijwerken, gebruikt u de opdracht az functionapp config set :

    az functionapp config set --name <FUNCTION_APP> \
    --resource-group <RESOURCE_GROUP> \
    --linux-fx-version <LINUX_FX_VERSION>
    

    Vervang door <FUNCTION_APP> de naam van uw functie-app. Vervang <RESOURCE_GROUP> ook door de naam van de resourcegroep voor uw functie-app. Vervang <LINUX_FX_VERSION> ten slotte door de waarde van een specifieke afbeelding die door een supportmedewerker aan u is verstrekt.

U kunt deze opdrachten uitvoeren vanuit Azure Cloud Shell door Open Cloud Shell te kiezen in de voorgaande codevoorbeelden. U kunt de Azure CLI ook lokaal gebruiken om deze opdracht uit te voeren nadat u az login zich hebt aangemeld.

De functie-app wordt opnieuw opgestart nadat de wijziging is aangebracht in de siteconfiguratie.

Werk het beheerde Linux-image bij

Deze sectie geldt alleen voor bestaande Python 3.11 en Java 8, 11 of 17 apps op Linux Elastic Premium of Dedicated (App Service) plannen die een Debian Bullseye managed image gebruiken. Als je app niet aan al deze voorwaarden voldoet, hoef je deze procedure niet te volgen.

Het nieuwere beheerde image biedt een tijdelijk pad voor een getroffen app om op zijn huidige taalversie te blijven terwijl deze overstapt naar een ondersteunde Linux-distributie. Deze procedure geldt niet voor Flex Consumption of aangepaste container-apps. Voor een app op het Linux Consumption-abonnement, migrer naar het Flex Consumption-abonnement.

Deze update selecteert de Linux-distributie voor de bestaande taalversie door gebruik te maken van een driedelige linuxFxVersion waarde. Het koppelt de Functions-host niet aan een specifiek DOCKER|<IMAGE_URI> image.

Kies een Bookworm- of NoblelinuxFxVersion-waarde

Bepaal eerst of je de taalversie kunt updaten of de huidige taalversie moet behouden en selecteer een nieuwere Linux-distributie.

  1. Overweeg om de app te updaten naar een nieuwere taalversie die wordt ondersteund. Na een taalupdate gebruikt de app de huidige standaard beheerde afbeelding voor die taalversie.

  2. Als de app op de huidige taalversie moet blijven, kies dan de bijbehorende nieuwere afbeeldingswaarde:

    Taalversie Debian Bullseye-waarde Nieuwere verspreiding Nieuwere beeldwaarde
    Python 3.11 Python\|3.11\|2.0 Debian Boekenwurm Python\|3.11\|3.0
    Java 8 Java\|8\|2.0 Ubuntu Noble Java\|8\|4.0
    Java 11 Java\|11\|2.0 Ubuntu Noble Java\|11\|4.0
    Java 17 Java\|17\|2.0 Ubuntu Noble Java\|17\|4.0

    Deze driedelige waarden selecteren expliciet het beheerde Linux-image voor deze Bullseye-era images. Ze worden niet teruggegeven door het az functionapp list-runtimes commando.

Test het nieuwere beheerde Linux-image

Test je app en de afhankelijkheden van de nieuwere image voordat je de productie-app bijwerkt.

  1. Maak een aparte testapp of maak een deploymentslot aan.

  2. Implementeer dezelfde code en configuratie als je productie-app gebruikt naar de test-app of het slot.

  3. Stel de nieuwere afbeeldingswaarde in door de stappen in Bijwerken de afbeeldingswaarde te volgen. Wanneer je een slot gebruikt, neem je --slot <SLOT_NAME> op in elke Azure CLI-opdracht.

  4. Roep elke functie aan en controleer of de app succesvol start, de triggers zoals verwacht draaien en dat de native of besturingssysteemafhankelijkheden correct worden geladen.

Werk de beeldwaarde bij

Het wijzigen van de afbeeldingswaarde start de functie-app opnieuw. Werk de productie bij tijdens een onderhoudsperiode, of gebruik een deployment slot.

  1. Bekijk de huidige linuxFxVersion waarde:

    az functionapp config show --name <APP_NAME> \
      --resource-group <RESOURCE_GROUP> \
      --query linuxFxVersion --output tsv
    

    Dit commando geeft de waarde terug die in de siteconfiguratie is opgeslagen. De teruggegeven waarde kan alleen de taal en taalversie bevatten, zoals Python|3.11, in plaats van de driedelige waarde die de Linux-distributie identificeert. Als de waarde de imageversie niet bevat, volg dan de stappen in Verify the Linux-distributie om te bevestigen dat de app momenteel Debian Bullseye gebruikt.

  2. Stel linuxFxVersion in op de nieuwere afbeeldingswaarde:

    az functionapp config set --name <APP_NAME> \
      --resource-group <RESOURCE_GROUP> \
      --linux-fx-version "<LANGUAGE|VERSION|IMAGE_VERSION>"
    

    Voor Python 3.11 op Debian Bookworm, gebruik Python|3.11|3.0. Voor Java op Ubuntu Noble gebruik Java|8|4.0, Java|11|4.0, of Java|17|4.0.

  3. Wacht tot de app opnieuw opstart.

Controleer de Linux-distributie

Controleer zowel de geconfigureerde waarde als de Linux-distributie die je app draait.

  1. Bevestig de bijgewerkte linuxFxVersion waarde:

    az functionapp config show --name <APP_NAME> \
      --resource-group <RESOURCE_GROUP> \
      --query linuxFxVersion --output tsv
    

    Omdat je expliciet een driedelige waarde instelt, geeft dit commando precies de Bookworm- of Noble-waarde terug die je hebt gekozen.

  2. Open de Kudu-site van de app op https://<APP_NAME>.scm.azurewebsites.net.

  3. Selecteer Omgeving en bekijk KUDU_ENV, of open een SSH-sessie en voer uit:

    cat /etc/os-release
    
  4. Bevestig dat de output Debian Bookworm voor Python 3.11 identificeert of Ubuntu Noble voor Java 8, 11 of 17.

  5. Roep elke functie aan en bevestig dat triggers en afhankelijkheden blijven werken zoals verwacht.

Draai de update van de beheerde Linux-installatiekopie terug

Als de bijgewerkte image een compatibiliteitsprobleem veroorzaakt, herstel dan tijdelijk de vorige linuxFxVersion waarde terwijl je het probleem oplost.

Warning

Debian Bullseye wordt na de einddatum niet meer ondersteund en ontvangt geen beveiligingsupdates meer. Gebruik rollback alleen als tijdelijke mitigatie en keer zo snel mogelijk terug naar een ondersteund image.

  1. Zoek in de tabel in Kies een Bookworm- of Noble-waarde linuxFxVersion de Debian Bullseye-waarde voor uw taalversie.

  2. Stel linuxFxVersion in op die Bullseye-waarde:

    az functionapp config set --name <APP_NAME> \
      --resource-group <RESOURCE_GROUP> \
      --linux-fx-version "<BULLSEYE_LINUX_FX_VERSION>"
    
  3. Wacht tot de app opnieuw is opgestart en herhaal dan de controles in Controleer de Linux-distributie.

Volgende stappen