ACI 統合コンテナー機能
Azure コンテナーインスタンス、単一コンテナーとしての実行
単一のコンテナーを ACI 上で実行するにはdocker runを用います。
1 つのコンテナーは、これに対応する ACI コンテナーグループ内において実行され、このグループ内にはこの 1 つのコンテナーのみが含まれます。
コンテナーの一覧はdocker psコマンドを使って確認します。
またコンテナーの停止や削除はdocker stop <CONTAINER>およびdocker rm <CONTAINER>を使って行います。
ACI コンテナーに対する Docker run オプション
以下の一覧表では、サポートされているdocker runフラグとその ACI 対応機能について示します。
凡例
- ✓: 実装済
- n: 未実装
- x: 適用不可 / 変換不能
| フラグ | 記号 | 内容 |
|---|---|---|
| --cpus | ✓ | コンテナーリソース 参照。 |
| -d, --detach | ✓ | コンテナー起動時にコンテナーログをデタッチします。デフォルトではコマンドラインにアタッチされコンテナーログが出力されます。 |
| --domainname | ✓ | ポート公開 参照。 |
| --e, --env | ✓ | 環境変数を設定します。 |
| --env-file | ✓ | 外部ファイルを利用して環境変数を設定します。 |
| --health-cmd | ✓ | ヘルスチェックコマンドを指定します。ヘルスチェック 参照。 |
| --health-interval | ✓ | ヘルスチェック間隔を指定します。 |
| --health-retries | ✓ | ヘルスチェックのリトライ数を指定します。 |
| --health-start-period | ✓ | ヘルスチェックの初期遅延時間を指定します。 |
| --health-timeout | ✓ | ヘルスチェックのタイムアウトを指定します。 |
| -l, --label | x | Docker ACI 統合においてはサポートされません。ACI Tags の制限によるためです。 |
| -m, --memory | ✓ | コンテナーリソース 参照。 |
| --name | ✓ | コンテナー名を指定します。この名前は ACI リソースグループ内でユニークであることが必要です。この名前はデフォルトで生成されます。 |
| -p, --publish | ✓ | ポート公開 参照。ACI では同一ポートのマッピングのみサポートされます。 |
| --restart | ✓ | 再起動ポリシー。以下のいずれか： always、no、on-failure |
| --rm | x | ACI ではコンテナーの自動削除がサポートされません。このため本フラグはサポートされません。 |
| -v, --volume | ✓ | 永続的ボリューム 参照。 |
ポート公開
コンテナーのポートは複数公開することが可能であり、docker run -p <PORT>:<PORT>を使って行います。
コンテナー実行時にポートが公開されていれば、公開 IP アドレスが割り当てられ必要なポートがアクセス可能となります。
そしてこれに応じた ACI コンテナーグループが公開されます。
メモ
ACI ではポートマッピングには対応していません。 したがって
-p <PORT>:<PORT>を利用するにあたっては、同一のポート番号を指定する必要があります。
ポートの公開にあたっては、--domainnameフラグを用いることで、コンテナーに対するサービスの DNS ホスト名を設定することもできます。
domainnameは ACI の DNS ラベル名の指定に利用されます。
そして ACI コンテナーグループは<DOMAINNANE>.<REGION>.azurecontainer.ioとしてアクセス可能になります。
なおdomainnameは<REGION>.azurecontainer.io内においてグローバルにユニークでなければなりません。
永続的ボリューム
Docker ボリュームは Azure ファイル共有にマッピングされます。
各ファイル共有は Azure ストレージアカウントの一部です。
ボリュームは複数指定することが可能で、docker run -v <STORAGE-ACCOUNT>/<FILESHARE>:<TARGET-PATH>を使って指定します。
runコマンドにおいては--volumeフラグや-vフラグを複数用いることにより、複数ボリュームを指定することができます。
ボリュームに対して利用するストレージアカウントは、同一でも異なっていても構いません。
異なるボリュームをマウントする対象パスは、それぞれに異なっている必要があり、重複してはなりません。
単一ファイルのマウントや Azure ファイル共有におけるサブフォルダーのマウントはサポートされません。
ストレージアカウントに対する資格情報は、デプロイの際に自動的に取得されます。 各ストレージアカウントが利用される際に、Azure ログイン情報を利用してストレージアカウント鍵が抽出されます。
コンテナーリソース
CPU とメモリのリソース予約は、コンテナー起動時にdocker run --cpus 1.5 --memory 2Gのようにして設定することができます。
単一のコンテナーにおいては、リソース予約量とは異なるリソース制約を設定することはできません。 ACI におけるリソース制約は、1 つのコンテナーグループにあるコンテナーに対して行います。 ただしこの制約は、全体のグループに対して予約されたリソース範囲内でなければなりません。 1 つのコンテナーグループ内にデプロイされているコンテナーが 1 つである場合は、リソース制約はリソース予約と等しくなければなりません。
ログ
コンテナーのログは、コマンドdocker logs <CONTAINER-ID>を使って確認することができます。
ログを監視するには--follow（-f）オプションを指定します。
docker runによってコンテナーが起動されると、起動時にデフォルトでそのコマンドラインにコンテナーログが接続されます。
コンテナー起動時にログを監視しない場合はdocker run --detachとします。
メモ
ACI ログの監視にあたっては出力に問題が発生するかもしれません。 特にコンテナーログを監視している端末画面をリサイズした場合に発生します。 これは ACI のログ機能が低レベルのログ取得処理となっていて、ログストリーム処理にはなっていないためです。 監視中のログは、実際には 2 秒ごとに取得されます。
ヘルスチェック
ヘルスチェックは先頭に--health-がつくフラグを使って設定します。
これは ACI のLivenessProbeに変換されます。
ヘルスチェックが失敗すると、そのコンテナーは健康でない（unhealthy）とされ停止します。
コンテナーを自動的に再起動するためには、コンテナーの起動時に再起動ポリシーを設定しておくことが必要です。
再起動ポリシーは--restartフラグを用い、その設定値にはno以外を指定します。
再起動ポリシーが指定されていない場合のデフォルトはnoとなることに注意してください。
再起動を自動化するためには、コンテナーも--restartにより指定される再起動ポリシーを持っておくことが必要です。
（docker run実行時のデフォルトは、再起動ポリシーがnoになります。）