Share via

Distribuire un flusso nell'endpoint online per l'inferenza in tempo reale con l'interfaccia della riga di comando

  • Articolo

Questo articolo illustra come distribuire il flusso in un endpoint online gestito o in un endpoint online Kubernetes da usare nell'inferenza in tempo reale con l'interfaccia della riga di comando di Azure Machine Learning v2.

Prima di iniziare, verificare di aver testato correttamente il flusso e assicurarsi che sia pronto per la distribuzione nell'ambiente di produzione. Per altre informazioni sul test del flusso, vedere Testare il flusso. Dopo aver testato il flusso si apprenderà come creare un endpoint e una distribuzione online gestiti e come usare l'endpoint per l'inferenza in tempo reale.

  • Questo articolo illustra come usare l'esperienza CLI.
  • Python SDK non è trattato in questo articolo. Vedere invece il notebook di esempio di GitHub. Per usare Python SDK, è necessario avere Python SDK v2 per Azure Machine Learning. Per altre informazioni, vedere Installare Python SDK v2 per Azure Machine Learning.

Importante

Gli elementi contrassegnati (anteprima) in questo articolo sono attualmente disponibili in anteprima pubblica. La versione di anteprima viene messa a disposizione senza contratto di servizio e non è consigliata per i carichi di lavoro di produzione. Alcune funzionalità potrebbero non essere supportate o potrebbero presentare funzionalità limitate. Per altre informazioni, vedere le Condizioni supplementari per l'uso delle anteprime di Microsoft Azure.

Prerequisiti

  • L'interfaccia della riga di comando di Azure e l'estensione di Azure Machine Learning per l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Installare, configurare e usare l'interfaccia della riga di comando (v2).
  • Un'area di lavoro di Azure Machine Learning. Se non è disponibile, seguire la procedura descritta nell'articolo Avvio rapido: Creare risorse dell'area di lavoro per crearne una.
  • I controlli degli accessi in base al ruolo di Azure vengono usati per concedere l'accesso alle operazioni in Azure Machine Learning. Per eseguire la procedura descritta in questo articolo, all'account utente deve essere assegnato il ruolo di proprietario o collaboratore per l'area di lavoro di Azure Machine Learning oppure un ruolo personalizzato che consenta "Microsoft.MachineLearningServices/workspaces/onlineEndpoints/". Se si usa Studio per creare/gestire endpoint/distribuzioni online, è necessaria un'autorizzazione aggiuntiva "Microsoft.Resources/deployments/write" dal proprietario del gruppo di risorse. Per altre informazioni, vedere Gestire l'accesso a un'area di lavoro di Azure Machine Learning.

Nota

L'endpoint online gestito supporta solo la rete virtuale gestita. Se l'area di lavoro si trova in una rete virtuale personalizzata, è possibile eseguire la distribuzione nell'endpoint online kubernetes o distribuirla in altre piattaforme, ad esempio Docker.

Allocazione della quota di macchine virtuali per la distribuzione

Per gli endpoint online gestiti, Azure Machine Learning riserva il 20% delle risorse di calcolo per l'esecuzione degli aggiornamenti. Se, quindi, si richiede un determinato numero di istanze in una distribuzione, è necessario che sia disponibile una quota per ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU per evitare che venga restituito un errore. Ad esempio, se si richiedono 10 istanze di una macchina virtuale Standard_DS3_v2 (fornita con quattro core) in una distribuzione, è necessario che sia disponibile una quota per 48 core (12 istanze per quattro core). Per visualizzare gli incrementi relativi all'utilizzo e alla quota di richieste, vedere Visualizzare l'utilizzo e le quote nel portale di Azure.

Preparare il flusso per la distribuzione

Ogni flusso includerà una cartella che contiene codici/prompt, definizione e altri artefatti del flusso. Se il flusso è stato sviluppato con l'interfaccia utente, è possibile scaricare la cartella del flusso dalla pagina dei dettagli del flusso. Se il flusso è stato sviluppato con l'interfaccia della riga di comando o con l'SDK, la cartella del flusso dovrebbe già essere disponibile.

In questo articolo si userà il flusso di esempio "basic-chat" come esempio per la distribuzione nell'endpoint online gestito di Azure Machine Learning.

Importante

Se è stato usato additional_includes nel flusso, è prima necessario usare pf flow build --source <path-to-flow> --output <output-path> --format docker per ottenere una versione risolta della cartella del flusso.

Impostare l'area di lavoro predefinita

Usare i comandi seguenti per impostare l'area di lavoro e il gruppo di risorse predefiniti per l'interfaccia della riga di comando.

az account set --subscription <subscription ID>
az configure --defaults workspace=<Azure Machine Learning workspace name> group=<resource group>

Registrare il flusso come modello (facoltativo)

Nella distribuzione online è possibile fare riferimento a un modello registrato oppure specificare il percorso del modello (da cui caricare i file del modello) inline. È consigliabile registrare il modello e specificare il nome e la versione del modello nella definizione della distribuzione. Usare il formato model:<model_name>:<version>.

Di seguito è riportato un esempio di definizione del modello per un flusso di chat.

Nota

Se il flusso non è un flusso di chat, non è necessario aggiungere questi elementi properties.

$schema: https://azuremlschemas.azureedge.net/latest/model.schema.json
name: basic-chat-model
path: ../../../../examples/flows/chat/basic-chat
description: register basic chat flow folder as a custom model
properties:
  # In AuzreML studio UI, endpoint detail UI Test tab needs this property to know it's from prompt flow
  azureml.promptflow.source_flow_id: basic-chat
  
  # Following are properties only for chat flow 
  # endpoint detail UI Test tab needs this property to know it's a chat flow
  azureml.promptflow.mode: chat
  # endpoint detail UI Test tab needs this property to know which is the input column for chat flow
  azureml.promptflow.chat_input: question
  # endpoint detail UI Test tab needs this property to know which is the output column for chat flow
  azureml.promptflow.chat_output: answer

Usare az ml model create --file model.yaml per registrare il modello nell'area di lavoro.

Definire l'endpoint

Per definire un endpoint, è necessario specificare:

  • Nome endpoint: nome dell'endpoint. Deve essere univoco nell'area di Azure. Per altre informazioni sulle regole di denominazione, vedere Limiti degli endpoint.
  • Modalità di autenticazione: metodo di autenticazione per l'endpoint. Scegliere tra l'autenticazione basata su chiave e l'autenticazione basata su token di Azure Machine Learning. Una chiave non scade, a differenza di un token. Per altre informazioni sull'autenticazione, vedere Eseguire l'autenticazione a un endpoint online. Facoltativamente, è possibile aggiungere una descrizione e tag all'endpoint.
  • Facoltativamente, è possibile aggiungere una descrizione e tag all'endpoint.
  • Se si vuole eseguire la distribuzione in un cluster Kubernetes (servizio Azure Kubernetes o cluster con abilitazione di Arc) che si connette all'area di lavoro, è possibile distribuire il flusso come endpoint online Kubernetes.

Di seguito è riportato un esempio di definizione dell'endpoint che per impostazione predefinita usa l'identità assegnata dal sistema.

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineEndpoint.schema.json
name: basic-chat-endpoint
auth_mode: key
properties:
# this property only works for system-assigned identity.
# if the deploy user has access to connection secrets, 
# the endpoint system-assigned identity will be auto-assigned connection secrets reader role as well
  enforce_access_to_default_secret_stores: enabled
Chiave Descrizione
$schema (Facoltativo) Schema YAML. Per vedere tutte le opzioni disponibili nel file YAML, è possibile visualizzare in un browser lo schema incluso nel frammento di codice precedente.
name Nome dell'endpoint.
auth_mode Usare key per l'autenticazione basata su chiave. Usare aml_token per l'autenticazione basata su token di Azure Machine Learning. Per ottenere il token più recente, usare il comando az ml online-endpoint get-credentials.
property: enforce_access_to_default_secret_stores (anteprima) - Per impostazione predefinita, l'endpoint userà l'identità assegnata dal sistema. Questa proprietà funziona solo per l'identità assegnata dal sistema.
- Questa proprietà indica che, se si dispone dell'autorizzazione di lettura per i segreti della connessione, all'identità dell'endpoint assegnata dal sistema verrà assegnato automaticamente il ruolo Lettore di segreti di connessione dell'area di lavoro di Azure Machine Learning, in modo che l'endpoint possa accedere correttamente alle connessioni quando esegue l'inferenza.
- Per impostazione predefinita, questa proprietà è impostata su "disabled".

Se si crea un endpoint online Kubernetes, è necessario specificare gli attributi aggiuntivi seguenti:

Chiave Descrizione
compute Destinazione di calcolo di Kubernetes in cui distribuire l'endpoint.

Per altre configurazioni dell'endpoint, vedere Schema dell'endpoint online gestito.

Importante

Se il flusso usa connessioni di autenticazione basate su ID Entra di Microsoft, indipendentemente dall'uso dell'identità assegnata dal sistema o dell'identità assegnata dall'utente, è sempre necessario concedere all'identità gestita i ruoli appropriati delle risorse corrispondenti in modo che possa effettuare chiamate API a tale risorsa. Ad esempio, se la connessione OpenAI di Azure usa l'autenticazione basata su ID Entra di Microsoft, è necessario concedere all'identità gestita dall'endpoint il ruolo Di collaboratore OpenAI OpenAI o OpenAI di Servizi cognitivi delle risorse OpenAI di Azure corrispondenti.

Usare l'identità assegnata dall'utente

Per impostazione predefinita, quando si crea un endpoint online, viene generata automaticamente un'identità gestita assegnata dal sistema. È anche possibile specificare per l'endpoint un'identità gestita esistente assegnata dall'utente.

Se si vuole usare l'identità assegnata dall'utente, è possibile specificare gli attributi aggiuntivi seguenti in endpoint.yaml:

identity:
  type: user_assigned
  user_assigned_identities:
    - resource_id: user_identity_ARM_id_place_holder

È inoltre anche necessario specificare l'elemento Client ID dell'identità assegnata dall'utente in environment_variables nel file deployment.yaml come indicato di seguito. Client ID è disponibile nella sezione Overview dell'identità gestita nel portale di Azure.

environment_variables:
  AZURE_CLIENT_ID: <client_id_of_your_user_assigned_identity>

Importante

È necessario concedere le autorizzazioni seguenti all'identità assegnata dall'utente prima di creare l'endpoint in modo che possa accedere alle risorse di Azure per eseguire l'inferenza. Altre informazioni su come concedere le autorizzazioni all'identità dell'endpoint.

Ambito Ruolo Perché è necessario
Area di lavoro di Azure Machine Learning Il ruolo Lettore segreti della connessione area di lavori di Azure Machine Learning OPPURE un ruolo personalizzato con "Microsoft.MachineLearningServices/workspaces/connections/listsecrets/action" Ottenere le connessioni all'area di lavoro
Registro contenitori dell'area di lavoro Pull record di controllo di accesso Eseguire il pull dell'immagine del contenitore
Archiviazione predefinita dell'area di lavoro Lettore dei dati del BLOB di archiviazione Caricare il modello dall'archiviazione
(Facoltativo) Area di lavoro di Azure Machine Learning Writer delle metriche dell'area di lavoro Dopo aver distribuito l'endpoint, se si desidera monitorare le metriche correlate all'endpoint, ad esempio utilizzo CPU/GPU/Disco/Memoria, è necessario concedere questa autorizzazione all'identità.

Definire la distribuzione

Per distribuzione si intende un set di risorse necessarie per ospitare il modello che esegue l'inferenza effettiva.

Di seguito è riportato un esempio di definizione della distribuzione, in cui la sezione model fa riferimento al modello di flusso registrato. È anche possibile specificare il percorso del modello di flusso inline.

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json
name: blue
endpoint_name: basic-chat-endpoint
model: azureml:basic-chat-model:1
  # You can also specify model files path inline
  # path: examples/flows/chat/basic-chat
environment: 
  image: mcr.microsoft.com/azureml/promptflow/promptflow-runtime:latest
  # inference config is used to build a serving container for online deployments
  inference_config:
    liveness_route:
      path: /health
      port: 8080
    readiness_route:
      path: /health
      port: 8080
    scoring_route:
      path: /score
      port: 8080
instance_type: Standard_E16s_v3
instance_count: 1
environment_variables:

  # "compute" mode is the default mode, if you want to deploy to serving mode, you need to set this env variable to "serving"
  PROMPTFLOW_RUN_MODE: serving

  # for pulling connections from workspace
  PRT_CONFIG_OVERRIDE: deployment.subscription_id=<subscription_id>,deployment.resource_group=<resource_group>,deployment.workspace_name=<workspace_name>,deployment.endpoint_name=<endpoint_name>,deployment.deployment_name=<deployment_name>

  # (Optional) When there are multiple fields in the response, using this env variable will filter the fields to expose in the response.
  # For example, if there are 2 flow outputs: "answer", "context", and I only want to have "answer" in the endpoint response, I can set this env variable to '["answer"]'.
  # If you don't set this environment, by default all flow outputs will be included in the endpoint response.
  # PROMPTFLOW_RESPONSE_INCLUDED_FIELDS: '["category", "evidence"]'
Attributo Descrizione
Name Nome della distribuzione.
Nome endpoint Nome dell'endpoint in cui creare la distribuzione.
Modello Modello da usare per la distribuzione. Questo valore può essere un riferimento a un modello con controllo delle versioni esistente nell'area di lavoro o a una specifica del modello inline.
Ambiente Ambiente in cui ospitare il modello e il codice. Contiene quanto segue:
- image
- inference_config: viene usato per creare un contenitore di gestione per le distribuzioni online, tra cui liveness route, readiness_route e scoring_route.
Tipo di istanza Dimensioni della macchina virtuale da usare per la distribuzione. Per l'elenco delle dimensioni supportate, vedere Elenco di SKU degli endpoint online gestiti.
Numero di istanze Numero di istanze da usare per la distribuzione. Basare il valore sul carico di lavoro previsto. Per la disponibilità elevata, è consigliabile impostare il valore almeno su 3. Si riserva un ulteriore 20% per l'esecuzione degli aggiornamenti. Per altre informazioni, vedere Limiti per gli endpoint online.
Variabili di ambiente È necessario impostare le variabili di ambiente seguenti per gli endpoint distribuiti da un flusso:
- (obbligatorio) PROMPTFLOW_RUN_MODE: serving: consente di specificare la modalità di gestione
- (obbligatorio) PRT_CONFIG_OVERRIDE: per il pull delle connessioni dall'area di lavoro
- (facoltativo) PROMPTFLOW_RESPONSE_INCLUDED_FIELDS:: quando sono presenti più campi nella risposta, l'uso di questa variabile di ambiente consente di filtrare i campi da esporre nella risposta.
Ad esempio, se sono presenti due output di flusso: "answer" e "context" e se si vuole avere solo "answer" nella risposta dell'endpoint, è possibile impostare questa variabile di ambiente su '["answer"]'.

Importante

Se la cartella del flusso contiene un requirements.txt file contenente le dipendenze necessarie per eseguire il flusso, è necessario seguire la distribuzione con una procedura di ambiente personalizzata per compilare l'ambiente personalizzato, incluse le dipendenze.

Se si crea una distribuzione online di Kubernetes, è necessario specificare gli attributi aggiuntivi seguenti:

Attributo Descrizione
Tipo Tipo di distribuzione. Impostare il valore su kubernetes.
Tipo di istanza Tipo di istanza creato nel cluster Kubernetes da usare per la distribuzione, che rappresenta la risorsa di calcolo per la richiesta o il limite della distribuzione. Per altri dettagli, vedere Creare e gestire il tipo di istanza.

Distribuire l'endpoint online in Azure

Per creare l'endpoint nel cloud, eseguire il codice seguente:

az ml online-endpoint create --file endpoint.yml

Per creare la distribuzione denominata blue nell'endpoint, eseguire il codice seguente:

az ml online-deployment create --file blue-deployment.yml --all-traffic

Nota

Questa distribuzione potrebbe richiedere più di 15 minuti.

Suggerimento

Se si preferisce non bloccare la console dell'interfaccia della riga di comando, è possibile aggiungere il flag --no-wait al comando. Tuttavia, questa operazione arresterà la visualizzazione interattiva dello stato della distribuzione.

Importante

Il flag --all-traffic usato in az ml online-deployment create alloca il 100% del traffico dell'endpoint alla distribuzione blu appena creata. Anche se questo è utile ai fini dello sviluppo e del test, per l'ambiente di produzione, potrebbe essere necessario aprire il traffico per la nuova distribuzione tramite un comando esplicito. Ad esempio, az ml online-endpoint update -n $ENDPOINT_NAME --traffic "blue=100".

Controllare lo stato dell'endpoint e della distribuzione

Per controllare lo stato dell'endpoint, eseguire il codice seguente:

az ml online-endpoint show -n basic-chat-endpoint

Per controllare lo stato della distribuzione, eseguire il codice seguente:

az ml online-deployment get-logs --name blue --endpoint basic-chat-endpoint

Richiamare l'endpoint per assegnare un punteggio ai dati usando il modello

È possibile creare un file sample-request.json simile al seguente:

{
  "question": "What is Azure Machine Learning?",
  "chat_history":  []
}

az ml online-endpoint invoke --name basic-chat-endpoint --request-file sample-request.json

È anche possibile chiamarlo con un client HTTP, ad esempio con curl:

ENDPOINT_KEY=<your-endpoint-key>
ENDPOINT_URI=<your-endpoint-uri>

curl --request POST "$ENDPOINT_URI" --header "Authorization: Bearer $ENDPOINT_KEY" --header 'Content-Type: application/json' --data '{"question": "What is Azure Machine Learning?", "chat_history":  []}'

Per ottenere la chiave dell'endpoint e l'URI dell'endpoint dall'area di lavoro di Azure Machine Learning, scegliere Endpoint>Utilizza>Informazioni sul consumo di base.

Configurazioni avanzate

Distribuire con connessioni diverse dallo sviluppo di flussi

È possibile che si voglia eseguire l'override delle connessioni del flusso durante la distribuzione.

Ad esempio, se il file flow.dag.yaml usa una connessione denominata my_connection, è possibile eseguirne l'override aggiungendo variabili di ambiente del codice YAML di distribuzione come illustrato di seguito:

Opzione 1: eseguire l'override del nome della connessione

environment_variables:
  my_connection: <override_connection_name>

Opzione 2: eseguire l'override facendo riferimento all'asset

environment_variables:
  my_connection: ${{azureml://connections/<override_connection_name>}}

Nota

È possibile fare riferimento a una connessione solo all'interno della stessa area di lavoro.

Eseguire la distribuzione con un ambiente personalizzato

Questa sezione illustra come usare un contesto di compilazione Docker per specificare l'ambiente per la distribuzione, presupponendo che si conoscano già gli ambienti Docker e Azure Machine Learning.

  1. Nell'ambiente locale creare una cartella denominata image_build_with_reqirements contenente i file seguenti:

    |--image_build_with_reqirements
|  |--requirements.txt
|  |--Dockerfile

    • requirements.txt deve essere ereditato dalla cartella del flusso, che è stata usata per tenere traccia delle dipendenze del flusso.

    • Il contenuto di Dockerfile è il seguente:

      FROM mcr.microsoft.com/azureml/promptflow/promptflow-runtime:latest
COPY ./requirements.txt .
RUN pip install -r requirements.txt

  2. Sostituire la sezione environment nel file YAML di definizione della distribuzione con il contenuto seguente:

    environment: 
  build:
    path: image_build_with_reqirements
    dockerfile_path: Dockerfile
  # deploy prompt flow is BYOC, so we need to specify the inference config
  inference_config:
    liveness_route:
      path: /health
      port: 8080
    readiness_route:
      path: /health
      port: 8080
    scoring_route:
      path: /score
      port: 8080

Usare il motore di gestione FastAPI (anteprima)

Per impostazione predefinita, la gestione del flusso di prompt usa il motore di gestione FLASK. A partire da prompt flow SDK versione 1.10.0, è supportato il motore di gestione basato su FastAPI. È possibile usare fastapi il motore di gestione specificando una variabile PROMPTFLOW_SERVING_ENGINEdi ambiente .

environment_variables:
  PROMPTFLOW_SERVING_ENGINE=fastapi

Configurare la concorrenza per la distribuzione

Quando si distribuisce il flusso nella distribuzione online, sono disponibili due variabili di ambiente da configurare per la concorrenza: PROMPTFLOW_WORKER_NUM e PROMPTFLOW_WORKER_THREADS. Sarà anche necessario impostare il parametro max_concurrent_requests_per_instance.

Di seguito è riportato un esempio di come configurarla nel file deployment.yaml.

request_settings:
  max_concurrent_requests_per_instance: 10
environment_variables:
  PROMPTFLOW_WORKER_NUM: 4
  PROMPTFLOW_WORKER_THREADS: 1

  • PROMPTFLOW_WORKER_NUM: questo parametro determina il numero di ruoli di lavoro (processi) che verranno avviati in un unico contenitore. Il valore predefinito è uguale al numero di core CPU e il valore massimo è il doppio del numero di core CPU.

  • PROMPTFLOW_WORKER_THREADS: questo parametro determina il numero di thread che verranno avviati in un unico ruolo di lavoro. Il valore predefinito è 1.

    Nota

    Quando si imposta PROMPTFLOW_WORKER_THREADS su un valore maggiore di 1, assicurarsi che il codice del flusso sia thread-safe.

  • max_concurrent_requests_per_instance: numero massimo di richieste simultanee consentite per ogni istanza per la distribuzione. Il valore predefinito è 10.

    Il valore suggerito per max_concurrent_requests_per_instance dipende dal tempo della richiesta:

    • Se il tempo della richiesta è maggiore di 200 ms, impostare max_concurrent_requests_per_instance su PROMPTFLOW_WORKER_NUM * PROMPTFLOW_WORKER_THREADS.
    • Se il tempo della richiesta è minore o uguale a 200 ms, impostare max_concurrent_requests_per_instance su (1.5-2) * PROMPTFLOW_WORKER_NUM * PROMPTFLOW_WORKER_THREADS. Questo può migliorare la velocità effettiva totale consentendo l'accodamento di alcune richieste sul lato server.
    • Se si inviano richieste tra aree diverse, è possibile modificare la soglia da 200 ms a 1 s.

Durante l'ottimizzazione dei parametri precedenti, è necessario monitorare le metriche seguenti per garantire prestazioni e stabilità ottimali:

  • Utilizzo CPU/memoria dell'istanza di questa distribuzione
  • Risposte diverse da 200 (4xx, 5xx)
    • Una risposta 429 indica in genere che è necessario ottimizzare le impostazioni di concorrenza seguendo le indicazioni precedenti o ridimensionare la distribuzione.
  • Stato della limitazione delle richieste di Azure OpenAI

Monitorare gli endpoint

Raccogliere metriche generali

È possibile visualizzare le metriche generali della distribuzione online (numeri di richiesta, latenza delle richieste, byte di rete, UTILIZZO CPU/GPU/disco/memoria e altro ancora).

Raccogliere i dati di traccia e le metriche di sistema durante il tempo di inferenza

È anche possibile raccogliere dati di traccia e richiedere metriche specifiche per la distribuzione del flusso (consumo di token, latenza del flusso e così via) durante il tempo di inferenza nell'area di lavoro collegata ad Application Insights aggiungendo una proprietà app_insights_enabled: true nel file yaml di distribuzione. Altre informazioni su traccia e metriche della distribuzione del flusso di richiesta.

Le metriche e la traccia specifiche del flusso dei prompt possono essere specificate in altri Application Insights diversi da quello collegato all'area di lavoro. È possibile specificare una variabile di ambiente nel file yaml di distribuzione come indicato di seguito. È possibile trovare il stringa di connessione di Application Insights nella pagina Panoramica in portale di Azure.

environment_variables:
  APPLICATIONINSIGHTS_CONNECTION_STRING: <connection_string>

Nota

Se si imposta app_insights_enabled: true solo ma l'area di lavoro non ha un application insights collegato, la distribuzione non avrà esito negativo, ma non verranno raccolti dati. Se si specificano sia che app_insights_enabled: true la variabile di ambiente precedente contemporaneamente, i dati di traccia e le metriche verranno inviati all'area di lavoro collegata ad Application Insights. Pertanto, se si vuole specificare un'applicazione diversa, è sufficiente mantenere la variabile di ambiente.

Errori comuni

Problema di timeout della richiesta upstream durante l'utilizzo dell'endpoint

Questo errore è in genere causato dal timeout. Per impostazione predefinita, il valore di request_timeout_ms è 5000. È possibile specificare fino a 5 minuti, ovvero 300.000 ms. Di seguito è riportato un esempio che illustra come specificare il timeout della richiesta nel file yaml di distribuzione. Altre informazioni sullo schema della distribuzione sono disponibili qui.

request_settings:
  request_timeout_ms: 300000

Passaggi successivi