Condividi tramite


Processi nelle app di Azure Container

I processi di App Contenitore di Azure consentono di eseguire attività in contenitori eseguite per una durata e un'uscita finiti. È possibile usare i processi per eseguire attività come l'elaborazione dei dati, l'apprendimento automatico o qualsiasi scenario in cui è necessaria l'elaborazione su richiesta.

Le app e i processi del contenitore vengono eseguiti nello stesso ambiente, consentendo loro di condividere funzionalità come la rete e la registrazione.

Confrontare app e processi del contenitore

Esistono due tipi di risorse di calcolo in App Contenitore di Azure: app e processi.

Le app sono servizi eseguiti continuamente. Se un contenitore in un'app non riesce, viene riavviato automaticamente. Esempi di app includono API HTTP, app Web e servizi in background che elaborano continuamente l'input.

I processi sono attività che iniziano, vengono eseguite per una durata limitata e terminano al termine. Ogni esecuzione di un processo esegue in genere una singola unità di lavoro. Le esecuzioni dei processi iniziano manualmente, in base a una pianificazione o in risposta agli eventi. Esempi di processi includono processi batch che eseguono attività su richiesta e pianificate.

Scenari di esempio

La tabella seguente confronta gli scenari comuni per app e processi:

Contenitore Risorsa di calcolo Note
Un server HTTP che gestisce il contenuto Web e le richieste API App Configurare una regola di scalabilità HTTP.
Un processo che genera rapporti finanziari notturni Mansione Usare il tipo di processo Pianificazione e configurare un'espressione cron.
Servizio in esecuzione continuo che elabora i messaggi da una coda bus di servizio di Azure App Configurare una regola di scalabilità personalizzata.
Processo che elabora un singolo messaggio o un piccolo batch di messaggi da una coda di Azure ed esce Mansione Usare il tipo di processo Evento e configurare una regola di scalabilità personalizzata per attivare le esecuzioni dei processi quando sono presenti messaggi nella coda.
Un'attività in background attivata su richiesta e viene chiusa al termine Mansione Usare il tipo di processo manuale e avviare le esecuzioni manualmente o a livello di codice usando un'API.
Strumento di esecuzione di GitHub Actions self-hosted o agente di Azure Pipelines Mansione Usare il tipo di processo evento e configurare una regola di scalabilità di GitHub Actions o Azure Pipelines .
Un'app Funzioni di Azure App Distribuire Funzioni di Azure in App contenitore.
Un'app guidata dagli eventi con Azure WebJobs SDK App Configurare una regola di scalabilità per ogni origine evento.

Concetti

Un ambiente app contenitore è un limite sicuro intorno a una o più app e processi contenitore. I processi includono alcuni concetti chiave:

  • Processo: un processo definisce la configurazione predefinita usata per ogni esecuzione del processo. La configurazione include l'immagine del contenitore da usare, le risorse da allocare e il comando da eseguire.
  • Esecuzione del processo: un'esecuzione del processo è una singola esecuzione di un processo che viene attivato manualmente, in base a una pianificazione o in risposta a un evento.
  • Replica processo: un'esecuzione tipica di un processo esegue una replica definita dalla configurazione del processo. Negli scenari avanzati, l'esecuzione di un processo può eseguire più repliche.

Panoramica dei processi di App Azure Container.

Autorizzazioni

Per avviare un processo dell'app contenitore, sono necessarie le autorizzazioni appropriate. Assicurarsi che all'account utente o all'entità servizio siano assegnati i ruoli seguenti:

  • Collaboratore app Azure Container: consente di creare e gestire app e processi del contenitore.
  • Lettore di Monitoraggio di Azure (facoltativo): consente di visualizzare i dati di monitoraggio per i processi.
  • Ruolo personalizzato: per autorizzazioni più granulari, è possibile creare un ruolo personalizzato con le azioni seguenti:
  • Microsoft.App/containerApps/jobs/start/action
  • Microsoft.App/containerApps/jobs/read
  • Microsoft.App/containerApps/jobs/executions/read

Per altre informazioni sull'assegnazione di ruoli e autorizzazioni, vedere Azure Role-Based Controllo di accesso.

Tipi di trigger di processo

Il tipo di trigger di un processo determina la modalità di avvio del processo. Sono disponibili i tipi di trigger seguenti:

  • Manuale: i processi manuali vengono attivati su richiesta.
  • Pianificazione: i processi pianificati vengono attivati in orari specifici e possono essere eseguiti ripetutamente.
  • Evento: eventi, ad esempio un messaggio che arriva in una coda, attiva processi basati su eventi.

Processi manuali

I processi manuali vengono attivati su richiesta usando l'interfaccia della riga di comando di Azure, portale di Azure o una richiesta all'API di Azure Resource Manager.

Esempi di processi manuali includono:

  • Attività di elaborazione una tantum, ad esempio la migrazione dei dati da un sistema a un altro.
  • Un sito di e-commerce in esecuzione come app contenitore avvia un'esecuzione del processo per elaborare l'inventario quando viene effettuato un ordine.

Per creare un processo manuale, usare il tipo di Manualprocesso .

Per creare un processo manuale usando l'interfaccia della riga di comando di Azure, usare il az containerapp job create comando . L'esempio seguente crea un processo manuale denominato my-job in un gruppo di risorse denominato my-resource-group e in un ambiente app contenitore denominato my-environment:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Manual" \
    --replica-timeout 1800 \
    --image "mcr.microsoft.com/k8se/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi"

L'immagine mcr.microsoft.com/k8se/quickstart-jobs:latest è un'immagine del contenitore di esempio pubblica che esegue un processo che attende alcuni secondi, stampa un messaggio nella console e quindi esce. Per autenticare e usare un'immagine del contenitore privato, vedere Contenitori.

Il comando precedente crea solo il processo. Per avviare un'esecuzione del processo, vedere Avviare un'esecuzione del processo su richiesta.

Processi pianificati

Per creare un processo pianificato, usare il tipo di Scheduleprocesso .

I processi di App contenitore usano espressioni cron per definire le pianificazioni. Supporta il formato di espressione cron standard con cinque campi per minuto, ora, giorno del mese, mese e giorno della settimana. Di seguito sono riportati esempi di espressioni cron:

Expression Descrizione
*/5 * * * * Viene eseguito ogni 5 minuti.
0 */2 * * * Viene eseguito ogni due ore.
0 0 * * * Viene eseguito ogni giorno a mezzanotte.
0 0 * * 0 Viene eseguito ogni domenica a mezzanotte.
0 0 1 * * Viene eseguito il primo giorno di ogni mese a mezzanotte.

Le espressioni Cron nei processi pianificati vengono valutate nell'ora UTC (Coordinated Universal Time).

Per creare un processo pianificato usando l'interfaccia della riga di comando di Azure, usare il az containerapp job create comando . L'esempio seguente crea un processo pianificato denominato my-job in un gruppo di risorse denominato e un ambiente app contenitore denominato my-resource-group my-environment:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Schedule" \
    --replica-timeout 1800 \
    --image "mcr.microsoft.com/k8se/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --cron-expression "*/1 * * * *"

L'immagine mcr.microsoft.com/k8se/quickstart-jobs:latest è un'immagine del contenitore di esempio pubblica che esegue un processo che attende alcuni secondi, stampa un messaggio nella console e quindi esce. Per autenticare e usare un'immagine del contenitore privato, vedere Contenitori.

L'espressione */1 * * * * cron esegue il processo ogni minuto.

Processi basati su eventi

Gli eventi dei sistemi di scalabilità personalizzati supportati attivano processi basati su eventi. Esempi di processi basati su eventi includono:

  • Processo eseguito quando viene aggiunto un nuovo messaggio a una coda, ad esempio bus di servizio di Azure, Kafka o RabbitMQ.
  • Strumento di esecuzione di GitHub Actions self-hosted o agente Di Azure DevOps che viene eseguito quando un nuovo processo viene accodato in un flusso di lavoro o in una pipeline.

Le app contenitore e i processi basati su eventi usano i scaler KEDA . Entrambi valutano le regole di ridimensionamento in un intervallo di polling per misurare il volume di eventi per un'origine evento, ma il modo in cui usano i risultati è diverso.

In un'app ogni replica elabora continuamente gli eventi e una regola di ridimensionamento determina il numero di repliche da eseguire per soddisfare la domanda. Nei processi basati su eventi, ogni esecuzione del processo elabora in genere un singolo evento e una regola di ridimensionamento determina il numero di esecuzioni di processi da eseguire.

Usare i processi quando ogni evento richiede una nuova istanza del contenitore con risorse dedicate o deve essere eseguita per molto tempo. I processi basati su eventi sono concettualmente simili ai processi di ridimensionamento KEDA.

Per creare un processo basato su eventi, usare il tipo di Eventprocesso .

Per creare un processo basato su eventi usando l'interfaccia della riga di comando di Azure, usare il az containerapp job create comando . L'esempio seguente crea un processo basato su eventi denominato my-job in un gruppo di risorse denominato e in un ambiente app contenitore denominato my-resource-group my-environment:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Event" \
    --replica-timeout 1800 \
    --image "docker.io/myuser/my-event-driven-job:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --min-executions "0" \
    --max-executions "10" \
    --scale-rule-name "queue" \
    --scale-rule-type "azure-queue" \
    --scale-rule-metadata "accountName=mystorage" "queueName=myqueue" "queueLength=1" \
    --scale-rule-auth "connection=connection-string-secret" \
    --secrets "connection-string-secret=<QUEUE_CONNECTION_STRING>"

Nell'esempio viene configurata una regola di scalabilità della coda Archiviazione di Azure.

Per un'esercitazione completa, vedere Distribuire un processo basato su eventi.

Avviare un'esecuzione del processo su richiesta

Per qualsiasi tipo di processo, è possibile avviare un'esecuzione del processo su richiesta.

Per avviare un'esecuzione del processo usando l'interfaccia della riga di comando di Azure, usare il az containerapp job start comando . L'esempio seguente avvia un'esecuzione di un processo denominato my-job in un gruppo di risorse denominato my-resource-group:

az containerapp job start --name "my-job" --resource-group "my-resource-group"

Quando si avvia un'esecuzione del processo, è possibile scegliere di eseguire l'override della configurazione del processo. Ad esempio, è possibile eseguire l'override di una variabile di ambiente o del comando di avvio per eseguire lo stesso processo con input diversi. La configurazione sottoposta a override viene usata solo per l'esecuzione corrente e non modifica la configurazione del processo.

Importante

Quando si esegue l'override della configurazione, l'intera configurazione del modello del processo viene sostituita con la nuova configurazione. Assicurarsi che la nuova configurazione includa tutte le impostazioni necessarie.

Per eseguire l'override della configurazione del processo durante l'avvio di un'esecuzione, usare il az containerapp job start comando e passare un file YAML contenente il modello da usare per l'esecuzione. Nell'esempio seguente viene avviata un'esecuzione di un processo denominato my-job in un gruppo di risorse denominato my-resource-group.

Recuperare la configurazione corrente del processo con il az containerapp job show comando e salvare il modello in un file denominato my-job-template.yaml:

az containerapp job show --name "my-job" --resource-group "my-resource-group" --query "properties.template" --output yaml > my-job-template.yaml

L'opzione --query "properties.template" restituisce solo la configurazione del modello del processo.

Modificare il file per eseguire l'override my-job-template.yaml della configurazione del processo. Ad esempio, per eseguire l'override delle variabili di ambiente, modificare la env sezione :

containers:
- name: print-hello
  image: ubuntu
  resources:
    cpu: 1
    memory: 2Gi
  env:
  - name: MY_NAME
    value: Azure Container Apps jobs
  args:
  - /bin/bash
  - -c
  - echo "Hello, $MY_NAME!"

Avviare il processo usando il modello:

az containerapp job start --name "my-job" --resource-group "my-resource-group" \
    --yaml my-job-template.yaml

Ottenere la cronologia di esecuzione del processo

Ogni processo di App contenitore mantiene una cronologia delle esecuzioni di processi recenti.

Per ottenere gli stati delle esecuzioni di processi usando l'interfaccia della riga di comando di Azure, usare il az containerapp job execution list comando . Nell'esempio seguente viene restituito lo stato dell'esecuzione più recente di un processo denominato my-job in un gruppo di risorse denominato my-resource-group:

az containerapp job execution list --name "my-job" --resource-group "my-resource-group"

La cronologia di esecuzione per i processi pianificati e basati su eventi è limitata alle ultime 100 esecuzioni di processi riuscite e non riuscite.

Per elencare tutte le esecuzioni di un processo o ottenere un output dettagliato da un processo, eseguire una query sul provider di log configurato per l'ambiente App contenitore.

Configurazione avanzata dei processi

I processi di App contenitore supportano opzioni di configurazione avanzate, ad esempio impostazioni del contenitore, tentativi, timeout e parallelismo.

Impostazioni contenitore

Le impostazioni del contenitore definiscono i contenitori da eseguire in ogni replica di un'esecuzione del processo. Includono variabili di ambiente, segreti e limiti delle risorse. Per altre informazioni, vedere Contenitori. L'esecuzione di più contenitori in un singolo processo è uno scenario avanzato. La maggior parte dei processi esegue un singolo contenitore.

Impostazioni del processo

La tabella seguente include le impostazioni del processo che è possibile configurare:

Impostazione Proprietà Gestione risorse di Azure Parametro dell'interfaccia della riga di comando Descrizione
Tipo di mansione triggerType --trigger-type Tipo di processo. (Manual, Scheduleo Event)
Timeout della replica replicaTimeout --replica-timeout Tempo massimo in secondi di attesa del completamento di una replica.
Intervallo di polling pollingInterval --polling-interval Tempo in secondi di attesa tra il polling degli eventi. Il valore predefinito è 30 secondi.
Limite di tentativi di replica replicaRetryLimit --replica-retry-limit Numero massimo di tentativi di ripetizione di una replica non riuscita. Per eseguire un errore in una replica senza riprovare, impostare il valore su 0.
Parallelism parallelism --parallelism Numero di repliche da eseguire per esecuzione. Per la maggior parte dei processi, impostare il valore su 1.
Numero di completamento della replica replicaCompletionCount --replica-completion-count Numero di repliche da completare correttamente affinché l'esecuzione abbia esito positivo. La maggior parte è uguale o minore del parallelismo. Per la maggior parte dei processi, impostare il valore su 1.

Esempio

L'esempio seguente crea un processo con opzioni di configurazione avanzate:

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Schedule" \
    --replica-timeout 1800 --replica-retry-limit 3 --replica-completion-count 5 --parallelism 5 \
    --image "myregistry.azurecr.io/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --command "/startup.sh" \
    --env-vars "MY_ENV_VAR=my-value" \
    --cron-expression "0 0 * * *"  \
    --registry-server "myregistry.azurecr.io" \
    --registry-username "myregistry" \
    --registry-password "myregistrypassword"

Restrizioni per i processi

Le seguenti funzionalità non sono supportate:

  • Dapr
  • Ingresso e funzionalità correlate, ad esempio domini personalizzati e certificati SSL

Passaggi successivi