次の方法で共有


readiness probe の構成

トラフィックを処理するコンテナー化されたアプリケーションの場合、コンテナーが受信要求を処理する準備ができているかどうか確認したほうがいいです。 Azure Container Instances は、特定の条件下でコンテナーにアクセスできないようにする構成を組み込む、readiness probe をサポートしています。 readiness probe は、Kubernetes readiness probe のように動作します。 たとえば、コンテナー アプリケーションが起動時に大規模なデータセットを読み込む必要があり、この間は要求を受信したくない場合があります。

この記事では、readiness probe を含むコンテナー グループをデプロイして、probe が成功したときにのみコンテナーがトラフィックを受信するようにする方法について説明します。

Azure Container Instances は、liveness probe もサポートしています。これを構成すると、異常なコンテナーが自動的に再起動されます。

YAML の構成

例として、readiness probe を含む次のスニペットを使用して readiness-probe.yaml ファイルを作成します。 このファイルは、小規模な Web アプリを実行するコンテナーで構成される、コンテナー グループを定義します。 アプリは、パブリックの mcr.microsoft.com/azuredocs/aci-helloworld イメージからデプロイされます。 このコンテナー アプリは、「Azure CLI を使用してコンテナー インスタンスを Azure にデプロイする」やその他のクイックスタートにも示されています。

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

開始コマンド

デプロイには、コンテナーの初回の実行開始時に実行される開始コマンドを定義する command プロパティが含まれています。 このプロパティは、文字列の配列を受け入れます。 このコマンドは、Web アプリが実行されているがコンテナーの準備ができていない時間をシミュレートします。

まず、シェル セッションを開始し、node コマンドを実行して Web アプリを起動します。 また、240 秒間スリープするコマンドを開始します。その後、/tmp ディレクトリ内に ready という名前のファイルを作成します。

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

readiness コマンド

この YAML ファイルは、readiness チェックとして機能する exec readiness コマンドをサポートする readinessProbe を定義します。 この例の readiness コマンドでは、/tmp ディレクトリに ready ファイルがあるかどうかをテストします。

ready ファイルが存在しない場合、readiness コマンドは 0 以外の値で終了します。コンテナーは実行を続行しますが、アクセスすることはできません。 コマンドが終了コード 0 で正常に終了すると、コンテナーにアクセスできるようになります。

periodSeconds プロパティは、readiness コマンドを 5 秒ごとに実行するように指定します。 readiness probe は、コンテナー グループの有効期間にわたって実行されます。

デプロイ例

次のコマンドを実行して、上記の YAML 構成を含むコンテナー グループをデプロイします。

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

readiness チェックの表示

この例では、最初の 240 秒間、ready ファイルが存在するかどうかチェックしたときに readiness コマンドが失敗します。 返された状態コードは、コンテナーの準備ができていないことを通知します。

これらのイベントは、Azure Portal または Azure CLI から表示できます。 たとえば、ポータルには、readiness コマンドが失敗したときにトリガーされる種類 Unhealthy のイベントが表示されます。

Portal の異常なイベント

コンテナーの readiness の確認

コンテナーを開始した後、最初はアクセスできないことを確認できます。 プロビジョニングの後、コンテナー グループの IP アドレスを取得します。

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

readiness probe が失敗したときにサイトにアクセスしてみます。

wget <ipAddress>

出力は、最初はサイトにアクセスできないことを示しています。

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

240 秒後、readiness コマンドが成功し、コンテナーの準備ができていることが通知されます。 今度は、wget コマンドを実行すると成功します。

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]

コンテナーの準備ができたら、Web ブラウザーを使用して IP アドレスを参照することにより、Web アプリにアクセスすることもできます。

注意

readiness probe は、コンテナー グループの有効期間中は継続して実行されます。 readiness コマンドが後になって失敗した場合、コンテナーに再度アクセスできなくなります。

次の手順

readiness probe は、依存するコンテナーで構成される複数コンテナー グループを必要とするシナリオで役に立ちます。 複数コンテナーのシナリオの詳細については、「Azure Container Instances でのコンテナー グループ」を参照してください。