Konfigurera beredskapsavsökning

Artikel
08/29/2024

För containerbaserade program som hanterar trafik kanske du vill kontrollera att containern är redo att hantera inkommande begäranden. Azure Container Instances stöder beredskapsavsökningar för att inkludera konfigurationer så att containern inte kan nås under vissa förhållanden. Beredskapsavsökningen fungerar som en Kubernetes-beredskapsavsökning. Ett containerprogram kan till exempel behöva läsa in en stor datauppsättning under starten och du vill inte att den ska ta emot begäranden under den här tiden.

Den här artikeln beskriver hur du distribuerar en containergrupp som innehåller en beredskapsavsökning, så att en container endast tar emot trafik när avsökningen lyckas.

Azure Container Instances stöder också liveness-avsökningar, som du kan konfigurera för att orsaka att en container med feltillstånd startas om automatiskt.

YAML-konfiguration

Skapa till exempel en readiness-probe.yaml fil med följande kodfragment som innehåller en beredskapsavsökning. Den här filen definierar en containergrupp som består av en container som kör en liten webbapp. Appen distribueras från den offentliga mcr.microsoft.com/azuredocs/aci-helloworld avbildningen. Den här containerbaserade appen visas också i Distribuera en containerinstans i Azure med hjälp av Azure CLI och andra snabbstarter.

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

Startkommando

Distributionen innehåller en command egenskap som definierar ett startkommando som körs när containern först börjar köras. Den här egenskapen accepterar en matris med strängar. Det här kommandot simulerar en tid när webbappen körs men containern inte är redo.

Först startar den en shell-session och kör ett node kommando för att starta webbappen. Det startar också ett kommando i viloläge i 240 sekunder, varefter en fil som anropas ready i /tmp katalogen skapas:

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

Beredskapskommando

Den här YAML-filen definierar en readinessProbe som stöder ett exec beredskapskommando som fungerar som beredskapskontroll. I det här exemplet testas beredskapskommandot för förekomsten av ready filen i /tmp katalogen.

ready När filen inte finns avslutas beredskapskommandot med ett värde som inte är noll. Containern fortsätter att köras men kan inte nås. När kommandot avslutas med slutkod 0 är containern redo att nås.

Egenskapen periodSeconds anger att beredskapskommandot ska köras var 5:e sekund. Beredskapsavsökningen körs under containergruppens livslängd.

Exempel på distribution

Kör följande kommando för att distribuera en containergrupp med den föregående YAML-konfigurationen:

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

Visa beredskapskontroller

I det här exemplet misslyckas beredskapskommandot under de första 240 sekunderna när det söker ready efter filens existens. Statuskoden returnerade signaler om att containern inte är redo.

Dessa händelser kan visas från Azure-portalen eller Azure CLI. Portalen visar till exempel att händelser av typen Unhealthy utlöses när beredskapskommandot misslyckas.

Händelse som inte är felfri i portalen

Verifiera containerberedskap

När du har startat containern kan du kontrollera att den inte är tillgänglig från början. Efter etableringen hämtar du IP-adressen för containergruppen:

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

Försök att komma åt platsen medan beredskapsavsökningen misslyckas:

wget <ipAddress>

Utdata visar att webbplatsen inte är tillgänglig från början:

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...

Efter 240 sekunder lyckas beredskapskommandot, vilket signalerar att containern är klar. När du kör wget kommandot lyckas det nu:

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]

När containern är klar kan du också komma åt webbappen genom att bläddra till IP-adressen med hjälp av en webbläsare.

Kommentar

Beredskapsavsökningen fortsätter att köras under containergruppens livslängd. Om beredskapskommandot misslyckas vid ett senare tillfälle blir containern återigen otillgänglig.

Nästa steg

En beredskapsavsökning kan vara användbar i scenarier som involverar grupper med flera containrar som består av beroende containrar. Mer information om scenarier med flera containrar finns i Containergrupper i Azure Container Instances.

Dela via