Configurare probe di idoneità

Articolo
09/04/2024

Per le applicazioni in contenitori che gestiscono il traffico, è possibile verificare che il contenitore sia pronto per gestire le richieste in ingresso. Istanze di Azure Container supporta l'inclusione di configurazioni nei probe di attività, in modo che non sia possibile accedere al contenitore in determinate condizioni. Il probe di idoneità si comporta come un probe di idoneità Kubernetes. Ad esempio, un'applicazione contenitore potrebbe dover caricare un set di dati di grandi dimensioni durante l'avvio e non si vuole che riceva richieste durante questo periodo.

Questo articolo illustra come distribuire un gruppo di contenitori che include un probe di idoneità, in modo che un contenitore riceva traffico solo quando il probe ha esito positivo.

Istanze di Azure Container supporta anche probe di attività, che è possibile configurare per provocare il riavvio automatico di un contenitore non integro.

Configurazione YAML

Ad esempio, creare un file readiness-probe.yaml con il frammento di codice seguente che include un probe di idoneità. Questo file definisce un gruppo di contenitori costituito da un contenitore che esegue una piccola app Web. L'app viene distribuita dall'immagine mcr.microsoft.com/azuredocs/aci-helloworld pubblica. Questa app in contenitori è illustrata anche in Distribuire un'istanza di contenitore in Azure usando l'interfaccia della riga di comando di Azure e altre guide introduttive.

apiVersion: 2019-12-01
location: eastus
name: readinesstest
properties:
  containers:
  - name: mycontainer
    properties:
      image: mcr.microsoft.com/azuredocs/aci-helloworld
      command:
        - "/bin/sh"
        - "-c"
        - "node /usr/src/app/index.js & (sleep 240; touch /tmp/ready); wait"
      ports:
      - port: 80
      resources:
        requests:
          cpu: 1.0
          memoryInGB: 1.5
      readinessProbe:
        exec:
          command:
          - "cat"
          - "/tmp/ready"
        periodSeconds: 5
  osType: Linux
  restartPolicy: Always
  ipAddress:
    type: Public
    ports:
    - protocol: tcp
      port: '80'
tags: null
type: Microsoft.ContainerInstance/containerGroups

Comando di avvio

La distribuzione include una proprietà command che definisce un comando iniziale che viene eseguito al primo avvio dell'esecuzione del contenitore. Questa proprietà accetta una matrice di stringhe. Questo comando simula un'ora in cui l'app Web viene eseguita, ma il contenitore non è pronto.

Prima di tutto, avvia una sessione della shell ed esegue un comando node per avviare l'app Web. Avvia anche un comando per dormire per 240 secondi, dopo il quale crea un file denominato ready all'interno della directory /tmp:

node /usr/src/app/index.js & (sleep 240; touch /tmp/ready); wait

Comando per l’idoneità

Questo file YAML definisce un readinessProbe che supporta un comando per l’idoneità exec che funge da controllo di conformità. In questo esempio il comando per l’idoneità verifica l'esistenza del file ready nella directory /tmp.

Quando il file ready non esiste, il comando per l’idoneità viene chiuso con un valore diverso da zero; il contenitore continua l'esecuzione, ma non è possibile accedervi. Quando il comando termina correttamente con il codice di uscita 0, il contenitore è pronto per l'accesso.

La proprietà periodSeconds stabilisce che il comando per l’idoneità deve essere eseguito ogni 5 secondi. Il probe di idoneità viene eseguito per la durata del gruppo di contenitori.

Esempio di distribuzione

Eseguire il comando seguente per distribuire un gruppo di contenitori con la configurazione YAML riportata in precedenza:

az container create --resource-group myResourceGroup --file readiness-probe.yaml

Visualizzare i controlli di disponibilità

In questo esempio, durante i primi 240 secondi, il comando per l’idoneità ha esito negativo quando verifica l'esistenza del file ready. Il codice di stato ha restituito segnali che il contenitore non è pronto.

Questi eventi possono essere visualizzati dal portale di Azure o dall'interfaccia della riga di comando di Azure. Ad esempio, il portale mostra gli eventi di tipo Unhealthy vengono attivati in caso di errore del comando per l’idoneità.

Evento di non integrità nel portale

Verificare l'idoneità dei contenitori

Dopo aver avviato il contenitore, è possibile verificare che non sia inizialmente accessibile. Dopo il provisioning, ottenere l'indirizzo IP del gruppo di contenitori:

az container show --resource-group myResourceGroup --name readinesstest --query "ipAddress.ip" --out tsv

Provare ad accedere al sito mentre il probe di idoneità ha esito negativo:

wget <ipAddress>

L'output mostra che il sito non è inizialmente accessibile:

wget 192.0.2.1

--2019-10-15 16:46:02--  http://192.0.2.1/
Connecting to 192.0.2.1... connected.
HTTP request sent, awaiting response...

Dopo 240 secondi, il comando per l’idoneità ha esito positivo, segnalando che il contenitore è pronto. Ora, quando si esegue il comando wget, l'operazione ha esito positivo:

wget 192.0.2.1

--2019-10-15 16:46:02--  http://192.0.2.1/
Connecting to 192.0.2.1... connected.
HTTP request sent, awaiting response...200 OK
Length: 1663 (1.6K) [text/html]
Saving to: ‘index.html.1’

index.html.1                       100%[===============================================================>]   1.62K  --.-KB/s    in 0s

2019-10-15 16:49:38 (113 MB/s) - ‘index.html.1’ saved [1663/1663]

Quando il contenitore è pronto, è anche possibile accedere all'app Web passando all'indirizzo IP usando un Web browser.

Nota

Il probe di idoneità continua viene eseguito per la durata del gruppo di contenitori. Se il comando per l’idoneità ha esito negativo in un secondo momento, il contenitore diventa nuovamente inaccessibile.

Passaggi successivi

Un probe di idoneità può essere utile negli scenari che coinvolgono gruppi multi-contenitore costituiti da contenitori dipendenti. Per altre informazioni sugli scenari con più contenitori, vedere Gruppi di contenitori in Istanze di Azure Container.

Condividi tramite