You are using Amazon FSx for Windows File Server file system for persistent container storage.
' -Force"],
"cpu": 512,
"memory": 256,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"essential": false,
"name": "container1",
"mountPoints": [
{
"sourceVolume": "fsx-windows-dir",
"containerPath": "C:\\fsx-windows-dir",
"readOnly": false
}
]
},
{
"entryPoint": [
"powershell",
"-Command"
],
"portMappings": [
{
"hostPort": 443,
"protocol": "tcp",
"containerPort": 80
}
],
"command": ["Remove-Item -Recurse C:\\inetpub\\wwwroot\\* -Force; Start-Sleep -Seconds 120; Move-Item -Path C:\\fsx-windows-dir\\index.html -Destination C:\\inetpub\\wwwroot\\index.html -Force; C:\\ServiceMonitor.exe w3svc"],
"mountPoints": [
{
"sourceVolume": "fsx-windows-dir",
"containerPath": "C:\\fsx-windows-dir",
"readOnly": false
}
],
"cpu": 512,
"memory": 256,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"essential": true,
"name": "container2"
}
],
"family": "fsx-windows",
"executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
"volumes": [
{
"name": "fsx-windows-dir",
"fsxWindowsFileServerVolumeConfiguration": {
"fileSystemId": "fs-0eeb5730b2EXAMPLE",
"authorizationConfig": {
"domain": "example.com",
"credentialsParameter": "arn:arn-1234"
},
"rootDirectory": "share"
}
}
]
}
```
`FSxWindowsFileServerVolumeConfiguration`
タイプ: オブジェクト
必須: いいえ
このパラメータは、タスクストレージに [FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) ファイルシステムを使用する場合に指定します。
`fileSystemId`
タイプ: 文字列
必須: はい
使用する FSx for Windows File Server ファイルシステムID。
`rootDirectory`
タイプ: 文字列
必須: はい
ホスト内にルートディレクトリとしてマウントする FSx for Windows File Server ファイルシステム内のディレクトリ。
`authorizationConfig`
`credentialsParameter`
タイプ: 文字列
必須: はい
認可の認証情報オプション。
+ [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) シークレットの Amazon リソースネーム (ARN)。
+ 用の Amazon リソースネーム (ARN)[Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html)パラメータ。
`domain`
タイプ: 文字列
必須: はい
[AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD) ディレクトリ、またはセルフホスト型 EC2 Active Directory によってホストされる完全修飾ドメイン名。
## FSx for Windows File Server ボリューム認証情報を保存する方法
credentials パラメータで使用するために認証情報を格納するには、2 つの異なる方法があります。
+ **AWS Secrets Managerシークレット**
この認証情報は、[*その他のタイプのシークレット*] カテゴリを使用して AWS Secrets Manager コンソールで作成できます。キー/値のペア、ユーザー名/管理者、パスワード/*パスワード*ごとに行を追加します。
+ **Systems Manager パラメータ**
この認証情報は、次のコードスニペット例でのフォームにテキストを入力することで、Systems Manager パラメータコンソールで作成できます。
```
{
"username": "admin",
"password": "password"
}
```
タスク定義の `FSxWindowsFileServerVolumeConfiguration` パラメータにある `credentialsParameter` では、シークレット ARN または Systems Manager パラメータ ARN が保持されます 。詳細については、*Secrets Manager ユーザーガイド* の「[AWSSecrets Manager とは？](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)」および*Secrets Manager ユーザーガイド* の「[Systems Manager パラメータの保存](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)」を参照してください。
# Amazon ECS 用の FSx for Windows File Server ファイルシステムを設定する方法について説明します。
FSx for Windows File Server ファイルシステムと、ファイルシステムにアクセスできるコンテナをホストする Amazon ECS に最適化された Windows インスタンスを起動する方法について説明します。これを行うには、最初に Directory Service AWS Managed Microsoft Active Directory を作成します。次に、Amazon EC2 インスタンスとタスク定義を使用して、FSx for Windows File Server ファイルシステムとクラスターを作成します。FSx for Windows File Server ファイルシステムを使用するために、コンテナのタスク定義を設定します。最後に、ファイルシステムをテストします。
アクティブディレクトリ または FSx for Windows File Server ファイルシステムのいずれかを起動または削除するのに、毎回 20～45 分かかります。90 分以上予約して、チュートリアルを完了するか、いくつかのセッションでチュートリアルを完了する準備をしてください。
## チュートリアルの前提条件
+ 管理ユーザー。「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」を参照してください。
+ (オプション) RDP アクセスを介して EC2 Windows インスタンスに接続するための `PEM` キーペア。キーペアの作成方法については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 のキーペアと Amazon EC2 インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。
+ 少なくとも 1 つのパブリックサブネットと 1 つのプライベートサブネット、および 1 つのセキュリティグループを持つ VPC。デフォルトの VPC を使用できます。NAT ゲートウェイやデバイスは必要ありません。Directory Service は、Active Directory でのネットワークアドレス変換 (NAT) をサポートしていません。これを機能させるには、アクティブディレクトリ、FSx for Windows File Server ファイルシステム、ECS クラスター、および EC2 インスタンスが VPC 内に配置されている必要があります。VPC と Active Directory の詳細については、「[VPC を作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)」および「[AWS Managed Microsoft AD を作成するための前提条件](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_prereqs)」を参照してください。
+ IAM ecsInstanceRole および ecsTaskExecutionRole アクセス許可は、お客様のアカウントに関連付けられています。このようなサービスリンクロールを使用すると、サービスが API 呼び出しを行い、ユーザーに代わってコンテナ、シークレット、ディレクトリ、ファイルサーバーにアクセスできます。
## ステップ 1: IAM アクセスロールを作成する
**AWS マネジメントコンソール を使用してクラスターを作成します。**
1. [Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)を参照して ecsInstanceRole があるかどうかを確認し、持っていない場合はどのように作成できるかを確認してください。
1. 実際の本番環境では、ロールポリシーを最小限のアクセス許可に合わせてカスタマイズすることをお勧めします。このチュートリアルを通じて取り組むために、次の AWS マネージド ポリシーが ecsInstanceRole に添付されていることを確認します。ポリシーがまだアタッチされていない場合は、ポリシーをアタッチします。
+ AmazonEC2ContainerServiceforEC2Role
+ AmazonSSMManagedInstanceCore
+ AmazonSSMDirectoryServiceAccess
AWS マネージド ポリシーをアタッチするには
1. [IAM コンソール](https://console.aws.amazon.com//iam/)を開きます。
1. ナビゲーションペインで **[ロール]** を選択します。
1. **[AWS 管理ロール]** を選択します。
1. **[アクセス許可]、[ポリシーのアタッチ]** の順に選択します。
1. アタッチする利用可能なポリシーを絞り込むには、[**Filter**] を使用します。
1. 適切なポリシーを選択し、[**Attach policy**] を選択します。
1. [Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md) を参照して ecsTaskExecutionRole があるかどうかを確認し、持っていない場合はどのように作成できるかを確認してください。
実際の本番環境では、ロールポリシーを最小限のアクセス許可に合わせてカスタマイズすることをお勧めします。このチュートリアルを通じて取り組むために、次の AWSマネージド ポリシーが ecsTaskExecutionRole に添付されていることを確認します。ポリシーがまだアタッチされていない場合は、ポリシーをアタッチします。AWSマネージド ポリシーをアタッチするには、前のセクションで説明した手順を使用します。
+ SecretsManagerReadWrite
+ AmazonFSxReadOnlyAccess
+ AmazonSSMReadOnlyAccess
+ AmazonECSTaskExecutionRolePolicy
## 手順 2: Windows Active Directory (AD) を作成する
1. 「*AWS Directory Service 管理ガイド*」の「[AWS マネージド AD の作成]で説明されている手順に従います](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_create_directory)。このチュートリアル用に指定した VPC を使用します。「*AWS マネージド AD の作成*」のステップ 3 で、次のステップで使用するためにユーザー名と管理者パスワードを保存します。また、今後の手順の完全修飾ディレクトリ DNS 名をメモしておきます。Active Directory の作成中に、次の手順を実行できます。
1. 次のステップで使用する AWS Secrets Manager のシークレットを作成します。詳細については、「*AWS Secrets Manager ユーザーガイド*」の「[Secrets Manager の使用を開始する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html#get-started)」を参照してください。
1. [Secrets Managerコンソール](https://console.aws.amazon.com//secretsmanager/) を開きます。
1. [**新しいシークレットを保存する**] を選択します｡
1. [**その他のシークレット**] を選択します。
1. [**シークレットキー/値**] では、最初の行に値 **admin** を含むキー **username** を作成します。[**\$1 行を追加**] をクリックします。
1. 新しい行で、キー **password** を作成します。値には、*AWSマネージド AD ディレクトリ の作成 *の手順 3 で入力したパスワードを入力します。
1. [**Next**] ボタンをクリックします。
1. シークレットの名前と説明を入力します。**[次へ]** をクリックします。
1. **[次へ]** をクリックします。[**保存**] をクリックします。
1. [**シークレット**] ページのリストから、作成したシークレットをクリックします。
1. 次の手順で使用するために、新しいシークレットの ARN を保存します。
1. Active Directory の作成中に、次の手順に進むことができます。
## ステップ 3: セキュリティグループを確認および更新する
このステップでは、使用しているセキュリティグループのルールを確認および更新します。このためには、VPC 用に作成されたデフォルトのセキュリティグループを使用できます。
**セキュリティグループを確認および更新します。**
ポートとの間でデータを送信するには、セキュリティグループを作成または編集する必要があります。これについては、[*FSx for Windows File Server ユーザーガイド*]の[[Amazon VPC セキュリティグループ](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/limit-access-security-groups.html#fsx-vpc-security-groups)]で説明されています。これを行うには、インバウンドルールの次の表の最初の行に示されているセキュリティグループインバウンドルールを作成します。このルールでは、同じセキュリティグループに割り当てられているネットワークインターフェイス (および関連付けられているインスタンス) からのインバウンドトラフィックを使用できます。作成したクラウドリソースはすべて同じ VPC 内にあり、同じセキュリティグループにアタッチされます。したがって、このルールでは、必要に応じて、FSx for Windows File Server ファイルシステム、アクティブディレクトリ、ECSインスタンスとの間でトラフィックを送信することができます。その他のインバウンドルールでは、ウェブサイトでトラフィックを利用し、ECS インスタンスに接続するための RDP アクセスが行えます。
次の表に、このチュートリアルに必要なセキュリティグループのインバウンドルールを示します。
| タイプ | プロトコル | ポート範囲 | ソース |
| --- | --- | --- | --- |
| すべてのトラフィック | すべて | すべて | *sg-securitygroup* |
| HTTPS | TCP | 443 | 0.0.0.0/0 |
| RDP | TCP | 3389 | ラップトップの IP アドレス |
次の表に、このチュートリアルに必要なセキュリティグループのアウトバウンドルールを示します。
| タイプ | プロトコル | ポート範囲 | 宛先 |
| --- | --- | --- | --- |
| すべてのトラフィック | すべて | すべて | 0.0.0.0/0 |
1. [EC2 コンソール](https://console.aws.amazon.com//ec2/)を開き、左側のメニューから [**セキュリティグループ**] を選択します。
1. 表示されるセキュリティグループのリストから、このチュートリアルで使用しているセキュリティグループの左側にあるチェックボックスをオンにします。
セキュリティグループの詳細が表示されます。
1. **[インバウンドルール]** または **[アウトバウンドルール]** タブを選択して、**[インバウンドルールの編集]** または **[アウトバウンドルールの編集]** ボタンを選択して、インバウンドルールおよびアウトバウンドルールを編集します。前の表に表示されたルールと一致するようにルールを編集します。このチュートリアルの後半で EC2 インスタンスを作成した後、「*Amazon EC2 ユーザーガイド*」の「[RDP を使用して Windows インスタンスに接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html)」に記載の手順に従って、EC2 インスタンスのパブリック IP アドレスを使用してインバウンドルールの RDP ソースを編集します。
## ステップ 4: FSx for Windows File Server ファイルシステムを作成する
セキュリティグループが検証および更新され、アクティブディレクトリ が作成され、アクティブステータスになったら、Active Directory と同じ VPC に FSx for Windows File Server ファイルシステムを作成します。次のステップを使用して、Windows タスク用の FSx for Windows File Server ファイルシステムを作成します。
**最初のファイルシステムを作成します。**
1. [[Amazon FSx コンソール](https://console.aws.amazon.com//fsx/)] を開きます。
1. ダッシュボードで **[Create file system]** (ファイルシステムの作成) を選択して、ファイルシステム作成ウィザードをスタートします。
1. **[Select file system type]** (ファイルシステムのタイプを選択) のページで、**[FSx for Windows File Server]** (FSx for Windows ファイルサーバー) を選択し、**[Next]** (次へ) を選択します。**[Create file system]** (ファイルシステムを作成) ページが表示されます。
1. **[File system details]** (ファイルシステム詳細) セクションで、ファイルシステムの名前を入力します。ファイルシステムに名前を付けると、ファイルの検索と管理が容易になります。最大 256 文字の Unicode 文字を使用できます。使用できる文字は、文字、数字、スペース、および特殊文字のプラス記号 (\$1)、マイナス記号 (-)、等号 (=)、ピリオド (.)、アンダースコア (\$1)、コロン (:)、スラッシュ (/) です。
1. [**Deployment type**] で [**Single-AZ**] を選択して、1 つのアベイラビリティーゾーンにデプロイされたファイルシステムをデプロイします。*[Single-AZ 2]* (シングル AZ 2) は、最新世代の単一アベイラビリティーゾーンファイルシステムで、SSD および HDD ストレージをサポートします。
1. [**Storage type**] で、 [**HDD**] を選択します。
1. [**Storage capacity**] に、ストレージの最小容量を入力します。
1. [**Throughput capacity**] はデフォルト設定のままにします。
1. [**ネットワーク & セキュリティ**] セクションで、Directory Service ディレクトリに対して選択したものと同じ Amazon VPC を選択します。
1. [**VPC Security Groups**] で、*ステップ 3: セキュリティグループを確認および更新する*で検証したセキュリティグループを選択します。
1. [**Windows 認証**] では、[**AWSマネージド Microsoft アクティブディレクトリ**] を選択し、リストからお使いの Directory Service ディレクトリを選択します。
1. **[Encryption]** (暗号化) では、**[aws / fsx (default)]** (aws / fsx (デフォルト) の **[Encryption key]** (暗号化キー) 設定をデフォルトのままにします。
1. [**Maintenance preferences**] ではデフォルト設定のままにします。
1. [**Next**] ボタンをクリックします。
1. **[Create file system]** (ファイルシステムの作成) ページで表示されるファイルシステム設定を確認します。参照のために、ファイルシステム作成後に変更できるファイルシステム設定を書き留めます。[**Create file system**] を選択します。
1. ファイルシステム ID をメモします。ID は後の手順で使用する必要があります。
FSx for Windows File Server ファイルシステムの作成中に、クラスターと EC2 インスタンスを作成するには、次のステップに進みます。
## ステップ 5: Amazon ECS クラスターを作成する
**Amazon ECS コンソールを使用してクラスターを作成する**
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションバーから、使用するリージョンを選択します。
1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. **[Clusters]** (クラスター) ページで、**[Create Cluster]** (クラスターの作成) を選択します。
1. **[クラスター設定]** の **[クラスター名]** に「**windows-fsx-cluster**」と入力します。
1. **[インフラストラクチャ]** を展開し、[AWS Fargate (サーバーレス)] をクリアして、**[Amazon EC2 インスタンス]** を選択します。
1. Auto Scaling グループを作成するには、**Auto Scaling group(ASG)** (Auto Scaling グループ) から、**[Create new group]** (新しいグループの作成) を選択し、グループに関する以下の詳細情報を入力します。
+ **[オペレーティングシステム/アーキテクチャ]** で **[Windows Server 2019 Core]** を選択します。
+ **[EC2 インスタンスタイプ]** で [t2.medium] または [t2.micro] を選択します。
1. **[作成]** を選択します。
## ステップ 6: Amazon ECS に最適化された Amazon EC2 インスタンスを作成する
Amazon ECS Windows コンテナインスタンスを作成します。
**Amazon ECS インスタンスを作成するには**
1. `aws ssm get-parameters` コマンドを使用して、VPC をホストするリージョン用の AMI 名を取得します。詳細については、「[Amazon ECS に最適化された AMI メタデータを取得する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_windows_AMI.html)」を参照してください。
1. Amazon EC2 コンソールを使用して、インスタンスを起動します。
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションバーから、使用するリージョンを選択します。
1. **EC2 ダッシュボード**から、[**Launch Instance**] を選択します。
1. [**Name (名前)**] に一意の名前を入力します。
1. **[アプリケーションと OS イメージ (Amazon マシンイメージ)]** の **[検索]** フィールドに、取得した AMI 名を入力します。
1. **[インスタンスタイプ]** で [t2.medium] または [t2.micro] を選択します。
1. **[Key pair (login)]** (キーペア (ログイン)) には、キーペアを選択します。キーペアを指定しない場合、
1. **[ネットワーク設定]** の **[VPC]** と **[サブネット]**で VPC とパブリックサブネットを選択します。
1. **[Network settings]** (ネットワーク設定) にある **[Security group]** (セキュリティグループ) には、既存のセキュリティグループを選択することも、新しいセキュリティグループを作成することもできます。選択したセキュリティグループに [チュートリアルの前提条件](#wfsx-prerequisites) で定義されたインバウンドルールとアウトバウンドルールがあることを確認してください。
1. **[Network settings]** (ネットワーク設定) の **[Auto-assign Public IP]** (パブリック IP の自動割り当て) で、**[Enable]** (有効にする) を選択します。
1. **[高度な詳細]** を展開し、作成した Active Directory の ID を **[ドメイン結合ディレクトリ]** で選択します。このオプションドメインは、EC2 インスタンスの起動時に AD に参加します。
1. **[Advanced details]** (高度な詳細) で、**[IAM instance profile]** (IAM インスタンスプロファイル) として **[ecsInstanceRole]** を選択します。
1. 次のユーザーデータを使用して、Amazon ECS コンテナインスタンスを設定します。**[Advanced Details]** (詳細情報) にある **[User data]** (ユーザーデータ) フィールドに以下のスクリプトを貼り付け、*cluster\$1name* をクラスターの名前に置き換えます。
```
```
1. 準備ができたら、確認フィールドを選択してから、[**Launch Instances**] を選択します。
1. 確認ページは、インスタンスが起動中であることを通知します。**[View Instances]** (インスタンスを表示) を選択して確認ページを閉じ、コンソールに戻ります。
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで、[**クラスター**] を選択し、**[windows-fsx-cluster]** を選択します。
1. **[インフラストラクチャ]** タブを選択し、インスタンスが **windows-fsx-cluster** クラスターに登録されていることを確認します。
## ステップ 7: Windows タスク定義を登録する
Amazon ECS クラスターで Windows コンテナを実行する前に、タスク定義を登録する必要があります。次のタスク定義の例では、シンプルなウェブページを表示します。このタスクは、FSx ファイルシステムにアクセスできる 2 つのコンテナを起動します。最初のコンテナは HTML ファイルをファイルシステムに書き込みます。2 番目のコンテナは、ファイルシステムから HTML ファイルをダウンロードし、ウェブページを提供します。
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで、**タスクの定義** を選択します。
1. **[Create new task definition]** (新しいタスク定義の作成)、**[Create new task definition with JSON]** (JSON で新しいタスク定義を作成) の順に選択します。
1. JSON エディタボックスで、タスク実行ロールの値と FSx ファイルシステムの詳細を置き換えてから [**保存**] を選択します。
```
{
"containerDefinitions": [
{
"entryPoint": [
"powershell",
"-Command"
],
"portMappings": [],
"command": ["New-Item -Path C:\\fsx-windows-dir\\index.html -ItemType file -Value '
Amazon ECS Sample App
It Works!
You are using Amazon FSx for Windows File Server file system for persistent container storage.
' -Force"],
"cpu": 512,
"memory": 256,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"essential": false,
"name": "container1",
"mountPoints": [
{
"sourceVolume": "fsx-windows-dir",
"containerPath": "C:\\fsx-windows-dir",
"readOnly": false
}
]
},
{
"entryPoint": [
"powershell",
"-Command"
],
"portMappings": [
{
"hostPort": 443,
"protocol": "tcp",
"containerPort": 80
}
],
"command": ["Remove-Item -Recurse C:\\inetpub\\wwwroot\\* -Force; Start-Sleep -Seconds 120; Move-Item -Path C:\\fsx-windows-dir\\index.html -Destination C:\\inetpub\\wwwroot\\index.html -Force; C:\\ServiceMonitor.exe w3svc"],
"mountPoints": [
{
"sourceVolume": "fsx-windows-dir",
"containerPath": "C:\\fsx-windows-dir",
"readOnly": false
}
],
"cpu": 512,
"memory": 256,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"essential": true,
"name": "container2"
}
],
"family": "fsx-windows",
"executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
"volumes": [
{
"name": "fsx-windows-dir",
"fsxWindowsFileServerVolumeConfiguration": {
"fileSystemId": "fs-0eeb5730b2EXAMPLE",
"authorizationConfig": {
"domain": "example.com",
"credentialsParameter": "arn:arn-1234"
},
"rootDirectory": "share"
}
}
]
}
```
## ステップ 8: タスクを実行して結果を表示する
タスクを実行する前に、FSx for Windows File Server ファイルシステムのステータスが [**Available**] であることを確認します。利用可能になったら、作成したタスク定義を使用してタスクを実行できます。タスクはコンテナを作成することから始まります。コンテナはファイルシステムを使用してコンテナ間で HTML ファイルをシャッフルします。シャッフル後、ウェブサーバーは単純な HTML ページを提供します。
**注記**
VPN 内からそのウェブサイトに接続できない場合があります。
**Amazon ECS コンソールを使用して、タスクを実行して結果を表示します。**
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで、[**クラスター**] を選択し、**[windows-fsx-cluster]** を選択します。
1. **[タスク]** タブを選択し、**[新しいタスクを実行]** を選択します。
1. [**起動タイプ**] で、[**EC2**] を選択します。
1. デプロイ設定の **[タスク定義]** で **[fsx-windows]** を選択し、**[作成]** を選択します。
1. タスクのステータスが **[実行中]** の場合は、タスク ID を選択します。
1. **[コンテナ]** で container1 のステータスが **[停止]** の場合、 container2 を選択してコンテナの詳細を表示します。
1. **[container2 のコンテナの詳細]** で **[ネットワークバインディング]** を選択し、コンテナに関連付けられている外部 IP アドレスをクリックします。ブラウザが開き、次のメッセージが表示されます。
```
Amazon ECS Sample App
It Works!
You are using Amazon FSx for Windows File Server file system for persistent container storage.
```
**注記**
メッセージが表示されるまでに数分かかることがあります。このメッセージが数分経っても表示されない場合は、VPN で実行していないことを確認し、コンテナインスタンスのセキュリティグループがポート 443 でのインバウンドネットワーク HTTP トラフィックを許可していることを確認します。
## ステップ 9: クリーンアップする。
**注記**
FSx for Windows File Server ファイルシステムまたは AD の削除には、20～45分かかります。AD の削除操作を開始する前に、FSx for Windows File Server ファイルシステムの削除操作が完了するまで待たなければなりません。
**FSx for Windows File Server ファイルシステムを削除します。**
1. [[Amazon FSxコンソール](https://console.aws.amazon.com//fsx/)] を開きます。
1. 作成した FSx for Windows File Server ファイルシステムの左側にあるラジオボタンを選択します。
1. **[アクション]** を選択します。
1. [**Delete file system**] をクリックします。
**AD を削除します。**
1. [Directory Service コンソール](https://console.aws.amazon.com//directoryservicev2/)を開きます。
1. 作成した AD の左側にあるラジオボタンを選択します。
1. **[アクション]** を選択します。
1. [**Delete directory**] を選択します。
**クラスターを削除します。**
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで、[**クラスター**] を選択し、**[windows-fsx-cluster]** を選択します。
1. **[クラスターの削除]** を選択してください。
1. フレーズを入力し、**[削除]** を選択します。
**EC2 インスタンスを終了します。**
1. [Amazon EC2 コンソール](https://console.aws.amazon.com//ec2/)を開きます。
1. 左側のメニューから、[**Instances**] を選択します。
1. 作成した EC2 インスタンスの左側にあるボックスをチェックします。
1. **[インスタンス状態]**、**[インスタンスを終了]** の順にクリックします。
**シークレットを削除します。**
1. [Secrets Managerコンソール](https://console.aws.amazon.com//secretsmanager/) を開きます。
1. このチュートリアル用に作成したシークレットを選択します。
1. [**Actions**] をクリックします。
1. [**Delete secret**] を選択します。
# Amazon ECS での Docker ボリュームの使用
Docker ボリュームを使用している場合は、組み込みの `local` ドライバーまたはサードパーティーのボリュームドライバーを使用できます。Docker ボリュームは Docker で管理され、ディレクトリはボリュームデータを含むコンテナインスタンスの `/var/lib/docker/volumes` に作成されます。
Docker ボリュームを使用するには、タスク定義で `dockerVolumeConfiguration` を指定します。詳細については、Docker ドキュメントの「[Volumes](https://docs.docker.com/engine/storage/volumes/)」を参照してください。
Docker ボリュームの一般的ユースケースは以下のとおりです。
+ コンテナで使用する永続データボリュームを提供する
+ 定義したデータボリュームを同じコンテナインスタンス上の異なるコンテナにある別々の場所で共有する
+ 空の非永続データボリュームを定義し、同じタスク内の複数のコンテナにマウントする
+ サードパーティー製ドライバーによって管理されるタスクに、データボリュームを提供する
## Docker ボリュームの使用に関する考慮事項
Docker ボリュームを使用する際は、以下の点を考慮します。
+ Docker ボリュームは、EC2 起動タイプ、または外部インスタンスを使用する場合にのみサポートされます。
+ Windows コンテナでは、`local` ドライバーの使用のみサポートされます。
+ サードパーティー製ドライバーを使用する場合は、コンテナエージェントを起動する前に、必ずドライバーをコンテナインスタンスにインストールしアクティブ化しておきます。エージェントを開始する前にサードパーティー製ドライバーがアクティブ化されていない場合は、以下のいずれかのコマンドを使用してコンテナエージェントを再起動することが可能です。
+ Amazon ECS に最適化された Amazon Linux 2 AMI の場合:
```
sudo systemctl restart ecs
```
+ Amazon ECS に最適化された Amazon Linux AMI の場合:
```
sudo stop ecs && sudo start ecs
```
タスク定義で Docker ボリュームを指定する方法については、「[Amazon ECS タスク定義で Docker ボリュームを指定する](specify-volume-config.md)」を参照してください。
# Amazon ECS タスク定義で Docker ボリュームを指定する
コンテナでデータボリュームを使用するには、ボリュームを指定し、タスク定義でポイント設定をマウントする必要があります。このセクションでは、コンテナのボリューム設定について説明します。Docker ボリュームを使用する`dockerVolumeConfiguration` を指定します。バインドマウントのホストボリュームを使用するタスクで、`host` とオプションの `sourcePath` を指定します。
次のタスク定義の JSON スニペットに、コンテナの `volumes` と `mountPoints` オブジェクト用の構文を示します。
```
{
"containerDefinitions": [
{
"mountPoints": [
{
"sourceVolume": "string",
"containerPath": "/path/to/mount_volume",
"readOnly": boolean
}
]
}
],
"volumes": [
{
"name": "string",
"dockerVolumeConfiguration": {
"scope": "string",
"autoprovision": boolean,
"driver": "string",
"driverOpts": {
"key": "value"
},
"labels": {
"key": "value"
}
}
}
]
}
```
`name`
タイプ: 文字列
必須: いいえ
ボリュームの名前。最大 255 文字の英字 (大文字と小文字の区別あり)、数字、ハイフン (`-`)、アンダースコア (`_`) を使用できます。この名前は、コンテナ定義 `mountPoints` オブジェクトの `sourceVolume` パラメータで参照されます。
`dockerVolumeConfiguration`
タイプ: [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) オブジェクト
必須: いいえ
このパラメータは、Docker ボリュームを使用する場合に指定します。Docker ボリュームは、EC2 インスタンスでタスクを実行する場合にのみサポートされます。Windows コンテナでは、`local` ドライバーの使用のみがサポートされます。バインドマウントを使用するには、代わりに `host` を指定します。
`scope`
タイプ: 文字列
有効な値: `task` \$1 `shared`
必須: いいえ
Docker ボリュームのスコープ。これにより、ボリュームのライフサイクルが決定されます。Docker ボリュームの範囲が `task` の場合は、タスクが開始すると自動的にプロビジョンされ、タスクが停止すると破棄されます。Docker ボリュームの範囲が `shared` の場合は、タスクの停止後も保持されます。
`autoprovision`
タイプ: ブール値
デフォルト値: `false`
必須: いいえ
この値が `true` の場合、既に存在していない場合は Docker ボリュームが作成されます。このフィールドは、`scope` が `shared` の場合にのみ使用されます。`scope` が `task` の場合、このパラメータは省略する必要があります。
`driver`
タイプ: 文字列
必須: いいえ
使用する Docker ボリュームドライバー。この名前はタスク配置に使用されるため、ドライバー値は Docker で提供されているドライバー名と一致する必要があります。ドライバーが Docker プラグイン CLI を使用してインストールされた場合は、`docker plugin ls` を使用してコンテナインスタンスからドライバー名を取得します。ドライバーが別の方法でインストール済みである場合は、Docker プラグイン検出を使用してドライバー名を取得します。
`driverOpts`
タイプ: 文字列
必須: いいえ
パススルーする Docker ドライバー固有のオプションのマップ。このパラメータは、Docker の「Create a volume」セクションの `DriverOpts` にマッピングされます。
`labels`
タイプ: 文字列
必須: いいえ
Docker ボリュームに追加するカスタムメタデータ。
`mountPoints`
タイプ: オブジェクト配列
必須: いいえ
コンテナでのデータボリュームのマウントポイント。このパラメータは creat-container Docker API の `Volumes` にマッピングされ、docker run の `--volume` オプションにマッピングされます。
Windows コンテナは `$env:ProgramData` と同じドライブに全部のディレクトリをマウントできます。Windows コンテナは、別のドライブにディレクトリをマウントすることはできません。また、マウントポイントは複数のドライブにまたがることはできません。Amazon EBS ボリュームを Amazon ECS タスクに直接アタッチするには、マウントポイントを指定する必要があります。
`sourceVolume`
タイプ: 文字列
必須: はい (`mountPoints` を使用する場合)
マウントするボリュームの名前。
`containerPath`
タイプ: 文字列
必須: はい (`mountPoints` を使用する場合)
ボリュームをマウントするコンテナ内のパス。
`readOnly`
タイプ: ブール値
必須: いいえ
この値が `true` の場合、コンテナはボリュームへの読み取り専用アクセスを許可されます。この値が `false` の場合、コンテナはボリュームに書き込むことができます。デフォルト値は `false` です。
Windows オペレーティングシステムを実行している EC2 インスタンスで実行されるタスクの場合、 値をデフォルト の `false` のままにします。
# Amazon ECS の Docker ボリュームの例
次の例は、コンテナにエフェメラルストレージを提供する方法、複数のコンテナに共有ボリュームを提供する方法、およびコンテナに NFS 永続ストレージを提供する方法を示しています。
**Docker ボリュームを使用してコンテナの一時ストレージを提供する**
この例では、コンテナは空のデータボリュームを使用しており、これはタスクが完了した後に破棄されます。ユースケースの一例としては、タスクの実行中に一部のスクラッチファイルストレージにアクセスする必要のあるコンテナが考えられます。このタスクは、Docker ボリュームを使用して行うことができます。
1. タスク定義の `volumes` セクションで、`name` および `DockerVolumeConfiguration` 値を使用して、データボリュームを定義します。この例では、タスクが停止した後にボリュームが削除されるように、範囲に `task` を指定して、組み込みの `local` ドライバーを使用します。
```
"volumes": [
{
"name": "scratch",
"dockerVolumeConfiguration" : {
"scope": "task",
"driver": "local",
"labels": {
"scratch": "space"
}
}
}
]
```
1. `containerDefinitions` セクションで、定義したボリュームの名前を参照する `mountPoints` 値と、コンテナにボリュームをマウントするための `containerPath` 値を使用して、コンテナを定義します。
```
"containerDefinitions": [
{
"name": "container-1",
"mountPoints": [
{
"sourceVolume": "scratch",
"containerPath": "/var/scratch"
}
]
}
]
```
**Docker ボリュームを使用して複数のコンテナの永続的ストレージを提供するには**
この例では、複数のコンテナで使用する共有ボリュームが必要で、また、使用するタスクの内の 1 つが停止した後も、このボリュームを維持する必要があります。組み込みの `local` ドライバーは使用中です。このためボリュームは、コンテナインスタンスのライフサイクルに紐付けられたままです。
1. タスク定義の `volumes` セクションで、`name` および `DockerVolumeConfiguration` 値を使用して、データボリュームを定義します。この例では、`shared` スコープをボリュームが維持されるように指定し、自動プロビジョニングを `true` に設定します。これは、使用するためのボリュームが作成されるようにするためです。また、組み込みの `local` ドライバーも使用します。
```
"volumes": [
{
"name": "database",
"dockerVolumeConfiguration" : {
"scope": "shared",
"autoprovision": true,
"driver": "local",
"labels": {
"database": "database_name"
}
}
}
]
```
1. `containerDefinitions` セクションで、定義したボリュームの名前を参照する `mountPoints` 値と、コンテナにボリュームをマウントするための `containerPath` 値を使用して、コンテナを定義します。
```
"containerDefinitions": [
{
"name": "container-1",
"mountPoints": [
{
"sourceVolume": "database",
"containerPath": "/var/database"
}
]
},
{
"name": "container-2",
"mountPoints": [
{
"sourceVolume": "database",
"containerPath": "/var/database"
}
]
}
]
```
**Docker ボリュームを使用してコンテナの NFS 永続的ストレージを提供する**
この例では、コンテナはタスクの開始時に自動的にマウントされ、タスクの停止時にアンマウントされる NFS データボリュームを使用します。これは Docker ビルトイン `local` ドライバーを使用します。ユースケースの一例としては、ローカル NFS ストレージがあり、ECS Anywhere タスクからアクセスする必要がある場合があります。これは、NFS ドライバーオプションの Docker ボリュームを使用して実現できます。
1. タスク定義の `volumes` セクションで、`name` および `DockerVolumeConfiguration` 値を使用して、データボリュームを定義します。この例では、タスクが停止した後にボリュームがアンマウントされるように `task` のスコープを指定してください。`local` ドライバーを使用し、`type`、`device`、および `o` オプションを適宜使用して `driverOpts` を設定します。`NFS_SERVER` は NFS サーバーエンドポイントに置き換えます。
```
"volumes": [
{
"name": "NFS",
"dockerVolumeConfiguration" : {
"scope": "task",
"driver": "local",
"driverOpts": {
"type": "nfs",
"device": "$NFS_SERVER:/mnt/nfs",
"o": "addr=$NFS_SERVER"
}
}
}
]
```
1. `containerDefinitions` セクションで、定義したボリュームの名前を参照する `mountPoints` 値と、コンテナにボリュームをマウントするための `containerPath` 値を使用して、コンテナを定義します。
```
"containerDefinitions": [
{
"name": "container-1",
"mountPoints": [
{
"sourceVolume": "NFS",
"containerPath": "/var/nfsmount"
}
]
}
]
```
# Amazon ECS でのバインドマウントの使用
バインドマウントでは、ホスト (Amazon EC2 インスタンスなど) 上のファイルまたはディレクトリがコンテナにマウントされます。バインドマウントは、Fargate インスタンスと Amazon EC2 インスタンスの両方でホストされているタスクでサポートされています。バインドマウントは、それらを使用するコンテナのライフサイクルに紐付けられています。タスクが停止するなど、バインドマウントを使用するすべてのコンテナが停止すると、データが削除されます。Amazon EC2 インスタンスでホストされているタスクの場合、タスク定義で `host` とオプションの `sourcePath` 値を指定することにより、ホスト側 Amazon EC2 インスタンスのライフサイクルにデータを紐付けすることができます。詳細については、Docker ドキュメントの「[Bind mounts](https://docs.docker.com/engine/storage/bind-mounts/)」を参照してください。
バインドマウントの一般的なユースケースは以下のとおりです。
+ 1 つ以上のコンテナにマウントするための空のデータボリュームを提供する。
+ 1 つ以上のコンテナにホストデータボリュームをマウントする。
+ ソースコンテナのデータボリュームを、同じタスク内の他のコンテナと共有する。
+ Dockerfile から 1 つ以上のコンテナにパスとその内容を公開する。
## バインドマウントを使用するときの考慮事項
バインドマウントを使用する際には、以下の点を考慮してください。
+ プラットフォームバージョン `1.4.0` 以降 (Linux) または `1.0.0` 以降 (Windows) を使用して AWS Fargate でホストされているタスクの場合、デフォルトでは、バインドマウント用に最低 20 GiB の一時ストレージが割り当てられます。タスク定義で `ephemeralStorage` パラメータを指定することによって、一時ストレージの総量を最大 200 GiB まで増やすことができます。
+ タスクの実行時に Dockerfile のファイルをデータボリュームに公開するために、Amazon ECS データプレーンが `VOLUME` ディレクティブを探します。`VOLUME` ディレクティブで指定された絶対パスが、タスク定義で指定された `containerPath` と同じである場合、`VOLUME` ディレクティブパス内のデータがデータボリュームにコピーされます。次の Dockerfile の例では、`/var/log/exported` ディレクトリにある `examplefile` という名前のファイルがホストに書き込まれ、その後でコンテナ内にマウントされます。
```
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN mkdir -p /var/log/exported
RUN touch /var/log/exported/examplefile
VOLUME ["/var/log/exported"]
```
デフォルトでは、ボリューム許可は `0755` に設定され、所有者は `root` に設定されます。これらのアクセス許可は Dockerfile でカスタマイズできます。次の例では、ディレクトリの所有者を `node` として定義しています。
```
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN yum install -y shadow-utils && yum clean all
RUN useradd node
RUN mkdir -p /var/log/exported && chown node:node /var/log/exported
RUN touch /var/log/exported/examplefile
USER node
VOLUME ["/var/log/exported"]
```
+ Amazon EC2 インスタンスでホストされているタスクで、`host` 値と `sourcePath` 値が指定されていない場合には、Docker デーモンがバインドマウントを自動的に管理します。このバインドマウントを参照するコンテナが存在しない場合、このマウントは、Amazon ECS コンテナエージェントのタスククリーンアップサービスによって最終的に削除されます。デフォルトでは、この処理はコンテナが終了してから 3 時間後に実行されま。また、この期間は `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` エージェント変数により設定することも可能です。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。コンテナのライフサイクルを通じてこのデータを永続化する必要がある場合は、バインドマウントの `sourcePath` 値を指定します。
+ Amazon ECS マネージドインスタンスでホストされているタスクの場合、ルートファイルシステムの一部が読み取り専用になっています。読み取り/書き込みバインドマウントは、永続データに `/tmp`、一時データに `/var` といった書き込み可能なディレクトリを使用する必要があります。他のディレクトリに読み取り/書き込みバインドマウントを作成しようとすると、以下のようなエラーでタスクの起動が失敗します。
```
error creating empty volume: error while creating volume path '/path': mkdir /path: read-only file system
```
読み取り専用バインドマウント (`mountPoints` パラメータの `"readOnly": true` で設定) は、ホスト上にある任意のアクセス可能なディレクトリをポイントできます。
書き込み可能なパスの完全なリストを表示するには、Amazon ECS マネージドインスタンスでタスクを実行し、それを使用してインスタンスのマウントテーブルを検査できます。ホストファイルシステムにアクセスするには、以下の設定を使用してタスク定義を作成します。
```
{
"pidMode": "host",
"containerDefinitions": [{
"privileged": true,
...
}]
}
```
次に、コンテナ内から以下のコマンドを実行します。
```
# List writable mounts
cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^rw,/ || $4 == "rw" {print $2}' | sort
# List read-only mounts
cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^ro,/ || $4 == "ro" {print $2}' | sort
```
**重要**
`privileged` 設定は、ホスト上でルートアクセスに相当する拡張機能をコンテナに付与します。この例では、診断目的でホストのマウントテーブルを検査するために使用されます。詳細については、「[コンテナを特権として実行することは避けてください (Amazon EC2)](security-tasks-containers.md#security-tasks-containers-recommendations-avoid-privileged-containers)」を参照してください。
コンテナ内でのコマンドのインタラクティブな実行に関する詳細については、「[ECS Exec を使用して Amazon ECS コンテナをモニタリングする](ecs-exec.md)」を参照してください。
# Amazon ECS タスク定義でバインドマウントを指定する
Fargate または Amazon EC2 インスタンスでホストされている Amazon ECS タスクについて、以下のタスク定義 JSON スニペットにタスク定義向け `volumes`、`mountPoints`、`ephemeralStorage` オブジェクトの構文を示します。
```
{
"family": "",
...
"containerDefinitions" : [
{
"mountPoints" : [
{
"containerPath" : "/path/to/mount_volume",
"sourceVolume" : "string"
}
],
"name" : "string"
}
],
...
"volumes" : [
{
"name" : "string"
}
],
"ephemeralStorage": {
"sizeInGiB": integer
}
}
```
Amazon EC2 インスタンスでホストされる Amazon ECS タスクで、タスクボリュームの詳細を指定する場合は、オプションの `host` パラメータおよび `sourcePath` を使用できます。これを指定すると、バインドマウントはコンテナではなくタスクのライフサイクルに紐付けされます。
```
"volumes" : [
{
"host" : {
"sourcePath" : "string"
},
"name" : "string"
}
]
```
以下では、各タスク定義パラメータについて詳しく説明します。
`name`
タイプ: 文字列
必須: いいえ
ボリュームの名前。最大 255 文字の英字 (大文字と小文字の区別あり)、数字、ハイフン (`-`)、アンダースコア (`_`) を使用できます。この名前は、コンテナ定義 `mountPoints` オブジェクトの `sourceVolume` パラメータで参照されます。
`host`
必須: いいえ
`host` パラメーターは、バインドマウントのライフサイクルを、タスクではなくホスト Amazon EC2 インスタンスと、それが格納されている場所に関連付けるために使用されます。`host` パラメーターが空の場合、Docker デーモンはデータボリュームのホストパスを割り当てますが、関連付けられたコンテナの実行が停止した後にデータが保持されるとは限りません。
Windows コンテナは `$env:ProgramData` と同じドライブに全部のディレクトリをマウントできます。
`sourcePath` パラメータは、Amazon EC2 インスタンスまたは Amazon ECS マネージドインスタンスでホストされているタスクを使用する場合にのみサポートされます。
`sourcePath`
タイプ: 文字列
必須: いいえ
`host` パラメータを使用する場合は、`sourcePath` を指定して、コンテナに表示されるホスト Amazon EC2 インスタンスのパスを宣言します。このパラメータが空の場合は、Docker デーモンによってホストパスが割り当てられます。`host` パラメータに `sourcePath` の場所が含まれている場合、データボリュームは手動で削除するまでホスト Amazon EC2 インスタンスの指定された場所に保持されます。`sourcePath` の値がホスト Amazon EC2 インスタンスに存在しない場合は、Docker デーモンによって作成されます。その場所が存在する場合は、ソースパスフォルダの内容がエクスポートされます。
`mountPoints`
タイプ: オブジェクト配列
必須: いいえ
コンテナでのデータボリュームのマウントポイント。このパラメータは creat-container Docker API の `Volumes` にマッピングされ、docker run の `--volume` オプションにマッピングされます。
Windows コンテナは `$env:ProgramData` と同じドライブに全部のディレクトリをマウントできます。Windows コンテナは、別のドライブにディレクトリをマウントすることはできません。また、マウントポイントは複数のドライブにまたがることはできません。Amazon EBS ボリュームを Amazon ECS タスクに直接アタッチするには、マウントポイントを指定する必要があります。
`sourceVolume`
タイプ: 文字列
必須: はい (`mountPoints` を使用する場合)
マウントするボリュームの名前。
`containerPath`
タイプ: 文字列
必須: はい (`mountPoints` を使用する場合)
ボリュームをマウントするコンテナ内のパス。
`readOnly`
タイプ: ブール値
必須: いいえ
この値が `true` の場合、コンテナはボリュームへの読み取り専用アクセスを許可されます。この値が `false` の場合、コンテナはボリュームに書き込むことができます。デフォルト値は `false` です。
Windows オペレーティングシステムを実行している EC2 インスタンスで実行されるタスクの場合、 値をデフォルト の `false` のままにします。
`ephemeralStorage`
タイプ: オブジェクト
必須: いいえ
タスクに割り当てるエフェメラルストレージの容量(GB)。このパラメータは、AWS Fargate プラットフォームバージョン `1.4.0` 以降 (Linux) または `1.0.0` 以降 (Windows) を使用してホストされているタスクの場合、利用可能なエフェメラルストレージの総量をデフォルト容量を超えて拡張するために使用されます。
コパイロットCLI、CloudFormation、AWSSDK または CLI を使用して、バインドマウントのエフェメラルストレージを指定します。
# Amazon ECS のバインドマウントの例
以下の例では、コンテナにバインドマウントを使用する場合の一般的なユースケースについて説明します。
**Fargate タスク用の一時ストレージ容量の増加を割り当てるには**
プラットフォームバージョン `1.4.0` 以降 (Linux) または `1.0.0` (Windows) を使用して Fargate でホストされる Amazon ECS タスクの場合、使用するタスク内のコンテナに対して、デフォルト容量を超えるエフェメラルストレージを割り当てることができます。この例は、他の例に組み込むことで、Fargate タスクに一時ストレージを割り当てることができます。
+ タスク定義で、`ephemeralStorage`オブジェクトを定義します。`sizeInGiB` は `21`および`200` の値の間にある整数である必要があり、GiB に表されます。
```
"ephemeralStorage": {
"sizeInGiB": integer
}
```
**1 つまたは複数のコンテナに空のデータボリュームを提供する**
場合によっては、タスク内のコンテナにスクラッチスペースを提供することがあります。例えば、タスクの実行中に同じスクラッチファイルの保存場所にアクセスする必要のある、2 つのデータベースコンテナがあるとします。これは、バインドマウントを使用して実現できます。
1. タスク定義の `volumes` セクションで、名前を `database_scratch` としてバインドマウントを定義します。
```
"volumes": [
{
"name": "database_scratch"
}
]
```
1. `containerDefinitions` セクションで、データベースのコンテナ定義を作成します。これにより、ボリュームがマウントされます。
```
"containerDefinitions": [
{
"name": "database1",
"image": "my-repo/database",
"cpu": 100,
"memory": 100,
"essential": true,
"mountPoints": [
{
"sourceVolume": "database_scratch",
"containerPath": "/var/scratch"
}
]
},
{
"name": "database2",
"image": "my-repo/database",
"cpu": 100,
"memory": 100,
"essential": true,
"mountPoints": [
{
"sourceVolume": "database_scratch",
"containerPath": "/var/scratch"
}
]
}
]
```
**Dockerfile 内のパスとその内容をコンテナに公開する**
この例には、コンテナ内にマウントするデータを書き込む Dockerfile があります。この例は、Fargate または Amazon EC2 インスタンスでホストされているタスクで機能します。
1. Dockerfile を作成します。次の例では、パブリックな Amazon Linux 2 コンテナイメージを使用して、コンテナ内にマウントする `/var/log/exported` ディレクトリに `examplefile` という名前のファイルを作成します。`VOLUME` ディレクティブは絶対パスを指定する必要があります。
```
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN mkdir -p /var/log/exported
RUN touch /var/log/exported/examplefile
VOLUME ["/var/log/exported"]
```
デフォルトでは、ボリューム許可は `0755` に設定され、所有者は `root` に設定されます。これらのアクセス許可は Dockerfile で変更できます。以下の例では、`/var/log/exported` ディレクトリの所有者が `node` に設定されています。
```
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN yum install -y shadow-utils && yum clean all
RUN useradd node
RUN mkdir -p /var/log/exported && chown node:node /var/log/exported
USER node
RUN touch /var/log/exported/examplefile
VOLUME ["/var/log/exported"]
```
1. タスク定義の `volumes` セクションで、名前を `application_logs` としてボリュームを定義します。
```
"volumes": [
{
"name": "application_logs"
}
]
```
1. `containerDefinitions` セクションで、アプリケーションのコンテナ定義を作成します。これにより、ストレージがマウントされます。`containerPath` 値は、Dockerfile の `VOLUME` ディレクティブで指定された絶対パスと一致する必要があります。
```
"containerDefinitions": [
{
"name": "application1",
"image": "my-repo/application",
"cpu": 100,
"memory": 100,
"essential": true,
"mountPoints": [
{
"sourceVolume": "application_logs",
"containerPath": "/var/log/exported"
}
]
},
{
"name": "application2",
"image": "my-repo/application",
"cpu": 100,
"memory": 100,
"essential": true,
"mountPoints": [
{
"sourceVolume": "application_logs",
"containerPath": "/var/log/exported"
}
]
}
]
```
**ホスト Amazon EC2 インスタンスのライフサイクルに紐付けされているコンテナに、空のデータボリュームを提供するには**
Amazon EC2 インスタンスでホストされているタスクの場合、バインドマウントを使用して、ホスト Amazon EC2 インスタンスのライフサイクルにデータを紐付けすることができます。これは、`host` パラメータを使用して `sourcePath` 値を指定することで設定できます。`sourcePath` に存在するファイルはすべて、`containerPath` の値でコンテナに表示されます。`containerPath` に書き込まれたファイルは、ホストの Amazon EC2 インスタンス上の `sourcePath` 値に書き込まれます。
**重要**
Amazon ECS は、Amazon EC2 インスタンス間でストレージを同期しません。永続的ストレージを使用するタスクは、使用可能なキャパシティーのあるクラスター内の Amazon EC2 インスタンスに配置できます。タスクを停止して再び開始した後に永続的ストレージが必要な場合は、タスクの開始時に毎回 AWS CLI の [start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html) コマンドを使用して、同一の Amazon EC2 インスタンスを指定し直す必要があります。永続ストレージに Amazon EFS ボリュームを使用することもできます。詳細については、「[Amazon ECS での Amazon EFS ボリュームの使用](efs-volumes.md)」を参照してください。
1. タスク定義の `volumes` セクションで、`name` および `sourcePath` 値を使用して、バインドマウントを定義します。次の例では、ホスト Amazon EC2 インスタンスはコンテナ内にマウントしたい `/ecs/webdata` のデータを含めます。
```
"volumes": [
{
"name": "webdata",
"host": {
"sourcePath": "/ecs/webdata"
}
}
]
```
1. `containerDefinitions` セクションで、定義したバインドマウントの名前を参照する `mountPoints` 値と、コンテナにバインドマウントをマウントするための `containerPath` 値を使用して、コンテナを定義します。
```
"containerDefinitions": [
{
"name": "web",
"image": "public.ecr.aws/docker/library/nginx:latest",
"cpu": 99,
"memory": 100,
"portMappings": [
{
"containerPort": 80,
"hostPort": 80
}
],
"essential": true,
"mountPoints": [
{
"sourceVolume": "webdata",
"containerPath": "/usr/share/nginx/html"
}
]
}
]
```
**定義したボリュームを異なる場所にある複数のコンテナにマウントする**
タスク定義でデータボリュームを定義し、そのボリュームをさまざまなコンテナのさまざまな場所にマウントできます。例えば、ホストコンテナの `/data/webroot` に、ウェブサイトのデータフォルダがあるとします。そのデータボリュームを、異なるドキュメントルートを持つ 2 つの異なる Web サーバーに、読み取り専用としてマウントしたい場合があります。
1. タスク定義の `volumes` セクションで、名前を `webroot`、ソースパスを `/data/webroot` としてデータボリュームを定義します。
```
"volumes": [
{
"name": "webroot",
"host": {
"sourcePath": "/data/webroot"
}
}
]
```
1. `containerDefinitions` セクションで、各ウェブサーバーのコンテナを定義しています。各コンテナの `mountPoints` で、`webroot` ボリュームを、そのコンテナのドキュメントルートを参照する `containerPath` 値に関連付けます。
```
"containerDefinitions": [
{
"name": "web-server-1",
"image": "my-repo/ubuntu-apache",
"cpu": 100,
"memory": 100,
"portMappings": [
{
"containerPort": 80,
"hostPort": 80
}
],
"essential": true,
"mountPoints": [
{
"sourceVolume": "webroot",
"containerPath": "/var/www/html",
"readOnly": true
}
]
},
{
"name": "web-server-2",
"image": "my-repo/sles11-apache",
"cpu": 100,
"memory": 100,
"portMappings": [
{
"containerPort": 8080,
"hostPort": 8080
}
],
"essential": true,
"mountPoints": [
{
"sourceVolume": "webroot",
"containerPath": "/srv/www/htdocs",
"readOnly": true
}
]
}
]
```
**`volumesFrom` を使用して別のコンテナからボリュームをマウントするには**
Amazon EC2 インスタンスでホストされているタスクの場合、あるコンテナに 1 つ以上のボリュームを定義し、(同じタスクの) 異なるコンテナ定義で `volumesFrom` パラメータを使用して、`sourceContainer` のすべてのボリュームを、最初に定義されていたマウントポイントにマウントできます。`volumesFrom` パラメータは、タスク定義で定義されたボリューム、および Dockerfile でイメージに組み込まれたボリュームに適用されます。
1. (オプション) イメージに組み込まれているボリュームを共有するには、Dockerfile の `VOLUME` 命令を使用します。次の Dockerfile の例では、`httpd` イメージを使用しボリュームを追加して、それを Apache ドキュメントルートの `dockerfile_volume` にマウントしています。これは、`httpd` ウェブサーバーが使用するフォルダーです。
```
FROM httpd
VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"]
```
この Dockerfile を使用してイメージを構築し、Docker ハブなどのレポジトリにプッシュして、タスク定義で使用できます。以下のステップで使用する `my-repo/httpd_dockerfile_volume` イメージ例は、上記の Dockerfile から構築したものです。
1. コンテナの他のボリュームとマウントポイントを定義するタスク定義を作成します。この例の `volumes` セクションでは、Docker デーモンによって管理される空のボリューム `empty` を作成します。また、`host_etc` と呼ばれるホストボリュームも定義されています。これは、ホストコンテナインスタンス上の `/etc` フォルダをエクスポートします。
```
{
"family": "test-volumes-from",
"volumes": [
{
"name": "empty",
"host": {}
},
{
"name": "host_etc",
"host": {
"sourcePath": "/etc"
}
}
],
```
コンテナ定義セクションで、先ほど定義したボリュームをマウントするコンテナを作成します。この例では、`web` コンテナが `empty` および `host_etc` ボリュームをマウントします。このコンテナは、Dockerfile 内のボリュームでビルドされたイメージを使用しています。
```
"containerDefinitions": [
{
"name": "web",
"image": "my-repo/httpd_dockerfile_volume",
"cpu": 100,
"memory": 500,
"portMappings": [
{
"containerPort": 80,
"hostPort": 80
}
],
"mountPoints": [
{
"sourceVolume": "empty",
"containerPath": "/usr/local/apache2/htdocs/empty_volume"
},
{
"sourceVolume": "host_etc",
"containerPath": "/usr/local/apache2/htdocs/host_etc"
}
],
"essential": true
},
```
`volumesFrom` を使用して、`web` コンテナに関連付けられているすべてのボリュームをマウントする、別のコンテナを作成します。`web` コンテナ上にあるすべてのボリュームは、同様に `busybox` コンテナにもマウントされます。これには、`my-repo/httpd_dockerfile_volume` イメージのビルドに使用された Dockerfile で指定されたボリュームも含まれます。
```
{
"name": "busybox",
"image": "busybox",
"volumesFrom": [
{
"sourceContainer": "web"
}
],
"cpu": 100,
"memory": 500,
"entryPoint": [
"sh",
"-c"
],
"command": [
"echo $(date) > /usr/local/apache2/htdocs/empty_volume/date && echo $(date) > /usr/local/apache2/htdocs/host_etc/date && echo $(date) > /usr/local/apache2/htdocs/dockerfile_volume/date"
],
"essential": false
}
]
}
```
このタスクが実行されると、2 つのコンテナでボリュームがマウントされ、`busybox` コンテナの `command` がファイルに日付と時刻を書き込みます。このファイルは、各ボリュームフォルダに `date` の名前で保存されています。その後、フォルダは `web` コンテナによって表示されるウェブサイトで見ることができます。
**注記**
`busybox` コンテナはクイックコマンドを実行して終了するため、コンテナ定義で `"essential": false` として設定する必要があります。そうしなければ、終了時にタスク全体が停止します。
# Amazon ECS のコンテナスワップメモリ空間の管理
Amazon ECS を使用すると、Linux ベースの Amazon EC2 インスタンスで、スワップメモリ空間の使用状況をコンテナレベルで制御できるようになります。コンテナ単位のスワップ設定を使用すると、タスク定義内で各コンテナについて、スワップを有効または無効にできます。これが有効化されたコンテナでは、使用されるスワップ領域の最大量を制限できます。例えば、レイテンシーが厳しいコンテナでは、スワップを無効にすることができます。一方で、メモリ需要が一時的に高くなるコンテナでは、スワップを有効にすることで、コンテナのロード時にメモリ不足エラーが発生する可能性を減らすことができます。
コンテナのスワップ設定は、以下のコンテナ定義パラメータによって管理されます。
`maxSwap`
コンテナが使用できるスワップメモリの合計 (MiB 単位)。このパラメータは、docker run の `--memory-swap` オプションに変換されます。値はコンテナメモリの合計に `maxSwap` の値を加えた値です。
`0` の `maxSwap` 値を指定した場合、コンテナはスワップを使用しません。許容値は、`0` または任意の正の整数です。`maxSwap` パラメータを省略すると、コンテナは実行中のコンテナインスタンスのスワップ設定を使用します。`swappiness` パラメータを使用するには、`maxSwap` 値を設定する必要があります。
`swappiness`
これにより、コンテナのメモリスワップ動作を調整できます。`swappiness` の値が `0` であると、必要な場合を除きスワップは発生しません。`swappiness` の値が `100` の場合は、ページが積極的にスワップされます。使用できる値は、`0` と `100` の間の整数です。`swappiness` パラメータを指定しない場合、デフォルト値の `60` が使用されます。`maxSwap` の値が指定されていない場合、このパラメータは無視されます。このパラメータは docker run の `--memory-swappiness` オプションにマッピングされます。
次の例に、JSON での構文を示します。
```
"containerDefinitions": [{
...
"linuxParameters": {
"maxSwap": integer,
"swappiness": integer
},
...
}]
```
## 考慮事項
コンテナごとのスワップ構成を使用する場合は、次の点を考慮してください。
+ スワップ領域は有効化され、使用するコンテナ向けのタスクをホストする、Amazon EC2 インスタンスに割り当てられる必要があります。Amazon ECS 最適化 AMI のデフォルトでは、スワップは有効になっていません。この機能を使用するには、インスタンスでスワップを有効にする必要があります。詳細は「*Amazon EC2 ユーザーガイド*」の「[インスタンスストアスワップボリューム](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-swap-volumes.html)」または「[How do I allocate memory to work as swap space in an Amazon EC2 instance?](https://repost.aws/knowledge-center/ec2-memory-swap-file)」を参照してください。
+ スワップスペースのコンテナ定義パラメータは、EC2 を指定したタスク定義でのみサポートされます。これらのパラメータは、Fargate の Amazon ECS での使用のみを目的としたタスク定義ではサポートされていません。
+ この機能は Linux コンテナでのみサポートされています。現在、Windows コンテナはサポートされていません。
+ コンテナ定義の `maxSwap` および `swappiness` パラメータがタスク定義から省略されている場合、各コンテナの `swappiness` には、デフォルト値の `60` が設定されます。さらに、スワップの合計使用量は、コンテナのメモリ量の 2 倍に制限されます。
+ Amazon Linux 2023 でタスクを使用している場合、`swappiness` パラメータはサポートされていません。
# Amazon ECS マネージドインスタンスの Amazon ECS タスク定義の違い
Amazon ECS マネージドインスタンスを使用するには、Amazon ECS マネージドインスタンスの起動タイプを使用するようにタスク定義を設定する必要があります。Amazon ECS マネージドインスタンスを使用する際には、追加の考慮事項があります。
## タスク定義パラメータ
Amazon ECS マネージドインスタンスを使用するタスクは、利用可能な Amazon ECS のタスク定義パラメータの大部分に対応しています。ただし一部のパラメータには、Amazon ECS マネージドインスタンスタスクでの使用には特定の動作制限が伴います。
次のタスク定義パラメータは Amazon ECS マネージドインスタンスタスクでは無効となっています。
+ `disableNetworking`
+ `dnsSearchDomains`
+ `dnsServers`
+ `dockerLabels`
+ `dockerSecurityOptions`
+ `dockerVolumeConfiguration`
+ `ephemeralStorage`
+ `extraHosts`
+ `fsxWindowsFileServerVolumeConfiguration`
+ `hostname`
+ `inferenceAccelerator`
+ `ipcMode`
+ `links`
+ `maxSwap`
+ `proxyConfiguration`
+ `sharedMemorySize`
+ `sourcepath` ボリューム
+ `swappiness`
+ `tmpfs`
以下のタスク定義パラメータは Amazon ECS マネージドインスタンスタスクで有効ですが、注意すべき制限があります。
+ `networkConfiguration` – Amazon ECS マネージドインスタンスタスクは、`awsvpc` または `host` ネットワークモードを使用します。
+ `placementConstraints` – 以下の制約属性がサポートされています。
+ `ecs.subnet-id`
+ `ecs.availability-zone`
+ `ecs.instance-type`
+ `ecs.cpu-architecture`
+ `requiresCompatibilities` – タスク定義が Amazon ECS マネージドインスタンスと互換性があることを確認するには、`MANAGED_INSTANCES` を含める必要があります。
+ `resourceRequirement` – `InferenceAccelerator` はサポートされていません。
+ `operatingSystemFamily` – Amazon ECS マネージドインスタンスは `LINUX` を使用します。
+ `volumes` - `sourcePath` が設定されたバインドマウントを使用するときは、パスがホスト上の書き込み可能なディレクトリをポイントしている必要があります。Amazon ECS マネージドインスタンスファイルシステムの一部は読み取り専用です。書き込み可能なディレクトリには、`/var` および `/tmp` が含まれます。詳細については、「[Amazon ECS でのバインドマウントの使用](bind-mounts.md)」を参照してください。
タスク定義が Amazon ECS マネージドインスタンスで使用できることを検証するために、タスク定義を登録する際に以下を指定できます。
+ AWS マネジメントコンソール の [**Requires Compatibilities (互換性が必要)**] フィールドで、`MANAGED_INSTANCES` を指定します。
+ AWS CLI で、`--requires-compatibilities` オプションを指定します。
+ Amazon ECS API で、`requiresCompatibilities` フラグを指定します。
# Fargate における Amazon ECS タスク定義の違い
Fargate を使用するには、Fargate 起動タイプを使用するようにタスク定義を設定する必要があります。Fargate の使用については他にもいくつかの考慮事項があります。
## タスク定義パラメータ
Fargate を使用するタスクは利用可能な Amazon ECS タスク定義パラメータのすべてをサポートするわけではありません。一部のパラメータはサポートされていません。また、Fargate タスクでは動作が異なるパラメータがあります。
次のタスク定義パラメータは Fargateタスクでは無効です:
+ `disableNetworking`
+ `dnsSearchDomains`
+ `dnsServers`
+ `dockerSecurityOptions`
+ `extraHosts`
+ `gpu`
+ `ipcMode`
+ `links`
+ `placementConstraints`
+ `privileged`
+ `maxSwap`
+ `swappiness`
以下のタスク定義パラメータはFargateタスクで有効ですが、注意すべき制限があります:
+ `linuxParameters` – コンテナに適用される Linux 固有のオプションを指定する場合、`capabilities` に追加できる機能は `CAP_SYS_PTRACE` のみです。`devices`、`sharedMemorySize`、および `tmpfs` パラメータはサポートされません。詳細については、「[Linux パラメータ](task_definition_parameters.md#container_definition_linuxparameters)」を参照してください。
+ `volumes` – Fargateタスクはバインドマウントのホストボリュームのみをサポートするため、`dockerVolumeConfiguration` パラメータはサポートされません。詳細については、「[ボリューム](task_definition_parameters.md#volumes)」を参照してください。
+ `cpu` - AWS Fargate での Windows コンテナの場合、値は 1 vCPU 未満にすることはできません。
+ `networkConfiguration` – Fargate タスクは、常に `awsvpc` ネットワークモードを使用します。
タスク定義が Fargateでの使用が有効であることを確認するために、タスク定義を登録する際に以下を指定できます:
+ AWS マネジメントコンソール の [**Requires Compatibilities (互換性が必要)**] フィールドで、`FARGATE` を指定します。
+ AWS CLI で、`--requires-compatibilities` オプションを指定します。
+ Amazon ECS API で、`requiresCompatibilities` フラグを指定します。
## オペレーティングシステムとアーキテクチャ
AWS Fargate のタスク定義とコンテナの定義を構成する場合、コンテナが実行するオペレーティングシステムを指定する必要があります。以下のオペレーティングシステムが AWS Fargate でサポートされています。
+ Amazon Linux 2
**注記**
Linux コンテナは、ホストオペレーティングシステムのカーネルおよびカーネル設定のみを使用することに留意してください。例えば、カーネル構成には `sysctl` システムコントロールが含まれます。Linux コンテナイメージは、任意の Linux ディストリビューションのファイルとプログラムを含むベースイメージから作成できます。CPU アーキテクチャが一致すると、どの OS 上で実行しているどの Linux コンテナイメージからでもコンテナを実行できます。
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core
AWS Fargate で Windows コンテナを実行する場合、X86\$164 CPU アーキテクチャを備えている必要があります。
AWS Fargate で Linux コンテナを実行する場合、ARM ベースのアプリケーションに X86\$164 CPU アーキテクチャ、または ARM64 アーキテクチャを使用できます。詳細については、「[64 ビット ARM ワークロードでの Amazon ECS タスク定義](ecs-arm64.md)」を参照してください。
## タスク CPU とメモリ
AWS Fargate の Amazon ECS タスク定義では、CPU とメモリをタスクレベルで指定する必要があります。ほとんどのユースケースでは、タスクレベルでこれらのリソースを指定するだけで十分です。以下の表に、タスクレベル CPU とメモリの有効な組み合わせを示します。タスク定義では、メモリの値を MiB または GB の文字列として指定できます。例えば、メモリの値を `3072` (MiB) または `3 GB` (GB) のいずれかで指定できます。JSON ファイルでは、CPU 値を CPU ユニットまたは仮想 CPU (vCPU) の文字列として指定できます。例えば、CPU 値を `1 vCPU` (vCPU) または `1024` (CPU ユニット) として指定できます。
| CPU の値 | メモリの値 | AWS Fargate でサポートされるオペレーティングシステム |
| --- | --- | --- |
| 256 (.25 vCPU) | 512 MiB、1 GB、2 GB | Linux |
| 512 (.5 vCPU) | 1 GB、2 GB、3 GB、4 GB | Linux |
| 1,024 (1 vCPU) | 2 GB、3 GB、4 GB、5 GB、6 GB、7 GB、8 GB | Linux、Windows |
| 2,048 (2 vCPU) | 4 GB ～ 16 GB (1 GB のインクリメント) | Linux、Windows |
| 4,096 (4 vCPU) | 8 GB ～ 30 GB (1 GB のインクリメント) | Linux、Windows |
| 8192 (8 vCPU) このオプションには Linux プラットフォーム `1.4.0` 以降が必要です。 | 16 GB～60 GB (4 GB のインクリメント) | Linux |
| 16384 (16vCPU) このオプションには Linux プラットフォーム `1.4.0` 以降が必要です。 | 32 GB～120 GB (8 GB のインクリメント) | Linux |
## タスクネットワーク
AWS Fargate の Amazon ECS を使用するタスクでは、`awsvpc` ネットワークモードが必要です。これは各タスクに Elastic Network Interface を提供します。このネットワークモードを使用したタスクの実行またはサービスの作成時に、ネットワークインターフェイスにアタッチするサブネットを 1 つ以上、またはネットワークインターフェイスに適用するセキュリティグループを 1 つ以上、指定する必要があります。
パブリックサブネットを使用している場合は、ネットワークインターフェイスにパブリック IP アドレスを指定するかどうかを決定します。パブリックサブネットの Fargate タスクを使用してコンテナイメージをプルするには、タスクの Elastic Network Interface に、インターネットへのルートまたはリクエストをインターネットにルーティングできる NAT ゲートウェイを持つパブリック IP アドレスが割り当てられている必要があります。 プライベートサブネットのFargateタスクでコンテナイメージをプルするには、リクエストをインターネットにルーティングするためのNATゲートウェイがサブネットに必要です。Amazon ECR でコンテナイメージをホストする場合、 Amazon ECR を設定してインターフェイス VPC エンドポイントを使用するようにできます。この場合、タスクのプライベート IPv4 アドレスがイメージのプルに使用されます。Amazon ECRインターフェイスエンドポイントの詳細については、*Amazon Elastic Container Registry ユーザーガイド*の [Amazon ECR Interface VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)を参照してください。
Fargate サービス向け `networkConfiguration` セクションの例を以下に示します。
```
"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "ENABLED",
"securityGroups": [ "sg-12345678" ],
"subnets": [ "subnet-12345678" ]
}
}
```
## タスクリソースの制限
AWS Fargate での Linux コンテナのAmazon ECS タスク定義では、コンテナに設定するリソース制限を定義するための `ulimits` パラメータがサポートされます。
AWS Fargate での Windows の Amazon ECS タスク定義では、コンテナに設定するリソース制限を定義するための `ulimits` パラメータがサポートされます。
Fargate でホストされる Amazon ECS タスクは、オペレーションシステムで設定されたデフォルトのリソース制限値を使用します。ただし、`nofile` リソース制限パラメータを除きます。`nofile` リソース制限は、コンテナが使用できるオープンファイルの数の制限を設定します。Fargate では、デフォルトの `nofile` ソフト制限は ` 65535` で、ハード制限は `65535` です。両方の制限の値を設定できます (最大 `1048576`)。
以下は、2 倍になったカスタム `nofile` 制限を定義する方法を示すタスク定義スニペットの例です。
```
"ulimits": [
{
"name": "nofile",
"softLimit": 2048,
"hardLimit": 8192
}
]
```
調整可能なその他のリソース制限の詳細については、[リソースの制限](task_definition_parameters.md#container_definition_limits) を参照してください。
## ログ記録
### イベントログ
Amazon ECS は、実行したアクションを EventBridge にログ記録します。Amazon ECS の Eventbridge イベントを使用して、Amazon ECS クラスター、サービスおよびタスクの現在の状態に関するほぼリアルタイムの通知を受け取れます。さらに、これらのイベントに対応するアクションを自動化できます。詳細については、「[EventBridge を使用して Amazon ECS エラーへの対応を自動化する](cloudwatch_event_stream.md)」を参照してください。
### タスクライフサイクルログ
Fargate で実行されるタスクは、タイムスタンプを公開してタスクライフサイクルの状態を追跡します。AWS CLI および SDK でタスクを説明することにより、AWS マネジメントコンソール のタスク詳細でタイムスタンプを確認できます。例えば、タイムスタンプを使用して、タスクがコンテナイメージのダウンロードに費やした時間を評価し、コンテナイメージのサイズを最適化するか、Seekable OCI インデックスを使用するかを判断できます。コンテナイメージのプラクティスに関する詳細については、「[Amazon ECS コンテナイメージのベストプラクティス](container-considerations.md)」を参照してください。
### アプリケーションログ
AWS Fargate の Amazon ECS タスク定義はログ設定の `awslogs`、`splunk`、および `awsfirelens` ログドライバーをサポートします。
この`awslogs`ログドライバーは、Amazon CloudWatch Logs にログ情報を送信するように Fargate タスクを設定します。以下に、`awslogs` ログドライバーが設定されているタスク定義のスニペットを示します。
```
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group" : "/ecs/fargate-task-definition",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
}
```
タスク定義で `awslogs` ログドライバーを使用してコンテナログをCloudWatch Logs に送信する方法の詳細については、[Amazon ECS ログを CloudWatch に送信する](using_awslogs.md)を参照してください。
タスク定義での `awsfirelens` ログドライバーの詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。
タスク定義での `splunk` ログドライバーの使用の詳細については、「[`splunk` ログドライバー](example_task_definitions.md#example_task_definition-splunk)」を参照してください。
## タスクストレージ
Fargate でホストされた Amazon ECS タスクでは、次のストレージタイプがサポートされています:
+ Amazon EBS ボリュームは、データ集約型のコンテナ化されたワークロード向けに、費用対効果と耐久性に優れた高性能なブロックストレージを提供します。詳細については、「[Amazon ECS での Amazon EBS ボリュームの使用](ebs-volumes.md)」を参照してください。
+ 永続的ストレージ用のAmazon EFS ボリューム。詳細については、「[Amazon ECS での Amazon EFS ボリュームの使用](efs-volumes.md)」を参照してください。
+ エフェメラルストレージ用のバインドマウント。詳細については、「[Amazon ECS でのバインドマウントの使用](bind-mounts.md)」を参照してください。
## Seekable OCI (SOCI) を使ったコンテナイメージの遅延読み込み
Linux プラットフォーム バージョン `1.4.0` を使用する Fargate 上の Amazon ECS タスクは、Seekable OCI (SOCI) を使用してタスクをより速く開始できます。SOCI では、コンテナは起動前にイメージプルに数秒しかかからないため、イメージがバックグラウンドでダウンロードされている間、環境のセットアップとアプリケーションのインスタンス化に時間を割けます。これは*遅延読み込み*と呼ばれています。Fargate が Amazon ECS タスクを開始すると、Fargate はタスク内のイメージに SOCI インデックスが存在するかどうかを自動的に検出し、イメージ全体がダウンロードされるのを待たずにコンテナを起動します。
SOCI インデックスなしで実行されるコンテナの場合、コンテナイメージはコンテナを起動する前に完全にダウンロードされます。この動作は、Fargate の他のすべてのプラットフォームバージョンと Amazon EC2 インスタンス上の Amazon ECS 最適化された AMI でも同じです。
Seekable OCI (SOCI) は AWS によって開発されたオープンソースのテクノロジーであり、コンテナイメージを遅延読み込みすることでコンテナをより速く起動できます。SOCI は、既存のコンテナイメージ内のファイルのインデックス (SOCI インデックス) を作成することで機能します。このインデックスは、イメージ全体をダウンロードする前にコンテナイメージから個々のファイルを抽出できるため、コンテナをより速く起動するのに役立ちます。SOCI インデックスは、コンテナレジストリ内のイメージと同じリポジトリにアーティファクトとして保存する必要があります。インデックスはイメージのコンテンツの信頼できるソースなので、信頼できるソースからの SOCI インデックスのみを使用してください。詳細については、「[コンテナイメージを遅延ロードするためのSeekable OCIの導入](https://aws.amazon.com/about-aws/whats-new/2022/09/introducing-seekable-oci-lazy-loading-container-images/)」を参照してください。
SOCI の使用を検討しているお客様は、SOCI Index Manifest v2 のみを使用できます。Fargate で SOCI を以前使用したことのある既存のお客様は、引き続き SOCI Index Manifest v1 を使用できますが、SOCI Index Manifest v2 に移行することを強くお勧めします。SOCI Index Manifest v2 は、一貫したデプロイを確保するために、コンテナイメージとその SOCI インデックスの間に明示的な関係を作成します。
**考慮事項**
Fargate に SOCI インデックスを使用してコンテナイメージをタスクに遅延読み込ませる場合は、次の点を考慮してください。
+ Linux プラットフォームバージョン `1.4.0` で実行されるタスクのみ SOCI インデックスを使用できます。Fargate で Windows コンテナを実行するタスクはサポートされていません。
+ X86\$164 または ARM64 CPU アーキテクチャ上で実行されるタスクがサポートされています。
+ タスク定義内のコンテナイメージは、互換性のあるイメージレジストリに保存する必要があります。以下に互換性のあるレジストリを示します。
+ Amazon ECR プライベートレジストリ
+ gzip 圧縮を使用する、または圧縮されていないコンテナイメージのみがサポートされます。zstd 圧縮を使用するコンテナイメージはサポートされていません。
+ SOCI Index Manifest v2 の場合、SOCI インデックスマニフェストを生成すると、SOCI インデックスの注釈を追加するときにコンテナイメージマニフェストが変更されます。これにより、新しいコンテナイメージダイジェストが作成されます。コンテナイメージのファイルシステムレイヤーの内容は変更されません。
+ SOCI Index Manifest v2 の場合、コンテナイメージがすでにコンテナイメージリポジトリに保存されている場合、SOCI インデックスが生成されたら、コンテナイメージを再プッシュする必要があります。コンテナイメージを再プッシュしても、ファイルシステムレイヤーが重複することでストレージコストは増加せず、新しいマニフェストファイルのみをアップロードします。
+ 圧縮サイズが 250 MiB より大きいコンテナイメージを使用して遅延読み込みを試すことをお勧めします。小さいイメージを読み込む時間が短くなる可能性は低くなります。
+ 遅延読み込みによってタスクの開始にかかる時間が変わる可能性があるため、Elastic Load Balancing のヘルスチェック猶予期間など、さまざまなタイムアウトを変更する必要がある場合があります。
+ コンテナイメージが遅延ロードされないようにするには、SOCI インデックスをアタッチせずにコンテナイメージを再プッシュする必要があります。
**Seekable OCI インデックスの作成**
コンテナイメージを遅延ロードするには、SOCI インデックス (メタデータファイル) を作成し、コンテナイメージと共にコンテナイメージリポジトリに保存する必要があります。SOCI インデックスを作成しプッシュするには、GitHub にあるオープンソースの [soci-snapshotter CLI ツール](https://github.com/awslabs/soci-snapshotter)を使用できます。または、CloudFormation AWS SOCI Index Builder をデプロイすることもできます。これは、コンテナイメージが Amazon ECR にプッシュされるときに SOCI インデックスを自動的に作成してプッシュするサーバーレスソリューションです。ソリューションとインストール手順の詳細については、GitHub の「[CloudFormation AWS SOCI Index Builder](https://awslabs.github.io/cfn-ecr-aws-soci-index-builder/)」を参照してください。CloudFormation AWS SOCI Index Builder は SOCI の導入を自動化できる手段ですが、オープンソースの SOCI ツールの方がインデックス生成に関してはより柔軟性があり、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインにインデックス生成を統合できます。
**注記**
イメージの SOCI インデックスを作成するには、そのイメージが `soci-snapshotter` を実行しているコンピュータ上の containerd イメージストアに存在する必要があります。イメージが Docker イメージストアにある場合、イメージは見つかりません。
**タスクが遅延読み込みを使用したことの検証**
SOCI を使用してタスクが遅延読み込みされたことを確認するには、タスク内部からタスクメタデータエンドポイントを確認します。タスクメタデータエンドポイントバージョン 4 をクエリすると、クエリ元のコンテナのデフォルトパスに `Snapshotter` フィールドが存在します。さらに、`/task` パス内のコンテナごとに `Snapshotter` フィールドがあります。このフィールドのデフォルト値は `overlayfs` であり、SOCI が使用されている場合、このフィールドは `soci` に設定されます。コンテナイメージに SOCI インデックスマニフェスト v2 がアタッチされていることを確認するには、AWS CLI を使用して Amazon ECR からイメージインデックスを取得できます。
```
IMAGE_REPOSITORY=r
IMAGE_TAG=latest
aws ecr batch-get-image \
--repository-name=$IMAGE_REPOSITORY \
--image-ids imageTag=$IMAGE_TAG \
--query 'images[0].imageManifest' --output text | jq -r '.manifests[] | select(.artifactType=="application/vnd.amazon.soci.index.v2+json")'
```
コンテナイメージに SOCI インデックスマニフェスト v1 がアタッチされていることを確認するには、OCI Referrers API を使用できます。
```
ACCOUNT_ID=111222333444
AWS_REGION=us-east-1
IMAGE_REPOSITORY=nginx-demo
IMAGE_TAG=latest
IMAGE_DIGEST=$(aws ecr describe-images --repository-name $IMAGE_REPOSITORY --image-ids imageTag=$IMAGE_TAG --query 'imageDetails[0].imageDigest' --output text)
ECR_PASSWORD=$(aws ecr get-login-password)
curl \
--silent \
--user AWS:$ECR_PASSWORD \
https://$ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/v2/$IMAGE_REPOSITORY/referrers/$IMAGE_DIGEST?artifactType=application%2Fvnd.amazon.soci.index.v1%2Bjson | jq -r '.'
```
# Windows を実行している EC2 インスタンスでの Amazon ECS タスク定義の違い
EC2 Windows インスタンスで実行されるタスクは、使用可能なすべての Amazon ECS タスク定義パラメータをサポートしているわけではありません。サポートされていないパラメータもあり、また一部のパラメータでは動作が異なることがあります。
以下のタスク定義パラメータは、Amazon EC2 Windows タスク定義ではサポートされていません。
+ `containerDefinitions`
+ `disableNetworking`
+ `dnsServers`
+ `dnsSearchDomains`
+ `extraHosts`
+ `links`
+ `linuxParameters`
+ `privileged`
+ `readonlyRootFilesystem`
+ `user`
+ `ulimits`
+ `volumes`
+ `dockerVolumeConfiguration`
+ `cpu`
Windows コンテナではコンテナレベル CPU を指定することをお勧めします。
+ `memory`
Windows コンテナではコンテナレベルメモリを指定することをお勧めします。
+ `proxyConfiguration`
+ `ipcMode`
+ `pidMode`
+ `taskRoleArn`
EC2 Windows インスタンス上のタスク向け IAM ロールには追加の設定が必要ですが、それらの設定の多くは Linux コンテナインスタンス上のタスクの IAM ロールの設定と類似しています。詳細については、「[Amazon EC2 Windows インスタンスの追加設定](task-iam-roles.md#windows_task_IAM_roles)」を参照してください。
# コンソールを使用した Amazon ECS タスク定義の作成
タスクまたはサービスとして実行するアプリケーションを定義できるように、タスク定義を作成します。
外部起動タイプのタスク定義を作成するときは、JSON エディタを使用してタスク定義を作成し、`requireCapabilities` パラメータを `EXTERNAL` に設定する必要があります。
タスク定義は、コンソールエクスペリエンスを使用するか、JSON ファイルを指定して作成できます。JSON エディタを使用すると、Amazon Q に推奨値を提供させることができます。詳細については、[Amazon Q Developer を使用して Amazon ECS コンソールでタスク定義のレコメンデーションを生成する](using-amazon-q.md)を参照してください。
## JSON 検証
Amazon ECS コンソールの JSON エディタは、JSON ファイル内で以下を検証します。
+ ファイルが有効な JSON ファイルであること。
+ ファイルに外部キーが含まれていないこと。
+ ファイルに `familyName` パラメータが含まれていること。
+ `containerDefinitions` の下に少なくとも 1 つのエントリがあること。
## CloudFormation スタック
次の動作は、2023 年 1 月 12 日以前に新しい Amazon ECS コンソールで作成されたタスク定義に適用されます。
タスク定義の作成時、Amazon ECS コンソールは、名前が `ECS-Console-V2-TaskDefinition-` で始まる CloudFormation スタックを自動的に作成します。AWS CLI または AWS SDK を使用してタスク定義を登録解除した場合は、手動でタスク定義スタックを削除する必要があります。詳細については、「*CloudFormation ユーザーガイド*」の「[スタックの削除](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)」を参照してください。
2023 年 1 月 12 日以降に作成されたタスク定義では、CloudFormation スタックの自動的な作成は行われません。
## 手順
------
#### [ Amazon ECS console ]
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで、**タスクの定義** を選択します。
1. **[新しいタスク定義の作成]** メニューで、**[新しいタスク定義を作成する]** を選択します。
1. **[Task definition family]** (タスク定義ファミリー) を使用する場合、タスク定義ファミリーには、タスク定義に一意の名前を指定します。
1. **[起動タイプ]** で、アプリケーション環境を選択します。コンソールのデフォルトは、**AWS Fargate** (サーバーレス) です。Amazon ECS は、この値を使用して検証を実行し、タスク定義パラメータがインフラストラクチャタイプに対して有効であることを確認します。
1. **[Operating system/Architecture]** (オペレーティングシステム/アーキテクチャ) を使用する場合、タスクのオペレーティングシステムと CPU アーキテクチャを選択します。
タスクを 64 ビット ARM アーキテクチャで実行するには、**[Linux/ARM64]** を選択します。詳細については、「[ランタイムプラットフォーム](task_definition_parameters.md#runtime-platform)」を参照してください。
Windows コンテナで **AWS Fargate** タスクを実行するには、サポートされている Windows オペレーティングシステムを選択します。詳細については、「[オペレーティングシステムとアーキテクチャ](fargate-tasks-services.md#fargate-task-os)」を参照してください。
1. **[Task size]** (タスクサイズ) では、タスク用に予約する CPU とメモリの値を選択します。CPU 値は vCPUs として指定され、メモリは GB として指定されます。
Fargate でホストされるタスクの場合、次の表に有効な CPU とメモリの組み合わせを示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-task-definition.html)
EC2 インスタンスまたは外部インスタンスを使用するタスクの場合、サポートされるタスク CPU 値は 128 CPU ユニット (0.125 vCPU) から 196608 CPU ユニット (192 vCPU) の範囲となります。
メモリ値を GB 単位で指定するには、数字に続けて **[GB]** と入力します。たとえば、**[メモリ値]** を 3 GB に設定するには、**[3GB]** と入力します。
**注記**
タスクレベル CPU およびメモリのパラメータは Windows コンテナでは無視されます。
1. **[Network mode]** (ネットワークモード) の場合、使用するネットワークモードを選択します。デフォルトは、**awsvpc** モードです。詳細については、[Amazon ECS タスクネットワーキング](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html)を参照してください。
**[ポートマッピング]** で、**[ホストポート]** に **[ブリッジ]** を選択した場合は、コンテナ用に予約するコンテナインスタンスのポート番号を入力します。
1. (オプション) **[タスクロール]** セクションを展開してタスク向け AWS Identity and Access Management (IAM) ロールを設定できます。
1. **[Task role]** (タスクロール) では、タスクに割り当てる IAM ロールを選択します。タスク IAM ロールは、タスク内のコンテナが AWS API 操作を呼び出すアクセス許可を提供します。
1. **[タスク実行ロール]** で、ロールを選択します。
タスク実行ロールをいつ使用するかの詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。ロールが不要な場合は、**[なし]** を選択します。
1. (オプション) **タスク配置** セクションを展開して、配置の制約を追加します。タスク配置の制約により、組み込み属性またはカスタム属性を使用して、タスクの配置に使用されるコンテナインスタンスをフィルタリングできます。
1. (オプション) **フォールトインジェクション** セクションを展開して、フォールトインジェクションを有効にします。フォールトインジェクションを使用すると、特定の障害シナリオに対するアプリケーションの反応をテストできます。
1. タスク定義で定義するコンテナごとに、以下のステップを実行します。
1. **[Name]** (名前) に、コンテナの名前を入力します。
1. **[Image URI]** (イメージ URI) には、コンテナの開始に使用するイメージを指定します。Amazon ECR Public Gallery レジストリ内のイメージは、Amazon ECR Public レジストリ名の使用でのみ指定することができます。例えば、`public.ecr.aws/ecs/amazon-ecs-agent:latest` が指定されている場合は、Amazon ECR Public Gallery でホストされている Amazon Linux コンテナが使用されます。他のすべてのリポジトリの場合は、`repository-url/image:tag` または `repository-url/image@digest` の形式を使用してリポジトリを指定します。
1. イメージが Amazon ECR の外部のプライベートレジストリにある場合は、**[プライベートレジストリ]** で **[プライベートレジストリ認証]** をオンにします。その後、**[Secrets Manager ARN または名前]** で、シークレットの Amazon リソースネーム (ARN) を入力します。
1. **[基本コンテナ]** の場合、もしタスク定義に 2 つ以上のコンテナが定義されていれば、そのコンテナを基本と見なすかどうかを指定できます。コンテナが **[基本]** とマークされている場合は、そのコンテナが停止するとタスクは停止します。各タスク定義には、少なくとも 1 つの基本コンテナを含む必要があります。
1. ポートマッピングにより、コンテナはホスト上のポートにアクセスしてトラフィックを送受信できるようになります。**[Port mappings]** (ポートマッピング) で、次のいずれかを実行]ます。
+ **[awsvpc]** ネットワークモードを使用する場合、**[Container port]** (コンテナポート) と **[Protocol]** (プロトコル) で、コンテナに使用するポートマッピングを選択します。
+ **[bridge]** ネットワークモードを使用する場合、**[Container port]** (コンテナポート) と **[Protocol]** (プロトコル) で、コンテナに使用するポートマッピングを選択します。
追加のコンテナポートマッピングを指定するには、**[Add more port mappings]** (ポートマッピングを追加) を選択します。
1. コンテナにルート ファイル システムへの読み取り専用アクセスを付与するには、**[読み取り専用ルートファイルシステム]** で **[読み取り専用]** を選択します。
1. (オプション) **[リソース割り当て制限]** のタスクレベルの値とは異なるコンテナ レベルの CPU、GPU、およびメモリの制限を定義するには、次の手順を実行します。
+ **[CPU]** には、Amazon ECS コンテナエージェントがそのコンテナ用に予約している CPU ユニット数を入力します。
+ **[GPU]** では、コンテナインスタンス用の GPU ユニット数を入力します。
GPU サポートを使用する Amazon EC2 インスタンスには、各 GPU について 1 つの GPU ユニットが装備されます。詳細については、「[GPU ワークロード向けの Amazon ECS タスク定義](ecs-gpu.md)」を参照してください。
+ **[メモリのハード制限]** には、コンテナに提供するメモリの量を GB 単位で入力します。コンテナがハード制限を超えようとすると、コンテナは停止します。
+ Docker 20.10.0 以降のデーモンではコンテナ用に最低 6 MiB のメモリを予約するため、コンテナ用に 6 MiB 未満のメモリを指定しないでください。
Docker 19.03.13-ce 以前のデーモンではコンテナ用に最低 4 MiB のメモリを予約するため、コンテナ用に 4 MiB 未満のメモリを指定しないでください。
+ **[メモリのソフト制限]** に、コンテナに予約するメモリのソフト制限 (GB 単位) を入力します。
システムメモリに競合がある場合、Docker はコンテナのメモリ量をこのソフト制限値内に維持しようとします。タスクレベルのメモリを指定しない場合は、**[メモリのハード制限]** と **[メモリのソフト制限]** の一方または両方にゼロ以外の整数を指定する必要があります。両方を指定する場合は、**[メモリのハード制限]** がメモリの **[ソフト制限]** より大きい必要があります。
この機能は Windows コンテナではサポートされません。
1. (オプション) **[環境変数]** セクションを展開し、コンテナに挿入する環境変数を指定します。環境変数は、キー値ペアを使用して個別に指定するか、Amazon S3 バケットでホストされている環境変数ファイルを指定して一括で指定できます。環境変数ファイルのフォーマット方法については、「[個々の環境変数を Amazon ECS コンテナに渡す](taskdef-envfiles.md)」を参照してください。
シークレットストレージの環境変数を指定するときは、**[キー]** にシークレット名を入力します。次に、**[ValueFrom]** に、Systems Manager パラメータストアシークレットまたは Secrets Manager シークレットの完全な ARN を入力します。
1. (オプション) **[Use log collection]** (ログコレクションを使用) を選択し、ログ構成を指定します。使用可能なログドライバーごとに、指定するログドライバーオプションがあります。デフォルトのオプションでは、コンテナログを Amazon CloudWatch Logs に送信します。その他のログドライバーオプションは、AWS FireLens を使用して設定されます。詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。
以下では、各コンテナログの送信先について詳しく説明します。
+ **Amazon CloudWatch** — コンテナログを CloudWatch Logs に送信するようにタスクを設定します。デフォルトのログドライバーオプションが提供され、ユーザーに代わり CloudWatch ロググループを作成します。別のロググループ名を指定するには、ドライバーオプションの値を変更します。
+ **Splunk へのログのエクスポート** — リモートサービスにログを送信する Splunk ドライバーにコンテナログを送信するタスクを設定します。Splunk Web サービスの URL を入力する必要があります。Splunk トークンは機密データとして扱われる可能性があるため、シークレットのオプションとして指定します。
+ **[Amazon Data Firehose へのログのエクスポート]** — Firehose にコンテナログを送信するようタスクを設定します。Firehose 配信ストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別の配信ストリーム名を指定するには、ドライバーオプションの値を変更します。
+ **Amazon Kinesis Data Streams へのログのエクスポート** — Kinesis Data Streams にコンテナログを送信するようタスクを設定します。Kinesis Data Streams のストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別のストリーム名を指定するには、ドライバーオプションの値を変更します。
+ **Amazon OpenSearch Service へのログのエクスポート** — コンテナログを OpenSearch Service ドメインに送信するようタスクを設定します。ログドライバーオプションを提供する必要があります。
+ **Amazon S3 へのログのエクスポート** — Amazon S3 バケットにコンテナログを送信するようタスクを設定します。デフォルトのログドライバーオプションが提供されていますが、有効な Amazon S3 バケット名を指定する必要があります。
1. (オプション) コンテナの追加パラメータを設定します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-task-definition.html)
1. (オプション) **[コンテナを追加する]**をクリックして、タスク定義にコンテナを追加します。
1. (オプション) **[ストレージ]** セクションを使用して、Fargate でホストされるタスクの一時ストレージ量を拡張することができます。またこのセクションを使用して、タスクのデータボリューム設定を追加することもできます。
1. Fargate タスクに使用可能なエフェメラルストレージをデフォルト値の 20 gibibytes (GiB) を超えて拡張するには、**[Amount]** (量) に最大で 200 GiB までの値を入力します。
1. (オプション) タスク定義のデータ ボリューム構成を追加するには、**[ボリュームの追加]** を選択し、以下のステップを実行します。
1. **[Volume name]** (ボリューム名) には、データボリュームの名前を入力します。データボリューム名は、コンテナマウントポイントを作成するときに使用されます。
1. **[ボリューム設定]** では、ボリュームをタスク定義の作成時に設定するのか、デプロイ時に設定するのかを選択します。
**注記**
タスク定義の作成時に設定できるボリュームには、バインドマウント、Docker、Amazon EFS、Amazon FSx for Windows File Server などがあります。デプロイ時にタスクを実行するとき、またはサービスを作成または更新するときに設定できるボリュームには Amazon EBS が含まれます。
1. **[ボリュームタイプ]**では、選択した設定タイプと互換性のあるボリュームタイプを選択し、ボリュームタイプを設定します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-task-definition.html)
1. 別のコンテナからボリュームを追加するには、**[以下からボリュームを追加:]** を選択し、次のように構成します。
+ **[コンテナ]** で、対象のコンテナを選択します。
+ **[ソース]** で、マウントするボリュームが含まれるコンテナを選択します。
+ **[読み取り専用]** では、コンテナがボリュームに対して読み取り専用アクセスを持つかどうかを選択します。
1. (オプション) AWS Distro for OpenTelemetry 統合を使用してアプリケーショントレースとメトリクス収集設定を構成するには、**[モニタリング]** を展開し、**[メトリクス収集を使用]** を選択してタスクのメトリクスを収集し、Amazon CloudWatch または Amazon Managed Service for Prometheus に送信します。このオプションを選択すると、Amazon ECS はアプリケーションメトリクスの送信向けに事前設定された AWS Distro for OpenTelemetry コンテナサイドカーを作成します。詳細については、「[アプリケーションメトリクスを使用して Amazon ECS アプリケーションのパフォーマンスを相関させる](metrics-data.md)」を参照してください。
1. **[Amazon CloudWatch]** を選択した場合、カスタムアプリケーションメトリクスはカスタムメトリクスとして CloudWatch にルーティングされます。詳細については、「[アプリケーションメトリクスを Amazon CloudWatch にエクスポートする](application-metrics-cloudwatch.md)」を参照してください。
**重要**
Amazon CloudWatch にアプリケーションメトリクスをエクスポートする場合、タスク定義には、必要なアクセス権限を持つタスク IAM ロールが必要です。詳細については、「[OpenTelemetry 用 AWS Distro と Amazon CloudWatch の統合に必要な IAM 許可](application-metrics-cloudwatch.md#application-metrics-cloudwatch-iam)」を参照してください。
1. **[Amazon Managed Service for Prometheus (Prometheus libraries instrumentation)]** (Prometheus 向け Amazon マネージドサービス (Prometheus ライブラリ計測)) を選択した場合、タスクレベルの CPU、メモリ、ネットワーク、ストレージのメトリクスとカスタムアプリケーションメトリクスが Amazon Managed Service for Prometheus にルーティングされます。**[Workspace のリモート書き込み用エンドポイント]** には、Prometheus ワークスペースのリモート書き込みエンドポイント URL を入力します。**[スクレイピングターゲット]** には、AWS Distro for OpenTelemetry コレクターがメトリクスデータをスクレイプするために使用できるホストとポートを入力します。詳細については、「[アプリケーションメトリクスを Amazon Managed Service for Prometheus にエクスポートする](application-metrics-prometheus.md)」を参照してください。
**重要**
Amazon Managed Service for Prometheus にアプリケーションメトリクスをエクスポートする場合、タスク定義には、必要なアクセス権限を持つタスク IAM ロールが必要です。詳細については、「[OpenTelemetry 用 AWS Distro と Amazon Managed Service for Prometheus の統合に必要な IAM 許可](application-metrics-prometheus.md#application-metrics-prometheus-iam)」を参照してください。
1. **[Amazon Managed Service for Prometheus (OpenTelemetry 計測)]** を選択した場合、タスクレベルの CPU、メモリ、ネットワーク、ストレージのメトリクスとカスタムアプリケーションメトリクスが Amazon Managed Service for Prometheus にルーティングされます。**[Workspace のリモート書き込み用エンドポイント]** には、Prometheus ワークスペースのリモート書き込みエンドポイント URL を入力します。詳細については、「[アプリケーションメトリクスを Amazon Managed Service for Prometheus にエクスポートする](application-metrics-prometheus.md)」を参照してください。
**重要**
Amazon Managed Service for Prometheus にアプリケーションメトリクスをエクスポートする場合、タスク定義には、必要なアクセス権限を持つタスク IAM ロールが必要です。詳細については、「[OpenTelemetry 用 AWS Distro と Amazon Managed Service for Prometheus の統合に必要な IAM 許可](application-metrics-prometheus.md#application-metrics-prometheus-iam)」を参照してください。
1. (オプション) **[Tags]** (タグ) を展開します。タグをキーバリューペアとしてタスク定義に追加します。
+ [タグを追加] **[Add tag]** (タグを追加) を選択し、以下を実行します。
+ [**キー**] にはキー名を入力します。
+ [**値**] にキー値を入力します。
+ [タグの削除] タグの横にある [**タグの削除**] を選択します。
1. **[作成]** を選択してタスク定義を登録します。
------
#### [ Amazon ECS console JSON editor ]
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで、**タスクの定義** を選択します。
1. **[新しいタスク定義の作成]** メニューで、**[JSON で新しいタスク定義を作成する]** を選択します。
1. JSON エディタボックスで、JSON ファイルを編集し、
JSON は、[JSON 検証](#json-validate-for-create) で指定された検証チェックに合格する必要があります。
1. **[作成]** を選択します。
------
# Amazon Q Developer を使用して Amazon ECS コンソールでタスク定義のレコメンデーションを生成する
Amazon ECS コンソールで JSON エディタを使用してタスク定義を作成する場合、Amazon Q Developer を使用することで、タスク定義に AI 生成のコード提案を取得できます。
インラインチャット機能を使用して、会話インターフェイスを使用してタスク定義 JSON を生成、説明、またはリファクタリングするように Amazon Q Developer に依頼できます。生成された提案は、タスク定義の任意の時点で挿入し、提案された変更を承認または拒否できます。Amazon ECS では、Amazon Q Developer を利用するために既存のインライン提案機能も強化されました。
JSON エディタを使用してタスク定義を作成する場合、Amazon Q Developer にタスク定義をより迅速に作成するための推奨事項を提供してもらうことができます。プロパティベースのインライン提案を作成することも、Amazon Q Developer の提案を使用してサンプルコードのブロック全体をオートコンプリートすることもできます。
この機能は、Amazon Q Developer がサポートされているリージョンで使用できます。詳細は「[AWS Services by Regions](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。
## 前提条件
前提条件は次のとおりです。
+ コンソールでタスク定義を作成するユーザーには、コンソールのアクセス許可に加えて、レコメンデーションのための `codewhisperer:GenerateRecommendations` のアクセス許可とインラインチャットを使用するための `q:SendMessage` が必要になります。詳細については、「[Amazon Q Developer を使用して、コンソールで推奨事項を提供するために必要なアクセス許可](console-permissions.md#amazon-q-permission)」を参照してください。
## 手順
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで、**タスクの定義** を選択します。
1. **[新しいタスク定義の作成]** メニューで、**[JSON で新しいタスク定義を作成する]** を選択します。
**[タスク定義の作成]** ページを開きます。
コンソールには、次のデフォルトテンプレートが用意されています。
```
{
"requiresCompatibilities": [
"FARGATE"
],
"family": "",
"containerDefinitions": [
{
"name": "",
"image": "",
"essential": true
}
],
"volumes": [],
"networkMode": "awsvpc",
"memory": "3 GB",
"cpu": "1 vCPU",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}
```
1. Amazon Q インライン提案ポップアップで、**[許可]** を選択します。
ポップアップを閉じると、歯車アイコンで Amazon Q を有効にできます。
1. JSON エディタボックスで、JSON ドキュメントを編集します。
Amazon Q でパラメータを作成して入力するには、追加する内容を含むコメントを入力します。以下の例では、コメントにより Amazon Q が太字の行を生成します。
```
{
"requiresCompatibilities": [
"FARGATE"
],
"family": "",
"containerDefinitions": [
{
"name": "",
"image": "",
"essential": true
},
// add an nginx container using an image from Public ECR, with port 80 open, and send logs to CloudWatch log group "myproxy"
{
"name": "nginx",
"image": "public.ecr.aws/nginx/nginx:latest",
"essential": true,
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "myproxy",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "nginx"
}
}
}
],
"volumes": [],
"networkMode": "awsvpc",
"memory": "3 GB",
"cpu": "1 vCPU",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}
```
1. インラインチャット機能を使用するには、線を強調表示し、星のアイコンを選択します。
Amazon Q Developer チャットボックスが表示されます。
リクエストを入力します。
Amazon Q Developer は JSON を生成して更新します。
変更を受け入れるには、**[すべて受け入れる]** を選択します。
1. **[作成]** を選択します。
# コンソールを使用した Amazon ECS タスク定義の更新
ある*タスク定義リビジョン*は、現在のタスク定義のコピーであり、新しいパラメータ値が既存のパラメータ値に置き換えられます。変更しないパラメータはすべて新しいリビジョンにあります。
タスク定義を更新するには、タスク定義リビジョンを作成します。サービスでタスク定義を使用する場合、更新されたタスク定義を使用するようサービスを更新する必要があります。
リビジョンを作成するときに、次のコンテナプロパティと環境プロパティを変更できます。
+ コンテナイメージ URI
+ ポートマッピング
+ 環境変数
+ インフラストラクチャ要件
+ タスクサイズ
+ コンテナサイズ
+ タスクロール
+ タスク実行ロール
+ ボリュームとコンテナマウントポイント
+ プライベートレジストリ
JSON エディタを使用すると、Amazon Q に推奨値を提供させることができます。詳細については、[Amazon Q Developer を使用して Amazon ECS コンソールでタスク定義のレコメンデーションを生成する](using-amazon-q.md)を参照してください。
## JSON 検証
Amazon ECS コンソールの JSON エディタは、JSON ファイル内で以下を検証します。
+ このJSON ファイルは有効です
+ ファイルに外部キーは含まれていません
+ ファイルに `familyName` パラメータが含まれています
+ `containerDefinitions` の下に少なくとも 1 つのエントリがあります
## 手順
------
#### [ Amazon ECS console ]
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションバーから、タスク定義を含むリージョンを選択します。
1. ナビゲーションペインで、**タスクの定義** を選択します。
1. タスク定義を選択します。
1. タスク定義リビジョンを選択し、**[新しいリビジョンを作成]**、**[新しいリビジョンを作成]** を選択します。
1. **[Create new task definition revision** (タスク定義の新しいリビジョンの作成) ページで変更を加えます。例えば、既存のコンテナの定義 (コンテナイメージ、メモリ制限、ポートマッピングなど) を変更する場合は、コンテナを選択して変更を加えます。**AWS Fargate**、**マネージドインスタンス**、**Amazon EC2 インスタンス** のいずれかにタスク定義の互換性を更新できます。
1. 情報を確認し、**[更新]** を選択します。
1. サービスでタスク定義を使用する場合、更新されたタスク定義でサービスを更新します。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。
------
#### [ Amazon ECS console JSON editor ]
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで、**タスクの定義** を選択します。
1. **[Create new revision]** (新しいリビジョンの作成)、**[Create new revision with JSON]** (JSON で新しいリビジョンを作成) の順に選択します。
1. JSON エディタボックスで、JSON ファイルを編集し、
JSON は、[JSON 検証](#json-validate-for-update) で指定された検証チェックに合格する必要があります。
1. **[作成]** を選択します。
------
# 新しいコンソールを使用した Amazon ECS タスク定義リビジョンの登録解除
そのタスク定義リビジョンを登録解除することで、タスクの実行やサービスの更新時、そのタスク定義リビジョンが `ListTaskDefinition` API コールにもコンソールにも表示されなくなります。
タスク定義リビジョンは登録解除されると、すぐに `INACTIVE` とマークされます。`INACTIVE` タスク定義リビジョンを参照する既存のタスクおよびサービスは、中断することなく引き続き実行されます。`INACTIVE` タスク定義のリビジョンを参照する既存のサービスは、希望するサービスの数を変更することでスケールアップまたはスケールダウンできます。
`INACTIVE` タスク定義のリビジョンを使用して、新しいタスクを実行したり、新しいサービスを作成したりすることはできません。また、`INACTIVE` タスク定義のリビジョンを参照するように既存のサービスを更新することはできません (登録解除後 10 分経過するまでは、これらの制限が有効にならないことがあります)。
**注記**
タスクファミリーのすべてのリビジョンを登録解除すると、タスク定義ファミリーが `INACTIVE` リストに移動されます。`INACTIVE` タスク定義の新しいリビジョンを追加すると、タスク定義ファミリーが `ACTIVE` リストに戻ります。
現時点では、`INACTIVE` タスク定義のリビジョンはアカウントで無期限に検出可能です。ただし、この動作は、今後変更される可能性があります。したがって、関連するタスクおよびサービスのライフサイクルを超えて持続する `INACTIVE` タスク定義のリビジョンに依存しないでください。
## CloudFormation スタック
次の動作は、2023 年 1 月 12 日以前に新しい Amazon ECS コンソールで作成されたタスク定義に適用されます。
タスク定義の作成時、Amazon ECS コンソールは、名前が `ECS-Console-V2-TaskDefinition-` で始まる CloudFormation スタックを自動的に作成します。AWS CLI または AWS SDK を使用してタスク定義を登録解除した場合は、手動でタスク定義スタックを削除する必要があります。詳細については、「*CloudFormation ユーザーガイド*」の「[スタックの削除](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)」を参照してください。
2023 年 1 月 12 日以降に作成されたタスク定義では、CloudFormation スタックの自動的な作成は行われません。
## 手順
**新しいタスク定義を登録解除するには (Amazon ECS コンソール)**
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションバーから、タスク定義を含むリージョンを選択します。
1. ナビゲーションペインで、**タスクの定義** を選択します。
1. **[Task Definitions]** (タスク定義) ページで、登録解除する 1 つ以上のタスク定義リビジョンを含むタスク定義ファミリーを選択します。
1. **[タスク定義名]** ページで、削除するリビジョンを選択し、次に **[アクション]**、**[登録解除]** の順に選択します。
1. **[Deregister]** (登録解除) ウィンドウの情報を確認し、**[Deregister]** (登録解除) を選択して終了します。
# コンソールを使用した Amazon ECS タスク定義リビジョンの削除
Amazon ECS で特定のタスク定義リビジョンが不要になったら、そのタスク定義リビジョンを削除することができます。
削除されたタスク定義リビジョンは、その後すぐに `INACTIVE` から `DELETE_IN_PROGRESS` に遷移します。状態が `DELETE_IN_PROGRESS` のタスク定義リビジョンを参照している既存のタスクおよびサービスは、中断することなく引き続き実行されます。
状態が `DELETE_IN_PROGRESS` のタスク定義リビジョンは、新しいタスクの実行や、新しいサービスの作成のために使用することはできません。また、`DELETE_IN_PROGRESS` 状態にあるタスク定義リビジョンを参照するように、既存のサービスを更新することもできません。
すべての `INACTIVE` タスク定義リビジョンを削除すると、タスク定義名はコンソールで表示されず、API でも返されません。タスク定義リビジョンが `DELETE_IN_PROGRESS` 状態にある場合、タスク定義名はコンソールに表示され、API で返されます。タスク定義名は Amazon ECS によって保持され、次回その名前を使用してタスク定義を作成するときにリビジョンがインクリメントされます。
## 削除をブロックできる Amazon ECS リソース
タスク定義リビジョンに依存する Amazon ECS リソースがある場合、タスク定義の削除リクエストは完了しません。次のリソースが原因で、タスク定義が削除されない場合があります。
+ Amazon ECS スタンドアロンタスク – タスクを正常に動作させるには、タスク定義が必要です。
+ Amazon ECS サービスタスク - タスクを正常に動作させるには、タスク定義が必要です。
+ Amazon ECS サービスのデプロイとタスクセット - Amazon ECS のデプロイまたはタスクセットのスケーリングイベントが開始される場合は、タスク定義が必要です。
タスク定義が `DELETE_IN_PROGRESS` の状態のままである場合は、コンソールまたは AWS CLI を使用して、タスク定義の削除をブロックしているリソースを特定し、停止できます。
### ブロックされたリソースが削除された後のタスク定義の削除
タスク定義の削除をブロックするリソースを削除すると、次のルールが適用されます。
+ Amazon ECS タスク - タスク定義の削除は、タスクが停止されてから完了するまでに最大 1 時間かかる場合があります。
+ Amazon ECS サービスのデプロイとタスクセット - タスク定義の削除は、デプロイまたはタスクセットが削除されてから完了するまでに最大 24 時間かかる場合があります。
## 手順
**タスク定義を登録解除するには (Amazon ECS コンソール)**
タスク定義リビジョンは、削除する前に登録解除する必要があります。詳細については、「[新しいコンソールを使用した Amazon ECS タスク定義リビジョンの登録解除](deregister-task-definition-v2.md)」を参照してください。
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションバーから、タスク定義を含むリージョンを選択します。
1. ナビゲーションペインで、**タスクの定義** を選択します。
1. **[タスク定義]** ページで、登録解除する 1 つ以上のタスク定義リビジョンを含むタスク定義ファミリーを選択します。
1. **[タスク定義名]** ページで、削除するリビジョンを選択し、次に **[アクション]**、**[削除]** の順に選択します。
**[削除]** が使用できない場合は、タスク定義の登録を解除する必要があります。
1. **[削除]** 確認ボックス内の情報を確認し、**[削除する]** を選択して終了します。
# Amazon ECS タスク定義のユースケース
さまざまな AWS のサービスや機能のタスク定義を作成する方法を説明します。
ワークロードによっては、設定を要するいくつかのタスク定義パラメータがあります。また、EC2 では、そのワークロード用に設計された特定のインスタンスを選択する必要があります。
**Topics**
+ [GPU ワークロード向けの Amazon ECS タスク定義](ecs-gpu.md)
+ [動画トランスコーディングワークロードでの Amazon ECS タスク定義](ecs-vt1.md)
+ [AWS Neuron 機械学習ワークロードでの Amazon ECS タスク定義](ecs-inference.md)
+ [深層学習インスタンスでの Amazon ECS タスク定義](ecs-dl1.md)
+ [64 ビット ARM ワークロードでの Amazon ECS タスク定義](ecs-arm64.md)
+ [Amazon ECS ログを CloudWatch に送信する](using_awslogs.md)
+ [Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)
+ [Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)
+ [コンテナ再起動ポリシーを使用して Amazon ECS タスク内の個々のコンテナを再起動する](container-restart-policy.md)
+ [Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)
# GPU ワークロード向けの Amazon ECS タスク定義
GPU 対応コンテナインスタンスを使用してクラスターを作成することで、GPU を使用するワークロードが Amazon ECS でサポートされます。p2、p3、p5、g3、g4、g5 のインスタンスタイプを使用する、Amazon EC2 GPU ベースのコンテナインスタンスでは、NVIDIA GPU へのアクセスが可能です。詳細については、「*Amazon EC2 インスタンスタイプガイド*」の「[Linux Accelerated Computing Instances](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)」を参照してください。
Amazon ECS には、事前設定された NVIDIA カーネルドライバーと Docker GPU ランタイムが付属する、GPU 最適化 AMI が用意されています。詳細については、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」を参照してください。
コンテナレベルのタスク配置のために、タスク定義でいくつかの GPU を指定できます。Amazon ECS は、使用が可能で GPU をサポートしているコンテナインスタンスをスケジュールし、物理的 GPU を適切なコンテナに固定して最適なパフォーマンスを実現します。
以下の Amazon EC2 GPU ベースのインスタンスタイプがサポートされています。詳細については、「[Amazon EC2 P2 インスタンス](https://aws.amazon.com/ec2/instance-types/p2/)」、「[Amazon EC2 P3 インスタンス](https://aws.amazon.com/ec2/instance-types/p3/)」、「[Amazon EC2 P4d インスタンス](https://aws.amazon.com/ec2/instance-types/p4/)」、「[Amazon EC2 P5 インスタンス](https://aws.amazon.com/ec2/instance-types/p5/)」、「[Amazon EC2 G3 インスタンス](https://aws.amazon.com/ec2/instance-types/g3/)」、「[Amazon EC2 G4 インスタンス](https://aws.amazon.com/ec2/instance-types/g4/)」、「[Amazon EC2 G5 インスタンス](https://aws.amazon.com/ec2/instance-types/g5/)」、「[Amazon EC2 G6 インスタンス](https://aws.amazon.com/ec2/instance-types/g6/)」、「[Amazon EC2 G6e Instances](https://aws.amazon.com/ec2/instance-types/g6e/)」を参照してください。
| インスタンスタイプ | GPU | GPU メモリ (GiB) | vCPU | メモリ (GiB) |
| --- | --- | --- | --- | --- |
| p3.2xlarge | 1 | 16 | 8 | 61 |
| p3.8xlarge | 4 | 64 | 32 | 244 |
| p3.16xlarge | 8 | 128 | 64 | 488 |
| p3dn.24xlarge | 8 | 256 | 96 | 768 |
| p4d.24xlarge | 8 | 320 | 96 | 1152 |
| p5.48xlarge | 8 | 640 | 192 | 2048 |
| g3s.xlarge | 1 | 8 | 4 | 30.5 |
| g3.4xlarge | 1 | 8 | 16 | 122 |
| g3.8xlarge | 2 | 16 | 32 | 244 |
| g3.16xlarge | 4 | 32 | 64 | 488 |
| g4dn.xlarge | 1 | 16 | 4 | 16 |
| g4dn.2xlarge | 1 | 16 | 8 | 32 |
| g4dn.4xlarge | 1 | 16 | 16 | 64 |
| g4dn.8xlarge | 1 | 16 | 32 | 128 |
| g4dn.12xlarge | 4 | 64 | 48 | 192 |
| g4dn.16xlarge | 1 | 16 | 64 | 256 |
| g5.xlarge | 1 | 24 | 4 | 16 |
| g5.2xlarge | 1 | 24 | 8 | 32 |
| g5.4xlarge | 1 | 24 | 16 | 64 |
| g5.8xlarge | 1 | 24 | 32 | 128 |
| g5.16xlarge | 1 | 24 | 64 | 256 |
| g5.12xlarge | 4 | 96 | 48 | 192 |
| g5.24xlarge | 4 | 96 | 96 | 384 |
| g5.48xlarge | 8 | 192 | 192 | 768 |
| g6.xlarge | 1 | 24 | 4 | 16 |
| g6.2xlarge | 1 | 24 | 8 | 32 |
| g6.4xlarge | 1 | 24 | 16 | 64 |
| g6.8xlarge | 1 | 24 | 32 | 128 |
| g6.16.xlarge | 1 | 24 | 64 | 256 |
| g6.12xlarge | 4 | 96 | 48 | 192 |
| g6.24xlarge | 4 | 96 | 96 | 384 |
| g6.48xlarge | 8 | 192 | 192 | 768 |
| g6.metal | 8 | 192 | 192 | 768 |
| gr6.4xlarge | 1 | 24 | 16 | 128 |
| g6e.xlarge | 1 | 48 | 4 | 32 |
| g6e.2xlarge | 1 | 48 | 8 | 64 |
| g6e.4xlarge | 1 | 48 | 16 | 128 |
| g6e.8xlarge | 1 | 48 | 32 | 256 |
| g6e16.xlarge | 1 | 48 | 64 | 512 |
| g6e12.xlarge | 4 | 192 | 48 | 384 |
| g6e24.xlarge | 4 | 192 | 96 | 768 |
| g6e48.xlarge | 8 | 384 | 192 | 1536 |
| gr6.8xlarge | 1 | 24 | 32 | 256 |
AWS Systems Manager パラメータストア API をクエリすることで、Amazon ECS に最適化された AMI の Amazon マシンイメージ (AMI) ID を取得できます。このパラメータを使用することで、Amazon ECS 最適化 AMI ID を手動で検索する必要がなくなります。Systems Manager Parameter Store API の詳細については、[GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html) を参照してください。使用するユーザーには、Amazon ECS 最適化 AMI メタデータを取得するための `ssm:GetParameter` IAM 許可が必要です。
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
```
# Amazon ECS マネージドインスタンスで GPU を使用する
Amazon ECS マネージドインスタンスは、次の Amazon EC2 インスタンスタイプを通じて、機械学習、高性能コンピューティング、ビデオ処理などのワークロードに対して GPU アクセラレーションコンピューティングをサポートしています。Amazon ECS マネージドインスタンスが対応するインスタンスタイプについて、詳しくは「[Amazon ECS マネージドインスタンスのインスタンスタイプ](managed-instances-instance-types.md)」を参照してください。
以下は、Amazon ECS マネージドインスタンスでサポートされている GPU ベースのインスタンスタイプのサブセットです。
+ `g4dn`: NVIDIA T4 GPUs を利用し、機械学習の推論、コンピュータビジョン、グラフィックを多用するアプリケーションに適しています。
+ `g5`: NVIDIA A10G GPUs を利用し、グラフィックスを多用するアプリケーションや機械学習ワークロードでより高いパフォーマンスを提供します。
+ `p3`: NVIDIA V100 GPUs を利用し、高性能コンピューティングと深層学習トレーニングに適しています。
+ `p4d`: NVIDIA A100 GPUs を利用し、機械学習トレーニングとハイパフォーマンスコンピューティングを支援します。
Amazon ECS マネージドインスタンスで GPU 対応インスタンスタイプを使用すると、NVIDIA ドライバーと CUDA ツールキットがインスタンスに事前にインストールされるため、GPU 対応ワークロードの実行が容易になります。
## GPU 対応インスタンスの選択
Amazon ECS マネージドインスタンスワークロードの GPU 対応インスタンスタイプを選択するには、キャパシティプロバイダーの起動テンプレートで `instanceRequirements` オブジェクトを使用します。次のスニペットは、GPU 対応インスタンスの選択に使用できる属性を示しています。
```
{
"instanceRequirements": {
"acceleratorTypes": "gpu",
"acceleratorCount": 1,
"acceleratorManufacturers": ["nvidia"]
}
}
```
次のスニペットは、起動テンプレートで GPU 対応インスタンスタイプを指定するために使用できる属性を示しています。
```
{
"instanceRequirements": {
"allowedInstanceTypes": ["g4dn.xlarge", "p4de.24xlarge"]
}
}
```
## GPU 対応コンテナイメージ
コンテナで GPUs を使用するには、必要な GPU ライブラリとツールを含むコンテナイメージを使用する必要があります。NVIDIA には、GPU ワークロードのベースとして使用できるいくつかの構築済みコンテナイメージが用意されています。
+ `nvidia:cuda`: GPU コンピューティング用の CUDA ツールキットを使用したベースイメージ。
+ `tensorflow/tensorflow:latest-gpu`: GPU 対応の TensorFlow。
+ `pytorch/pytorch:latest-cuda`: GPU 対応の PyTorch。
GPU を使用した Amazon ECS マネージドインスタンスのタスク定義サンプルは「[Amazon ECS タスク定義での GPU の指定](ecs-gpu-specifying.md)」を参照してください。
## 考慮事項
**注記**
g2 インスタンスファミリータイプのサポートは廃止されました。
p2 インスタンスファミリータイプは、バージョン `20230912` より前の Amazon ECS GPU 最適化 AMI でのみサポートされています。引き続き p2 インスタンスを使用する必要がある場合は、[P2 インスタンスが必要な場合の対処方法](#p2-instance) を参照してください。
これら両方のインスタンスファミリータイプで NVIDIA/CUDA ドライバーをインプレース更新すると、GPU ワークロードに障害が発生する可能性があります。
Amazon ECS で GPU の使用を開始する前に、以下について検討することをお勧めします。
+ クラスターには、GPU 対応コンテナインスタンスと GPU 非対応コンテナインスタンスを混在させることができます。
+ GPU ワークロードは外部インスタンスでの実行が可能です。外部インスタンスをクラスターに登録するときは、`--enable-gpu` フラグがインストールスクリプトに含まれていることを確認してください。詳細については、「[Amazon ECS クラスターに外部インスタンスを登録する](ecs-anywhere-registration.md)」を参照してください。
+ エージェント設定ファイルで `ECS_ENABLE_GPU_SUPPORT` を `true` に設定する必要があります。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
+ タスクの実行時またはサービスの作成時に、インスタンスタイプ属性を使用してタスク配置制約を設定することで、タスクが起動されるコンテナインスタンスを指定できます。これにより、リソースをより効果的に使用できます。詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。
以下の例では、デフォルトクラスター内の `g4dn.xlarge` コンテナインスタンスでタスクを起動しています。
```
aws ecs run-task --cluster default --task-definition ecs-gpu-task-def \
--placement-constraints type=memberOf,expression="attribute:ecs.instance-type == g4dn.xlarge" --region us-east-2
```
+ Amazon ECS は、コンテナ定義で指定された GPU リソース要件が適用されるコンテナごとに、コンテナランタイムとして NVIDIA のコンテナランタイムが使用されるように設定します。
+ NVIDIA コンテナランタイムが適切に機能するためには、コンテナにいくつかの環境変数を設定する必要があります。これらの環境変数のリストについては、「[Docker を使用した特殊設定](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html?highlight=environment%20variable)」を参照してください。Amazon ECS は、`NVIDIA_VISIBLE_DEVICES`環境変数の値を Amazon ECS がコンテナに割り当てる GPU デバイス ID のリストに設定します。Amazon ECS は、これら以外の必須環境変数の設定は行いません。そのため、これらの必須変数がコンテナイメージで設定されていること、あるいはコンテナ定義内で設定されていることを確認する必要があります。
+ p5 インスタンスタイプファミリーは、バージョン `20230929` 以降の Amazon ECS GPU 最適化 AMI でサポートされています。
+ g4 インスタンスタイプファミリーは、バージョン `20230913` 以降の Amazon ECS GPU 最適化 AMI でサポートされています。詳細については、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」を参照してください。Amazon ECS コンソールのクラスター作成ワークフローではサポートされていません。これらのインスタンスタイプを使用するには、Amazon EC2 コンソール、AWS CLI、または API を使用して、手動でインスタンスをクラスターに登録する必要があります。
+ p4d.24xlarge インスタンスタイプは、CUDA 11 以降でのみ動作します。
+ Amazon ECS GPU 最適化 AMI は IPv6 が有効になっているため、`yum` を使用するとき問題が生じます。これは、以下のコマンドで IPv4 を使用するように `yum` を構成することで解決できます。
```
echo "ip_resolve=4" >> /etc/yum.conf
```
+ NVIDIA/CUDA ベースのイメージを使用しないコンテナイメージをビルドする場合は、`NVIDIA_DRIVER_CAPABILITIES` コンテナランタイム変数に以下のいずれかの値を設定します。
+ `utility,compute`
+ `all`
変数の設定方法については、NVIDIA の Web サイトの「[NVIDIA コンテナランタイムの制御](https://sarus.readthedocs.io/en/stable/user/custom-cuda-images.html#controlling-the-nvidia-container-runtime)」を参照してください。
+ Windows コンテナでは、GPU はサポートされません。
# Amazon ECS 向け GPU コンテナインスタンスの起動
Amazon EC2 上で Amazon ECS の GPU インスタンスを使用するには、起動テンプレートとユーザーデータファイルを作成し、インスタンスを起動する必要があります。
これにより、GPU 用に設定されたタスク定義を使用するタスクを実行できます。
## 起動テンプレートを使用する
起動テンプレートを作成します。
+ Amazon ECS に最適化された AMI 用の GPU AMI ID を使用する起動テンプレートを作成してください。起動テンプレートの作成方法について、詳しくは「*Amazon EC2 ユーザーガイド*」の「[Create a new launch template using parameters you define](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#create-launch-template-define-parameters)」を参照してください。
**[Amazon マシンイメージ]** には、前のステップの AMI ID を使用します。Systems Manager パラメータで AMI ID を指定する方法については、「*Amazon EC2 ユーザーガイド*」の「[Specify a Systems Manager parameter in a launch template](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-launch-template.html#use-an-ssm-parameter-instead-of-an-ami-id)」を参照してください。
起動テンプレートの **[ユーザーデータ]** に以下を追加します。*cluster-name* をクラスターの名前に置き換えます。
```
#!/bin/bash
echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config;
echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config
```
## AWS CLI の使用
AWS CLI を使用して、コンテナインスタンスを起動できます。
1. `userdata.toml` というファイルを作成します。このファイルは、インスタンスのユーザーデータに使用されます。*cluster-name* をクラスターの名前に置き換えます。
```
#!/bin/bash
echo ECS_CLUSTER=cluster-name >> /etc/ecs/ecs.config;
echo ECS_ENABLE_GPU_SUPPORT=true >> /etc/ecs/ecs.config
```
1. 次のコマンドを実行して、GPU AMI ID を取得します。これは次のステップで使用します。
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
```
1. 次のコマンドを実行して、GPU インスタンスを起動します。次のパラメータを必ず置き換えてください。
+ *subnet* を、インスタンスを起動するプライベートまたはパブリックサブネットの ID に置き換えます。
+ *gpu\$1ami* を、前のステップの AMI ID に置き換えます。
+ *t3.large* を、使用するインスタンスタイプに置き換えます。
+ *region* を、リージョンコードに置き換えます。
```
aws ec2 run-instances --key-name ecs-gpu-example \
--subnet-id subnet \
--image-id gpu_ami \
--instance-type t3.large \
--region region \
--tag-specifications 'ResourceType=instance,Tags=[{Key=GPU,Value=example}]' \
--user-data file://userdata.toml \
--iam-instance-profile Name=ecsInstanceRole
```
1. 次のコマンドを実行して、コンテナインスタンスがクラスターに登録されていることを検証します。このコマンドを実行するときは、次のパラメータを必ず置き換えてください。
+ *cluster* を、自分のクラスター名に置き換えます。
+ *region* を、リージョンコードに置き換えます。
```
aws ecs list-container-instances --cluster cluster-name --region region
```
# Amazon ECS タスク定義での GPU の指定
コンテナインスタンス上の GPU と Docker GPU ランタイムを利用するには、コンテナに必要な GPU の数をタスク定義内で必ず指定します。GPU をサポートするコンテナが配置されると、Amazon ECS コンテナエージェントは必要な数の物理 GPU を適切なコンテナに固定します。タスク内でコンテナ用に予約されている、すべての GPU の数は、タスクが起動されたコンテナインスタンスで使用できる GPU の数を超えることはできません。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
**重要**
GPU 要件をタスク定義で指定していない場合、タスクではデフォルトの Docker ランタイムが使用されます。
タスク定義での GPU 要件の JSON 形式は以下のとおりです。
```
{
"containerDefinitions": [
{
...
"resourceRequirements" : [
{
"type" : "GPU",
"value" : "2"
}
],
},
...
}
```
以下の例では、GPU 要件を指定する Docker コンテナの構文を示しています。このコンテナは 2 つの GPU を使用しており、`nvidia-smi` ユーティリティを実行した後に終了します。
```
{
"containerDefinitions": [
{
"memory": 80,
"essential": true,
"name": "gpu",
"image": "nvidia/cuda:11.0.3-base",
"resourceRequirements": [
{
"type":"GPU",
"value": "2"
}
],
"command": [
"sh",
"-c",
"nvidia-smi"
],
"cpu": 100
}
],
"family": "example-ecs-gpu"
}
```
次のタスク定義の例は、使用可能な GPU 数を出力する TensorFlow コンテナを示しています。タスクは Amazon ECS マネージドインスタンスで実行され、1 つの GPU が必要で、`g4dn.xlarge` インスタンスを使用します。
```
{
"family": "tensorflow-gpu",
"networkMode": "awsvpc",
"executionRoleArn": "arn:aws:iam::account-id:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"name": "tensorflow",
"image": "tensorflow/tensorflow:latest-gpu",
"essential": true,
"command": [
"python",
"-c",
"import tensorflow as tf; print('Num GPUs Available: ', len(tf.config.list_physical_devices('GPU')))"
],
"resourceRequirements": [
{
"type": "GPU",
"value": "1"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/tensorflow-gpu",
"awslogs-region": "region",
"awslogs-stream-prefix": "ecs"
}
}
}
],
"requiresCompatibilities": [
"MANAGED_INSTANCES"
],
"cpu": "4096",
"memory": "8192",
}
```
## GPU の共有
GPU を共有する場合は、以下を設定する必要があります。
1. タスク定義から GPU リソース要件を削除して、Amazon ECS が共有する必要がある GPU を予約しないようにします。
1. GPU を共有する場合は、次のユーザーデータをインスタンスに追加します。これにより、NVIDIA がコンテナインスタンスのデフォルトの Docker コンテナランタイムになり、すべての Amazon ECS コンテナが GPU を使用できるようになります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[ユーザーデータ入力を使用して EC2 インスタンスを起動するときにコマンドを実行する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)」を参照してください。
```
const userData = ec2.UserData.forLinux();
userData.addCommands(
'sudo rm /etc/sysconfig/docker',
'echo DAEMON_MAXFILES=1048576 | sudo tee -a /etc/sysconfig/docker',
'echo OPTIONS="--default-ulimit nofile=32768:65536 --default-runtime nvidia" | sudo tee -a /etc/sysconfig/docker',
'echo DAEMON_PIDFILE_TIMEOUT=10 | sudo tee -a /etc/sysconfig/docker',
'sudo systemctl restart docker',
);
```
1. コンテナに `NVIDIA_VISIBLE_DEVICES` 環境変数を設定します。これを行うには、タスク定義内で環境変数を設定します。有効な値の詳細については、NVIDIA ドキュメントサイトの「[GPU 列挙](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html#gpu-enumeration)」を参照してください。
## P2 インスタンスが必要な場合の対処方法
P2 インスタンスを使用する必要がある場合、次のいずれかのオプションを使用してインスタンスを使用し続けることができます。
どちらのオプションでも、インスタンスユーザーデータを変更する必要があります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[ユーザーデータ入力を使用して EC2 インスタンスを起動するときにコマンドを実行する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)」を参照してください。
**サポートされている最新の GPU 最適化 AMI を使用する**
GPU に最適化された AMI の `20230906` バージョンを使用して、インスタンスのユーザーデータに以下を追加できます。
cluster-name をクラスターの名前に置き換えます。
```
#!/bin/bash
echo "exclude=*nvidia* *cuda*" >> /etc/yum.conf
echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config
```
**GPU に最適化された最新の AMI を使用し、ユーザーデータを更新する**
以下をインスタンスのユーザーデータに追加します。これにより Nvidia 535/Cuda12.2 ドライバーがアンインストールされ、次に Nvidia 470/Cuda11.4 ドライバーがインストールされ、バージョンが修正されます。
```
#!/bin/bash
yum remove -y cuda-toolkit* nvidia-driver-latest-dkms*
tmpfile=$(mktemp)
cat >$tmpfile <
> /etc/yum.conf
nvidia-smi
```
**P2 と互換性のある GPU に最適化された独自の AMI を作成する**
P2 インスタンスと互換性のある独自の Amazon ECS GPU 最適化 AMI を作成し、その AMI を使用して P2 インスタンスを起動できます。
1. 次のコマンドを実行して `amazon-ecs-ami repo` をクローンします。
```
git clone https://github.com/aws/amazon-ecs-ami
```
1. 必要な Amazon ECS エージェントとソースの Amazon Linux AMI バージョンを `release.auto.pkrvars.hcl` または `overrides.auto.pkrvars.hcl` に設定します。
1. P2 と互換性のあるプライベート EC2 AMI を構築するには、次のコマンドを実行します。
リージョンをインスタンスリージョンがあるリージョンに置き換えます。
```
REGION=region make al2keplergpu
```
1. 以下のインスタンスユーザーデータを含む AMI を使用して Amazon ECS クラスターに接続します。
cluster-name をクラスターの名前に置き換えます。
```
#!/bin/bash
echo "ECS_CLUSTER=cluster-name" >> /etc/ecs/ecs.config
```
# 動画トランスコーディングワークロードでの Amazon ECS タスク定義
Amazon ECS で動画トランスコーディングワークロードを使用するには、[Amazon EC2 VT1](https://aws.amazon.com/ec2/instance-types/vt1/) インスタンスを登録します。これらのインスタンスを登録した後は、事前レンダリングされたライブ動画のトランスコーディングワークロードを、Amazon ECS タスクとして実行できます。Amazon EC2 VT1 インスタンスは、Xilinx U30 メディアトランスコーディングカードを使用して、事前レンダリングされたライブ動画のトランスコーディングワークロードを高速化します。
**注記**
Amazon ECS 以外のコンテナで動画トランスコーディングワークロードを実行する方法については、[Xilinx のドキュメント](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#working-with-docker-vt1)を参照してください。
## 考慮事項
Amazon ECS で VT1 のデプロイを開始する前に、以下の点を考慮してください。
+ クラスターには、VT1 コンテナインスタンスと VT1 以外のインスタンスを混在させることができます。
+ アクセラレータ付きの AVC (H.264) および HEVC (H.265) コーデックを備えた、Xilinx U30 メディアトランスコーディングカードを使用する Linux アプリケーションが必要です。
**重要**
他のコーデックを使用するアプリケーションでは、VT1 インスタンスのパフォーマンスが強化されていない場合があります。
+ U30 カードでは、トランスコーディングタスクを 1 つのみ実行できます。各カードには、2 つのデバイスが関連付けられています。VT1 インスタンスごとに、使用しているカードの数だけのトランスコーディングタスクを実行できます。
+ サービスの作成時、またはスタンドアロンタスクの実行時に、インスタンスタイプ属性を使用してタスク配置制約を設定することができます。これにより、指定したコンテナインスタンスでタスクが起動されることを保証します。また、リソースを効果的に使用し、動画トランスコーディングワークロードのタスクが VT1 インスタンスに配置されるようにすることができます。詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。
次の例では、タスクが`default` クラスターの `vt1.3xlarge` インスタンス上で実行されます。
```
aws ecs run-task \
--cluster default \
--task-definition vt1-3xlarge-xffmpeg-processor \
--placement-constraints type=memberOf,expression="attribute:ecs.instance-type == vt1.3xlarge"
```
+ ホストコンテナインスタンス向けに用意された、特定の U30 カードを使用するようにコンテナを設定します。これを行うには、`linuxParameters` パラメータによりデバイスの詳細を指定します。詳細については、「[タスク定義の要件](#ecs-vt1-requirements)」を参照してください。
## VT1 AMI の使用
Amazon ECS コンテナインスタンス用 Amazon EC2 上で AMI を実行するには、2 つのオプションがあります。1 番目のオプションは、AWS Marketplace にある Xilinx 公式 AMI を使用することです。2 番目のオプションは、サンプルのリポジトリを利用して、独自の AMI を構築することです。
+ [Xilinx は、AWS Marketplace に AMI を提供しています](https://aws.amazon.com/marketplace/pp/prodview-phvk6d4mq3hh6)。
+ Amazon ECS は、動画トランスコーディングワークロード用の AMI を構築するために使用できる、サンプルのリポジトリを提供しています。この AMI には Xilinx U30 ドライバー備わります。[GitHub](https://github.com/aws-samples/aws-vt-baseami-pipeline) で、Packer スクリプトを含むリポジトリを入手できます。Packer の詳細については、「[Packer documentation](https://developer.hashicorp.com/packer/docs)」(Packer ドキュメント) を参照してください。
## タスク定義の要件
Amazon ECS で動画トランスコーディングコンテナを実行するには、アクセラレータ付きの H.264/AVC および H.265/HEVC コーデックを使用する動画トランスコーディングアプリケーションが、タスク定義に含まれている必要があります。[Xilinx GitHub](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage) の手順に従うことで、コンテナイメージを構築できます。
タスク定義は、インスタンスタイプに固有である必要があります。これらのインスタンスタイプは、3xlarge、6xlarge、および 24xlarge です。コンテナでは、ホストコンテナインスタンス向けに用意された、特定の Xilinx U30 デバイスの使用を設定する必要があります。これは、`linuxParameters` パラメータを使用して設定します。次の表に、各インスタンスタイプに固有のカードとデバイス SoC の詳細を示します。
| インスタンスタイプ | vCPU | RAM (GiB) | U30 アクセラレータカード | アドレス可能な XCU30 SoC デバイス | デバイスへのパス |
| --- | --- | --- | --- | --- | --- |
| vt1.3xlarge | 12 | 24 | 1 | 2 | /dev/dri/renderD128,/dev/dri/renderD129 |
| vt1.6xlarge | 24 | 48 | 2 | 4 | /dev/dri/renderD128,/dev/dri/renderD129,/dev/dri/renderD130,/dev/dri/renderD131 |
| vt1.24xlarge | 96 | 182 | 8 | 16 | /dev/dri/renderD128,/dev/dri/renderD129,/dev/dri/renderD130,/dev/dri/renderD131,/dev/dri/renderD132,/dev/dri/renderD133,/dev/dri/renderD134,/dev/dri/renderD135,/dev/dri/renderD136,/dev/dri/renderD137,/dev/dri/renderD138,/dev/dri/renderD139,/dev/dri/renderD140,/dev/dri/renderD141,/dev/dri/renderD142,/dev/dri/renderD143 |
**重要**
タスク定義に EC2 インスタンスにないデバイスがリストされている場合、タスクの実行は失敗します。タスクが失敗した場合は、`stoppedReason` にエラーメッセージ `CannotStartContainerError: Error response from daemon: error gathering device information while adding custom device "/dev/dri/renderD130": no such file or directory` が表示されます。
# Amazon ECS タスク定義での動画トランスコーディングの指定
次の例に、Amazon EC2 の Linux コンテナのタスク定義に使用される構文を示します。このタスク定義は、「[Xilinx documentation](https://xilinx.github.io/video-sdk/v1.5/container_setup.html#creating-a-docker-image-for-vt1-usage)」(Xilinx のドキュメント) で説明されている手順により構築されるコンテナイメージ用です。この例を使用する場合は、`image` を独自のイメージで置き換え、`/home/ec2-user` ディレクトリにあるインスタンスにビデオファイルをコピーします。
------
#### [ vt1.3xlarge ]
1. `vt1-3xlarge-ffmpeg-linux.json` と言う名前で、以下の内容が記述されたテキストファイルを作成します。
```
{
"family": "vt1-3xlarge-xffmpeg-processor",
"requiresCompatibilities": ["EC2"],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.os-type == linux"
},
{
"type": "memberOf",
"expression": "attribute:ecs.instance-type == vt1.3xlarge"
}
],
"containerDefinitions": [
{
"entryPoint": [
"/bin/bash",
"-c"
],
"command": ["/video/ecs_ffmpeg_wrapper.sh"],
"linuxParameters": {
"devices": [
{
"containerPath": "/dev/dri/renderD128",
"hostPath": "/dev/dri/renderD128",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD129",
"hostPath": "/dev/dri/renderD129",
"permissions": [
"read",
"write"
]
}
]
},
"mountPoints": [
{
"containerPath": "/video",
"sourceVolume": "video_file"
}
],
"cpu": 0,
"memory": 12000,
"image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
"essential": true,
"name": "xilinix-xffmpeg"
}
],
"volumes": [
{
"name": "video_file",
"host": {"sourcePath": "/home/ec2-user"}
}
]
}
```
1. タスク定義を登録します。
```
aws ecs register-task-definition --family vt1-3xlarge-xffmpeg-processor --cli-input-json file://vt1-3xlarge-xffmpeg-linux.json --region us-east-1
```
------
#### [ vt1.6xlarge ]
1. `vt1-6xlarge-ffmpeg-linux.json` と言う名前で、以下の内容が記述されたテキストファイルを作成します。
```
{
"family": "vt1-6xlarge-xffmpeg-processor",
"requiresCompatibilities": ["EC2"],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.os-type == linux"
},
{
"type": "memberOf",
"expression": "attribute:ecs.instance-type == vt1.6xlarge"
}
],
"containerDefinitions": [
{
"entryPoint": [
"/bin/bash",
"-c"
],
"command": ["/video/ecs_ffmpeg_wrapper.sh"],
"linuxParameters": {
"devices": [
{
"containerPath": "/dev/dri/renderD128",
"hostPath": "/dev/dri/renderD128",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD129",
"hostPath": "/dev/dri/renderD129",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD130",
"hostPath": "/dev/dri/renderD130",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD131",
"hostPath": "/dev/dri/renderD131",
"permissions": [
"read",
"write"
]
}
]
},
"mountPoints": [
{
"containerPath": "/video",
"sourceVolume": "video_file"
}
],
"cpu": 0,
"memory": 12000,
"image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
"essential": true,
"name": "xilinix-xffmpeg"
}
],
"volumes": [
{
"name": "video_file",
"host": {"sourcePath": "/home/ec2-user"}
}
]
}
```
1. タスク定義を登録します。
```
aws ecs register-task-definition --family vt1-6xlarge-xffmpeg-processor --cli-input-json file://vt1-6xlarge-xffmpeg-linux.json --region us-east-1
```
------
#### [ vt1.24xlarge ]
1. `vt1-24xlarge-ffmpeg-linux.json` と言う名前で、以下の内容が記述されたテキストファイルを作成します。
```
{
"family": "vt1-24xlarge-xffmpeg-processor",
"requiresCompatibilities": ["EC2"],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.os-type == linux"
},
{
"type": "memberOf",
"expression": "attribute:ecs.instance-type == vt1.24xlarge"
}
],
"containerDefinitions": [
{
"entryPoint": [
"/bin/bash",
"-c"
],
"command": ["/video/ecs_ffmpeg_wrapper.sh"],
"linuxParameters": {
"devices": [
{
"containerPath": "/dev/dri/renderD128",
"hostPath": "/dev/dri/renderD128",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD129",
"hostPath": "/dev/dri/renderD129",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD130",
"hostPath": "/dev/dri/renderD130",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD131",
"hostPath": "/dev/dri/renderD131",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD132",
"hostPath": "/dev/dri/renderD132",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD133",
"hostPath": "/dev/dri/renderD133",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD134",
"hostPath": "/dev/dri/renderD134",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD135",
"hostPath": "/dev/dri/renderD135",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD136",
"hostPath": "/dev/dri/renderD136",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD137",
"hostPath": "/dev/dri/renderD137",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD138",
"hostPath": "/dev/dri/renderD138",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD139",
"hostPath": "/dev/dri/renderD139",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD140",
"hostPath": "/dev/dri/renderD140",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD141",
"hostPath": "/dev/dri/renderD141",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD142",
"hostPath": "/dev/dri/renderD142",
"permissions": [
"read",
"write"
]
},
{
"containerPath": "/dev/dri/renderD143",
"hostPath": "/dev/dri/renderD143",
"permissions": [
"read",
"write"
]
}
]
},
"mountPoints": [
{
"containerPath": "/video",
"sourceVolume": "video_file"
}
],
"cpu": 0,
"memory": 12000,
"image": "0123456789012.dkr.ecr.us-west-2.amazonaws.com/aws/xilinx-xffmpeg",
"essential": true,
"name": "xilinix-xffmpeg"
}
],
"volumes": [
{
"name": "video_file",
"host": {"sourcePath": "/home/ec2-user"}
}
]
}
```
1. タスク定義を登録します。
```
aws ecs register-task-definition --family vt1-24xlarge-xffmpeg-processor --cli-input-json file://vt1-24xlarge-xffmpeg-linux.json --region us-east-1
```
------
# AWS Neuron 機械学習ワークロードでの Amazon ECS タスク定義
機械学習ワークロード用のクラスターには、[Amazon EC2 Trn1](https://aws.amazon.com/ec2/instance-types/trn1/)、[Amazon EC2 Trn2](https://aws.amazon.com/ec2/instance-types/trn2/)、[Amazon EC2 Inf1](https://aws.amazon.com/ec2/instance-types/inf1/)、および [Amazon EC2 Inf2](https://aws.amazon.com/ec2/instance-types/inf2/) インスタンスを登録できます。
Amazon EC2 Trn1 および Trn2 インスタンスには、[AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/) チップが搭載されています。これらのインスタンスは、クラウドでの機械学習用に高性能で低コストのトレーニングを提供します。Trn1 または Trn2 インスタンスで AWS Neuron を用いる機械学習フレームワークを使用して、機械学習推論モデルをトレーニングできます。その後、Inf1 インスタンスまたは Inf2 インスタンスでモデルを実行して、AWS Inferentia チップのアクセラレーションを使用できます。
Amazon EC2 Inf1 インスタンスと Inf2 インスタンスは、[AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/) チップを搭載しています。これらは、クラウドで高性能かつ最低レベルのコストの推論を提供します。
機械学習モデルは、専用の Software Developer Kit (SDK) である [AWS Neuron](https://aws.amazon.com/ai/machine-learning/neuron/) を使用してコンテナにデプロイされます。この SDK は、AWS 機械学習チップの機械学習パフォーマンスを最適化するコンパイラ、ランタイム、およびプロファイリングツールからなります。 AWSNeuron は、TensorFlow、PyTorch、Apache MXNet などの一般的な機械学習フレームワークをサポートしています。
## 考慮事項
Amazon ECS での Neuron のデプロイを開始する前に、以下の点を考慮してください。
+ クラスターには、Trn1、Trn2、Inf1、Inf2、およびその他インスタンスの組み合わせを含めることができます。
+ AWS Neuron をサポートする機械学習フレームワークを使用するコンテナ内に、Linux アプリケーションが必要です。
**重要**
他のフレームワークを使用するアプリケーションでは、Trn1、Trn2、Inf1、Inf2 インスタンスでパフォーマンスが向上しない場合があります。
+ 各 [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/) または [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/) チップで実行できる推論または推論トレーニングのタスクは 1 つだけです。Inf1 の場合、各チップには 4 つの NeuronCore があります。Trn1、Trn2、および Inf2 の場合、各チップに 2 つの NeuronCore があります。Trn1、Trn2、Inf1、Inf2 インスタンスごとに、チップの数だけのタスクを実行できます。
+ サービスの作成時、またはスタンドアロンタスクの実行時にタスク配置制約を設定する場合は、インスタンスタイプ属性を使用します。これにより、指定したコンテナインスタンスでタスクが起動されることを保証します。そうすることで、全体的なリソース使用率を最適化し、推論ワークロードのタスクを確実に Trn1、Trn2、Inf1、Inf2 インスタンスに配置できます。詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。
次の例では、`default` クラスターの `Inf1.xlarge` インスタンスでタスクが実行されます。
```
aws ecs run-task \
--cluster default \
--task-definition ecs-inference-task-def \
--placement-constraints type=memberOf,expression="attribute:ecs.instance-type == Inf1.xlarge"
```
+ Neuron リソース要件はタスク定義で定義できません。代わりに、ホストコンテナインスタンス向けに用意された、特定の AWS Trainium または AWS Inferentia チップを使用するようコンテナを設定します。これを行うには、`linuxParameters` パラメータを使用してデバイスの詳細を指定します。詳細については、「[タスク定義の要件](#ecs-inference-requirements)」を参照してください。
## Amazon ECS に最適化された Amazon Linux 2023 (Neuron) AMI の使用
Amazon ECS では、Amazon Linux 2023 ベースの Amazon ECS 最適化 AMI が、AWS Trainium および AWS Inferentia のワークロード用に用意されています。これには、Docker 用の AWS Neuron ドライバーとランタイムが付属しています。この AMI により、Amazon ECS 上で機械学習推論ワークロードの実行が容易になります。
Amazon EC2 の Trn1、Inf1、Inf2 インスタンスを起動する際は、Amazon ECS に最適化された Amazon Linux 2023 (Neuron) AMI を使用することをお勧めします。
現在の Amazon ECS に最適化された Amazon Linux 2023 (Neuron) AMI を取得するには、AWS CLI で次のコマンドを使用します。
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended
```
## タスク定義の要件
Amazon ECS 上に Neuron をデプロイするには、TensorFlow の推論モデルを提供するビルド済みコンテナのコンテナ定義が、タスク定義の中に含まれている必要があります。この定義は、AWS Deep Learning Containers によって提供されます。このコンテナには、AWS Neuron ランタイムと TensorFlow Serving アプリケーションが含まれています。起動時に、このコンテナは Amazon S3 からモデルを取得し、保存されたモデルを使用して Neuron TensorFlow Serving を起動した後、予測リクエストのために待機します。次の例でのコンテナイメージでは、 TensorFlow 1.15 と Ubuntu 18.04 を使用しています。Neuron 用に最適化された事前構築済みの Deep Learning Containers の完全なリストは、GitHub に保持されます。詳細については、「[AWS Neuron TensorFlow Serving の使用](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-inferentia-tf-neuron-serving.html)」を参照してください。
```
763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-inference-neuron:1.15.4-neuron-py37-ubuntu18.04
```
または、独自の Neuron サイドカーコンテナイメージを構築することもできます。詳細は「*AWS Deep Learning AMIs デベロッパーガイド*」の「[チュートリアル: Neuron TensorFlow Serving](https://github.com/aws-neuron/aws-neuron-sdk/blob/master/frameworks/tensorflow/tensorflow-neuron/tutorials/tutorials-tensorflow-utilizing-neuron-capabilities.rst)」を参照してください。
タスク定義は、1 つのインスタンスタイプに固有である必要があります。コンテナでは、ホストコンテナインスタンス向けに用意された、固有の AWS Trainium または AWS Inferentia デバイスを使用するよう設定する必要があります。これは、`linuxParameters` パラメータを使用して設定します。タスク定義の例については、「[Amazon ECS タスク定義での AWS Neuron 機械学習の指定](ecs-inference-task-def.md)」を参照してください。次の表に、各インスタンスタイプに固有のチップの詳細を示します。
| インスタンスタイプ | vCPU | RAM (GiB) | AWS ML アクセラレーターチップ | デバイスへのパス |
| --- | --- | --- | --- | --- |
| trn1.2xlarge | 8 | 32 | 1 | /dev/neuron0 |
| trn1.32xlarge | 128 | 512 | 16 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15 |
| trn2.48xlarge | 192 | 1536 | 16 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15 |
| inf1.xlarge | 4 | 8 | 1 | /dev/neuron0 |
| inf1.2xlarge | 8 | 16 | 1 | /dev/neuron0 |
| inf1.6xlarge | 24 | 48 | 4 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3 |
| inf1.24xlarge | 96 | 192 | 16 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11, /dev/neuron12, /dev/neuron13, /dev/neuron14, /dev/neuron15 |
| inf2.xlarge | 8 | 16 | 1 | /dev/neuron0 |
| inf2.8xlarge | 32 | 64 | 1 | /dev/neuron0 |
| inf2.24xlarge | 96 | 384 | 6 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, |
| inf2.48xlarge | 192 | 768 | 12 | /dev/neuron0, /dev/neuron1, /dev/neuron2, /dev/neuron3, /dev/neuron4, /dev/neuron5, /dev/neuron6, /dev/neuron7, /dev/neuron8, /dev/neuron9, /dev/neuron10, /dev/neuron11 |
# Amazon ECS タスク定義での AWS Neuron 機械学習の指定
次に、使用する構文を表示する `inf1.xlarge` 用の Linux タスク定義の例を示します。
```
{
"family": "ecs-neuron",
"requiresCompatibilities": ["EC2"],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.os-type == linux"
},
{
"type": "memberOf",
"expression": "attribute:ecs.instance-type == inf1.xlarge"
}
],
"executionRoleArn": "${YOUR_EXECUTION_ROLE}",
"containerDefinitions": [
{
"entryPoint": [
"/usr/local/bin/entrypoint.sh",
"--port=8500",
"--rest_api_port=9000",
"--model_name=resnet50_neuron",
"--model_base_path=s3://amzn-s3-demo-bucket/resnet50_neuron/"
],
"portMappings": [
{
"hostPort": 8500,
"protocol": "tcp",
"containerPort": 8500
},
{
"hostPort": 8501,
"protocol": "tcp",
"containerPort": 8501
},
{
"hostPort": 0,
"protocol": "tcp",
"containerPort": 80
}
],
"linuxParameters": {
"devices": [
{
"containerPath": "/dev/neuron0",
"hostPath": "/dev/neuron0",
"permissions": [
"read",
"write"
]
}
],
"capabilities": {
"add": [
"IPC_LOCK"
]
}
},
"cpu": 0,
"memoryReservation": 1000,
"image": "763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-inference-neuron:1.15.4-neuron-py37-ubuntu18.04",
"essential": true,
"name": "resnet50"
}
]
}
```
# 深層学習インスタンスでの Amazon ECS タスク定義
Amazon ECS で深層学習ワークロードを使用するには、[Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/)インスタンスをクラスターに登録します。Amazon EC2 DL1 インスタンスには、Habana Labs (インテル子会社) の Gaudi アクセラレータを搭載しています。Habana Gaudiアクセラレータには、Habana SynapseAI SDK を使用して接続します。この SDK は、TensorFlow および PyTorch による、一般的な機械学習フレームワークをサポートしています。
## 考慮事項
Amazon ECS 上で DL1 のデプロイを開始する前に、以下の点を考慮してください。
+ クラスターには、DL1 コンテナインスタンスと DL1 以外のインスタンスを混在させることができます。
+ サービスの作成時、またはスタンドアロンタスクの実行時、特にタスク配置制約を設定する場合には、インスタンスタイプ属性を使用して、タスクが起動されるコンテナインスタンスを確定できます。これにより、リソースが効果的に使用され、深層学習ワークロードのタスクが DL1 インスタンス上に配置されることが保証されます。詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。
次の例では、`default` クラスターの `dl1.24xlarge` インスタンスでタスクを実行します。
```
aws ecs run-task \
--cluster default \
--task-definition ecs-dl1-task-def \
--placement-constraints type=memberOf,expression="attribute:ecs.instance-type == dl1.24xlarge"
```
## DL1 AMI の使用
Amazon ECS 向けの Amazon EC2 DL1 インスタンス上で AMI を実行するためには、以下の 3 つのオプションがあります。
+ Habana が[ここで](https://aws.amazon.com/marketplace/pp/prodview-h24gzbgqu75zq)提供している AWS Marketplace AMI。
+ Amazon Web Services によって提供される Habana 深層学習 AMI。これには、Amazon ECS コンテナエージェントは含まれないため、このエージェントを個別にインストールする必要があります。
+ [GitHub リポジトリ](https://github.com/aws-samples/aws-habana-baseami-pipeline)を通じて提供されるカスタム AMI をビルドするには、Packer を使用します。詳細については、「[the Packer documentation](https://developer.hashicorp.com/packer/docs)」(Packer ドキュメント) を参照してください。
# Amazon ECS タスク定義での深層学習の指定
Habana Gaudi アクセラレータ付きの深層学習コンテナを Amazon ECS で実行するには、AWS Deep Learning Containers が提供する Habana SynapseAI を使用して TensorFlow または PyTorch 向けに深層学習モデルを提供する、ビルド済みコンテナのコンテナ定義が、対象のタスク定義内に含まれている必要があります。
次のコンテナイメージには TensorFlow 2.7.0 と Ubuntu 20.04 が含まれています。Neuron 用に最適化された事前構築済みの深層学習コンテナの完全なリストは、GitHub で確認できます。詳細については、「[Habana Training Containers](https://github.com/aws/deep-learning-containers/blob/master/available_images.md#habana-training-containers)」(Habana トレーニングコンテナ) を参照してください。
```
763104351884.dkr.ecr.us-east-1.amazonaws.com/tensorflow-training-habana:2.7.0-hpu-py38-synapseai1.2.0-ubuntu20.04
```
以下の例で、Amazon EC2 の Linux コンテナのタスク定義で使用する構文を示します。この例で使用するイメージには、`vault.habana.ai/gaudi-docker/1.1.0/ubuntu20.04/habanalabs/tensorflow-installer-tf-cpu-2.6.0:1.1.0-614` から入手が可能な Habana Labs のシステム管理インターフェイスツール (HL-SMI) が含まれています。
```
{
"family": "dl-test",
"requiresCompatibilities": ["EC2"],
"placementConstraints": [
{
"type": "memberOf",
"expression": "attribute:ecs.os-type == linux"
},
{
"type": "memberOf",
"expression": "attribute:ecs.instance-type == dl1.24xlarge"
}
],
"networkMode": "host",
"cpu": "10240",
"memory": "1024",
"containerDefinitions": [
{
"entryPoint": [
"sh",
"-c"
],
"command": ["hl-smi"],
"cpu": 8192,
"environment": [
{
"name": "HABANA_VISIBLE_DEVICES",
"value": "all"
}
],
"image": "vault.habana.ai/gaudi-docker/1.1.0/ubuntu20.04/habanalabs/tensorflow-installer-tf-cpu-2.6.0:1.1.0-614",
"essential": true,
"name": "tensorflow-installer-tf-hpu"
}
]
}
```
# 64 ビット ARM ワークロードでの Amazon ECS タスク定義
Amazon ECS は 64 ビット ARM アプリケーションの使用をサポートしています。アプリケーションは、[AWS Graviton プロセッサ](https://aws.amazon.com/ec2/graviton/)搭載のプラットフォーム上で実行できます。この構成、さまざまなワークロードに適しています。対象となるのは、アプリケーションサーバー、マイクロサービス、ハイパフォーマンスコンピューティング、CPU ベースの機械学習推論、ビデオエンコーディング、電子回路設計オートメーション、ゲーム配信、オープンソースデータベース、インメモリーキャッシュなどのワークロードです。
## 考慮事項
64 ビット ARM アーキテクチャを使用するタスク定義のデプロイを開始する前に、次の点を考慮してください。
+ アプリケーションは、Fargate または EC2 を使用できます。
+ アプリケーションは Linux オペレーティングシステムのみで使用できます。
+ Fargate タイプの場合、アプリケーションは Fargate プラットフォームバージョン `1.4.0` 以降を使用する必要があります。
+ アプリケーションは、モニタリングに Fluent Bit または CloudWatch を使用できます。
+ Fargate の場合、次の AWS リージョンでは 64 ビット ARM のワークロードには対応していません。
+ 米国東部 (バージニア北部)、`use1-az3` アベイラビリティーゾーン
+ EC2 の場合、以下を参照して、使用したいインスタンスタイプが利用地域でサポートされていることを確認してください。
+ [Amazon EC2 M6g インスタンス](https://aws.amazon.com/ec2/instance-types/m6)
+ [Amazon EC2 T4g インスタンス](https://aws.amazon.com/ec2/instance-types/t4/)
+ [Amazon EC2 C6g インスタンス](https://aws.amazon.com/ec2/instance-types/c6g/)
+ [Amazon EC2 R6gd インスタンス](https://aws.amazon.com/ec2/instance-types/r6/)
+ [Amazon EC2 X2gd インスタンス](https://aws.amazon.com/ec2/instance-types/x2/)
フィルターで Amazon EC2 の `describe-instance-type-offerings` コマンドを使用して、リージョンのインスタンスオファリングを表示することもできます。
```
aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=instance-type --region region
```
次の例では、米国東部 (バージニア北部) (us-east-1) リージョンで M6 インスタンスタイプが使用可能かどうかを確認します。
```
aws ec2 describe-instance-type-offerings --filters "Name=instance-type,Values=m6*" --region us-east-1
```
詳細については、「*Amazon EC2 コマンドラインリファレンス*」の「[インスタンスタイプオファリングの説明](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)」を参照してください。
# Amazon ECS タスク定義での ARM アーキテクチャの指定
ARM アーキテクチャを使用するには、`cpuArchitecture` タスク定義パラメータに `ARM64` を指定します。
次の例では、タスク定義で ARM アーキテクチャが指定されています。JSON 形式にあります。
```
{
"runtimePlatform": {
"operatingSystemFamily": "LINUX",
"cpuArchitecture": "ARM64"
},
...
}
```
次の例に、「hello world」を表示する ARM アーキテクチャのタスク定義を示します。
```
{
"family": "arm64-testapp",
"networkMode": "awsvpc",
"containerDefinitions": [
{
"name": "arm-container",
"image": "public.ecr.aws/docker/library/busybox:latest",
"cpu": 100,
"memory": 100,
"essential": true,
"command": [ "echo hello world" ],
"entryPoint": [ "sh", "-c" ]
}
],
"requiresCompatibilities": [ "EC2" ],
"cpu": "256",
"memory": "512",
"runtimePlatform": {
"operatingSystemFamily": "LINUX",
"cpuArchitecture": "ARM64"
},
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}
```
# Amazon ECS ログを CloudWatch に送信する
タスクのコンテナを設定して CloudWatch Logs にログ情報を送信できます。タスクで Fargate を使用すると、コンテナからログを表示できます。EC2 を使用すると、コンテナからの異なるログを 1 か所で便利に表示できます。また、コンテナインスタンスのディスク容量をコンテナログが占有してしまうことも防止できます。
**注記**
タスクのコンテナによってログ記録される情報のタイプは、`ENTRYPOINT` コマンドによって大きく異なります。デフォルトでは、キャプチャされるログには、コンテナをローカルに実行した場合に通常はインタラクティブターミナルに表示されるコマンド出力 (`STDOUT` および `STDERR` I/O ストリーム) が表示されます。`awslogs` ログドライバーは、これらのログを Docker から CloudWatch Logs に渡します。Docker ログの処理方法 (ファイルデータやストリームをキャプチャする別の方法) の詳細については、Docker ドキュメントの[コンテナまたはサービスのログを表示する](https://docs.docker.com/engine/logging/)を参照してください。
your Amazon ECS コンテナインスタンスから CloudWatch Logs にシステムログを送信するには、「*Amazon CloudWatch Logs ユーザーガイド*」の「[ログファイルをモニタリングする」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html)と「[CloudWatch Logs クォータ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html)」を参照してください。
## Fargate
タスクで Fargate を使用する場合、`awslogs` ログドライバーを有効化するには、必要な `logConfiguration` パラメータをタスク定義に追加する必要があります。詳細については、「[Amazon ECS タスク定義の例: CloudWatch にログをルーティングする](specify-log-config.md)」を参照してください。
Fargate の Windows コンテナでは、タスク定義パラメータに `& \ < > ^ |` などの特殊文字が含まれている場合は、次のいずれかのオプションを実行します。
+ パラメータ文字列全体を二重引用符で囲んだエスケープ (`\`) を追加する
例
```
"awslogs-multiline-pattern": "\"^[|DEBUG|INFO|WARNING|ERROR\"",
```
+ 各特殊文字の周囲にエスケープ (`^`) 文字を追加する
例
```
"awslogs-multiline-pattern": "^^[^|DEBUG^|INFO^|WARNING^|ERROR",
```
## EC2
タスクで EC2 を使用する場合、`awslogs` ログドライバーをオンにするには、Amazon ECS コンテナインスタンスに、コンテナエージェントのバージョン 1.9.0 以降が必要です。エージェントのバージョンの確認と最新バージョンへの更新については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。
**注記**
Amazon ECS に最適化された AMI か、もしくは少なくともバージョン `1.9.0-1` の `ecs-init` パッケージを含むカスタム AMI を使用する必要があります。カスタム AMI を使用する場合、**docker run** ステートメント内で以下の環境変数を使用するか、または環境変数ファイルを使用することにより、エージェントの起動時に Amazon EC2 インスタンス上で `awslogs` ロギングドライバーが使用可能となることを指定する必要があります。
```
ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
```
Amazon ECS コンテナインスタンスでは、コンテナインスタンスで起動する IAM ロールに `logs:CreateLogStream` および `logs:PutLogEvents` アクセス許可も必要になります。Amazon ECS で `awslogs` ログドライバーのサポートを有効にする前に Amazon ECS コンテナインスタンスを作成した場合は、このアクセス許可の追加が必要となる場合があります。`ecsTaskExecutionRole` はタスクに割り当てられた時点で使用され、また、正しいアクセス許可が含まれている必要があります。タスクの実行ロールの詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。コンテナインスタンスでコンテナインスタンス用の管理 IAM ポリシーを使用している場合、通常そのコンテナインスタンスには、適切なアクセス許可が付与されています。コンテナインスタンスのマネージド IAM ポリシーについては、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。
# Amazon ECS タスク定義の例: CloudWatch にログをルーティングする
コンテナがログを CloudWatch に送信する前に、タスク定義でコンテナの `awslogs` ログドライバーを指定する必要があります。ログパラメータの詳細については、「[ストレージとログ記録](task_definition_parameters.md#container_definition_storage)」を参照してください
下にあるタスク定義 JSON には、各コンテナに指定された `logConfiguration` オブジェクトが含まれています。その 1 つは、`awslogs-wordpress` というロググループにログを送信する WordPress コンテナ用です。もう 1 つは、`awslogs-mysql` というロググループにログを送信する MySQL コンテナ用です。どちらのコンテナも `awslogs-example` ログストリームプレフィックスを使用します。
```
{
"containerDefinitions": [
{
"name": "wordpress",
"links": [
"mysql"
],
"image": "public.ecr.aws/docker/library/wordpress:latest",
"essential": true,
"portMappings": [
{
"containerPort": 80,
"hostPort": 80
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-create-group": "true",
"awslogs-group": "awslogs-wordpress",
"awslogs-region": "us-west-2",
"awslogs-stream-prefix": "awslogs-example"
}
},
"memory": 500,
"cpu": 10
},
{
"environment": [
{
"name": "MYSQL_ROOT_PASSWORD",
"value": "password"
}
],
"name": "mysql",
"image": "public.ecr.aws/docker/library/mysql:latest",
"cpu": 10,
"memory": 500,
"essential": true,
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-create-group": "true",
"awslogs-group": "awslogs-mysql",
"awslogs-region": "us-west-2",
"awslogs-stream-prefix": "awslogs-example",
"mode": "non-blocking",
"max-buffer-size": "25m"
}
}
}
],
"family": "awslogs-example"
}
```
## 次のステップ
+ CloudWatch AWS CLI または API を使用してロググループの保持ポリシーを設定できます (オプション)。詳細は「*AWS Command Line Interfaceリファレンス*」の「[put-retention-policy](https://docs.aws.amazon.com/cli/latest/reference/logs/put-retention-policy.html)」を参照してください。
+ `awslogs` ログドライバーを使用するタスク定義をコンテナ定義ログ設定に登録すると、タスク定義を使用してタスクを実行またはサービスを作成し、CloudWatch Logs へのログの送信を開始できます。詳細については、「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」および「[Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)」を参照してください。
# Amazon ECS ログを AWS サービスまたは AWS Partner に送信する
FireLens for Amazon ECS では、タスク定義パラメータを使用してログを AWS サービスや AWS Partner Network (APN) の宛先にルーティングし、ログを保存および分析できます。AWS Partner Network は、プログラム、専門知識、リソースを活用して顧客向けサービスの構築、マーケティング、販売を行うパートナーのグローバルコミュニティです。詳細については、「[AWS Partner](https://aws.amazon.com/partners/work-with-partners/)」を参照してください。FireLens は [Fluentd](https://www.fluentd.org/) および [Fluent Bit](https://fluentbit.io/) と連携しています。Fluent Bit イメージ用に AWS を提供していますが、Fluentd や Fluent Bit のイメージはご用意いただいたものを使用することもできます。
デフォルトでは、Amazon ECS は、Firelens コンテナを使用するコンテナより前に Firelens コンテナを起動するようにコンテナの依存関係を設定します。また Firelens コンテナは、それを使用するすべてのコンテナが停止した後で停止します。
この機能を使用するには、タスク用の IAM ロールを作成し、AWS のサービスを使用するために必要なアクセス許可をタスクに付与する必要があります。例えば、コンテナから Firehose にログをルーティングする場合、タスクには `firehose:PutRecordBatch` API を呼び出すためのアクセス許可が必要です。詳細については、*IAM ユーザーガイド*の「[IAM ID アクセス許可の追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
以下の場合は、タスクに Amazon ECS タスク実行ロールが必要になることもあります。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
+ タスクが Fargate でホストされていて、Amazon ECR からコンテナイメージをプルしたり、ログ設定で AWS Secrets Manager の機密データを参照したりする場合は、タスク実行 IAM ロールを含める必要があります。
+ Amazon S3 でホストされているカスタム設定ファイルを使用する場合は、タスク実行 IAM ロールに `s3:GetObject` アクセス許可が含まれている必要があります。
FireLens for Amazon ECS を使用する際は、以下の点を考慮してください。
+ コンソール上でコンテナ名を簡単に区別できるよう、`my_service_` をログコンテナ名に追加することをおすすめします。
+ Amazon ECS はデフォルトで、アプリケーションコンテナと FireLens コンテナの間に開始コンテナ順序依存関係を追加します。アプリケーションコンテナと FireLens コンテナ間でコンテナ順序を指定すると、デフォルトの開始コンテナ順序が上書きされます。
+ FireLens for Amazon ECS は、Linux の AWS Fargate と Linux の Amazon EC2 の両方でホストされたタスクでサポートされます。Windows コンテナは FireLens をサポートしていません。
Windows コンテナの集中ロギングを設定する方法については、「[Centralized logging for Windows containers on Amazon ECS using Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/)」(Fluent Bit を使用した Amazon ECS での Windows コンテナの集中ロギング) を参照してください。
+ Amazon ECS の FireLens は、CloudFormation テンプレートを使用して設定できます。詳細については、*AWS CloudFormation ユーザーガイド*の「[AWS::ECS::TaskDefinition FirelensConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html)」を参照してください。
+ FireLens はポート `24224` でリッスンするため、FireLens ログルーターがタスク外に到達できないようにするには、タスクが使用するセキュリティグループでポート `24224` でのインバウンドトラフィックを許可してはなりません。`awsvpc` ネットワークモードを使用するタスクの場合、これは、そのタスクに関連付けられたセキュリティグループです。`host` ネットワークモードを使用するタスクでは、そのタスクをホストする Amazon EC2 インスタンスに関連付けられているセキュリティグループです。`bridge` ネットワークモードを使用するタスクの場合、ポート `24224` を使用するポートマッピングを作成しないでください。
+ `bridge` ネットワークモードを使用するタスクの場合、FireLens 設定のコンテナは、それに依存するアプリケーションコンテナが開始する前に開始する必要があります。コンテナの開始順序を制御するには、タスク定義の依存関係条件を使用します。詳細については、「[コンテナの依存関係](task_definition_parameters.md#container_definition_dependson)」を参照してください。
**注記**
FireLens 設定のコンテナ定義で依存関係条件パラメータを使用する場合は、各コンテナに `START` または `HEALTHY` 条件要件があることを確認してください。
+ デフォルトでは、FireLens はクラスターとタスクの定義名、およびクラスターの Amazon リソースネーム (ARN) をメタデータキーとして stdout/stderr コンテナログに追加します。メタデータ形式の例を次に示します。
```
"ecs_cluster": "cluster-name",
"ecs_task_arn": "arn:aws:ecs:region:111122223333:task/cluster-name/f2ad7dba413f45ddb4EXAMPLE",
"ecs_task_definition": "task-def-name:revision",
```
ログにメタデータを含めたくない場合は、タスク定義の「`firelensConfiguration`」セクションで `enable-ecs-log-metadata` を `false` に設定します。
```
"firelensConfiguration":{
"type":"fluentbit",
"options":{
"enable-ecs-log-metadata":"false",
"config-file-type":"file",
"config-file-value":"/extra.conf"
}
```
非ルートユーザーとして実行するように FireLens コンテナを設定できます。以下の点を考慮してください。
+ 非ルートユーザーとして実行するように FireLens コンテナを設定するには、次のいずれかの形式でユーザーを指定する必要があります。
+ `uid`
+ `uid:gid`
+ `uid:group`
コンテナ定義について、詳細は「*Amazon Elastic Container Service API リファレンス*」の「[ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html)」を参照してください。
FireLens コンテナは UNIX ソケット経由でアプリケーションログを受け取ります。Amazon ECS エージェントは `uid` を使用してソケットディレクトリの所有権を FireLens コンテナに割り当てます。
+ 非ルートユーザーとして実行するための FireLens コンテナ設定は、Amazon ECS エージェントバージョン `1.96.0` 以降、および Amazon ECS 最適化 AMI のバージョン `v20250716` 以降でサポートされています。
+ FireLens コンテナのユーザーを指定する場合、`uid` は一意でなければならず、タスク内の他のコンテナまたはコンテナインスタンスに属する他のプロセスには使用されません。
Amazon S3 でホストするファイルや Amazon S3 内のファイルなど、Amazon ECS で複数の設定ファイルを使用する方法については、「[Init process for Fluent Bit on ECS, multi-config support](https://github.com/aws/aws-for-fluent-bit/tree/mainline/use_cases/init-process-for-fluent-bit)」を参照してください。
構成例については、「[Amazon ECS タスク定義の例: FireLens にログをルーティングする](firelens-taskdef.md)」を参照してください。
高スループットのログ有効化と設定について、詳細は「[高スループットの Amazon ECS ログの設定](firelens-docker-buffer-limit.md)」を参照してください。
# 高スループットの Amazon ECS ログの設定
ログスループットの高いシナリオでは、FireLens と Fluent Bit を組み合わせた `awsfirelens` ログドライバーを使用することをお勧めします。 Fluent Bit は、リソースを効率的に処理し、数百万のログレコードを処理できる軽量ログプロセッサです。ただし、大規模に最適なパフォーマンスを実現するには、その設定を調整する必要があります。
このセクションでは、システムの安定性を維持し、データ損失を回避しながら、高いログスループットを処理するための高度な Fluent Bit 最適化手法について説明します。
FireLens でカスタム設定ファイルを使用する方法については、「[カスタム設定ファイルを使用する](firelens-taskdef.md#firelens-taskdef-customconfig)」を参照してください。その他の例については、GitHub の「[Amazon ECS FireLens の例](https://github.com/aws-samples/amazon-ecs-firelens-examples)」を参照してください。
**注記**
`workers` や `threaded` など、このセクションの一部の設定オプションでは、Fluent Bit バージョン 3 以降の AWS が必要です。使用可能なバージョンについては、「 [AWS for Fluent Bit リリース](https://github.com/aws/aws-for-fluent-bit/releases)」を参照してください。
## ファイルシステムのバッファリングを使用する
デフォルトでは、 Fluent Bit はメモリ内のすべてのデータをバッファします。データが出力にフラッシュされるよりも速く取り込まれると、バッファが満杯になります。満杯になると、入力プラグインはバッファスペースが使用可能になるまで一時停止します。これにより、バックプレッシャーが発生し、アプリケーションの速度が低下する可能性があります。
高スループットのシナリオでは、ファイルシステムのバッファリングを使用することをお勧めします。Fluent Bit がバッファリングとストレージを管理する方法の詳細については、 Fluent Bit ドキュメントの「[バッファリングとストレージ](https://docs.fluentbit.io/manual/administration/buffering-and-storage)」を参照してください。
ファイルシステムのバッファリングには、次の利点があります。
+ **バッファ容量が大きい** — 通常、ディスクスペースはメモリよりも豊富です。
+ **永続性** – バッファされたデータは Fluent Bit 再起動後も保持されます。
+ **グレースフルデグラデーション** – 出力の失敗時に、メモリの枯渇を引き起こすのではなく、データがディスクに蓄積されます。
ファイルシステムのバッファリングを有効にするには、カスタム Fluent Bit 設定ファイルを指定します。次の例は、推奨される設定です。
```
[SERVICE]
# Flush logs every 1 second
Flush 1
# Wait 120 seconds during shutdown to flush remaining logs
Grace 120
# Directory for filesystem buffering
storage.path /var/log/flb-storage/
# Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
storage.max_chunks_up 32
# Flush backlog chunks to destinations during shutdown (prevents log loss)
storage.backlog.flush_on_shutdown On
[INPUT]
Name forward
unix_path /var/run/fluent.sock
# Run input in separate thread to prevent blocking
threaded true
# Enable filesystem buffering for persistence
storage.type filesystem
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
# Use multiple workers for parallel processing
workers 2
# Retry failed flushes up to 15 times
retry_limit 15
# Maximum disk space for buffered data for this output
storage.total_limit_size 10G
```
主な設定パラメータ:
`storage.path`
Fluent Bit がバッファされたチャンクをディスクに保存するディレクトリ。
`storage.backlog.flush_on_shutdown`
有効にすると、Fluent Bit はシャットダウン中にすべてのバックログファイルシステムのチャンクを送信先にフラッシュしようとします。これにより、Fluent Bit が停止する前にデータ配信を確保できますが、シャットダウン時間が長くなる可能性があります。
`storage.max_chunks_up`
メモリに残っているチャンクの数。デフォルトは 128 チャンクで、各チャンクは最大 4～5 MB を使用できるため、500 MB 以上のメモリを消費する可能性があります。メモリに制約のある環境では、この値を小さくします。たとえば、バッファリングに 50 MB 使用できる場合は、これを 8～10 チャンクに設定します。
`storage.type filesystem`
入力プラグインのファイルシステムストレージを有効にします。名前にかかわらず、 Fluent Bit は `mmap` を使用してチャンクをメモリとディスクの両方にマッピングし、パフォーマンスを犠牲にすることなく永続性を提供します。
`threaded true`
Fluent Bit のメインイベントループとは別に、独自のスレッドで入力を実行します。これにより、遅い入力がパイプライン全体をブロックすることを防ぎます。
## 出力設定の最適化
ネットワークの問題、サービスの停止、送信先スロットリングにより、ログの配信が妨げられる場合があります。適切な出力設定により、データ損失のない耐障害性を保証します。
出力フラッシュが失敗した場合、 Fluent Bit はオペレーションを再試行できます。次のパラメータは再試行動作を制御します。
`retry_limit`
レコードを削除する前の最大再試行回数。デフォルトは 1 です。本番環境では、数分の停止に対応できるよう、エクスポネンシャルバックオフを用いた再試行数を 15 回以上に設定することをお勧めします。
`scheduler.base`
再試行間の最小秒数。10 秒をお勧めします。
`scheduler.cap`
エクスポネンシャルバックオフを使用する場合の再試行間の最大秒数。60 秒をお勧めします。
`workers`
並列出力処理のスレッド数。複数のワーカーが同時フラッシュを許可し、多くのチャンクを処理する際のスループットを向上させます。
`[SERVICE]` セクションの `Grace` パラメータは、バッファされたデータをフラッシュするためにシャットダウン中に Fluent Bit が待機する時間を設定します。`Grace` 期間はコンテナの `stopTimeout` と調整する必要があります。`SIGKILL` を受信する前に Fluent Bit がフラッシュを完了できるように、`stopTimeout` が `Grace` 期間を超えていることを確認します。たとえば、`Grace` が 120 秒の場合、 `stopTimeout` を 150 秒に設定します。
次の例は、高スループットシナリオで推奨されるすべての設定を含む完全な Fluent Bit 設定を示しています。
```
[SERVICE]
# Flush logs every 1 second
Flush 1
# Wait 120 seconds during shutdown to flush remaining logs
Grace 120
# Directory for filesystem buffering
storage.path /var/log/flb-storage/
# Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
storage.max_chunks_up 32
# Flush backlog chunks to destinations during shutdown (prevents log loss)
storage.backlog.flush_on_shutdown On
# Minimum seconds between retries
scheduler.base 10
# Maximum seconds between retries (exponential backoff cap)
scheduler.cap 60
[INPUT]
Name forward
unix_path /var/run/fluent.sock
# Run input in separate thread to prevent blocking
threaded true
# Enable filesystem buffering for persistence
storage.type filesystem
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
# Use multiple workers for parallel processing
workers 2
# Retry failed flushes up to 15 times
retry_limit 15
# Maximum disk space for buffered data for this output
storage.total_limit_size 10G
```
## マルチ送信先ログを使用して信頼性を高める
複数の送信先にログを送信すると、単一障害点がなくなります。たとえば、CloudWatch Logs で機能停止が発生した場合でも、ログは Amazon S3 に到達します。
マルチ送信先ログには、次の利点があります。Amazon S3 出力プラグインは、gzip 形式や Parquet 形式などの圧縮オプションもサポートしているため、ストレージコストを削減できます。詳細については、「Fluent Bit ドキュメント」の「[S3 圧縮](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression)」を参照してください。
マルチ送信先ログには、次の利点があります。
+ **冗長性** – 一方の送信先が失敗しても、ログはもう一方の送信先に到達します。
+ **復旧** – 一方のシステムのギャップを他方のシステムから再構築します。
+ **耐久性** – ログを Amazon S3 にアーカイブして長期保持します。
+ **コスト最適化** – 最近のログを CloudWatch Logs などの高速クエリサービスに短期間保存し、すべてのログを低コストの Amazon S3 ストレージにアーカイブして長期保持します。
次の Fluent Bit 設定は、CloudWatch Logs と Amazon S3 の両方にログを送信します。
```
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
workers 2
retry_limit 15
[OUTPUT]
Name s3
Match *
bucket my-logs-bucket
region us-west-2
total_file_size 100M
s3_key_format /fluent-bit-logs/$(ecs_task_id)/%Y%m%d/%H/%M/$UUID
upload_timeout 10m
# Maximum disk space for buffered data for this output
storage.total_limit_size 5G
```
どちらの出力も同じ `Match *` パターンを使用するため、すべてのレコードは両方の送信先に個別に送信されます。どちらか一方の送信先が停止しても、ログは引き続き他の送信先に流れ続け、失敗したフラッシュは後で再試行できるようにファイルシステムバッファに蓄積されます。
## tail 入力プラグインでファイルベースのログを使用する
ログ損失が重大な懸念事項となる高スループットのシナリオでは、別の方法として、アプリケーションがディスク上のファイルにログを書き込み、`tail` 入力プラグインを使用してそれらを読み取るように Fluent Bit を設定します。このアプローチは、Docker ログドライバーレイヤーを完全にバイパスします。
tail プラグインを使用したファイルベースのログ記録には、次の利点があります。
+ **オフセット追跡** – tail プラグインはデータベースファイルにファイルオフセットを保存できるため (`DB` オプションを使用)、Fluent Bit 再起動した際に耐久性があります。これにより、コンテナの再起動時にログが消失するのを防ぐことができます。
+ **入力レベルのバッファリング** – `Mem_Buf_Limit` を使用して入力プラグインでメモリバッファ制限を直接設定できるため、メモリ使用量をより詳細に制御できます。
+ **Docker のオーバーヘッドを回避** – Docker のログバッファを経由することなく、ログはファイルから Fluent Bit に直接送信されます。
このアプローチを使用するには、アプリケーションが `stdout` ではなくファイルにログを書き込む必要があります。アプリケーションコンテナと Fluent Bit コンテナの両方が、ログファイルが保存されている共有ボリュームをマウントします。
次の例は、ベストプラクティスを使用した tail 入力設定を示しています。
```
[INPUT]
Name tail
# File path or glob pattern to tail
Path /var/log/app.log
# Database file for storing file offsets (enables resuming after restart)
DB /var/log/flb_tail.db
# when true, controls that only fluent-bit will access the database (improves performance)
DB.locking true
# Skip long lines instead of skipping the entire file
Skip_Long_Lines On
# How often (in seconds) to check for new files matching the glob pattern
Refresh_Interval 10
# Extra seconds to monitor a file after rotation to account for pending flush
Rotate_Wait 30
# Maximum size of the buffer for a single line
Buffer_Max_Size 10MB
# Initial allocation size for reading file data
Buffer_Chunk_Size 1MB
# Maximum memory buffer size (tail pauses when full)
Mem_Buf_Limit 75MB
```
tail 入力プラグインを使用する場合は、次の点を考慮してください。
+ ディスクの枯渇を防ぐために、アプリケーションログのログローテーションを実装します。基盤となるボリュームメトリクスをモニタリングしてパフォーマンスを測定します。
+ ログ形式に基づいて、`Ignore_Older`、`Read_from_Head` および複数行パーサーなどの設定を検討してください。
詳細については、「Fluent Bit ドキュメント」の「[Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail)」を参照してください。ベストプラクティスについては、「Fluent Bit トラブルシューティングガイド」の AWS の「[ベストプラクティスを使用した Tail 設定](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices)」を参照してください。
## FireLens に直接ログ記録する
`awsfirelens` ログドライバーがタスク定義で指定されている場合、Amazon ECS コンテナエージェントは次の環境変数をコンテナに挿入します。
`FLUENT_HOST`
FireLens コンテナに割り当てられた IP アドレス。
`bridge` ネットワークモードの EC2 を使用している場合、FireLens ログルーターコンテナ (コンテナ定義に `firelensConfiguration` オブジェクトがあるコンテナ) を再起動した後で、アプリケーションコンテナの `FLUENT_HOST` 環境変数が不正確になる可能性があります。これは、`FLUENT_HOST` が動的 IP アドレスであり、再起動後に変更される場合があるためです。アプリケーションコンテナから `FLUENT_HOST` IP アドレスへの直接的なロギングは、アドレスの変更後に失敗することがあります。個々のコンテナの再起動に関する詳細については、「[コンテナ再起動ポリシーを使用して Amazon ECS タスク内の個々のコンテナを再起動する](container-restart-policy.md)」を参照してください。
`FLUENT_PORT`
Fluent Forward プロトコルがリッスンしているポート。
これらの環境変数を使用して、`stdout` に書き込む代わりに Fluent Forward プロトコルを使用してアプリケーションコードから Fluent Bit ログルーターに直接ログを記録できます。このアプローチでは、Docker ログドライバーレイヤーをバイパスします。これにより、次の利点が得られます。
+ **低レイテンシー** – Docker のログインフラストラクチャを経由することなく、ログは Fluent Bit に直接送信されます。
+ **構造化ログ** – JSON エンコーディングのオーバーヘッドなしで、構造化ログデータをネイティブに送信します。
+ **より良い制御** – アプリケーションは独自のバッファリングとエラー処理ロジックを実装できます。
次の Fluent ロガーライブラリは Fluent Forward プロトコルをサポートし、ログを Fluent Bit に直接送信するために使用できます。
+ **Go** – [fluent-logger-golang](https://github.com/fluent/fluent-logger-golang)
+ **Python** – [fluent-logger-python](https://github.com/fluent/fluent-logger-python)
+ **Java** – [fluent-logger-java](https://github.com/fluent/fluent-logger-java)
+ **Node.js** – [fluent-logger-node](https://github.com/fluent/fluent-logger-node)
+ **Ruby** – [fluent-logger-ruby](https://github.com/fluent/fluent-logger-ruby)
## Docker バッファ制限を設定する
タスク定義を作成する際は、`log-driver-buffer-limit` で値を指定することで、メモリにバッファリングされるログの行数を指定できます。これにより、Docker と Fluent Bit の間のバッファが制御されます。詳細については、Docker ドキュメントの「[Fluentd ロギングドライバー](https://docs.docker.com/engine/logging/drivers/fluentd/)」を参照してください。
このオプションは、スループットが高いために Docker がバッファメモリを使い果たし、新しいメッセージを追加するためにバッファメッセージを破棄する可能性がある場合に使用します。
このオプションを使用する場合は、次の点を考慮してください。
+ このオプションは、EC2 およびプラットフォームバージョン `1.4.0` 以降の Fargate でサポートされています。
+ このオプションは、`logDriver` が `awsfirelens` に設定されている場合にのみ有効です。
+ デフォルトのバッファ制限は `1048576` (ログの行数) です。
+ バッファ制限は、`0` ログ行以上、`536870912` ログ行未満である必要があります。
+ このバッファに使用されるメモリの最大量は、各ログ行のサイズとバッファのサイズ積です。たとえば、アプリケーションのログ行が平均 `2` KiB の場合、4096 のバッファ制限では最大 `8` MiB を使用します。タスクレベルで割り当てられるメモリの合計量は、ログドライバーのメモリバッファに加えて、すべてのコンテナに割り当てられたメモリ量よりも大きくなければなりません。
次のタスク定義は、`log-driver-buffer-limit` を設定する方法を示しています。
```
{
"containerDefinitions": [
{
"name": "my_service_log_router",
"image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
"cpu": 0,
"memoryReservation": 51,
"essential": true,
"firelensConfiguration": {
"type": "fluentbit"
}
},
{
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:latest",
"name": "app",
"logConfiguration": {
"logDriver": "awsfirelens",
"options": {
"Name": "firehose",
"region": "us-west-2",
"delivery_stream": "my-stream",
"log-driver-buffer-limit": "52428800"
}
},
"dependsOn": [
{
"containerName": "my_service_log_router",
"condition": "START"
}
],
"memoryReservation": 100
}
]
}
```
# Amazon ECS の Fluent Bit イメージリポジトリの AWS
AWS は、CloudWatch Logs と Firehose の両方のプラグインに Fluent Bit イメージを提供します。Fluent Bit は、リソース使用率が Fluentd よりも低いため、ログルーターとして使用することをお勧めします。詳細については、「[CloudWatch Logs for Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit)」および「[Amazon Kinesis Firehose for Fluent Bit](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit)」を参照してください。
**AWS for Fluent Bit** イメージは、Amazon ECR Public Gallery と Amazon ECR リポジトリの両方の Amazon ECR で利用が可能で、高可用性を実現できます。
## Amazon ECR Public Gallery
AWS for Fluent Bit イメージは Amazon ECR Public Gallery で利用できます。これはパブリックリポジトリであり、すべての AWS リージョン リージョンから使用できるため、AWS for Fluent Bit イメージのダウンロード先として推奨されます 詳細については、Amazon ECR Public Gallery の「[aws-for-fluent-bit](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit)」を参照してください。
### Linux
Amazon ECR Public Gallery の AWS for Fluent Bit イメージは、`ARM64` または `x86-64` アーキテクチャの Amazon Linux オペレーティングシステムをサポートしています。
目的のイメージタグを使用してリポジトリ URL を指定することにより、Amazon ECR Public Gallery からAWS for Fluent Bit イメージをプルできます。利用可能な画像タグは、Amazon ECR Public Gallery の [**Image tags (画像タグ)**] タブにあります。
Docker CLI で使用する構文を以下に示します。
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```
たとえば、次の Docker CLI コマンドを使用すれば、Fluent Bit リリースの AWS の「3.x」ファミリの最新イメージをプルできます。
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```
**注記**
認証されていないプルは許可されますが、認証されたプルよりもレート制限が低くなります。プルする前に、次のコマンドを使用して AWS アカウントの使用を認証します。
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
#### Fluent Bit 3.0.0 向けの AWS
Fluent Bit バージョン `2.x` の既存 AWS に加えて、Fluent Bit の AWS は新しいメジャーバージョン `3.x` をサポートします。新しいメジャーバージョンには、イメージを Amazon Linux 2 から Amazon Linux 2023 にアップグレードし、Fluent Bit バージョン `1.9.10` を `4.1.1` にアップグレードすることが含まれます。詳細は GitHub の「[AWS for Fluent Bit repository](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md)」を参照してください。
次の例は、Fluent Bit `3.x` イメージの AWS の更新済みタグを示しています。
Fluent Bit イメージの AWS にはマルチアーキテクチャタグを使用できます。
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```
### Server
Amazon ECR Public Gallery の AWS for Fluent Bit イメージは、次のオペレーティングシステムを備えた `AMD64` アーキテクチャをサポートしています。
+ Windows Server 2022 Full
+ Windows Server 2022 Core
+ Windows Server 2019 Full
+ Windows Server 2019 Core
AWS Fargate の Windows コンテナは FireLens をサポートしません。
目的のイメージタグを使用してリポジトリ URL を指定することにより、Amazon ECR Public Gallery からAWS for Fluent Bit イメージをプルできます。利用可能な画像タグは、Amazon ECR Public Gallery の [**Image tags (画像タグ)**] タブにあります。
Docker CLI で使用する構文を以下に示します。
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```
例えば、次の Docker CLI コマンドを使用して、AWS for Fluent Bit イメージの最新安定版をプルできます。
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:windowsservercore-stable
```
**注記**
認証されていないプルは許可されますが、認証されたプルよりもレート制限が低くなります。プルする前に、次のコマンドを使用して AWS アカウントの使用を認証します。
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
## Amazon ECR
AWS for Fluent Bit イメージは、Amazon ECR で高可用性を活用できます。次のコマンドを使用して、イメージ URI の取得および特定の AWS リージョンでイメージの可用性を確立できます。
### Linux
最新の安定している AWS for Fluent Bit イメージの URI は、次のコマンドを使用して取得できます。
```
aws ssm get-parameters \
--names /aws/service/aws-for-fluent-bit/stable \
--region us-east-1
```
次のコマンドを使用して Systems Manager パラメータストアのパラメータをクエリすると、AWS for Fluent Bit イメージのすべてのバージョンを一覧表示できます。
```
aws ssm get-parameters-by-path \
--path /aws/service/aws-for-fluent-bit \
--region us-east-1
```
AWS for Fluent Bit イメージの最新安定版は、Systems Manager パラメータストア名を参照することにより、CloudFormation テンプレート内に見つかります。次にの例を示します。
```
Parameters:
FireLensImage:
Description: Fluent Bit image for the FireLens Container
Type: AWS::SSM::Parameter::Value
Default: /aws/service/aws-for-fluent-bit/stable
```
**注記**
コマンドが失敗するか、出力がない場合、イメージはコマンドが呼び出される AWS リージョンでは使用できません。
### Server
最新の安定している AWS for Fluent Bit イメージの URI は、次のコマンドを使用して取得できます。
```
aws ssm get-parameters \
--names /aws/service/aws-for-fluent-bit/windowsservercore-stable \
--region us-east-1
```
次のコマンドを使用して Systems Manager パラメータストアのパラメータをクエリすると、AWS for Fluent Bit イメージのすべてのバージョンを一覧表示できます。
```
aws ssm get-parameters-by-path \
--path /aws/service/aws-for-fluent-bit/windowsservercore \
--region us-east-1
```
最新の安定している AWS for Fluent Bit イメージは、Systems Manager パラメータストア名を参照することにより、CloudFormation テンプレートで参照できます。次にの例を示します。
```
Parameters:
FireLensImage:
Description: Fluent Bit image for the FireLens Container
Type: AWS::SSM::Parameter::Value
Default: /aws/service/aws-for-fluent-bit/windowsservercore-stable
```
# Amazon ECS タスク定義の例: FireLens にログをルーティングする
FireLens でカスタムログルーティングを使用するには、タスク定義で以下を指定する必要があります。
+ FireLens 設定を含むログルーターコンテナ。コンテナは `essential` とマークすることが推奨されます。
+ `awsfirelens` ログドライバーを指定するログ設定を含む 1 つ以上のアプリケーションコンテナ。
+ タスクでログをルーティングするために必要なアクセス許可を含むタスク IAM ロール の、Amazon リソースネーム (ARN)。
AWS マネジメントコンソール を使用して新しいタスク定義を作成する場合、ログルーターコンテナを簡単に追加できる FireLens 統合セクションがあります。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
Amazon ECS はログ設定を変換し、Fluentd または Fluent Bit 出力設定を生成します。出力設定は、`/fluent-bit/etc/fluent-bit.conf` (Fluent Bit) および `/fluentd/etc/fluent.conf` (Fluentd) のログルーティングコンテナにマウントされます。
**重要**
FireLens は、ポート `24224` でリッスンします。したがって、FireLens ログルーターがタスクの外に到達できないようにするには、タスクが使用するセキュリティグループで、ポート `24224` での入力トラフィックを許可してはなりません。`awsvpc` ネットワークモードを使用する場合、このセキュリティグループは、タスクに関連付けられたセキュリティグループです。`host` ネットワークモードを使用する場合、これはタスクをホストする Amazon EC2 インスタンスに関連付けられているセキュリティグループです。`bridge` ネットワークモードを使用するタスクの場合、ポート `24224` を使用するポートマッピングを作成しないでください。
デフォルトでは、Amazon ECS は、ログのソースを識別するのに役立つ追加のフィールドをログエントリに追加します。
+ `ecs_cluster` - タスクが所属するクラスターの名前。
+ `ecs_task_arn` – コンテナが属しているタスクの完全な Amazon リソースネーム (ARN)。
+ `ecs_task_definition` - タスクが使用しているタスク定義名とリビジョン。
+ `ec2_instance_id` - コンテナがホストされている Amazon EC2 インスタンス ID。このフィールドは、EC2 起動タイプを使用するタスクでのみ有効です。
メタデータが必要ない場合は、`enable-ecs-log-metadata` を `false` に設定できます。
以下のタスク定義の例では、Fluent Bit を使用してログを CloudWatch Logs にルーティングするログルーターコンテナを定義しています。また、これによりアプリケーションコンテナを定義します。このコンテナでは、ログ設定を使用してログを Amazon Data Firehose にルーティングし、イベントのバッファリングに使用されるメモリを 2MiB に設定します。
**注記**
タスク定義のその他の例については、GitHub の [Amazon ECS FireLens の例](https://github.com/aws-samples/amazon-ecs-firelens-examples)を参照してください。
```
{
"family": "firelens-example-firehose",
"taskRoleArn": "arn:aws:iam::123456789012:role/ecs_task_iam_role",
"containerDefinitions": [
{
"name": "log_router",
"image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
"cpu": 0,
"memoryReservation": 51,
"portMappings": [],
"essential": true,
"environment": [],
"mountPoints": [],
"volumesFrom": [],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/ecs-aws-firelens-sidecar-container",
"mode": "non-blocking",
"awslogs-create-group": "true",
"max-buffer-size": "25m",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "firelens"
},
"secretOptions": []
},
"systemControls": [],
"firelensConfiguration": {
"type": "fluentbit"
}
},
{
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:latest",
"name": "app",
"logConfiguration": {
"logDriver": "awsfirelens",
"options": {
"Name": "firehose",
"region": "us-west-2",
"delivery_stream": "my-stream",
"log-driver-buffer-limit": "1048576"
}
},
"memoryReservation": 100
}
]
}
```
`logConfiguration` オブジェクトのオプションとして指定されたキーバリューペアは、Fluentd または Fluent Bit 出力設定の生成に使用されます。Fluent Bit 出力定義のコード例は次のとおりです。
```
[OUTPUT]
Name firehose
Match app-firelens*
region us-west-2
delivery_stream my-stream
```
**注記**
FireLens は `match` 設定を管理します。タスク定義では `match` 設定を指定しません。
## カスタム設定ファイルを使用する
カスタム設定ファイルを指定できます。設定ファイルの形式は、使用しているログルーターでネイティブな形式を使用します。詳細については、「[Fluentd 設定ファイルの構文](https://docs.fluentd.org/configuration/config-file)」および「[YAML 設定](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml)」を参照してください。
カスタム設定ファイルでは、`bridge` または `awsvpc` ネットワークモードを使用するタスクについて、TCP 経由で Fluentd または Fluent Bit の転送入力を設定しないでください。入力設定は FireLens により追加されています。
カスタム設定ファイルを指定するには、FireLens 設定に次のオプションを含める必要があります。
`config-file-type`
カスタム設定ファイルのソースの場所。使用できるオプションは、`s3` または `file` です。
AWS Fargate でホストされるタスクは、`file` 設定ファイルタイプのみをサポートします。ただし、Fluent Bit init コンテナの AWS を使用して、AWS Fargate の Amazon S3 でホストされている設定ファイルを使用できます。詳細については、GitHub の「[Init process for Fluent Bit on ECS, multi-config support](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md)」を参照してください。
`config-file-value`
カスタム設定ファイルのソース。`s3` 設定ファイルタイプを使用する場合、設定ファイルの値は Amazon S3 バケットとファイルの完全な ARN です。`file` 設定ファイルタイプを使用する場合、設定ファイルのこの値は、コンテナイメージ内、またはそのコンテナにマウントされているボリューム上に存在する設定ファイルへの完全パスです。
カスタム設定ファイルを使用する場合、FireLens が使用するパスとは異なるパスを指定する必要があります。Amazon ECS は Fluent Bit に `/fluent-bit/etc/fluent-bit.conf` ファイルパスと Fluentd に `/fluentd/etc/fluent.conf` を指定します。
次の例は、カスタム設定を指定するときに必要な構文を示しています。
**重要**
Amazon S3 でホストされるカスタム設定ファイルを指定するには、適切なアクセス許可を持つタスク実行 IAM ロールが作成されている必要があります。
次に、カスタム設定を指定する際に必要な構文を示します。
```
{
"containerDefinitions": [
{
"essential": true,
"image": "906394416424.dkr.ecr.us-west-2.amazonaws.com/aws-for-fluent-bit:3",
"name": "log_router",
"firelensConfiguration": {
"type": "fluentbit",
"options": {
"config-file-type": "s3 | file",
"config-file-value": "arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf | filepath"
}
}
}
]
}
```
**注記**
AWS Fargate でホストされるタスクは、`file` 設定ファイルタイプのみをサポートします。ただし、Fluent Bit init コンテナの AWS を使用して、AWS Fargate の Amazon S3 でホストされている設定ファイルを使用できます。詳細については、GitHub の「[Init process for Fluent Bit on ECS, multi-config support](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md)」を参照してください。
# Amazon ECS での AWS 以外のコンテナイメージの使用
プライベートレジストリを使用して認証情報を AWS Secrets Manager に保存し、タスク定義内で参照します。これは、タスク定義で認証が必要な AWS の外部にあるプライベートレジストリーに存在するコンテナイメージを参照できます。この機能は、Amazon ECS Anywhere を使用して Fargate、Amazon EC2 インスタンス、および外部インスタンスでホストされるタスクでサポートされています。
**重要**
タスク定義で、Amazon ECR に保存されたイメージを参照している場合、このトピックは適用されません。詳細については、*Amazon Elastic Container Registry ユーザーガイド*の「[Amazon ECS で Amazon ECR イメージを使用する](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html)」を参照してください。
Amazon EC2 インスタンスでホストされるタスクの場合は、この機能のためにコンテナエージェントのバージョン `1.19.0` 以降が必要です。ただし、最新のコンテナエージェントのバージョンを使用することをお勧めします。エージェントのバージョンの確認方法と最新バージョンへの更新方法については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。
Fargate でホストされているタスクの場合、この機能にはプラットフォームバージョン `1.2.0` 以降が必要です。詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。
コンテナの定義内で、作成したシークレットの詳細 で `repositoryCredentials` オブジェクトを指定します。参照されるシークレットは、タスクが使用するものと異なる AWS リージョン、または異なるアカウントに置くことができます。
**注記**
Amazon ECS API、AWS CLI、または AWS SDK を使用しており、起動するタスクと同じ AWS リージョン にシークレットが存在する場合は、シークレットの完全な ARN または名前のどちらも使用可能です。シークレットが別のアカウントに存在する場合は、シークレットの完全な ARN を指定する必要があります。AWS マネジメントコンソール を使用する場合は、シークレットの完全な ARN を常に指定する必要があります。
必要なパラメータが含まれるタスク定義のスニペットを、以下に示します。
次のパラメータを置き換えます。
+ *private-repo* をプライベートリポジトリのホスト名に
+ *private-image* をイメージ名に
+ *arn:aws:secretsmanager:region:aws\$1account\$1id:secret:secret\$1name* をシークレット Amazon リソースネーム (ARN) に
```
"containerDefinitions": [
{
"image": "private-repo/private-image",
"repositoryCredentials": {
"credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
}
}
]
```
**注記**
プライベートレジストリ認証を有効にするもうひとつの方法として、Amazon ECS コンテナエージェントの環境変数を使用してプライベートレジストリを認証する方法があります。このメソッドは、Amazon EC2 インスタンスでホストされるタスクでのみサポートされています。詳細については、「[プライベート Docker イメージ用の Amazon ECS コンテナインスタンスを設定する](private-auth-container-instances.md)」を参照してください。
**プライベートレジストリを使用するには**
1. タスク定義にはタスク実行ロールが必要です。このロールを使用して、コンテナエージェントでコンテナイメージをプルできます。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
プライベートレジストリ認証を使用すると、Amazon ECS タスクは、認証情報を必要とする AWS の外部 (Docker Hub、Quay.io、独自のプライベートレジストリなど) のプライベートレジストリからコンテナイメージをプルすることができます。この機能は Secrets Manager を使用してレジストリ認証情報を安全に保存し、`repositoryCredentials` パラメータを使用してタスク定義で参照します。
プライベートレジストリ認証の設定の詳細については、「[Amazon ECS での非 AWS コンテナイメージの使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html)」を参照してください。
プライベートレジストリ認証情報を含むシークレットにアクセスできるようにするには、以下のアクセス許可を、インラインポリシーとしてタスクの実行ロールに追加します。詳細については、「[IAM ポリシーの追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
+ `secretsmanager:GetSecretValue`— Secrets Manager からプライベートレジストリ認証情報を取得するために必要です。
+ `kms:Decrypt` – シークレットでカスタムの KMS キーを使用し、デフォルトのキーを使用しない場合にのみ必須です。カスタムキーの Amazon リソースネーム (ARN) は、リソースとして追加する必要があります。
次の例では、インラインポリシーによりアクセス許可を追加しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:secret_name",
"arn:aws:kms:us-east-1:111122223333:key/key_id"
]
}
]
}
```
------
1. プライベートレジストリ認証情報のシークレットを作成するには、AWS Secrets Manager を使用します。シークレットの作成方法について、詳細は「*AWS Secrets Manager ユーザーガイド*」の「[AWS Secrets Manager シークレットを作成する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」を参照してください。
以下の形式でプライベートレジストリの認証情報を入力します。
```
{
"username" : "privateRegistryUsername",
"password" : "privateRegistryPassword"
}
```
1. タスク定義を登録する 詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
# コンテナ再起動ポリシーを使用して Amazon ECS タスク内の個々のコンテナを再起動する
タスク定義で定義されている必須のコンテナと必須ではないコンテナそれぞれに再起動ポリシーを有効にして、一時的な障害をより迅速に克服し、タスクの可用性を維持することができます。コンテナの再起動ポリシーを有効にすると、コンテナが終了した場合、Amazon ECS はタスクを置き換えることなくコンテナを再起動できます。
再起動ポリシーは、デフォルトではコンテナに対して有効になっていません。コンテナの再起動ポリシーを有効にすると、コンテナを再起動しない終了コードを指定できます。これらは、終了コード `0` のように再起動を必要としない成功を示す終了コードである可能性があります。再起動を試みる前に、コンテナが正常に実行する必要のある時間を指定することもできます。これらのパラメータの詳細については、「[再起動ポリシー](task_definition_parameters.md#container_definition_restart_policy)」を参照してください。これらの値を指定するタスク定義の例については、「[Amazon ECS タスク定義でコンテナ再起動ポリシーを指定する](container-restart-policy-example.md)」を参照してください。
Amazon ECS タスクメタデータエンドポイントまたは CloudWatch Container Insights を使用して、コンテナが再起動した回数をモニタリングできます。タスクメタデータエンドポイントの詳細については、「[Amazon ECS タスクメタデータエンドポイントバージョン 4](task-metadata-endpoint-v4.md)」および「[Fargate のタスク用の Amazon ECS タスクメタデータエンドポイントバージョン 4](task-metadata-endpoint-v4-fargate.md)」を参照してください。Amazon ECS Container Insights メトリクスの一覧については、「*Amazon CloudWatch ユーザーガイド*」の「[Amazon ECS Container Insights メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html)」を参照してください。
コンテナ再起動ポリシーは、Fargate、Amazon EC2 インスタンスに加えて、Amazon ECS Anywhere を使用する外部インスタンスでホストされるタスクでサポートされています。
## 考慮事項
コンテナの再起動ポリシーを有効にする前に、次の点を考慮してください。
+ Fargate の Windows コンテナでは、再起動ポリシーはサポートされません。
+ Amazon EC2 インスタンスでホストされるタスクの場合は、この機能のためにコンテナエージェントのバージョン `1.86.0` 以降が必要です。ただし、最新のコンテナエージェントのバージョンを使用することをお勧めします。エージェントのバージョンの確認方法と最新バージョンへの更新方法については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。
+ `bridge` ネットワークモードの EC2 を使用している場合、FireLens ログルーターコンテナ (コンテナ定義に `firelensConfiguration` オブジェクトがあるコンテナ) を再起動した後で、アプリケーションコンテナの `FLUENT_HOST` 環境変数が不正確になる可能性があります。これは、`FLUENT_HOST` が動的 IP アドレスであり、再起動後に変更される場合があるためです。アプリケーションコンテナから `FLUENT_HOST` IP アドレスへの直接的なロギングは、アドレスの変更後に失敗することがあります。の詳細については、「`FLUENT_HOST`」を参照してください。[高スループットの Amazon ECS ログの設定](firelens-docker-buffer-limit.md)
+ Amazon ECS エージェントは、コンテナの再起動ポリシーを処理します。予期しない理由で Amazon ECS エージェントが失敗するか実行されなくなったりすると、コンテナは再起動されません。
+ ポリシーで定義された再起動試行期間は、Amazon ECS がコンテナを再起動するまでにコンテナが実行される必要のある期間 (秒単位) を決定します。
# Amazon ECS タスク定義でコンテナ再起動ポリシーを指定する
タスク定義でコンテナの再起動ポリシーを指定するには、コンテナ定義内で `restartPolicy` オブジェクトを指定します。`restartPolicy` オブジェクトの詳細については、「[再起動ポリシー](task_definition_parameters.md#container_definition_restart_policy)」を参照してください。
以下は、Web サーバーをセットアップするために、Fargate で Linux コンテナを使用するタスク定義です。コンテナ定義には、コンテナの再起動ポリシーを有効にするために `enabled` が true に設定された `restartPolicy` オブジェクトが含まれています。コンテナは再起動する前に 180 秒間実行する必要があります。成功を示す終了コード `0` で終了した場合、コンテナは再起動しません。
```
{
"containerDefinitions": [
{
"command": [
"/bin/sh -c \"echo ' Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
' > /usr/local/apache2/htdocs/index.html && httpd-foreground\""
],
"entryPoint": ["sh", "-c"],
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:2.4",
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/fargate-task-definition",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
},
"name": "sample-fargate-app",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
],
"restartPolicy": {
"enabled": true,
"ignoredExitCodes": [0],
"restartAttemptPeriod": 180
}
}
],
"cpu": "256",
"executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
"family": "fargate-task-definition",
"memory": "512",
"networkMode": "awsvpc",
"runtimePlatform": {
"operatingSystemFamily": "LINUX"
},
"requiresCompatibilities": ["FARGATE"]
}
```
コンテナ定義で `restartPolicy` オブジェクトを含むタスク定義を登録した後、そのタスク定義でタスクを実行するか、サービスを作成することができます。詳細については、「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」および「[Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)」を参照してください。
# Amazon ECS コンテナに機密データを渡す
認証情報などの機密データを、コンテナ内のデータベースなどに安全に渡すことができます。
API キーやデータベース認証情報などのシークレットは、アプリケーションが他のシステムにアクセスするためによく使用されます。多くの場合、ユーザー名とパスワード、証明書、または API キーで構成されます。これらのシークレットへのアクセスは、IAM を使用する特定の IAM プリンシパルに限定され、またランタイムにコンテナに挿入される必要があります。
シークレットは、AWS Secrets Manager または Amazon EC2 Systems Manager Parameter Store からコンテナにシームレスに挿入できます。これらのシークレットは、タスク内で以下のいずれかとして参照できます。
1. `secrets` コンテナ定義パラメータを使用する環境変数として参照されます。
1. ロギングプラットフォームが認証を必要とする場合、`secretOptions` として参照されます。詳細については、「[ログの設定オプション](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html#API_LogConfiguration_Contents)」を参照してください。
1. コンテナの取得元のレジストリーが認証を必要とする場合、これらは、`repositoryCredentials` コンテナ定義パラメータを使用するイメージによって取得されるシークレットとして参照されます。Amazon ECR Public Gallery からイメージを取得するときは、この方法を使用してください。詳細については、「[タスクのプライベートレジストリの認証](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html)」を参照してください。
シークレットの管理を設定するときは、次を行うことをお勧めします。
## シークレットマテリアルの保存に AWS Secrets Manager または AWS Systems Manager Parameter Store を使用する
API キー、データベース認証情報、およびその他のシークレットマテリアルは、Secrets Manager または暗号化されたパラメータとして Systems Manager Parameter Store に安全に保存する必要があります。これらのサービスは、どちらも AWS KMS を使用して機密データを暗号化する管理されたキー値ストアである点で似ています。ただし、Secrets Manager には、シークレットを自動的にローテーションし、ランダムなシークレットを生成し、アカウント間でシークレットを共有する機能も含まれています。これらの機能を利用するには、Secrets Manager を使用します。それ以外の場合は、Systems Manager パラメータストアで暗号化されたパラメータを使用します。
**重要**
シークレットが変更された場合は、新しいデプロイを強制するか、新しいタスクを起動して最新のシークレット値を取得する必要があります。詳細については、以下の各トピックを参照してください。
タスク - タスクを停止してから開始します。詳細については、「[Amazon ECS タスクの停止](standalone-task-stop.md)」および「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」を参照してください。
サービス - サービスを更新し、[新しいデプロイの強制] オプションを使用します。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。
## 暗号化された Amazon S3 バケットからデータを取得する
暗号化された Amazon S3 バケットにシークレットを保存し、タスクロールを使用してそのシークレットへのアクセスを制限する必要があります。こうすることで、`docker inspect` の実行時に環境変数の値が誤ってログに漏れて公開されるのを防ぐことができます。これを行う場合、Amazon S3 バケットからシークレットを読み取るようにアプリケーションを作成する必要があります。手順については、「[Amazon S3 バケット向けのサーバー側のデフォルトの暗号化動作の設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html)」を参照してください。
## サイドカーコンテナを使用してシークレットをボリュームにマウントする
環境変数はデータ漏えいのリスクが高いため、AWS Secrets Manager からシークレットを読みとり、共有ボリュームに書き込むサイドカーコンテナを実行する必要があります。このコンテナは、[Amazon ECS コンテナの順序付け](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html)を使用することでアプリケーションコンテナより先に実行して終了できます。これを行うと、アプリケーションコンテナでシークレットが書き込まれたボリュームが後からマウントされます。Amazon S3 バケットメソッドと同様に、共有ボリュームからシークレットを読み取るようにアプリケーションを作成する必要があります。ボリュームの範囲はタスクに限定されるため、タスクが停止するとボリュームは自動的に削除されます。例については、[Task-def.json](https://github.com/aws-samples/aws-secret-sidecar-injector/blob/master/ecs-task-def/task-def.json) プロジェクトを参照してください。
Amazon EC2 では、シークレットが書き込まれるボリュームは、AWS KMS カスタマーマネージドキーで暗号化できます。AWS Fargate では、ボリュームストレージはサービスマネージドキーを使用して自動的に暗号化されます。
# 個々の環境変数を Amazon ECS コンテナに渡す
**重要**
機密データは、AWS Secrets Manager secrets または AWS Systems Manager Parameter Store のパラメータに保存することをお勧めします。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
タスク定義で指定された環境変数は、許可されたすべてのユーザーとロールが、タスク定義の `DescribeTaskDefinition` アクションを読み取ることができます。
環境変数は、以下の方法でコンテナに渡すことができます。
+ `environment` コンテナ定義パラメータを個別に使用します。これは、[https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) の `--env` オプションにマッピングされます。
+ `environmentFiles` コンテナ定義パラメータを使用して、環境変数を含む 1 つ以上のファイルを一括で一覧表示します。ファイルは、Amazon S3 でホストされている必要があります。これは、[https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) の `--env-file` オプションにマッピングされます。
以下は、個々の環境変数の指定方法を示すタスク定義のスニペットです。
```
{
"family": "",
"containerDefinitions": [
{
"name": "",
"image": "",
...
"environment": [
{
"name": "variable",
"value": "value"
}
],
...
}
],
...
}
```
# 環境変数を Amazon ECS コンテナに渡す
**重要**
機密データは、AWS Secrets Manager secrets または AWS Systems Manager Parameter Store のパラメータに保存することをお勧めします。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
環境変数ファイルは Amazon S3 のオブジェクトのため、Amazon S3 のセキュリティに関するすべての考慮事項が適用されます。
Fargate の Windows コンテナと Windows コンテナでは、`environmentFiles` パラメータを使用できません。
環境変数ファイルを作成して Amazon S3 に保存し、環境変数をコンテナに渡すことができます。
ファイルに環境変数を指定することで、環境変数を一括で挿入できます。コンテナ定義内で、環境変数ファイルを含む `environmentFiles` バケットのリストを使用して Amazon S3 オブジェクトを指定します。
Amazon ECS は環境変数にサイズ制限を適用しませんが、環境変数ファイルが大きいとディスク容量が一杯になってしまう可能性があります。環境変数ファイルを使用する各タスクは、ファイルのコピーをディスクにダウンロードします。Amazon ECS は、タスクのクリーンアップの一環としてファイルを削除します。
サポートされている環境変数については、「[高度なコンテナ定義パラメータ - 環境](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment)」を参照してください。
コンテナ定義で環境変数ファイルを指定する際には、以下の点を考慮してください。
+ Amazon EC2 上の Amazon ECS タスクでこの機能を使用するには、コンテナインスタンスにバージョン `1.39.0` 以降のコンテナエージェントが必要です。エージェントのバージョンの確認方法と最新バージョンへの更新方法については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。
+ AWS Fargate 上のAmazon ECS タスクでは、この機能を使用するには、タスクでプラットフォームバージョン `1.4.0` 以降 (Linux) を使用する必要があります。詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。
変数がオペレーティングシステムプラットフォームでサポートされていることを確認します。詳細については、「[コンテナ定義](task_definition_parameters.md#container_definitions)」および「[その他のタスク定義パラメータ](task_definition_parameters.md#other_task_definition_params)」を参照してください。
+ ファイルには、ファイル拡張子 `.env` と UTF-8 エンコーディングを使用する必要があります。
+ タスク実行ロールは、Amazon S3 の追加アクセス許可でこの機能を使用するのに必要です。これにより、コンテナエージェントは Amazon S3 から環境変数ファイルをプルできます。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
+ 1 つのタスク定義につき 10 ファイルという制限があります。
+ 環境ファイルの各行には、`VARIABLE=VALUE` 形式で環境変数を含む必要があります。スペースまたは引用符は、Amazon ECS ファイルの値の一部として**含まれます**。`#` で始まる行はコメントとして扱われ、無視されます。環境変数ファイルの構文の詳細については、Docker ドキュメントの「[Set environment variables (-e, --env, --env-file)](https://docs.docker.com/reference/cli/docker/container/run/#env)」を参照してください。
次に、適切な構文を示します。
```
#This is a comment and will be ignored
VARIABLE=VALUE
ENVIRONMENT=PRODUCTION
```
+ コンテナ定義に `environment` パラメータを使用して環境変数が指定されている場合は、環境ファイルに含まれる変数よりも優先されます。
+ 同じ変数を含む複数の環境ファイルが指定されている場合、それらのファイルは入力順に処理されます。これは、変数の最初の値が使用され、重複する変数の後続の値は無視されることを意味します。一意の変数名を使用することをお勧めします。
+ 環境ファイルがコンテナをオーバーライドするように指定されている場合、そのファイルが適用されます。さらに、コンテナ定義で指定されているその他の環境ファイルは、すべて無視されます。
+ Fargate には次のルールが適用されます。
+ このファイルはネイティブの Docker env ファイルと同様に処理されます。
+ 空白で Amazon S3 に保存されている環境変数を参照するコンテナ定義は、コンテナに表示されません。
+ シェルエスケープ処理はサポートされていません。
+ コンテナのエントリポイントが `VARIABLE` 値を解釈します。
## 例
以下は、環境変数ファイルの指定方法を示すタスク定義のスニペットを示します。
```
{
"family": "",
"containerDefinitions": [
{
"name": "",
"image": "",
...
"environmentFiles": [
{
"value": "arn:aws:s3:::amzn-s3-demo-bucket/envfile_object_name.env",
"type": "s3"
}
],
...
}
],
...
}
```
# Amazon ECS で Secrets Manager シークレットをプログラムで伝達する
アプリケーション内でプレーンテキストの機密情報をハードコーディングする代わりに、Secrets Manager を使用して機密データを保存することができます。
機密データの取得にはこの方法が推奨されます。これにより、以後、Secrets Manager のシークレットが更新された場合には、アプリケーションが自動的に最新バージョンのシークレットを取得するようになります。
Secrets Manager でシークレットを作成します。Secrets Manager シークレットの作成後、アプリケーションコードを更新して、そのシークレットを取得します。
Secrets Manager で機密データの保護を行う前に、以下の考慮事項を確認してください。
+ [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html) API の `SecretString` パラメータで作成されたシークレットであるテキストデータを格納するシークレットのみがサポートされます。[CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html) API の `SecretBinary` パラメータで作成されたシークレットであるバイナリデータを格納するシークレットはサポートされていません。
+ セキュリティ制御を強化するために、インターフェイス VPC エンドポイントを使用します。Secrets Manager 用に、インターフェイス VPC エンドポイントを作成する必要があります。VPC エンドポイントについて、詳細は「*AWS Secrets Manager ユーザーガイド*」の「[VPC エンドポイントの作成](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html)」を参照してください。
+ タスクで使用する VPC は、DNS 解決を使用している必要があります。
+ タスク定義では、Secrets Manager の追加アクセス許可を持つタスク ロールを使用する必要があります。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
## Secrets Manager シークレットを作成する
Secrets Manager コンソールを使用して、機密データ用のシークレットを作成できます。シークレットの作成方法について、詳細は「*AWS Secrets Manager ユーザーガイド*」の「[AWS Secrets Manager シークレットを作成する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」を参照してください。
## Secrets Manager シークレットをプログラムにより取得するようにアプリケーションを更新する
アプリケーションから直接 Secrets Manager API を呼び出し、シークレットを取得することができます。詳細は「*AWS Secrets Manager ユーザーガイド*」の「[AWS Secrets Manager からのシークレットの取得](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)」を参照してください。
AWS Secrets Manager に保存されている機密データを取得するには、*AWS SDK コードサンプルコードライブラリ*の「[AWS SDK を使用する AWS Secrets Manager のコードサンプル](https://docs.aws.amazon.com/code-library/latest/ug/secrets-manager_code_examples.html)」を参照してください。
# Amazon ECS で Systems Manager Parameter Store シークレットをプログラムで伝達する
Systems Manager Parameter Store により、シークレットの安全な保管および管理ができます。パスワード、データベース文字列、EC2 インスタンス ID、AMI ID、ライセンスコードなどのデータをアプリケーションにハードコートする代わりに、パラメータ値として保存できます。値はプレーンテキストまたは暗号化されたデータとして保存できます。
機密データの取得にはこの方法が推奨されます。これにより、以後、Secrets Manager Parameter Store のパラメータが更新された場合にアプリケーションが自動的に最新バージョンを取得するようになります。
Systems Manager Parameter Store で機密データの保護を行う前に、以下の考慮事項を確認してください。
+ テキストデータを格納するシークレットのみがサポートされます。バイナリデータを格納するシークレットはサポートされません。
+ セキュリティ制御を強化するために、インターフェイス VPC エンドポイントを使用します。
+ タスクで使用する VPC は、DNS 解決を使用している必要があります。
+ EC2 を使用するタスクでは、この機能を使用するのに Amazon ECS エージェント設定変数 `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true` を使用する必要があります。コンテナインスタンスの作成時に `/etc/ecs/ecs.config` ファイルに追加するか、既存のインスタンスに追加して ECS エージェントを再起動できます。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
+ タスク定義では、Systems Manager パラメーター ストアに対する追加のアクセス許可を持つタスク ロールを使用する必要があります。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
## パラメータを作成する
Systems Manager コンソールを使用すると、機密データ用に Systems Manager Parameter Store のパラメータを作成できます。詳細は「*AWS Systems Manager ユーザーガイド*」の「[Systems Manager パラメータを作成する (コンソール)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html)」または「[Systems Manager パラメータを作成する (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html)」を参照してください。
## Systems Manager Parameter Store のシークレットをプログラムで取得するようにアプリケーションを更新する
Systems Manager Parameter Store のパラメータに保存されている機密データを取得するには、*AWS SDK コードサンプルコードライブラリ*の「[AWS SDK を使用した Systems Manager のコードサンプル](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html)」を参照してください。
# Amazon ECS 環境変数経由で Secrets Manager シークレットを伝達する
シークレットを環境変数として挿入する場合、シークレットの内容全体、シークレット内の特定の JSON キーを指定できます。これは、コンテナに公開される機密データの制御に役立ちます。シークレットのバージョニングについて、詳細は「*AWS Secrets Manager ユーザーガイド*」の「[Secrets Manager シークレットの内容](https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html#term_version)」を参照してください。
環境変数を使用して Secrets Manager シークレットをコンテナに挿入する場合は、以下を考慮する必要があります。
+ 重要なデータは、コンテナが最初に開始されたときにコンテナに挿入されます。シークレットを後で更新またはローテーションすると、コンテナには更新された値が自動的に送信されなくなります。この場合は、新しいタスクを起動する必要があります。または、タスクがサービスの一部である場合は、サービスを更新し、**[Force new deployment]** (新しいデプロイの強制) オプションを使用して、新しいタスクの起動をサービスに強制できます。
+ コンテナとコンテナログ、およびデバッグツールで実行されるアプリケーションは、環境変数にアクセスできます。
+ AWS Fargate 上の Amazon ECS タスクでは、以下の点を考慮してください。
+ シークレットの内容全体を環境変数として挿入したり、ログ設定にシークレットを挿入したりするには、プラットフォームバージョン `1.3.0` 以降を使用する必要があります。詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。
+ 特定の JSON キーまたはシークレットのバージョンを環境変数またはログ設定に挿入するには、プラットフォームバージョン `1.4.0` 以降 (Linux) または `1.0.0` (Windows) を使用する必要があります。詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。
+ EC2 上の Amazon ECS タスクでは、以下の点を考慮する必要があります。
+ シークレットの特定の JSON キーやバージョンを使用してシークレットを挿入するには、コンテナインスタンスにバージョン `1.37.0` 以降のコンテナエージェントが必要です。ただし、最新のコンテナエージェントのバージョンを使用することをお勧めします。エージェントのバージョンの確認と最新バージョンへの更新については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。
シークレットの内容全体を環境変数として挿入したり、ログ設定にシークレットを挿入したりするには、コンテナインスタンスにバージョン `1.22.0` 以降のコンテナエージェントが必要です。
+ インターフェイス VPC エンドポイントを使用してセキュリティコントロールを強化し、プライベートサブネットを介して Secrets Manager に接続します。Secrets Manager 用に、インターフェイス VPC エンドポイントを作成する必要があります。VPC エンドポイントについて、詳細は「*AWS Secrets Manager ユーザーガイド*」の「[VPC エンドポイントの作成](https://docs.aws.amazon.com/secretsmanager/latest/userguide/setup-create-vpc.html)」を参照してください。Secrets Manager と Amazon VPC の使用の詳細については、「[How to connect to Secrets Manager service within a Amazon VPC](https://aws.amazon.com/blogs//security/how-to-connect-to-aws-secrets-manager-service-within-a-virtual-private-cloud/)」を参照してください。
+ `awslogs` ログドライバーを使用するように設定された Windows タスクの場合は、コンテナインスタンスで `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` 環境変数も設定する必要があります。次の構文を使用します。
```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
Initialize-ECSAgent -Cluster -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
```
+ タスク定義では、Secrets Manager の追加アクセス許可を持つタスク実行ロールを使用する必要があります。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
## AWS Secrets Manager シークレットを作成する
Secrets Manager コンソールを使用して、機密データ用のシークレットを作成できます。詳細については、*AWS Secrets Manager ユーザーガイド*の「[Create an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」を参照してください。
## コンテナ定義に環境変数を追加します。
コンテナの定義内では、以下を指定できます。
+ コンテナに設定する環境変数の名前が含まれている `secrets` オブジェクト
+ Secrets Manager シークレットの Amazon リソースネーム (ARN)。
+ コンテナに渡す機密データが含まれている追加のパラメータ
次の例は、Secrets Manager シークレットに指定する必要がある完全な構文を示しています。
```
arn:aws:secretsmanager:region:aws_account_id:secret:secret-name:json-key:version-stage:version-id
```
次のセクションでは、追加のパラメータについて説明します。追加のパラメータはオプションですが、これらを使用しないでデフォルト値を使用する場合は、コロン `:` を含める必要があります。以下の例でより詳細なコンテキストを示します。
`json-key`
キーと値のペアのキーの名前を指定します。値は設定する環境変数の値です。JSON 形式の値のみがサポートされます。JSON キーを指定しないと、シークレットの内容全体が使用されます。
`version-stage`
使用するシークレットのバージョンのステージングラベルを指定します。バージョンのステージングラベルを指定した場合、バージョン ID は指定できません。バージョンのステージを指定しないと、デフォルトの動作として、`AWSCURRENT` ステージングラベルのシークレットが取得されます。
ステージングラベルは、シークレットが更新またはローテーションされたときに、シークレットのさまざまなバージョンを追跡するために使用します。シークレットの各バージョンには、1 つ以上のステージングラベルと 1 つの ID があります。
`version-id`
使用するシークレットのバージョンの固有 ID を指定します。バージョン ID を指定した場合、バージョンのステージングラベルは指定できません。バージョン ID を指定しないと、デフォルトの動作として、`AWSCURRENT` ステージングラベルのシークレットが取得されます。
バージョン ID は、シークレットが更新またはローテーションされたときに、シークレットのさまざまなバージョンを追跡するために使用します。シークレットの各バージョンには ID があります。詳細については、*AWS Secrets Managerユーザーガイド*の「[AWS Secrets Managerの主な用語と概念](https://docs.aws.amazon.com/secretsmanager/latest/userguide/terms-concepts.html#term_secret)」を参照してください。
### コンテナの定義の例
以下の例では、コンテナの定義で Secrets Manager シークレットを参照する方法を示します。
**Example シークレット全体を参照する**
次に示すのは、Secrets Manager シークレットのテキスト全体を参照するときの形式を示すタスク定義のスニペットです。
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
}]
}]
}
```
コンテナ内から、このシークレットの値にアクセスするには、`$environment_variable_name` を呼び出します。
**Example シークレット全体を参照する**
次に示すのは、複数の Secrets Manager シークレットのテキスト全体を参照するときの形式を示すタスク定義のスニペットです。
```
{
"containerDefinitions": [{
"secrets": [
{
"name": "environment_variable_name1",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
},
{
"name": "environment_variable_name2",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-abcdef"
},
{
"name": "environment_variable_name3",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-ABCDEF"
}
]
}]
}
```
コンテナ内から、このシークレットの値にアクセスするには、`$environment_variable_name1`、`$environment_variable_name2`、`$environment_variable_name3` を呼び出します。
**Example シークレット内の特定のキーを参照する**
次に示すのは、シークレットの内容と、シークレットに関連付けられているバージョンのステージングラベルおよびバージョン ID を表示する [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) コマンドの出力例です。
```
{
"ARN": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf",
"Name": "appauthexample",
"VersionId": "871d9eca-18aa-46a9-8785-981ddEXAMPLE",
"SecretString": "{\"username1\":\"password1\",\"username2\":\"password2\",\"username3\":\"password3\"}",
"VersionStages": [
"AWSCURRENT"
],
"CreatedDate": 1581968848.921
}
```
前のコンテナの定義の出力で特定のキーを参照するには、ARN の最後にキー名を指定します。
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::"
}]
}]
}
```
**Example 特定のシークレットバージョンを参照する**
次に示すのは、シークレットの暗号化されていない内容と、シークレットのすべてのバージョンのメタデータを表示する [describe-secret](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/describe-secret.html) コマンドの出力例です。
```
{
"ARN": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf",
"Name": "appauthexample",
"Description": "Example of a secret containing application authorization data.",
"RotationEnabled": false,
"LastChangedDate": 1581968848.926,
"LastAccessedDate": 1581897600.0,
"Tags": [],
"VersionIdsToStages": {
"871d9eca-18aa-46a9-8785-981ddEXAMPLE": [
"AWSCURRENT"
],
"9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE": [
"AWSPREVIOUS"
]
}
}
```
前のコンテナの定義の出力で特定のバージョンのステージングラベルを参照するには、ARN の最後にキー名を指定します。
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf::AWSPREVIOUS:"
}]
}]
}
```
前のコンテナの定義の出力で特定のバージョン ID を参照するには、ARN の最後にキー名を指定します。
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE"
}]
}]
}
```
**Example シークレットの特定のキーおよびバージョンのステージングラベルを参照する**
シークレット内の特定のキーと特定のバージョンのステージングラベルの両方を参照する方法は次のとおりです。
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1:AWSPREVIOUS:"
}]
}]
}
```
特定のキーとバージョン ID を指定するには、次の構文を使用します。
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::9d4cb84b-ad69-40c0-a0ab-cead3EXAMPLE"
}]
}]
}
```
環境変数で指定されたシークレットを使用してタスク定義を作成する方法については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
# Amazon ECS 環境変数を使用して Systems Manager パラメータを伝達する
Amazon ECS を使用すると、AWS Systems Manager Parameter Store のパラメータに機密データを保存した上で、コンテナの定義からそれを参照することによって、コンテナに機密データを取り込むことができます。
環境変数を使用して、コンテナに Systems Manager シークレットを注入する場合は、以下を考慮する必要があります。
+ 重要なデータは、コンテナが最初に開始されたときにコンテナに挿入されます。シークレットを後で更新またはローテーションすると、コンテナには更新された値が自動的に送信されなくなります。この場合は、新しいタスクを起動する必要があります。または、タスクがサービスの一部である場合は、サービスを更新し、**[Force new deployment]** (新しいデプロイの強制) オプションを使用して、新しいタスクの起動をサービスに強制できます。
+ AWS Fargate 上の Amazon ECS タスクでは、以下の点を考慮する必要があります。
+ シークレットの内容全体を環境変数として挿入したり、ログ設定にシークレットを挿入したりするには、プラットフォームバージョン `1.3.0` 以降を使用する必要があります。詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。
+ 特定の JSON キーまたはシークレットのバージョンを環境変数またはログ設定に挿入するには、プラットフォームバージョン `1.4.0` 以降 (Linux) または `1.0.0` (Windows) を使用する必要があります。詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。
+ EC2 上の Amazon ECS タスクでは、以下の点を考慮する必要があります。
+ シークレットの特定の JSON キーやバージョンを使用してシークレットを挿入するには、コンテナインスタンスにバージョン `1.37.0` 以降のコンテナエージェントが必要です。ただし、最新のコンテナエージェントのバージョンを使用することをお勧めします。エージェントのバージョンの確認と最新バージョンへの更新については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。
シークレットの内容全体を環境変数として挿入したり、ログ設定にシークレットを挿入したりするには、コンテナインスタンスにバージョン `1.22.0` 以降のコンテナエージェントが必要です。
+ セキュリティ制御を強化するために、インターフェイス VPC エンドポイントを使用します。Systems Manager 用に、インターフェイス VPC エンドポイントを作成する必要があります。VPC エンドポイントについては、「AWS Systems Manager ユーザーガイド」の「[Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html)」を参照してください。**
+ タスク定義では、Systems Manager パラメーター ストアに対する追加のアクセス許可を持つタスク実行ロールを使用する必要があります。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
+ `awslogs` ログドライバーを使用するように設定された Windows タスクの場合は、コンテナインスタンスで `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` 環境変数も設定する必要があります。次の構文を使用します。
```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
Initialize-ECSAgent -Cluster -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
```
## Systems Manager パラメータを作成する
Systems Manager コンソールを使用すると、機密データ用に Systems Manager Parameter Store のパラメータを作成できます。詳細は「*AWS Systems Manager ユーザーガイド*」の「[Systems Manager パラメータを作成する (コンソール)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html)」または「[Systems Manager パラメータを作成する (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html)」を参照してください。
## コンテナ定義に環境変数を追加します。
タスク定義でのコンテナ定義内では、コンテナに設定する環境変数の名前と、コンテナに渡す機密データが含まれている Systems Manager Parameter Store パラメータの ARN 全体を使用して `secrets` を指定します。詳細については、「[secrets](task_definition_parameters.md#ContainerDefinition-secrets)」を参照してください。
以下に示すのは、Systems Manager パラメータストアのパラメータを参照するときの形式を示すタスク定義のスニペットです。起動するタスクと同じリージョンに Systems Manager パラメータストアのパラメータが存在する場合は、パラメータの完全な ARN または名前のどちらも使用できます。パラメータが別のリージョンに存在する場合は、完全な ARN を指定する必要があります。
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
}]
}]
}
```
環境変数で指定されたシークレットを使用してタスク定義を作成する方法については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
## Systems Manager Parameter Store のシークレットをプログラムで取得するようにアプリケーションを更新する
Systems Manager Parameter Store のパラメータに保存されている機密データを取得するには、*AWS SDK コードサンプルコードライブラリ*の「[AWS SDK を使用した Systems Manager のコードサンプル](https://docs.aws.amazon.com/code-library/latest/ug/ssm_code_examples.html)」を参照してください。
# Amazon ECS ログ記録設定のシークレットを伝達する
`logConfiguration` に `secretOptions` パラメータを使用することで、ロギングに使用される機密データを渡すことができます。
シークレットは Secrets Manager または Systems Manager に保存できます。
## Secrets Manager を使用する
コンテナの定義内で `logConfiguration` を指定するときに、コンテナに設定するログドライバーオプションの名前と、コンテナに渡す機密データが含まれている Secrets Manager シークレットの ARN 全体を使用して `secretOptions` を指定できます。シークレットの作成の詳細については、「[AWS Secrets Manager の作成](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」を参照してください。
以下に示すのは、Secrets Manager シークレットを参照するときの形式を示すタスク定義のスニペットです。
```
{
"containerDefinitions": [{
"logConfiguration": [{
"logDriver": "splunk",
"options": {
"splunk-url": "https://your_splunk_instance:8088"
},
"secretOptions": [{
"name": "splunk-token",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
}]
}]
}]
}
```
## コンテナ定義に環境変数を追加します。
コンテナの定義内で、コンテナに設定する環境変数の名前と、コンテナに渡す機密データが含まれている Systems Manager パラメータストアのパラメータの ARN 全体を使用して `secrets` を指定できます。詳細については、「[secrets](task_definition_parameters.md#ContainerDefinition-secrets)」を参照してください。
以下に示すのは、Systems Manager パラメータストアのパラメータを参照するときの形式を示すタスク定義のスニペットです。起動するタスクと同じリージョンに Systems Manager パラメータストアのパラメータが存在する場合は、パラメータの完全な ARN または名前のどちらも使用できます。パラメータが別のリージョンに存在する場合は、完全な ARN を指定する必要があります。
```
{
"containerDefinitions": [{
"secrets": [{
"name": "environment_variable_name",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
}]
}]
}
```
環境変数で指定されたシークレットを使用してタスク定義を作成する方法については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
## 使用アイテム Systems Manager
ログ設定には機密データを注入できます。コンテナの定義内で `logConfiguration` を指定するときに、コンテナに設定するログドライバーオプションの名前と、コンテナに渡す機密データが含まれている Systems Manager パラメータストアのパラメータの ARN 全体を使用して `secretOptions` を指定できます。
**重要**
起動するタスクと同じリージョンに Systems Manager パラメータストアのパラメータが存在する場合は、パラメータの完全な ARN または名前のどちらも使用できます。パラメータが別のリージョンに存在する場合は、完全な ARN を指定する必要があります。
以下に示すのは、Systems Manager パラメータストアのパラメータを参照するときの形式を示すタスク定義のスニペットです。
```
{
"containerDefinitions": [{
"logConfiguration": [{
"logDriver": "fluentd",
"options": {
"tag": "fluentd demo"
},
"secretOptions": [{
"name": "fluentd-address",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter:/parameter_name"
}]
}]
}]
}
```
# Amazon ECS の Secrets Manager シークレットを使用した機密データの指定
Amazon ECS では、機密データを AWS Secrets Manager シークレットに保存し、コンテナ定義でそれを参照することで、機密データをコンテナに挿入することができます。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
Secrets Manager シークレットを作成して、Amazon ECS タスク定義でシークレットを参照し、コンテナ内の環境変数をクエリすることでシークレットの内容を表示して正しく動作したことを確認する方法について説明します。
## 前提条件
このチュートリアルでは、以下の前提条件が完了済みであることを前提としています。
+ 「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」のステップを完了していること。
+ ユーザーに、Secrets Manager および Amazon ECS リソースを作成するのに必要な IAM アクセス許可があります。
## ステップ 1:Secrets Manager シークレットを作成する
Secrets Manager コンソールを使用して、機密データ用のシークレットを作成できます。このチュートリアルでは、後にコンテナで参照するユーザー名とパスワードを保存するための基本的なシークレットを作成します。詳細については、*AWS Secrets Manager ユーザーガイド*の「[Create an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」を参照してください。
**[key/value pairs to be stored in this secret]** (このシークレットに格納されたキーおよび値のペア) は、チュートリアルの最後にコンテナに存在する環境変数の値です。
**[Secret ARN]** (シークレット ARN) を保存し、後のステップのタスク実行 IAM ポリシーとタスク定義で参照できるようにします。
## ステップ 2: タスク実行ロールにシークレットアクセス許可を追加する
Amazon ECS で Secrets Manager シークレットから機密データを取得するには、タスク実行ロールにシークレットアクセス許可が必要です。詳細については、「[Secrets Manager または Systems Manager のアクセス許可](task_execution_IAM_role.md#task-execution-secrets)」を参照してください。
## ステップ 3: タスク定義を作成する
Amazon ECS コンソールを使用して、Secrets Manager シークレットを参照するタスク定義を作成します。
**シークレットを指定するタスク定義を作成するには**
IAM コンソールを使用して、必要なアクセス許可を持つタスク実行ロールを更新します。
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで、**タスクの定義** を選択します。
1. **[Create new task definition]** (新しいタスク定義の作成)、**[Create new task definition with JSON]** (JSON で新しいタスク定義を作成) の順に選択します。
1. JSON エディタボックスで、以下のタスク定義 JSON テキストを入力して、ステップ 1 で作成した Secrets Manager シークレットの完全な ARN と、ステップ 2 で更新したタスク定義ロールを指定します。**[保存]** を選択します。
1.
```
{
"executionRoleArn": "arn:aws:iam::aws_account_id:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"entryPoint": [
"sh",
"-c"
],
"portMappings": [
{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
}
],
"command": [
"/bin/sh -c \"echo ' Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
' > /usr/local/apache2/htdocs/index.html && httpd-foreground\""
],
"cpu": 10,
"secrets": [
{
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:username_value",
"name": "username_value"
}
],
"memory": 300,
"image": "public.ecr.aws/docker/library/httpd:2.4",
"essential": true,
"name": "ecs-secrets-container"
}
],
"family": "ecs-secrets-tutorial"
}
```
1. **[作成]** を選択します。
## ステップ 4: クラスターを作成する
Amazon ECS コンソールを使用してコンテナインスタンスを含むクラスターを作成し、タスクを実行します。利用可能なリソースを使用して登録された少なくとも 1 つのコンテナインスタンスを持つ既存のクラスターがあり、このチュートリアル用に作成されたタスク定義の 1 つのインスタンスを実行できる場合は、次のステップに進みます。
このチュートリアルでは、Amazon ECS最適化Amazon Linux 2 AMIを使用して、1つの`t2.micro`コンテナ・インスタンスでクラスタを作成します。
EC2 用にクラスターを作成する方法については、「[Amazon EC2 ワークロード用の Amazon ECS クラスターを作成する](create-ec2-cluster-console-v2.md)」を参照してください。
## ステップ 5: タスクを実行する
Amazon ECS コンソールを使用し、作成したタスク定義を使用してタスクを実行できます。このチュートリアルでは、前のステップで作成したクラスターを使用し、EC2 を使用してタスクを実行します。
タスクを実行する方法については、「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」を参照してください。
## ステップ 6: 確認する
以下のステップを使用して、すべてのステップが正常に完了し、コンテナに環境変数が適切に作成されたことを確認できます。
**環境変数が作成されたことを確認するには**
1. コンテナインスタンスのパブリック IP アドレスまたは DNS アドレスを見つけます。
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで **[クラスター]** を選択した後、作成してあるクラスターを選択します。
1. **[インフラストラクチャ]** を選択した後、コンテナインスタンスを選択します。
1. インスタンスの **[パブリック IP]** または **[パブリック DNS]** を記録します。
1. macOS または Linux コンピュータを使用している場合は、以下のコマンドでインスタンスに接続します (パスとアドレスはプライベートキーへのパスとインスタンスのパブリックアドレスに置き換えます)。
```
$ ssh -i /path/to/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com
```
Windows コンピュータを使用している場合は、「*Amazon EC2 ユーザーガイド*」の「[PuTTY を使用して Linux インスタンスに接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-from-windows.html)」を参照してください。
**重要**
インスタンス接続時の問題について、詳細は「*Amazon EC2 ユーザーガイド*」の「[インスタンスへの接続に関するトラブルシューティング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html)」を参照してください。
1. インスタンスで実行するコンテナを一覧表示します。`ecs-secrets-tutorial` コンテナのコンテナ ID をメモしておきます。
```
docker ps
```
1. 前のステップの出力のコンテナ ID を使用して `ecs-secrets-tutorial` コンテナに接続します。
```
docker exec -it container_ID /bin/bash
```
1. `echo` コマンドを使用して環境変数の値を出力します。
```
echo $username_value
```
このチュートリアルが成功すると、次のような出力が表示されます。
```
password_value
```
**注記**
あるいは、`env` (または `printenv`) コマンドを使用して、コンテナ内の環境変数をすべて一覧表示できます。
## ステップ 7: クリーンアップする
このチュートリアルが終了したら、未使用のリソースに対する料金が発生しないように、それに関連付けられたリソースをクリーンアップする必要があります。
**リソースをクリーンアップするには**
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. **[Clusters]** (クラスター) ページで、クラスターを選択します。
1. [**Delete Cluster**] を選択します。
1. 確認ボックスで、**delete *cluster name*** と入力し、[**削除**] を選択します。
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで **Roles (ロール) ** を選択してください。
1. ロールの一覧で `ecsTaskExecutionRole` を探し、選択します。
1. **[アクセス許可]** を選択した後、**[ECSSecrets チュートリアル]** の横にある **[X]** を選択します。**[**を削除] を選択します。
1. [[https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)]で、Secrets Manager コンソール を開きます。
1. 作成した [**username\$1value**] シークレットを選択し、[**Actions (アクション)**]、[**Delete secret (シークレットの削除)**] の順に選択します。
# Amazon ECS マネージドインスタンスの Amazon ECS タスク定義パラメータ
タスク定義は、タスクファミリー、AWS Identity and Access Management (IAM) タスクロール、ネットワークモード、コンテナ定義、ボリューム、および容量に分類されます。ファミリとコンテナの定義は、タスク定義の必須項目です。これに対して、タスクロール、ネットワークモード、ボリューム、および容量は省略することができます。
これらのパラメータを JSON ファイルで使用し、タスク定義を設定できます。
Amazon ECS マネージドインスタンスの各タスク定義パラメータについて、以下に詳述します。
## ファミリー
`family`
タイプ: 文字列
必須: はい
タスク定義を登録するときに、ファミリー (複数バージョンのタスク定義の名前のようなもの) を指定する必要があります。登録したタスク定義には、リビジョン番号が与えられます。特定のファミリーに登録した最初のタスク定義には、リビジョン 1 が与えられます。その後に登録したタスク定義には、連番でリビジョン番号が与えられます。
## Capacity
タスク定義の登録時、Amazon ECS がタスク定義の検証基準となる容量を指定できます。タスク定義が指定された互換性を検証しない場合、クライアント例外が返されます。詳細は「[Amazon ECS 起動タイプ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_types.html)」を参照してください。
タスク定義では、以下のパラメータが使用できます。
`requiresCompatibilities`
タイプ: 文字列配列
必須: いいえ
有効な値: `MANAGED_INSTANCES`
タスク定義が検証された容量。これにより、タスク定義で使用されているすべてのパラメータが、Amazon ECS マネージドインスタンスの要件を満たしていることの確認処理が開始されます。
## タスクロール
`taskRoleArn`
タイプ: 文字列
必須: いいえ
タスク定義を登録するときに、IAM ロールのタスクロールを割り当てて、タスクのコンテナに、関連するポリシーに指定された AWS API を呼び出すためのアクセス権限を付与できます。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
## タスク実行ロール
`executionRoleArn`
タイプ: 文字列
必須: 条件による
ユーザーに代わって AWS API コールを実行するアクセス許可を Amazon ECS コンテナエージェントに付与するタスク実行ロールの Amazon リソースネーム (ARN)。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
タスク実行 IAM ロールは、タスクの要件に応じて必要です。ロールは、プライベート ECR イメージのプルと `awslogs` ログドライバーの使用に必要です。
## ネットワークモード
`networkMode`
タイプ: 文字列
必須: いいえ
デフォルト: `awsvpc`
タスクのコンテナで使用するネットワークモード。Amazon ECS マネージドインスタンスでホストされている Amazon ECS タスクの場合、有効な値は `awsvpc` と `host` となります。ネットワークモードが指定されていない場合、デフォルトのネットワークモードは `awsvpc` です。
ネットワークモードが `host` である場合、タスクはネットワークの分離をバイパスし、コンテナはホストのネットワークスタックを直接使用します。
`host` ネットワークモードをによりタスクを実行する場合、より良いセキュリティーのために、ルートユーザー (UID 0) を使用してコンテナを実行しないでください。セキュリティのベストプラクティスとしては、常にルート以外のユーザーを使用します。
ネットワークモードが `awsvpc` の場合は、タスクに Elastic Network Interface が割り当てられるため、タスク定義を使用したサービスの作成時またはタスクの実行時に `NetworkConfiguration` を指定する必要があります。詳細については、「[Amazon ECS マネージドインスタンスの Amazon ECS タスクネットワーキング](managed-instance-networking.md)」を参照してください。
`host` および `awsvpc` のネットワークモードは、Amazon EC2 のネットワークスタックを使用するので、コンテナのネットワークパフォーマンスが最大限発揮されます。`host` および `awsvpc` ネットワークモードにおいて公開されるコンテナポートは、対応するホストポート (`host` ネットワークモードの場合)、またはアタッチされた Elastic Network Interface ポート (`awsvpc` ネットワークモードの場合) に直接マッピングされます。このため、動的ホストポートマッピングは使用できません。
## ランタイムプラットフォーム
`operatingSystemFamily`
タイプ: 文字列
必須: いいえ
デフォルト: LINUX
タスク定義を登録する際、オペレーティングシステムファミリを指定します。
このフィールドで有効な値は `LINUX` です。
サービスで使用されるすべてのタスク定義は、このパラメータに対して同じ値を設定する必要があります。
タスク定義がサービスの一部である場合、この値はサービスの `platformFamily` 値と一致する必要があります。
`cpuArchitecture`
タイプ: 文字列
必須: 条件による
タスク定義を登録する際は、CPU アーキテクチャを指定します。有効な値は `X86_64` および `ARM64` です。
値を指定しない場合、Amazon ECS はキャパシティプロバイダーの設定に基づいて、使用可能な CPU アーキテクチャにタスクを配置しようとします。タスクが特定の CPU アーキテクチャに配置されるようにするには、タスク定義で `cpuArchitecture` の値を指定します。
サービスで使用されるすべてのタスク定義は、このパラメータに対して同じ値を設定する必要があります。
の詳細については、「`ARM64`」を参照してください。[64 ビット ARM ワークロードでの Amazon ECS タスク定義](ecs-arm64.md)
## タスクサイズ
タスク定義の登録時に、そのタスクが使用する CPU とメモリの合計量を指定できます。これは、コンテナ定義レベルの `cpu` および `memory` の値とは異なります。Amazon EC2 インスタンスでホストされるタスクの場合、これらのフィールドは省略可能です。
**注記**
タスクレベル CPU およびメモリのパラメータは Windows コンテナでは無視されます。Windows コンテナではコンテナレベルリソースを指定することをお勧めします。
`cpu`
タイプ: 文字列
必須: 条件による
タスクに適用される CPU ユニットのハード制限。JSON ファイルでは、CPU 値を CPU ユニットまたは仮想 CPU (vCPU) の文字列として指定できます。例えば、CPU 値を `1 vCPU` (vCPU) または `1024` (CPU ユニット) として指定できます。タスク定義が登録されると、vCPU 値は、CPU ユニットを示す整数に変換されます。
このフィールドはオプションです。クラスターに、要求された CPU ユニットが利用できる登録済みのコンテナインスタンスがない場合、タスクは失敗します。サポートされている値は、`0.125` vCPU から `10` vCPU までです。
`memory`
タイプ: 文字列
必須: 条件による
タスクに適用されるメモリのハード制限です。タスク定義のメモリの値は、メビバイト (MiB) またはギガバイト (GB) の文字列として指定できます。例えば、メモリの値を `3072` (MiB) または `3 GB` (GB) のいずれかで指定できます。タスク定義が登録されると、GB 値は、MiB を示す整数に変換されます。
このフィールドはオプションです。任意の値を使用できます。タスクレベルでメモリ値が指定されている場合、コンテナレベルのメモリ値の設定は省略可能です。クラスターに、要求されたメモリが利用できる登録済みのコンテナインスタンスがない場合、タスクは失敗します。特定のインスタンスタイプについて、タスクにできるだけ多くのメモリを提供することで、リソースの使用率を最大化することができます。詳細については、「[Amazon ECS Linux コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。
## その他のタスク定義パラメータ
以下のタスク定義パラメータは、Amazon ECS コンソールから、**[Configure via JSON (JSON による設定)]** オプションを使用してタスク定義を登録する際に使用します。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
**Topics**
+ [エフェメラルストレージ](#task_definition_ephemeralStorage-managed-instances)
+ [IPC モード](#task_definition_ipcmode-managed-instances)
+ [PID モード](#task_definition_pidmode-managed-instances)
+ [プロキシ設定](#proxyConfiguration-managed-instances)
+ [タグ](#tags-managed-instances)
+ [Elastic Inference アクセラレーター (廃止)](#elastic-Inference-accelerator-managed-instances)
+ [配置の制約事項](#constraints-managed-instances)
+ [ボリューム](#volumes-managed-instances)
### エフェメラルストレージ
`ephemeralStorage`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: [EphemeralStorage](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EphemeralStorage.html) オブジェクト
必須: いいえ
タスクに割り当てるエフェメラルストレージの容量(GB 単位)。このパラメーターは、AWS Fargate でホストされるタスクにおいて、利用可能なエフェメラルストレージの総量をデフォルトの容量を超えて拡張する際に使用します。詳細については、「[Amazon ECS でのバインドマウントの使用](bind-mounts.md)」を参照してください。
### IPC モード
`ipcMode`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: 文字列
必須: いいえ
タスクのコンテナで使用する IPC リソースの名前空間。有効な値は `host`、`task` または `none` です。`host` が指定されている場合、同一のコンテナインスタンス上にある (`host` IPC モードを指定した) タスク内のすべてのコンテナは、ホスト Amazon EC2 インスタンスと同じ IPC リソースを共有します。`task` が指定されている場合、指定されたタスク内のすべてのコンテナは同じ IPC リソースを共有します。`none` が指定されている場合、タスクのコンテナ内の IPC リソースはプライベートです。タスク内またはコンテナインスタンスの他のコンテナと共有されることはありません。値を指定しない場合、IPC リソース名前空間の共有はコンテナランタイム設定によって異なります。
### PID モード
`pidMode`
タイプ: 文字列
必須: いいえ
タスクのコンテナで使用するプロセス名前空間。有効な値は `host` または `task` です。`host` が指定されている場合、同じコンテナインスタンスで `host` PID モードを指定したタスク内のすべてのコンテナは、ホスト Amazon EC2 インスタンスと同じプロセス名前空間を共有します。`task` が指定されている場合、指定したタスク内のすべてのコンテナは同じプロセス名前空間を共有します。値が指定されていない場合、デフォルトはプライベート名前空間です。
`host` PID モードを使用する場合は、意図せずプロセス名前空間が公開されるリスクが高いことに注意してください。
### プロキシ設定
`proxyConfiguration`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) オブジェクト
必須: いいえ
App Mesh プロキシ設定の詳細。
### タグ
タスク定義に適用し、サービスの分類と整理に役立つメタデータ。各タグは、キーおよび値 (オプション) で構成されます。両方を定義します。
タグには以下のベーシックな制限があります。
+ リソースあたりのタグの最大数は 50 です
+ タグキーはリソースごとにそれぞれ一意である必要があります。また、各タグキーに設定できる値は 1 つのみです。
+ キーの最大長 - 128 文字 (Unicode) (UTF-8)
+ 値の最大長 - 256 文字 (Unicode) (UTF-8)
+ 複数の のサービス間およびリソース間でタグ付けスキーマを使用する場合、他のサービスにも許容される文字数に制限がある可能性があることに注意してください。一般的に使用が許可される文字は、UTF-8 で表現可能な文字、数字、スペース、および以下の文字です: \$1、-、=、.、\$1、:、/、@。
+ タグのキーと値は大文字と小文字が区別されます。
+ `aws:`、`AWS:`、またはその大文字または小文字の組み合わせを、キーまたは値のプレフィックスとして使用しないでください。これらの文字列は AWS による使用のために予約されています。このプレフィックスを持つタグのキーや値を編集または削除することはできません。このプレフィックスを持つタグは、リソースあたりのタグ数の制限には計算されません。
`key`
タイプ: 文字列
必須: いいえ
タグを構成するキーと値のペアの一部。キーは、より具体的なタグ値のカテゴリのように動作する、一般的なラベルです。
`value`
タイプ: 文字列
必須: いいえ
タグを構成するキーと値のペアのオプションの一部。値はタグカテゴリ (キー) の記述子として機能します。
### Elastic Inference アクセラレーター (廃止)
**注記**
Amazon Elastic Inference (EI) は利用できなくなりました。
`inferenceAccelerator`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: [InferenceAccelerator](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_InferenceAccelerator.html) オブジェクト
必須: いいえ
タスク内のコンテナに使用する Elastic Inference アクセラレーター。
### 配置の制約事項
`placementConstraints`
タイプ: [TaskDefinitionPlacementConstraint](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskDefinitionPlacementConstraint.html) オブジェクトの配列
必須: いいえ
タスクに使用する、配置制約オブジェクトの配列。タスクごとに最大 10 個の制約を指定できます (この制限数には、タスク定義内の制約と、実行時に指定される制約が含まれます)。
Amazon ECS は、Amazon ECS マネージドインスタンスで実行されるタスクの `distinctInstace` および `memberOf` の配置制約に対応しています。`memberOf` 配置制約を使用するタスクでは、次の属性がサポートされています。
+ `ecs.subnet-id`
+ `ecs.availability-zone`
+ `ecs.cpu-architecture`
+ `ecs.instance-type`
配置制約について、詳細は「[Amazon ECS がタスクに使用するコンテナインスタンスを定義する](task-placement-constraints.md)」を参照してください。
### ボリューム
タスク定義を登録するときは、オプションでタスクのボリュームのリストを指定できます。これにより、タスクでデータボリュームを使用できます。
ボリュームタイプおよびその他のパラメータについて、詳細は「[Amazon ECS タスクのストレージオプション](using_data_volumes.md)」を参照してください。
`name`
タイプ: 文字列
必須: はい
ボリュームの名前。最大 255 文字の英字 (大文字と小文字)、数字、ハイフンを使用できます。この名前は、コンテナ定義 `sourceVolume` の `mountPoints` パラメータで参照されます。
`host`
タイプ: [ HostVolumeProperties](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_HostVolumeProperties.html) オブジェクト
必須: いいえ
このパラメータは、バインドマウントのホストボリュームを使用する場合に指定します。`host` パラメータの内容により、バインドマウントのホストボリュームがホストコンテナインスタンスで保持されるかどうかと、その保存場所が決まります。`host` パラメータが空の場合は、システムがデータボリュームにホストパスを割り当てます。ただし、関連付けられたコンテナが実行を停止した後も、データが保持されるという保証はありません。
`sourcePath`
タイプ: 文字列
必須: いいえ
`host` パラメータを使用するときは、`sourcePath` を指定して、コンテナに提示されるホストインスタンス上のパスを宣言します。このパラメータが空の場合は、システムがホストパスを割り当てます。`host` パラメータにファイルの場所 `sourcePath` が含まれている場合、データボリュームは、手動で削除されるまでホストインスタンス上の指定された場所に保持されます。`sourcePath` の値がホストインスタンスに存在しない場合は、システムが値を作成します。その場所が存在する場合は、ソースパスフォルダの内容がエクスポートされます。
Amazon ECS マネージドインスタンスでは、ホストファイルシステムの一部が読み取り専用になっています。`sourcePath` は、`/var` または `/tmp` などの書き込み可能なディレクトリをポイントしている必要があります。詳細については、「[Amazon ECS でのバインドマウントの使用](bind-mounts.md)」を参照してください。
`dockerVolumeConfiguration`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) オブジェクト
必須: いいえ
このパラメータは、Docker ボリュームを使用する場合に指定します。
`efsVolumeConfiguration`
タイプ: [EFSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) オブジェクト
必須: いいえ
このパラメータは、タスクストレージに Amazon EFS ファイルシステムを使用するときに指定します。
`fsxWindowsFileServerVolumeConfiguration`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) オブジェクト
必須: いいえ
このパラメータは、タスクストレージに Amazon FSx for Windows File Server ファイルシステムを使用する場合に指定します。
`configuredAtLaunch`
タイプ: ブール値
必須: いいえ
起動時にボリュームを設定するかどうかを示します。これは、スタンドアロンタスクまたはサービスの一部として作成されたタスクの Amazon EBS ボリュームを作成するために使用されます。各タスク定義リビジョンでは、ボリューム設定で起動時に設定できるボリュームは 1 つだけです。
## コンテナ定義
タスク定義を登録するときは、コンテナインスタンスの Docker デーモンに渡されるコンテナ定義のリストを指定する必要があります。以下のパラメータをコンテナ定義で使用できます。
**Topics**
+ [名前](#container_definition_name-managed-instances)
+ [Image](#container_definition_image-managed-instances)
+ [メモリ](#container_definition_memory-managed-instances)
+ [CPU](#container_definition_cpu-managed-instances)
+ [ポートマッピング](#container_definition_portmappings-managed-instances)
+ [プライベートリポジトリの認証情報](#container_definition_repositoryCredentials-managed-instances)
+ [Essential](#container_definition_essential-managed-instances)
+ [エントリポイント](#container_definition_entrypoint-managed-instances)
+ [コマンド](#container_definition_command-managed-instances)
+ [作業ディレクトリパス](#container_definition_workingdirectory-managed-instances)
+ [詳細コンテナ定義パラメータ](#advanced_container_definition_params-managed-instances)
+ [Linux パラメータ](#container_definition_linuxparameters-managed-instances)
### 名前
`name`
タイプ: 文字列
必須: はい
コンテナの名前。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコアを使用できます。タスク定義で複数のコンテナをリンクしている場合、あるコンテナの `name` を別のコンテナの `links` に入力できます。これにより、コンテナ同士を接続します。
### Image
`image`
タイプ: 文字列
必須: はい
コンテナの開始に使用するイメージ。この文字列は Docker デーモンに直接渡されます。デフォルトでは、Docker Hub レジストリのイメージを使用できます。`repository-url/image:tag` または `repository-url/image@digest` で他のリポジトリを指定することもできます。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコア、コロン、ピリオド、スラッシュ、シャープ記号を使用できます。このパラメータは、docker create-container コマンドの `Image` と docker run コマンドの `IMAGE` パラメータにマッピングされます。
+ 新しいタスクが開始されると、Amazon ECS コンテナエージェントは、指定されたイメージおよびタグの最新バージョンをプルしてコンテナで使用します。ただし、リポジトリイメージの後続の更新がすでに実行されているタスクに反映されることはありません。
+ タスク定義のイメージパスでタグまたはダイジェストを指定しない場合、Amazon ECS コンテナエージェントは `latest` タグを使用して指定されたイメージを取り込みます。
+ リポジトリイメージに後から加えられた更新内容が、実行中のタスクに反映されることはありません。
+ プライベートレジストリのイメージがサポートされています。詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。
+ Amazon ECR リポジトリのイメージは、`registry/repository:tag` または `registry/repository@digest` の完全な命名規則 (例えば、`aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` や、`aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`) を使用して指定します。
+ Docker Hub の公式リポジトリのイメージでは、1 つの名前 (例: `ubuntu` または `mongo`) を使用します。
+ Docker Hub の他のリポジトリのイメージは、組織名で修飾されます (例: `amazon/amazon-ecs-agent`)。
+ 他のオンラインリポジトリのイメージは、さらにドメイン名で修飾されます (例: `quay.io/assemblyline/ubuntu`)。
`versionConsistency`
タイプ: 文字列
有効な値: `enabled`\$1`disabled`
必須: いいえ
コンテナ定義で指定されたコンテナイメージタグを Amazon ECS がイメージダイジェストに解決するかどうかを指定します。デフォルトでは、この動作は `enabled` です。コンテナの値を `disabled` として設定した場合、Amazon ECS はコンテナイメージタグをダイジェストに解決せず、コンテナ定義で指定された元のイメージ URI をデプロイ用に使用します。コンテナイメージの解決の詳細については、「[コンテナイメージの解決](deployment-type-ecs.md#deployment-container-image-stability)」を参照してください。
### メモリ
`memory`
タイプ: 整数
必須: いいえ
コンテナに適用されるメモリの量 (MiB 単位)。コンテナは、ここで指定したメモリを超えようとすると、強制終了されます。タスク内のすべてのコンテナ用に予約されるメモリの合計量は、タスクの `memory` 値より小さくする必要があります (指定されている場合)。このパラメータは docker create-container コマンドの `Memory` にマッピングされ、`--memory` オプションは docker run にマッピングされます。
Docker デーモン 20.10.0 以降によって、コンテナ用として 6 MiB 以上のメモリが予約されます。従って、このコンテナに対しては 6 MiB 未満のメモリは指定しないようにします。
Docker デーモン 19.03.13-ce 以降では、コンテナ用として 4 MiB 以上のメモリが予約されます。このため、このコンテナ用には 4 MiB 未満のメモリを指定しないようにします。
リソースの使用率を最大化することを目的に、特定のインスタンスタイプにおいて、タスクにできるだけ多くのメモリを提供する場合には、「[Amazon ECS Linux コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。
`memoryReservation`
タイプ: 整数
必須: いいえ
コンテナ用に予約するメモリのソフト制限 (MiB 単位)。システムメモリに競合がある場合、Docker はコンテナのメモリ量をこのソフト制限値内に維持しようとします。ただし、コンテナは必要に応じてより多くのメモリを使用することができます。コンテナは、`memory` パラメーターで指定されたハード制限 (該当する場合) またはコンテナインスタンス上の利用可能なすべてのメモリのいずれか早く達する方まで使用できます。このパラメータは docker create-container コマンドの `MemoryReservation` にマッピングされ、`--memory-reservation` オプションは docker run にマッピングされます。
タスクレベルでメモリ値を指定しない場合、コンテナ定義で `memory` または `memoryReservation` の一方または両方に 0 以外の整数を指定する必要があります。両方を指定する場合、`memory` は `memoryReservation` より大きいことが必要です。`memoryReservation` を指定する場合、コンテナが配置されているコンテナインスタンスで使用可能なメモリリソース量から、上記の値が減算されます。それ以外の場合は、`memory` の値が使用されます。
例えば、コンテナが通常 128 MiB のメモリを使用しているが、短期間にメモリが 256 MiB にバーストする場合があるとします。128 MiB の `memoryReservation` と 300 MiB の `memory` ハード制限を設定できます。この設定では、コンテナが、コンテナインスタンスの残りのリソースから 128 MiB のメモリのみを予約できます。同時に、この構成により、コンテナは必要に応じてより多くのメモリ リソースを使用できるようになります。
Docker デーモン 20.10.0 以降によって、コンテナ用として 6 MiB 以上のメモリが予約されます。従って、このコンテナに対しては 6 MiB 未満のメモリは指定しないようにします。
Docker デーモン 19.03.13-ce 以降では、コンテナ用として 4 MiB 以上のメモリが予約されます。このため、このコンテナ用には 4 MiB 未満のメモリを指定しないようにします。
リソースの使用率を最大化することを目的に、特定のインスタンスタイプにおいて、タスクにできるだけ多くのメモリを提供する場合には、「[Amazon ECS Linux コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。
### CPU
`cpu`
タイプ: 整数
必須: いいえ
コンテナ用に予約されている `cpu` ユニットの数。このパラメータは docker create-container コマンドの `CpuShares` にマッピングされ、`--cpu-shares` オプションは docker run にマッピングされます。
EC2 キャパシティプロバイダーを使用するタスクでは、このフィールドはオプションです。その場合、タスク内のすべてのコンテナ用に予約される CPU の合計量が、タスクレベルの `cpu` の値を下回ることが唯一の要件となります。
[[Amazon EC2 インスタンス](https://aws.amazon.com/ec2/instance-types/)] 詳細ページのインスタンスタイプに一覧表示されている vCPU 数に 1,024 を乗算して、EC2 インスタンスタイプごとに使用可能な CPU ユニットの数を判断できます。
Linux コンテナは、割り当てられた CPU ユニットと同じ比率を使用して、割り当てられていない CPU ユニットをコンテナインスタンス上の他コンテナと共有します。例えば、単一コンテナタスクを単一コアインスタンスタイプで実行する場合、そのコンテナ用に 512 個の CPU ユニットを指定しており、そのタスクがコンテナインスタンスで実行される唯一のタスクであると、そのコンテナは 1,024 個の CPU ユニットすべてをいつでも使用できます。ただし、そのコンテナインスタンスで同じタスクの別のコピーを起動した場合、各タスクについて、必要に応じて最低で 512 CPU ユニットが保証されます。さらに、各コンテナは他のコンテナが使用していなければ、より高い CPU 使用率にフロートする可能性があります。両方のタスクが常に 100% アクティブであった場合、512 CPU ユニットに制限されます。
Linux コンテナインスタンスでは、コンテナインスタンス上の Docker デーモンは、CPU 値を使用して、実行中のコンテナに対する相対 CPU 配分比率を計算します。詳細については、Docker ドキュメントの「[CPU 配分の制約](https://docs.docker.com/engine/reference/run/#cpu-share-constraint)」を参照してください。Linux kernel が許可する CPU の有効な最小共有値は 2 です。ただし、CPU のパラメータは必要なく、コンテナ定義で 2 以下の CPU 値を使用できます。CPU 値が 2 未満の場合 (null を含む)、動作は Amazon ECS コンテナエージェントのバージョンによって異なります。
+ **エージェントのバージョンが 1.1.0 以下である:** Null と 0 の CPU 値は Docker に 0 として渡され、Docker はそれを 1,024 個の CPU 配分に変換します。1 の CPU 値は Docker に 1 として渡され、Linux カーネルはそれを 2 個の CPU 配分に変換します。
+ **エージェントのバージョンが 1.2.0 以上である:** Null、0、1 の CPU 値は Docker に 2 として渡されます。
Windows コンテナインスタンスでは、CPU 制限は絶対制限またはクォータとして適用されます。Windows コンテナはタスク定義で指定された一定量の CPU にのみアクセスします。ヌルまたはゼロの CPU 値は `0` として Docker に渡され、これを Windows は 1 つの CPU の 1％ として解釈します。
### ポートマッピング
`portMappings`
タイプ: オブジェクト配列
必須: いいえ
ポートマッピングは、コンテナのネットワークポートを外部に公開します。これは、クライアントがアプリケーションにアクセスすることを可能にします。これは、同じタスク内にあるコンテナ間の通信にも使用されます。
`awsvpc` ネットワークモードを使用するタスク定義では、`containerPort` のみを指定します。`hostPort` は常に無視され、コンテナポートはホスト上の番号が大きいランダムなポートに自動的にマップされます。
このパラメータのほとんどのフィールド (`containerPort`、`hostPort`、`protocol` を含む) は docker create-container コマンドの `PortBindings` にマッピングされ、`--publish` オプションは docker run にマッピングされます。タスク定義でネットワークモードを `host` に設定している場合、ホストポートは未定義とするか、ポートマッピングのコンテナポートと一致させる必要があります。
タスクが `RUNNING` ステータスに達すると、手動および自動で割り当てられたホストとコンテナポートが次の場所で表示されます:
+ コンソール: 指定されたタスクのコンテナ詳細の [**Network Bindings**] セクション。
+ AWS CLI: `networkBindings` コマンド出力の **describe-tasks** セクション。
+ API: `DescribeTasks` レスポンス。
+ メタデータ: タスクメタデータのエンドポイント。
`appProtocol`
タイプ: 文字列
必須: いいえ
ポートマッピングに使用されるアプリケーションプロトコル。このパラメータは Service Connect にのみ適用されます。アプリケーションが使用するプロトコルと一貫性を持つように、このパラメータを設定することをお勧めします。このパラメータを設定すると、Amazon ECS はサーバー コネクト プロキシにプロトコル固有の接続処理を追加します。このパラメータを設定すると、Amazon ECS は Amazon ECS コンソールと CloudWatch にプロトコル固有のテレメトリを追加します。
このパラメータ値を設定しないと、TCP が使用されます。ただし、Amazon ECS では、TCP 用のプロトコル固有のテレメトリーは追加されません。
詳細については、「[Service Connect を使用して Amazon ECS サービスを短縮名で接続する](service-connect.md)」を参照してください。
有効なプロトコル値: `"HTTP" | "HTTP2" | "GRPC" `
`containerPort`
タイプ: 整数
必須: はい (`portMappings` を使用する場合)
ユーザーが指定したホストポートまたは自動的に割り当てられたホストポートにバインドされるコンテナポートの番号。
`awsvpc` ネットワークモードを使用するタスクの場合は、`containerPort` を使用して公開ポートを指定します。
`containerPortRange`
タイプ: 文字列
必須: いいえ
動的にマッピングされたホストポート範囲にバインドされるコンテナのポート番号の範囲。
このパラメータは、`register-task-definition` API を使用してのみ設定できます。このオプションは、`portMappings` パラメータで使用できます。詳細については、「*AWS Command Line Interface リファレンス*」の「[register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html)」を参照してください。
`containerPortRange` を指定するときは、以下のルールが適用されます。
+ `awsvpc` ネットワークモードを使用する必要があります。
+ コンテナインスタンスには、少なくともコンテナエージェントのバージョン 1.67.0 と `ecs-init` パッケージのバージョン 1.67.0-1 が必要です。
+ 各コンテナにつき、最大 100 のポートレンジを指定できます。
+ `hostPortRange` は指定しません。`hostPortRange` の値は次のように設定されます。
+ `awsvpc` ネットワークモードのタスク内のコンテナでは、`hostPort` は `containerPort` と同じ値に設定されます。これは静的マッピング戦略です。
+ `containerPortRange` の有効な値は 1～65535 です。
+ 1 つのポートは、コンテナごとに 1 つのポートマッピングにのみ含められます。
+ 重複するポート範囲は指定できません。
+ 範囲内の最初のポートは、最後のポートよりも小さくなければなりません。
+ Docker では、ポートの数が多い場合は、Docker デーモン設定ファイルの docker-proxy をオフにすることをお勧めします。
詳細については、GitHub の [Issue \$111185](https://github.com/moby/moby/issues/11185) を参照してください。
Docker デーモン設定ファイルの docker-proxy をオフにする方法については、*Amazon ECS 開発者ガイド*の「[Docker デーモン](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon)」を参照してください。
[DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) を呼び出すと、コンテナポートにバインドされているホストポートである `hostPortRange` を表示できます。
ポート範囲は、EventBridge に送信される Amazon ECS タスクイベントに含まれません。詳細については、「[EventBridge を使用して Amazon ECS エラーへの対応を自動化する](cloudwatch_event_stream.md)」を参照してください。
`hostPortRange`
タイプ: 文字列
必須: いいえ
ネットワークバインディングで使用されるホストのポート番号範囲。これは Docker によって割り当てられ、Amazon ECS エージェントによって配信されます。
`hostPort`
タイプ: 整数
必須: いいえ
コンテナ用に予約するコンテナインスタンスのポート番号。
`hostPort` は、空白のままにするか、`containerPort` と同じ値にできます。
Docker バージョン 1.6.0 以降のデフォルトの一時ポート範囲は、インスタンスの `/proc/sys/net/ipv4/ip_local_port_range` にリストされています。このカーネルパラメータが使用できない場合、`49153–65535` から始まるデフォルトのエフェメラルポート範囲が使用されます。エフェメラルポート範囲では、ホストポートを指定しないでください。これらの範囲は自動割り当て用に予約済みです。一般的に、`32768` より小さい番号のポートは一時ポート範囲に含まれません。
デフォルトの予約済みポートは、SSH 用の `22`、Docker ポートの `2375` および `2376`、Amazon ECS コンテナエージェントポートの `51678-51680` です。実行中のタスクに対して以前にユーザーが指定したホストポートも、タスクの実行中に予約されます。タスクが停止すると、ホストポートはリリースされます。現在の予約済みポートは、**describe-container-instances** 出力の `remainingResources` に表示されます。コンテナインスタンスには、デフォルトの予約済みポートを含めて、一度に最大 100 個の予約済みポートを割り当てられます。自動的に割り当てられるポートは、この 100 個の予約済みポートクォータにはカウントされません。
`name`
タイプ: 文字列
必須: いいえ。サービスに Service Connect および VPC Lattice を設定する場合は必要です。
ポートマッピングに使用される名前。このパラメータは Service Connect および VPC Lattice にのみ適用されます。このパラメータは、サービスの Service Connect および VPC Lattice 設定で使用する名前です。
詳細については、「[Service Connect を使用して Amazon ECS サービスを短縮名で接続する](service-connect.md)」を参照してください。
次の例では、Service Connect および VPC Lattice の 2 つの必須フィールドが使用されています。
```
"portMappings": [
{
"name": string,
"containerPort": integer
}
]
```
`protocol`
タイプ: 文字列
必須: いいえ
ポートマッピングに使用されるプロトコル。有効な値は、`tcp` および `udp` です。デフォルト: `tcp`。
`tcp` は Service Connect でのみサポートされます。このフィールドが設定されていない場合は、`tcp` が暗示されることに注意してください。
ホストポートを指定する際は、以下の構文を使用します。
```
"portMappings": [
{
"containerPort": integer,
"hostPort": integer
}
...
]
```
自動割り当てのホストポートが必要な場合は、以下の構文を使用します。
```
"portMappings": [
{
"containerPort": integer
}
...
]
```
### プライベートリポジトリの認証情報
`repositoryCredentials`
タイプ: [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) オブジェクト
必須: いいえ
プライベートレジストリ認証用のリポジトリ認証情報。
詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。
`credentialsParameter`
タイプ: 文字列
必須: はい (`repositoryCredentials` を使用する場合)
プライベートリポジトリの認証情報が含まれているシークレットの Amazon リソースネーム (ARN)。
詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。
Amazon ECS API、AWS CLI、または AWS SDK を使用する場合、起動するタスクと同じリージョンにシークレットが存在する場合は、シークレットの完全な ARN または名前のどちらも使用できます。AWS マネジメントコンソール を使用する場合は、シークレットの完全な ARN を指定する必要があります。
必要なパラメータが含まれるタスク定義のスニペットを、以下に示します。
```
"containerDefinitions": [
{
"image": "private-repo/private-image",
"repositoryCredentials": {
"credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
}
}
]
```
### Essential
`essential`
タイプ: ブール値
必須: いいえ
コンテナの `essential` パラメータが `true` とマークされている場合、そのコンテナが何らかの理由で失敗または停止すると、タスクに含まれる他のすべてのコンテナは停止されます。コンテナの `essential` パラメータが `false` とマークされている場合、その失敗はタスクに含まれる残りのコンテナに影響を与えません。このパラメータを省略した場合、コンテナは必須と見なされます。
すべてのタスクには少なくとも 1 つの必須コンテナが必要です。アプリケーションが複数のコンテナで構成される場合は、用途が共通するコンテナをコンポーネントにグループ化し、それらのコンポーネントを複数のタスク定義に分ける必要があります。詳細については、「[Amazon ECS 用のアプリケーションの構築](application_architecture.md)」を参照してください。
### エントリポイント
`entryPoint`
タイプ: 文字列配列
必須: いいえ
コンテナに渡されるエントリポイント。このパラメータは docker create-container コマンドの `Entrypoint` にマッピングされ、`--entrypoint` オプションは docker run にマッピングされます。
```
"entryPoint": ["string", ...]
```
### コマンド
`command`
タイプ: 文字列配列
必須: いいえ
コンテナに渡されるコマンド。このパラメータは docker create-container コマンドの `Cmd` にマッピングされ、`COMMAND` パラメータは docker run にマッピングされます。複数の引数がある場合、各引数は配列において区切られた文字列である必要があります。
```
"command": ["string", ...]
```
### 作業ディレクトリパス
`workingDirectory`
タイプ: 文字列
必須: いいえ
コマンドを実行するコンテナ内の作業ディレクトリ。このパラメータは docker create-container コマンドの `WorkingDir` にマッピングされ、`--workdir` オプションは docker run にマッピングされます。
### 詳細コンテナ定義パラメータ
以下のコンテナ定義用の詳細パラメータは、Amazon ECS コンテナインスタンスでのコンテナの起動に使用する docker run コマンドの拡張機能を追加します。
**Topics**
+ [再起動ポリシー](#container_definition_restart_policy-managed-instances)
+ [ヘルスチェック](#container_definition_healthcheck-managed-instances)
+ [環境](#container_definition_environment-managed-instances)
+ [セキュリティ](#container_definition_security-managed-instances)
+ [ネットワーク設定](#container_definition_network-managed-instances)
+ [ストレージとログ記録](#container_definition_storage-managed-instances)
+ [リソースの要件](#container_definition_resourcerequirements-managed-instances)
+ [[コンテナのタイムアウト]](#container_definition_timeout-managed-instances)
+ [コンテナの依存関係](#container_definition_dependency-managed-instances)
+ [システムコントロール](#container_definition_systemcontrols-managed-instances)
+ [インタラクティブ](#container_definition_interactive-managed-instances)
+ [擬似ターミナル](#container_definition_pseudoterminal-managed-instances)
#### 再起動ポリシー
`restartPolicy`
コンテナ再起動ポリシーと関連する設定パラメータ。コンテナの再起動ポリシーを設定すると、Amazon ECS はタスクを置き換えることなくコンテナを再起動できます。詳細については、「[コンテナ再起動ポリシーを使用して Amazon ECS タスク内の個々のコンテナを再起動する](container-restart-policy.md)」を参照してください。
`enabled`
タイプ: ブール値
必須: はい
コンテナに対して再起動ポリシーを有効にするかどうかを指定します。
`ignoredExitCodes`
タイプ: 整数配列
必須: いいえ
Amazon ECS が無視し、再起動を試みない終了コードのリスト。最大 50 個のコンテナ終了コードを指定できます。デフォルトでは、Amazon ECS はいずれの終了コードも無視しません。
`restartAttemptPeriod`
タイプ: 整数
必須: いいえ
再起動を試みる前にコンテナが実行する必要がある時間 (秒単位）。コンテナを再起動できるのは、`restartAttemptPeriod` 秒に 1 回のみです。コンテナがこの期間実行できずに早く終了した場合、コンテナは再起動されません。最小の `restartAttemptPeriod` は 60 秒、最大の `restartAttemptPeriod` は 1,800 秒を指定できます。デフォルトでは、コンテナは再起動の前に 300 秒間実行する必要があります。
#### ヘルスチェック
`healthCheck`
コンテナに対するヘルスチェックのコマンドと、コンテナのための関連する設定パラメータです。詳細については、「[コンテナのヘルスチェックを使用して Amazon ECS タスク状態を判定する](healthcheck.md)」を参照してください。
`command`
正常状態かどうかを決定するために、コンテナが実行するコマンドが格納された文字列配列。この文字列配列の先頭には、コマンド引数を直接実行するための `CMD`、またはコンテナのデフォルトシェルでコマンドを実行するための `CMD-SHELL` を付加できます。これらのいずれも指定しない場合は `CMD` が使用されます。
AWS マネジメントコンソール にタスク定義を登録する場合は、カンマで区切ったコマンドリストを使用してください。これらのコマンドは、タスク定義が作成された後に文字列に変換されます。ヘルスチェックに対する入力の例を次に示します。
```
CMD-SHELL, curl -f http://localhost/ || exit 1
```
AWS マネジメントコンソール JSON パネル、AWS CLI、または API を使用してタスク定義を登録するときは、コマンドのリストを角かっこで囲みます。ヘルスチェックに対する入力の例を次に示します。
```
[ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ]
```
`stderr` が出力されない終了コード 0 は成功を示し、0 以外の終了コードは失敗を示します。
`interval`
各ヘルスチェック間の時間間隔 (秒単位)。5 〜 300 秒を指定できます。デフォルトの値は 30 秒です。
`timeout`
成功まで待機しているヘルスチェックが、失敗したと見なされるまでの期間 (秒単位) です。2 〜 60 秒を指定できます。デフォルト値は 5 秒です。
`retries`
コンテナが異常と見なされるまでに、失敗したヘルスチェックを再試行する回数です。1〜10 回を指定できます。デフォルト値は 3 回の再試行です。
`startPeriod`
失敗したヘルスチェックの再試行が最大回数に達する前に、コンテナにブートストラップための時間を提供するオプションの猶予期間です。0～300 秒の値を指定できます。デフォルトでは、`startPeriod` は無効となっています。
ヘルスチェックが `startPeriod` 内で成功した場合、コンテナは正常であるとみなされ、その後の失敗は最大再試行回数にカウントされます。
#### 環境
`cpu`
タイプ: 整数
必須: いいえ
Amazon ECS コンテナエージェントがコンテナ用に予約した `cpu` ユニットの数。Linux では、このパラメータは「[Create a container](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate)」セクションの `CpuShares` にマッピングされます。
このフィールドは、Amazon ECS マネージドインスタンスで実行されるタスクではオプションです。タスク内のすべてのコンテナのために予約されている CPU の合計量は、タスクレベルの `cpu` 値以上にはできません。
Linux コンテナは、割り当てられた CPU ユニットと同じ比率を使用して、割り当てられていない CPU ユニットをコンテナインスタンス上の他コンテナと共有します。例えば、そのコンテナ用に 512 個の CPU ユニットが指定された単一コアインスタンスタイプで、唯一のコンテナタスクを実行するとします。さらに、そのタスクはコンテナインスタンスで実行される唯一のタスクです。この場合のコンテナは、1,024 個の CPU ユニット配分を任意のタイミングで使用できます。一方、そのコンテナインスタンスで同じタスクのコピーを別途起動したと仮定します。各タスクには、必要に応じて少なくとも 512 個の CPU ユニットが保証されます。同様に、その他のコンテナが残りの CPU を使用していない場合、各コンテナは CPU 使用率を高められます。ただし、両方のタスクが常に 100% アクティブである場合、使用できるのは 512 CPU ユニットに制限されます。
Linux コンテナインスタンスでは、コンテナインスタンス上の Docker デーモンは、CPU 値を使用して、実行中のコンテナに対する相対 CPU 配分比率を計算します。Linux カーネルが許可する最小の有効な CPU 共有値は 2 で、Linux カーネルが許可する最大の有効な CPU 共有値は 262,144 です。ただし、CPU のパラメータは必須ではなく、コンテナ定義では 2 未満の CPU 値および 262144 より大きな CPU 値を使用できます。CPU 値が 2 未満 (null を含む) および 262144 より大きな値である場合、動作は Amazon ECS コンテナエージェントのバージョンによって異なります。
その他の例については、「[Amazon ECS で CPU およびメモリリソースの管理方法](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/)」を参照してください。
`gpu`
タイプ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) オブジェクト
必須: いいえ
Amazon ECS コンテナエージェントがコンテナ用に予約した物理 `GPUs` の数。タスク内でコンテナ用に予約されているすべての GPU の数は、タスクが起動されたコンテナインスタンスで使用できる GPU の数を超えることはできません。詳細については、「[GPU ワークロード向けの Amazon ECS タスク定義](ecs-gpu.md)」を参照してください。
`Elastic Inference accelerator`
このパラメータは、Amazon ECS マネージドインスタンスがホストするコンテナではサポートされていません。
タイプ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) オブジェクト
必須: いいえ
`InferenceAccelerator` タイプでは、`value` はタスク定義で指定される `InferenceAccelerator` の `deviceName` と一致します。詳細については、「[Elastic Inference アクセラレーター名 (廃止)](task_definition_parameters.md#elastic-Inference-accelerator)」を参照してください。
`essential`
タイプ: ブール値
必須: いいえ
コンテナの `essential` パラメーターが `true` としてマークされており、そのコンテナが何らかの理由で失敗するか停止するとします。その後、タスクの一部である他のすべてのコンテナが停止されます。コンテナの `essential` パラメータを `false` にマークしておくと、そのコンテナ失敗はタスク内にある残りのコンテナに影響を与えません。このパラメータを省略した場合、コンテナは必須と見なされます。
すべてのタスクには少なくとも 1 つの必須コンテナが必要です。複数のコンテナで構成されるアプリケーションがあるとします。次に、共通の目的で使用されるコンテナをコンポーネントにグループ化し、さまざまなコンポーネントを複数のタスク定義に分離します。詳細については、「[Amazon ECS 用のアプリケーションの構築](application_architecture.md)」を参照してください。
```
"essential": true|false
```
`entryPoint`
初期のバージョンの Amazon ECS コンテナエージェントは、`entryPoint` パラメータを正しく処理しません。`entryPoint` の使用時に問題が発生する場合は、コンテナエージェントを更新するか、代わりに `command` 配列項目としてコマンドと引数を入力します。
タイプ: 文字列配列
必須: いいえ
コンテナに渡されるエントリポイント。
```
"entryPoint": ["string", ...]
```
`command`
タイプ: 文字列配列
必須: いいえ
コンテナに渡されるコマンド。このパラメータは create-container コマンドの `Cmd` にマッピングされ、 `COMMAND` パラメータは docker run にマッピングされます。複数の引数がある場合、各引数は配列内で、区切られた文字列により指定する必要があります。
```
"command": ["string", ...]
```
`workingDirectory`
タイプ: 文字列
必須: いいえ
コマンドを実行するコンテナ内の作業ディレクトリ。このパラメータは、[Docker Remote API](https://docs.docker.com/reference/api/engine/version/v1.38/) の [コンテナの作成](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) セクションにある `WorkingDir` にマッピングされ、`--workdir` オプションは [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) にマッピングされます。
```
"workingDirectory": "string"
```
`environmentFiles`
タイプ: オブジェクト配列
必須: いいえ
コンテナに渡す環境変数が含まれるファイルのリスト。このパラメータは docker run コマンドの `--env-file` オプションにマッピングされます。
最大 10 個の環境ファイルを指定できます。ファイルには、ファイル拡張子 `.env` が必要です。環境ファイルの各行には、`VARIABLE=VALUE` 形式で環境変数が含まれています。`#` で始まる行はコメントとして扱われ、無視されます。
コンテナ定義に個別の環境変数が指定されている場合は、環境ファイルに含まれる変数よりも優先されます。同じ変数を含む複数の環境ファイルが指定されている場合、それらのファイルは上から下に処理されます。一意の変数名を使用することをお勧めします。詳細については、「[個々の環境変数を Amazon ECS コンテナに渡す](taskdef-envfiles.md)」を参照してください。
`value`
タイプ: 文字列
必須: はい
環境変数ファイルを含む Amazon S3 オブジェクトの Amazon リソースネーム (ARN)。
`type`
タイプ: 文字列
必須: はい
使用するファイルのタイプ。`s3` はサポートされる唯一の値です。
`environment`
タイプ: オブジェクト配列
必須: いいえ
コンテナに渡す環境変数。このパラメータは docker create-container コマンドの `Env` にマッピングされ、`--env` オプションは docker run コマンドにマッピングされます。
認証情報データなどの機密情報にプレーンテキストの環境変数を使用することはお勧めしません。
`name`
タイプ: 文字列
必須: はい (`environment` を使用する場合)
環境変数の名前。
`value`
タイプ: 文字列
必須: はい (`environment` を使用する場合)
環境変数の値。
```
"environment" : [
{ "name" : "string", "value" : "string" },
{ "name" : "string", "value" : "string" }
]
```
`secrets`
タイプ: オブジェクト配列
必須: いいえ
コンテナに公開するシークレットを表すオブジェクトです。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
`name`
タイプ: 文字列
必須: はい
コンテナの環境変数として設定する値。
`valueFrom`
タイプ: 文字列
必須: はい
コンテナに公開するシークレット。サポートされている値は、AWS Secrets Manager シークレットの完全な Amazon リソースネーム (ARN)、または AWS Systems Manager Parameter Store 内のパラメータの完全な ARN のいずれかです。
起動するタスクと同じ AWS リージョン に Systems Manager パラメータストアのパラメータまたは Secrets Manager のパラメータが存在する場合は、シークレットの完全な ARN または名前のいずれかを使用できます。パラメータが別のリージョンに存在する場合は、完全な ARN を指定する必要があります。
```
"secrets": [
{
"name": "environment_variable_name",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
}
]
```
#### セキュリティ
`privileged`
タイプ: ブール値
必須: いいえ
このパラメータが `true` のとき、コンテナには、ホストコンテナインスタンスに対する昇格されたアクセス権限 (`root` ユーザーと同様) が付与されます。このパラメータは docker create-container コマンドの `Privileged` にマッピングされ、`--privileged` オプションは docker run にマッピングされます。
`user`
タイプ: 文字列
必須: いいえ
コンテナ内で使用するユーザー。このパラメータは docker create-container コマンドの `User` にマッピングされ、`--user` オプションは docker run にマッピングされます。
`host` ネットワークモードを使用してタスクを実行する場合、ルートユーザー (UID 0) を使用してコンテナを実行しないでください。セキュリティを強化するために、ルート以外のユーザーを使用することをお勧めします。
以下の形式を使用して、`user` を指定できます。UID または GID を指定する場合は、正の整数として指定する必要があります。
+ `user`
+ `user:group`
+ `uid`
+ `uid:gid`
+ `user:gid`
+ `uid:group`
`readonlyRootFilesystem`
タイプ: ブール値
必須: いいえ
このパラメータが `true` のとき、コンテナは読み取り専用のルートファイルシステムを付与されます。このパラメータは docker create-container コマンドの `ReadonlyRootfs` にマッピングされ、`--read-only` オプションは docker run にマッピングされます。
`dockerSecurityOptions`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: 文字列配列
必須: いいえ
SELinux および AppArmor のマルチレベルセキュリティシステム向けのカスタムラベルに提供する文字列のリスト。このフィールドは、Fargate を使用するタスク内のコンテナには無効です。
`ulimits`
タイプ: [Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) オブジェクトの配列
必須: いいえ
コンテナで設定する `ulimits` のリスト。タスク定義で ulimit 値を指定すると、Docker によって設定されたデフォルト値が上書きされます。このパラメータは docker create-container コマンドの `Ulimits` にマッピングされ、`--ulimit` オプションは docker run にマッピングされます。有効な命名値は [Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) データ型で表示されます。
Fargate でホストされる Amazon ECS タスクは、オペレーションシステムで設定されたデフォルトのリソース制限値を使用します。ただし、Fargate がオーバーライドする `nofile` リソース制限パラメータを除きます。`nofile` リソース制限は、コンテナが使用できるオープンファイルの数の制限を設定します。デフォルトの `nofile` ソフト制限は `1024` で、ハード制限は `65535` です。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.18 以上を使用する必要があります。コンテナインスタンスの Docker Remote API のバージョンを確認するには、コンテナインスタンスにログインし、`sudo docker version --format '{{.Server.APIVersion}}'` コマンドを実行します。
`dockerLabels`
タイプ: 文字列間のマッピング
必須: いいえ
コンテナに追加するラベルのキー/値マップ。このパラメータは docker create-container コマンドの `Labels` にマッピングされ、`--label` オプションは docker run にマッピングされます。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.18 以上を使用する必要があります。
```
"dockerLabels": {"string": "string"
...}
```
#### ネットワーク設定
`disableNetworking`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: ブール値
必須: いいえ
このパラメータが true のとき、ネットワークはコンテナ内でオフになります。
デフォルト: `false`。
```
"disableNetworking": true|false
```
`links`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: 文字列配列
必須: いいえ
`link` パラメータでは、コンテナがポートマッピングを必要とせずに互いに通信することを許可します。このパラメータは、タスク定義のネットワークモードが `bridge` に設定されている場合にのみサポートされます。`name:internalName` コンストラクトは Docker リンクの `name:alias` に似ています。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコアを使用できます。
同じコンテナインスタンスに配置されたコンテナ同士は、リンクやホストポートマッピングを必要とせずに、互いに通信する場合があります。コンテナインスタンスでのネットワークの分離は、セキュリティグループと VPC 設定によって制御されます。
```
"links": ["name:internalName", ...]
```
`hostname`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: 文字列
必須: いいえ
コンテナに使用するホスト名。このパラメータは docker create-container の `Hostname` にマッピングされ、`--hostname` オプションは docker run にマッピングされます。
```
"hostname": "string"
```
`dnsServers`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: 文字列配列
必須: いいえ
コンテナに提示する DNS サーバーのリスト。
```
"dnsServers": ["string", ...]
```
`extraHosts`
このパラメータは、`awsvpc` ネットワークモードを使用するタスクではサポートされていません。
タイプ: オブジェクト配列
必須: いいえ
コンテナ上の `/etc/hosts` ファイルに追加する、ホスト名と IP アドレスのマッピングリスト。
このパラメータは docker create-container コマンドの `ExtraHosts` にマッピングされ、`--add-host` オプションは docker run にマッピングされます。
```
"extraHosts": [
{
"hostname": "string",
"ipAddress": "string"
}
...
]
```
`hostname`
タイプ: 文字列
必須: はい (`extraHosts` を使用する場合)
`/etc/hosts` エントリで使用するホスト名。
`ipAddress`
タイプ: 文字列
必須: はい (`extraHosts` を使用する場合)
`/etc/hosts` エントリで使用する IP アドレス。
#### ストレージとログ記録
`readonlyRootFilesystem`
タイプ: ブール値
必須: いいえ
このパラメータが true のとき、コンテナはそのルートファイルシステムへの読み取り専用アクセスを許可されます。このパラメータは docker create-container コマンドの `ReadonlyRootfs` にマッピングされ、`--read-only` オプションは docker run にマッピングされます。
デフォルト: `false`。
```
"readonlyRootFilesystem": true|false
```
`mountPoints`
タイプ: オブジェクト配列
必須: いいえ
コンテナでのデータボリュームのマウントポイント。このパラメータは creat-container Docker API の `Volumes` にマッピングされ、docker run の `--volume` オプションにマッピングされます。
Windows コンテナは `$env:ProgramData` と同じドライブに全部のディレクトリをマウントできます。Windows コンテナは、別のドライブにディレクトリをマウントすることはできません。また、マウントポイントは複数のドライブにまたがることはできません。Amazon EBS ボリュームを Amazon ECS タスクに直接アタッチするには、マウントポイントを指定する必要があります。
`sourceVolume`
タイプ: 文字列
必須: はい (`mountPoints` を使用する場合)
マウントするボリュームの名前。
`containerPath`
タイプ: 文字列
必須: はい (`mountPoints` を使用する場合)
ボリュームをマウントするコンテナ内のパス。
`readOnly`
タイプ: ブール値
必須: いいえ
この値が `true` の場合、コンテナはボリュームへの読み取り専用アクセスを許可されます。この値が `false` の場合、コンテナはボリュームに書き込むことができます。デフォルト値は `false` です。
Windows オペレーティングシステムを実行している EC2 インスタンスで実行されるタスクの場合、 値をデフォルト の `false` のままにします。
`volumesFrom`
タイプ: オブジェクト配列
必須: いいえ
別コンテナからマウントするデータボリューム。このパラメータは docker create-container コマンドの `VolumesFrom` にマッピングされ、`--volumes-from` オプションは docker run にマッピングされます。
`sourceContainer`
タイプ: 文字列
必須: はい (`volumesFrom` を使用する場合)
ボリュームのマウント元のコンテナの名前。
`readOnly`
タイプ: ブール値
必須: いいえ
この値が `true` の場合、コンテナはボリュームへの読み取り専用アクセスを許可されます。この値が `false` の場合、コンテナはボリュームに書き込むことができます。デフォルト値は `false` です。
```
"volumesFrom": [
{
"sourceContainer": "string",
"readOnly": true|false
}
]
```
`logConfiguration`
タイプ: [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) オブジェクト
必須: いいえ
コンテナに対するログ構成の仕様です。
ログ設定を使用したタスク定義の例については、「[Amazon ECS のタスク定義の例](example_task_definitions.md)」を参照してください。
このパラメータは docker create-container コマンドの `LogConfig` にマッピングされ、`--log-driver` オプションは docker run にマッピングされます。デフォルトでは、コンテナは Docker デーモンで使用されるのと同じロギングドライバーを使用します。ただし、コンテナ定義の中で、このパラメータによりログドライバーを指定することで、Docker デーモンとは異なるログドライバーをコンテナに使用させることも可能です。コンテナに異なるロギングドライバーを使用するには、コンテナインスタンス (またはリモートログ記録オプションの別のログサーバー) でログシステムを適切に設定する必要があります。
コンテナのログ設定を指定する際には、以下の点に注意してください。
+ 現在、Amazon ECS では Docker デーモンに使用可能なログドライバーがいくつかサポートされています。
+ このパラメータを使用するには、コンテナインスタンスで Docker Remote API のバージョン 1.18 以降が必要です。
```
"logConfiguration": {
"logDriver": "awslogs",""splunk", "awsfirelens",
"options": {"string": "string"
...},
"secretOptions": [{
"name": "string",
"valueFrom": "string"
}]
}
```
`logDriver`
タイプ: 文字列
有効な値: `"awslogs","splunk","awsfirelens"`
必須: はい (`logConfiguration` を使用する場合)
コンテナに使用するログドライバー。デフォルトでは、上記の有効な値は Amazon ECS コンテナエージェントが通信できるログドライバーです。
サポートされているログドライバーは `awslogs`、`splunk`、`awsfirelens` です。
タスク定義で `awslogs` ログドライバーを使用してコンテナログを CloudWatch Logs に送信する方法については、「[Amazon ECS ログを CloudWatch に送信する](using_awslogs.md)」を参照してください。
`awsfirelens` ログドライバーの使用について、詳細は「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。
上記に示されていないカスタムドライバーがある場合、[GitHub で入手できる](https://github.com/aws/amazon-ecs-agent) Amazon ECS コンテナエージェントプロジェクトを fork し、そのドライバーを使用するようにカスタマイズできます。含めたい変更については、プルリクエストを送信することをお勧めします。ただし、現時点では、このソフトウェアの変更されたコピーの実行はサポートされていません。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.18 以上を使用する必要があります。
`options`
タイプ: 文字列間のマッピング
必須: いいえ
ログドライバーに送信する設定オプションの Key-Value マップ。
指定できるオプションは、ログドライバーに応じて異なります。`awslogs` ルーターを使用して Amazon CloudWatch にログをルーティングするときに指定できるオプションには、以下が含まれます。
`awslogs-create-group`
必須: いいえ
ロググループを自動的に作成させるかどうかを指定します。このオプションを指定しない場合、デフォルトは `false` です。
`awslogs-create-group` を使用する前に、IAM ポリシーにはアクセス許可 `logs:CreateLogGroup` が含まれている必要があります。
`awslogs-region`
必須: はい
`awslogs` ログドライバが Docker ログを送信する先の、AWS リージョン を指定します。CloudWatch Logs では、異なるリージョンのクラスターからすべてのログを 1 つのリージョンに送信するように選択できます。これにより、すべてのログを一元的な場所で確認できるようになります。他にも、リージョンごとにそれらを分離して、より細分化することが可能です。このオプションで指定するリージョンに、対象のロググループが存在することを確認してください。
`awslogs-group`
必須: はい
`awslogs` ログドライバーがログストリームを送信する先の、ロググループを指定する必要があります。
`awslogs-stream-prefix`
必須: はい
指定したプレフィックス、コンテナ名、コンテナが属する Amazon ECS タスクの ID にログストリームを関連付けるには、`awslogs-stream-prefix` オプションを使用します。このオプションでプレフィックスを指定した場合、ログストリームの形式は以下のようになります。
```
prefix-name/container-name/ecs-task-id
```
このオプションでプレフィックスを指定しない場合、ログストリームには、コンテナインスタンスの Docker デーモンによって割り当てられたコンテナ ID に基づいた名前が付けられます。Docker コンテナ ID (コンテナインスタンスでのみ使用可能) だけでそのログを送信したコンテナを追跡するのは難しいため、このオプションでプレフィックスを指定することをお勧めします。
Amazon ECS サービスでは、サービス名をプレフィックスとして使用できます。これにより、コンテナが属するサービスへのログストリームと、それを送信したコンテナの名前、そのコンテナが所属するタスクの ID を追跡できます。
Amazon ECS コンソールを使用する際に [Log] ペインにログを表示するためには、ログのストリームプレフィックスを指定する必要があります。
`awslogs-datetime-format`
必須: いいえ
このオプションは、Python `strftime` 形式で複数行起動パターンを定義します。ログメッセージは、パターンに一致する 1 行と、それに続くパターンに一致しない行で構成されます。一致する 1 行とは、ログメッセージ間の区切りです。
この形式を使用する場合のユースケースの例としては、スタックダンプなどの解析された出力があり、これを使用しなければ、複数のエントリに記録されることになります。適切なパターンにより、単一のエントリにキャプチャさせます。
詳細については、[awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format)を参照してください。
`awslogs-datetime-format` と `awslogs-multiline-pattern` オプションの両方を設定することはできません。
複数行のログ記録は、すべてのログメッセージの正規表現の解析とマッチングを実行します。これによりログ記録のパフォーマンスに悪影響が及ぶ可能性があります。
`awslogs-multiline-pattern`
必須: いいえ
このオプションでは、正規表現を使用する複数行起動パターンを定義します。ログメッセージは、パターンに一致する 1 行と、それに続くパターンに一致しない行で構成されます。一致する 1 行とは、ログメッセージ間の区切りです。
詳細については、「[awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern)」を参照してください。
`awslogs-datetime-format` も設定されている場合は、このオプションは無視されます。
`awslogs-datetime-format` と `awslogs-multiline-pattern` オプションの両方を設定することはできません。
複数行のログ記録は、すべてのログメッセージの正規表現の解析とマッチングを実行します。これによりログ記録のパフォーマンスに悪影響が及ぶ可能性があります。
`mode`
必須: いいえ
有効な値: `non-blocking` \$1 `blocking`
このオプションは、コンテナから `awslogs` ログドライバーへのログメッセージの配信モードを定義します。選択した配信モードは、コンテナからンテナーからのログの流れが中断されたときのアプリケーションの可用性に影響します。
`blocking` モードを使用しており、CloudWatch へのログのフローが中断されると、`stdout` ストリームと `stderr` ストリームに書き込むためのコンテナコードからの呼び出しがブロックされます。その結果、アプリケーションのロギングスレッドがブロックされます。これにより、アプリケーションが応答しなくなり、コンテナのヘルスチェックが失敗する可能性があります。
`non-blocking` モードを使用する場合、コンテナのログは代わりに `max-buffer-size` オプションで設定されたメモリ内の中間バッファに保存されます。これにより、ログを CloudWatch に送信できない場合にアプリケーションが応答しなくなるのを防ぎます。サービスの可用性を確保したいが、多少のログ損失があっても問題ない場合は、このモードを使用することをおすすめします。詳細については、「[Preventing log loss with non-blocking mode in the `awslogs` container log driver](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/)」を参照してください。
`max-buffer-size`
必須: いいえ
デフォルト値: `1m`
`non-blocking` モードが使用されている場合、`max-buffer-size` ログオプションは、中間メッセージ用のストレージに使用されるバッファのサイズを制御します。アプリケーションに基づいて、必ず適切なバッファサイズを指定してください。バッファがいっぱいになると、それ以上ログを保存できなくなります。保存できないログは失われます。
`splunk` ログルーターを使用してログをルーティングするには、`splunk-token` と `splunk-url` を指定する必要があります。
ログの保存と分析のための AWS のサービス または AWS Partner Network を送信先としたログのルーティングに `awsfirelens` ログルーターを使用するときは、`log-driver-buffer-limit` オプションを設定して、イベントがログルーターコンテナに送信される前に、メモリでバッファリングされるイベントの数を制限できます。この制限は、スループットが高い場合に発生する可能性がある、Docker 内のバッファのメモリ不足による、潜在的なログ損失の問題を解決するのに役立ちます。詳細については、「[高スループットの Amazon ECS ログの設定](firelens-docker-buffer-limit.md)」を参照してください。
`awsfirelens` を使用してログをルーティングするときに指定できるその他のオプションは、送信先に応じて異なります。Amazon Data Firehose にログをエクスポートするときは、`region` を使用して AWS リージョンを指定し、`delivery_stream` を使用してログストリームの名前を指定することができます。
Amazon Kinesis Data Streams にログをエクスポートするときは、`region` を使用して AWS リージョンを指定し、`stream` を使用してデータストリーム名を指定することができます。
Amazon OpenSearch Service にログをエクスポートするときは、`Name`、`Host` (プロトコルを使用しない OpenSearch Service エンドポイント)、`Port`、`Index`、`Type`、`Aws_auth`、`Aws_region`、`Suppress_Type_Name`、および `tls` といったオプションを指定できます。
Amazon S3 にログをエクスポートするときは、`bucket` オプションを使用してバケットを指定できます。また、`region`、`total_file_size`、`upload_timeout`、および `use_put_object` をオプションとして指定することもできます。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.19 以上を使用する必要があります。
`secretOptions`
タイプ: オブジェクト配列
必須: いいえ
ログ設定に渡すシークレットを示すオブジェクト。ログ構成で使用されるシークレットには、認証トークン、証明書、または暗号化キーを含められます。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
`name`
タイプ: 文字列
必須: はい
コンテナの環境変数として設定する値。
`valueFrom`
タイプ: 文字列
必須: はい
コンテナのログ設定に公開するシークレット。
```
"logConfiguration": {
"logDriver": "splunk",
"options": {
"splunk-url": "https://cloud.splunk.com:8080",
"splunk-token": "...",
"tag": "...",
...
},
"secretOptions": [{
"name": "splunk-token",
"valueFrom": "/ecs/logconfig/splunkcred"
}]
}
```
`firelensConfiguration`
タイプ: [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html) オブジェクト
必須: いいえ
コンテナの FireLens 構成。これは、コンテナログのログルーターの指定と設定に使用されます。詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。
```
{
"firelensConfiguration": {
"type": "fluentd",
"options": {
"KeyName": ""
}
}
}
```
`options`
タイプ: 文字列間のマッピング
必須: いいえ
ログルーターの設定時に使用するオプションの Key-Value マップ。このフィールドはオプションで、カスタム設定ファイルを指定するか、タスク、タスク定義、クラスター、コンテナインスタンスの詳細などのメタデータをログイベントに追加するために使用できます。指定した場合、使用する構文は `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}` です。詳細については、「[Amazon ECS タスク定義の例: FireLens にログをルーティングする](firelens-taskdef.md)」を参照してください。
`type`
タイプ: 文字列
必須: はい
使用するログルーター。有効な値は `fluentd` または `fluentbit` です。
#### リソースの要件
`resourceRequirements`
タイプ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) オブジェクトの配列
必須: いいえ
コンテナに割り当てるリソースのタイプと量。サポートされている唯一のリソースは GPU です。
`type`
タイプ: 文字列
必須: はい
コンテナに割り当てるリソースのタイプ。サポート対象の値は `GPU` です。
`value`
タイプ: 文字列
必須: はい
指定されたリソースタイプの値。
`GPU` タイプを使用する場合、値は Amazon ECS コンテナエージェントがコンテナ用に予約する物理的な `GPUs` の数です。タスク内でコンテナ用に予約されている、すべての GPU の数は、タスクが起動されたコンテナインスタンスで使用できる GPU の数を超えることはできません。
GPU は、Fargate 上で実行するタスクでは使用できません。
#### [コンテナのタイムアウト]
`startTimeout`
タイプ: 整数
必須: いいえ
値の例: `120`
コンテナの依存関係解決の再試行を止めるまでの待機時間 (秒)。
例えば、タスク定義内に 2 つのコンテナを指定するとします。`containerA` は、`COMPLETE`、`SUCCESS`、または `HEALTHY` のいずれかのステータスに到達する `containerB` に依存関係を持ちます。`startTimeout` の値に `containerB` が指定されていて、コンテナが時間内に目標のステータスまで到達しない場合、`containerA` は開始しません。
あるコンテナが依存関係における制限事項を満たさない場合、または制限を満たす前にタイムアウトした場合、Amazon ECS は、依存関係にある他のコンテナの状態も次に遷移させることはしません。
最大値は 600 秒 (10 分) です。
`stopTimeout`
タイプ: 整数
必須: いいえ
値の例: `120`
コンテナが正常に終了しなかった場合にコンテナが強制終了されるまでの待機時間 (秒)。
このパラメータを指定しない場合には、デフォルト値の 30 秒が適用されます。最大値は 86400 秒 (24 時間) です。
#### コンテナの依存関係
`dependsOn`
型: [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) オブジェクトの配列
必須: いいえ
コンテナの起動と停止に定義されている依存関係。コンテナには複数の依存関係を含めることができます。依存関係がコンテナの起動に対して定義されている場合、コンテナの停止の場合、依存関係は逆になります。例については、[コンテナの依存関係](example_task_definitions.md#example_task_definition-containerdependency)を参照してください。
あるコンテナが依存関係における制限事項を満たさない場合、または制限を満たす前にタイムアウトした場合、Amazon ECS は、依存関係にある他のコンテナの状態も次に遷移させることはしません。
このパラメータでは、タスクまたはサービスがプラットフォームバージョン `1.3.0` 以降（Linux）または `1.0.0`（Windows）を使用している必要があります。
```
"dependsOn": [
{
"containerName": "string",
"condition": "string"
}
]
```
`containerName`
タイプ: 文字列
必須: はい
コンテナ名が指定された条件を満たしている必要があります。
`condition`
タイプ: 文字列
必須: はい
コンテナの依存関係の条件です。使用可能な条件とその動作を以下に示します。
+ `START` - この条件は、すぐに現在のリンクとボリュームの動作をエミュレートします。この条件は、他のコンテナの開始を許可する前に、依存コンテナが開始されていることを検証します。
+ `COMPLETE` - この条件は、他のコンテナの開始を許可する前に、依存コンテナの実行が完了 (終了) することを検証します。これは、スクリプトを実行して終了するだけの、重要性の低いコンテナのために便利です。この条件は、必須コンテナには設定できません。
+ `SUCCESS` - この条件は `COMPLETE` と同じですが、コンテナが `zero` ステータスで終了していることも必要です。この条件は、必須コンテナには設定できません。
+ `HEALTHY` — この条件は、他のコンテナの開始を許可する前に、依存コンテナがそのコンテナのヘルスチェックに合格したことを検証します。これには、タスク定義に設定されているヘルスチェックが依存コンテナにある必要があります。タスクの起動時にのみ、この条件が確認されます。
#### システムコントロール
`systemControls`
型: [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) オブジェクト
必須: いいえ
コンテナ内で設定する名前空間カーネルパラメータのリスト。このパラメータは docker create-container コマンドの `Sysctls` にマッピングされ、`--sysctl` オプションは docker run にマッピングされます。例えば、接続をより長く維持するように `net.ipv4.tcp_keepalive_time` 設定を構成できます。
`awsvpc` または `host` ネットワークモードも使用する単一のタスクで、複数のコンテナに対してネットワーク関連の `systemControls` パラメータを指定することは推奨されません。これを行うと、次のような欠点があります。
+ `systemControls` をいずれかのコンテナ用に設定した場合、タスク内のすべてのコンテナに適用されます。単一のタスクの複数のコンテナに対して異なる `systemControls` を設定すると、最後に開始されたコンテナによって、有効になる `systemControls` が決定します。
タスク内でコンテナに使用するため IPC リソース名前空間を設定している場合、システムコントロールには以下の条件が適用されます。詳細については、「[IPC モード](task_definition_parameters.md#task_definition_ipcmode)」を参照してください。
+ `host` IPC モードを使用するタスクの場合、IPC 名前空間の `systemControls` はサポートされていません。
+ `task` IPC モードを使用するタスクでは、IPC 名前空間の `systemControls` 値が、タスク内のすべてのコンテナに適用されます。
```
"systemControls": [
{
"namespace":"string",
"value":"string"
}
]
```
`namespace`
タイプ: 文字列
必須: いいえ
`value` を設定する名前空間カーネルパラメータ。
有効な IPC 名前空間の値: `"fs.mqueue.*"` で開始する `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"`、および `Sysctls`
有効なネットワーク名前空間値: `"net.*"` で始まる `Sysctls`。Fargate では、コンテナ内に存在する名前空間 `Sysctls` のみが受け入れられます。
これらの値はすべて Fargate でサポートされています。
`value`
タイプ: 文字列
必須: いいえ
`namespace` で指定された名前空間カーネルパラメータの値。
#### インタラクティブ
`interactive`
タイプ: ブール値
必須: いいえ
このパラメータが `true` の場合、`stdin` または `tty` を割り当てる必要がある、コンテナ化されたアプリケーションをデプロイすることができます。このパラメータは docker create-container コマンドの `OpenStdin` にマッピングされ、`--interactive` オプションは docker run にマッピングされます。
デフォルト: `false`。
#### 擬似ターミナル
`pseudoTerminal`
タイプ: ブール値
必須: いいえ
このパラメータが `true` の場合、TTY が割り当てられます。このパラメータは docker create-container コマンドの `Tty` にマッピングされ、`--tty` オプションは docker run にマッピングされます。
デフォルト: `false`。
### Linux パラメータ
`linuxParameters`
型: [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) オブジェクト
必須: いいえ
Linux カーネル機能など、コンテナに適用される Linux に固有の変更です。
`capabilities`
型: [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) オブジェクト
必須: いいえ
Docker から提供されているデフォルト構成に追加または削除される、コンテナ用の Linux 機能。
`devices`
タイプ: [デバイス](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html)オブジェクト配列
必須: いいえ
コンテナに公開するすべてのホストデバイス。このパラメータは docker create-container コマンドの `Devices` にマッピングされ、`--device` オプションは docker run にマッピングされます。
`initProcessEnabled`
タイプ: ブール値
必須: いいえ
信号を転送しプロセスを利用するコンテナ内で、`init` を実行。このパラメータは docker run の `--init` オプションにマッピングされます。
`maxSwap`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: 整数
必須: いいえ
コンテナが使用できるスワップメモリの合計 (MiB 単位)。このパラメータは、docker run の `--memory-swap` オプションに変換されます。値はコンテナメモリの合計に `maxSwap` の値を加えた値です。
`swappiness`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: 整数
必須: いいえ
これにより、コンテナのメモリスワップ動作を調整できます。`swappiness` 値が `0` の場合、絶対に必要な場合を除きスワップは行われません。`100` 値が `swappiness` の場合、ページは非常に積極的にスワップされます。有効な値は、`0` と `100` の間の整数です。`swappiness` パラメータを指定しない場合、デフォルト値の `60` が使用されます。`maxSwap` の値が指定されていない場合、このパラメータは無視されます。このパラメータは docker run の `--memory-swappiness` オプションにマッピングされます。
`sharedMemorySize`
このパラメータは、Amazon ECS マネージドインスタンス上で実行されるタスクには対応していません。
タイプ: 整数
必須: いいえ
`/dev/shm` ボリュームのサイズ (MiB) です。このパラメータは docker run の `--shm-size` オプションにマッピングされます。
`tmpfs`
型: [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) オブジェクト配列
必須: いいえ
Tmpfs マウントのコンテナパス、マウントオプション、およびサイズ (MiB) です。このパラメータは docker run の `--tmpfs` オプションにマッピングされます。
# Fargate での Amazon ECS タスク定義パラメータ
タスク定義は、タスクファミリー、AWS Identity and Access Management (IAM) タスクロール、ネットワークモード、コンテナ定義、ボリューム、および起動タイプという各部分に分かれています。ファミリとコンテナの定義は、タスク定義の必須項目です。これに対して、タスクロール、ネットワークモード、ボリューム、および起動タイプは省略することができます。
これらのパラメータを JSON ファイルで使用し、タスク定義を設定できます。
Fargate の各タスク定義パラメータについて、以下に詳述します。
## ファミリー
`family`
タイプ: 文字列
必須: はい
タスク定義を登録するときに、ファミリー (複数バージョンのタスク定義の名前のようなもの) を指定する必要があります。登録したタスク定義には、リビジョン番号が与えられます。特定のファミリーに登録した最初のタスク定義には、リビジョン 1 が与えられます。その後に登録したタスク定義には、連番でリビジョン番号が与えられます。
## Capacity
タスク定義の登録時、Amazon ECS がタスク定義の検証基準となる容量を指定できます。タスク定義が指定された互換性を検証しない場合、クライアント例外が返されます。
タスク定義では、以下のパラメータが使用できます。
`requiresCompatibilities`
タイプ: 文字列配列
必須: いいえ
有効な値: `FARGATE`
タスク定義が検証された容量。これにより、タスク定義で使用されているすべてのパラメータが、Fargate の要件を満たしていることの確認処理が開始されます。
## タスクロール
`taskRoleArn`
タイプ: 文字列
必須: いいえ
タスク定義を登録するときに、IAM ロールのタスクロールを割り当てて、タスクのコンテナに、関連するポリシーに指定された AWS API を呼び出すためのアクセス権限を付与できます。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
## タスク実行ロール
`executionRoleArn`
タイプ: 文字列
必須: 条件による
ユーザーに代わって AWS API コールを実行するアクセス許可を Amazon ECS コンテナエージェントに付与するタスク実行ロールの Amazon リソースネーム (ARN)。
タスク実行 IAM ロールは、タスクの要件に応じて必要です。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
## ネットワークモード
`networkMode`
タイプ: 文字列
必須: はい
タスクのコンテナで使用する Docker ネットワークモード。Fargate でホストされている Amazon ECS タスクでは、`awsvpc` ネットワークモードが必要です。
## ランタイムプラットフォーム
`operatingSystemFamily`
タイプ: 文字列
必須: 条件による
デフォルト: LINUX
Fargate でホストされる Amazon ECS タスクでは、このパラメータは必須です。
タスク定義を登録する際、オペレーティングシステムファミリを指定します。
有効な値は、`LINUX`、`WINDOWS_SERVER_2025_FULL`、`WINDOWS_SERVER_2025_CORE`、`WINDOWS_SERVER_2022_FULL`、`WINDOWS_SERVER_2022_CORE`、`WINDOWS_SERVER_2019_FULL` および `WINDOWS_SERVER_2019_CORE` です。
サービスで使用されるすべてのタスク定義は、このパラメータに対して同じ値を設定する必要があります。
タスク定義がサービスの一部である場合、この値はサービスの `platformFamily` 値と一致する必要があります。
`cpuArchitecture`
タイプ: 文字列
必須: 条件による
デフォルト: X86\$164
パラメータを `null` のままにすると、Fargate でホストされているタスクの開始すしたときにデフォルト値が自動的に割り当てられます。
タスク定義を登録する際は、CPU アーキテクチャを指定します。有効な値は `X86_64` および `ARM64` です。
サービスで使用されるすべてのタスク定義は、このパラメータに対して同じ値を設定する必要があります。
Linux タスクがある場合は、値を `ARM64` に設定できます。詳細については、「[64 ビット ARM ワークロードでの Amazon ECS タスク定義](ecs-arm64.md)」を参照してください。
## タスクサイズ
タスク定義の登録時に、そのタスクが使用する CPU とメモリの合計量を指定できます。これは、コンテナ定義レベルの `cpu` および `memory` の値とは異なります。Fargate (Linux 向けと Windows 向けの両方) でホストされるタスクの場合、これらのフィールドは必須です。また、`cpu` および `memory` の両方について、特定の値がサポートされています。
以下のパラメータをタスク定義で使用できます。
`cpu`
タイプ: 文字列
必須: はい
タスクレベルの CPU およびメモリパラメータは必須であり、タスクが実行されるインスタンスタイプとサイズを判断するために使用されます。Windows タスクの場合、Windows にはコンテナのグループに集合リソース制限を簡単に適用できるネイティブメカニズムがないため、これらの値は実行時に適用されません。リソース制限を適用する場合は、Windows コンテナのコンテナレベルのリソースを使用することをお勧めします。
タスクに適用される CPU ユニットのハード制限。JSON ファイルでは、CPU 値を CPU ユニットまたは仮想 CPU (vCPU) の文字列として指定できます。例えば、CPU 値を `1 vCPU` (vCPU) または `1024` (CPU ユニット) として指定できます。タスク定義が登録されると、vCPU 値は、CPU ユニットを示す整数に変換されます。
このフィールドは必須であり、次のいずれかの値を使用する必要があります。この値により `memory` パラメータでサポートされる値の範囲が決まります。以下の表に、タスクレベル CPU とメモリの有効な組み合わせを示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html)
`memory`
タイプ: 文字列
必須: はい
タスクレベルの CPU およびメモリパラメータは必須であり、タスクが実行されるインスタンスタイプとサイズを判断するために使用されます。Windows タスクの場合、Windows にはコンテナのグループに集合リソース制限を簡単に適用できるネイティブメカニズムがないため、これらの値は実行時に適用されません。リソース制限を適用する場合は、Windows コンテナのコンテナレベルのリソースを使用することをお勧めします。
タスクに適用されるメモリのハード制限です。タスク定義のメモリの値は、メビバイト (MiB) またはギガバイト (GB) の文字列として指定できます。例えば、メモリの値を `3072` (MiB) または `3 GB` (GB) のいずれかで指定できます。タスク定義が登録されると、GB 値は、MiB を示す整数に変換されます。
このフィールドは必須であり、次のいずれかの値を使用する必要があります。この値により `cpu` パラメータでサポートされる値の範囲が決まります。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html)
## コンテナ定義
タスク定義を登録するときは、コンテナインスタンスの Docker デーモンに渡されるコンテナ定義のリストを指定する必要があります。以下のパラメータをコンテナ定義で使用できます。
**Topics**
+ [標準のコンテナ定義のパラメータ](#standard_container_definition_params)
+ [詳細コンテナ定義パラメータ](#advanced_container_definition_params)
+ [その他のコンテナ定義のパラメータ](#other_container_definition_params)
### 標準のコンテナ定義のパラメータ
以下のタスク定義のパラメータは必須であるか、ほとんどのコンテナ定義で使用されます。
**Topics**
+ [名前](#container_definition_name)
+ [Image](#container_definition_image)
+ [メモリ](#container_definition_memory)
+ [ポートマッピング](#container_definition_portmappings)
+ [プライベートリポジトリの認証情報](#container_definition_repositoryCredentials)
#### 名前
`name`
タイプ: 文字列
必須: はい
コンテナの名前。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコアを使用できます。タスク定義で複数のコンテナをリンクしている場合、あるコンテナの `name` を別のコンテナの `links` に入力できます。これにより、コンテナ同士を接続します。
#### Image
`image`
タイプ: 文字列
必須: はい
コンテナの開始に使用するイメージ。この文字列は Docker デーモンに直接渡されます。デフォルトでは、Docker Hub レジストリのイメージを使用できます。`repository-url/image:tag` または `repository-url/image@digest` で他のリポジトリを指定することもできます。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコア、コロン、ピリオド、スラッシュ、シャープ記号を使用できます。このパラメータは、docker create-container コマンドの `Image` と docker run コマンドの `IMAGE` パラメータにマッピングされます。
+ 新しいタスクが開始されると、Amazon ECS コンテナエージェントは、指定されたイメージおよびタグの最新バージョンをプルしてコンテナで使用します。ただし、リポジトリイメージの後続の更新がすでに実行されているタスクに反映されることはありません。
+ タスク定義のイメージパスでタグまたはダイジェストを指定しない場合、Amazon ECS コンテナエージェントは `latest` タグを使用して指定されたイメージを取り込みます。
+ リポジトリイメージに後から加えられた更新内容が、実行中のタスクに反映されることはありません。
+ プライベートレジストリのイメージがサポートされています。詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。
+ Amazon ECR リポジトリのイメージは、`registry/repository:tag` または `registry/repository@digest` の完全な命名規則 (例えば、`aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` や、`aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`) を使用して指定します。
+ Docker Hub の公式リポジトリのイメージでは、1 つの名前 (例: `ubuntu` または `mongo`) を使用します。
+ Docker Hub の他のリポジトリのイメージは、組織名で修飾されます (例: `amazon/amazon-ecs-agent`)。
+ 他のオンラインリポジトリのイメージは、さらにドメイン名で修飾されます (例: `quay.io/assemblyline/ubuntu`)。
`versionConsistency`
タイプ: 文字列
有効な値: `enabled`\$1`disabled`
必須: いいえ
コンテナ定義で指定されたコンテナイメージタグを Amazon ECS がイメージダイジェストに解決するかどうかを指定します。デフォルトでは、この動作は `enabled` です。コンテナの値を `disabled` として設定した場合、Amazon ECS はコンテナイメージタグをダイジェストに解決せず、コンテナ定義で指定された元のイメージ URI をデプロイ用に使用します。コンテナイメージの解決の詳細については、「[コンテナイメージの解決](deployment-type-ecs.md#deployment-container-image-stability)」を参照してください。
#### メモリ
`memory`
タイプ: 整数
必須: いいえ
コンテナに適用されるメモリの量 (MiB 単位)。コンテナは、ここで指定したメモリを超えようとすると、強制終了されます。タスク内のすべてのコンテナ用に予約されるメモリの合計量は、タスクの `memory` 値より小さくする必要があります (指定されている場合)。このパラメータは docker create-container コマンドの `Memory` にマッピングされ、`--memory` オプションは docker run にマッピングされます。
Docker デーモン 20.10.0 以降によって、コンテナ用として 6 MiB 以上のメモリが予約されます。従って、このコンテナに対しては 6 MiB 未満のメモリは指定しないようにします。
Docker デーモン 19.03.13-ce 以降では、コンテナ用として 4 MiB 以上のメモリが予約されます。このため、このコンテナ用には 4 MiB 未満のメモリを指定しないようにします。
リソースの使用率を最大化することを目的に、特定のインスタンスタイプにおいて、タスクにできるだけ多くのメモリを提供する場合には、「[Amazon ECS Linux コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。
`memoryReservation`
タイプ: 整数
必須: いいえ
コンテナ用に予約するメモリのソフト制限 (MiB 単位)。システムメモリに競合がある場合、Docker はコンテナのメモリ量をこのソフト制限値内に維持しようとします。ただし、コンテナは必要に応じてより多くのメモリを使用することができます。コンテナは、`memory` パラメーターで指定されたハード制限 (該当する場合) またはコンテナインスタンス上の利用可能なすべてのメモリのいずれか早く達する方まで使用できます。このパラメータは docker create-container コマンドの `MemoryReservation` にマッピングされ、`--memory-reservation` オプションは docker run にマッピングされます。
タスクレベルでメモリ値を指定しない場合、コンテナ定義で `memory` または `memoryReservation` の一方または両方に 0 以外の整数を指定する必要があります。両方を指定する場合、`memory` は `memoryReservation` より大きいことが必要です。`memoryReservation` を指定する場合、コンテナが配置されているコンテナインスタンスで使用可能なメモリリソース量から、上記の値が減算されます。それ以外の場合は、`memory` の値が使用されます。
例えば、コンテナが通常 128 MiB のメモリを使用しているが、短期間にメモリが 256 MiB にバーストする場合があるとします。128 MiB の `memoryReservation` と 300 MiB の `memory` ハード制限を設定できます。この設定では、コンテナが、コンテナインスタンスの残りのリソースから 128 MiB のメモリのみを予約できます。同時に、この構成により、コンテナは必要に応じてより多くのメモリ リソースを使用できるようになります。
このパラメータは Windows コンテナではサポートされません。
Docker デーモン 20.10.0 以降によって、コンテナ用として 6 MiB 以上のメモリが予約されます。従って、このコンテナに対しては 6 MiB 未満のメモリは指定しないようにします。
Docker デーモン 19.03.13-ce 以降では、コンテナ用として 4 MiB 以上のメモリが予約されます。このため、このコンテナ用には 4 MiB 未満のメモリを指定しないようにします。
リソースの使用率を最大化することを目的に、特定のインスタンスタイプにおいて、タスクにできるだけ多くのメモリを提供する場合には、「[Amazon ECS Linux コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。
#### ポートマッピング
`portMappings`
タイプ: オブジェクト配列
必須: いいえ
ポートマッピングは、コンテナのネットワークポートを外部に公開します。これは、クライアントがアプリケーションにアクセスすることを可能にします。これは、同じタスク内にあるコンテナ間の通信にも使用されます。
`awsvpc` ネットワークモードを使用するタスク定義では、`containerPort` のみを指定します。`hostPort` は常に無視され、コンテナポートはホスト上の番号が大きいランダムなポートに自動的にマップされます。
Windows のポートマッピングでは、`localhost` の代わりに `NetNAT` ゲートウェイを使用します。Windows のポートマッピングにはループバックが存在しないため、ホスト自体からコンテナのマッピングされたポートにアクセスはできません。
このパラメータのほとんどのフィールド (`containerPort`、`hostPort`、`protocol` を含む) は docker create-container コマンドの `PortBindings` にマッピングされ、`--publish` オプションは docker run にマッピングされます。タスク定義でネットワークモードを `host` に設定している場合、ホストポートは未定義とするか、ポートマッピングのコンテナポートと一致させる必要があります。
タスクが `RUNNING` ステータスに達すると、手動および自動で割り当てられたホストとコンテナポートが次の場所で表示されます:
+ コンソール: 指定されたタスクのコンテナ詳細の [**Network Bindings**] セクション。
+ AWS CLI: `networkBindings` コマンド出力の **describe-tasks** セクション。
+ API: `DescribeTasks` レスポンス。
+ メタデータ: タスクメタデータのエンドポイント。
`appProtocol`
タイプ: 文字列
必須: いいえ
ポートマッピングに使用されるアプリケーションプロトコル。このパラメータは Service Connect にのみ適用されます。アプリケーションが使用するプロトコルと一貫性を持つように、このパラメータを設定することをお勧めします。このパラメータを設定すると、Amazon ECS はサーバー コネクト プロキシにプロトコル固有の接続処理を追加します。このパラメータを設定すると、Amazon ECS は Amazon ECS コンソールと CloudWatch にプロトコル固有のテレメトリを追加します。
このパラメータ値を設定しないと、TCP が使用されます。ただし、Amazon ECS では、TCP 用のプロトコル固有のテレメトリーは追加されません。
詳細については、「[Service Connect を使用して Amazon ECS サービスを短縮名で接続する](service-connect.md)」を参照してください。
有効なプロトコル値: `"http" | "http2" | "grpc" `
`containerPort`
タイプ: 整数
必須: はい (`portMappings` を使用する場合)
ユーザーが指定したホストポートまたは自動的に割り当てられたホストポートにバインドされるコンテナポートの番号。
`awsvpc` ネットワークモードを使用するタスクの場合は、`containerPort` を使用して公開ポートを指定します。
Fargate 上の Windows コンテナの場合、`containerPort` にポート 3150 は使用できません。このポートは予約済みです。
`containerPortRange`
タイプ: 文字列
必須: いいえ
動的にマッピングされたホストポート範囲にバインドされるコンテナのポート番号の範囲。
このパラメータは、`register-task-definition` API を使用してのみ設定できます。このオプションは、`portMappings` パラメータで使用できます。詳細については、「*AWS Command Line Interface リファレンス*」の「[register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html)」を参照してください。
`containerPortRange` を指定するときは、以下のルールが適用されます。
+ `awsvpc` ネットワークモードを使用する必要があります。
+ このパラメータは、Linux と Windows の両オペレーティングシステムで使用できます。
+ コンテナインスタンスには、少なくともコンテナエージェントのバージョン 1.67.0 と `ecs-init` パッケージのバージョン 1.67.0-1 が必要です。
+ 各コンテナにつき、最大 100 のポートレンジを指定できます。
+ `hostPortRange` は指定しません。`hostPortRange` の値は次のように設定されます。
+ `awsvpc` ネットワークモードのタスク内のコンテナでは、`hostPort` は `containerPort` と同じ値に設定されます。これは静的マッピング戦略です。
+ `containerPortRange` の有効な値は 1～65535 です。
+ 1 つのポートは、コンテナごとに 1 つのポートマッピングにのみ含められます。
+ 重複するポート範囲は指定できません。
+ 範囲内の最初のポートは、最後のポートよりも小さくなければなりません。
+ Docker では、ポートの数が多い場合は、Docker デーモン設定ファイルの docker-proxy をオフにすることをお勧めします。
詳細については、GitHub の [Issue \$111185](https://github.com/moby/moby/issues/11185) を参照してください。
Docker デーモン設定ファイルの docker-proxy をオフにする方法については、*Amazon ECS 開発者ガイド*の「[Docker デーモン](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon)」を参照してください。
[DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) を呼び出すと、コンテナポートにバインドされているホストポートである `hostPortRange` を表示できます。
ポート範囲は、EventBridge に送信される Amazon ECS タスクイベントに含まれません。詳細については、「[EventBridge を使用して Amazon ECS エラーへの対応を自動化する](cloudwatch_event_stream.md)」を参照してください。
`hostPortRange`
タイプ: 文字列
必須: いいえ
ネットワークバインディングで使用されるホストのポート番号範囲。これは Docker によって割り当てられ、Amazon ECS エージェントによって配信されます。
`hostPort`
タイプ: 整数
必須: いいえ
コンテナ用に予約するコンテナインスタンスのポート番号。
`hostPort` は、空白のままにするか、`containerPort` と同じ値にできます。
Docker バージョン 1.6.0 以降のデフォルトの一時ポート範囲は、インスタンスの `/proc/sys/net/ipv4/ip_local_port_range` にリストされています。このカーネルパラメータが使用できない場合、`49153–65535` から始まるデフォルトのエフェメラルポート範囲が使用されます。エフェメラルポート範囲では、ホストポートを指定しないでください。これらの範囲は自動割り当て用に予約済みです。一般的に、`32768` より小さい番号のポートは一時ポート範囲に含まれません。
デフォルトの予約済みポートは、SSH 用の `22`、Docker ポートの `2375` および `2376`、Amazon ECS コンテナエージェントポートの `51678-51680` です。実行中のタスクに対して以前にユーザーが指定したホストポートも、タスクの実行中に予約されます。タスクが停止すると、ホストポートはリリースされます。現在の予約済みポートは、**describe-container-instances** 出力の `remainingResources` に表示されます。コンテナインスタンスには、デフォルトの予約済みポートを含めて、一度に最大 100 個の予約済みポートを割り当てられます。自動的に割り当てられるポートは、この 100 個の予約済みポートクォータにはカウントされません。
`name`
タイプ: 文字列
必須: いいえ。サービスに Service Connect および VPC Lattice を設定する場合は必要です。
ポートマッピングに使用される名前。このパラメータは Service Connect および VPC Lattice にのみ適用されます。このパラメータは、サービスの Service Connect および VPC Lattice 設定で使用する名前です。
詳細については、「[Service Connect を使用して Amazon ECS サービスを短縮名で接続する](service-connect.md)」を参照してください。
次の例では、Service Connect および VPC Lattice の 2 つの必須フィールドが使用されています。
```
"portMappings": [
{
"name": string,
"containerPort": integer
}
]
```
`protocol`
タイプ: 文字列
必須: いいえ
ポートマッピングに使用されるプロトコル。有効な値は、`tcp` および `udp` です。デフォルト: `tcp`。
`tcp` は Service Connect でのみサポートされます。このフィールドが設定されていない場合は、`tcp` が暗示されることに注意してください。
ホストポートを指定する際は、以下の構文を使用します。
```
"portMappings": [
{
"containerPort": integer,
"hostPort": integer
}
...
]
```
自動割り当てのホストポートが必要な場合は、以下の構文を使用します。
```
"portMappings": [
{
"containerPort": integer
}
...
]
```
#### プライベートリポジトリの認証情報
`repositoryCredentials`
タイプ: [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) オブジェクト
必須: いいえ
プライベートレジストリ認証用のリポジトリ認証情報。
詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。
`credentialsParameter`
タイプ: 文字列
必須: はい (`repositoryCredentials` を使用する場合)
プライベートリポジトリの認証情報が含まれているシークレットの Amazon リソースネーム (ARN)。
詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。
Amazon ECS API、AWS CLI、または AWS SDK を使用する場合、起動するタスクと同じリージョンにシークレットが存在する場合は、シークレットの完全な ARN または名前のどちらも使用できます。AWS マネジメントコンソール を使用する場合は、シークレットの完全な ARN を指定する必要があります。
必要なパラメータが含まれるタスク定義のスニペットを、以下に示します。
```
"containerDefinitions": [
{
"image": "private-repo/private-image",
"repositoryCredentials": {
"credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
}
}
]
```
### 詳細コンテナ定義パラメータ
以下のコンテナ定義用の詳細パラメータは、Amazon ECS コンテナインスタンスでのコンテナの起動に使用する docker run コマンドの拡張機能を追加します。
**Topics**
+ [再起動ポリシー](#container_definition_restart_policy)
+ [ヘルスチェック](#container_definition_healthcheck)
+ [環境](#container_definition_environment)
+ [ネットワーク設定](#container_definition_network)
+ [ストレージとログ記録](#container_definition_storage)
+ [セキュリティ](#container_definition_security)
+ [リソースの制限](#container_definition_limits)
+ [Docker のラベル](#container_definition_labels)
#### 再起動ポリシー
`restartPolicy`
コンテナ再起動ポリシーと関連する設定パラメータ。コンテナの再起動ポリシーを設定すると、Amazon ECS はタスクを置き換えることなくコンテナを再起動できます。詳細については、「[コンテナ再起動ポリシーを使用して Amazon ECS タスク内の個々のコンテナを再起動する](container-restart-policy.md)」を参照してください。
`enabled`
タイプ: ブール値
必須: はい
コンテナに対して再起動ポリシーを有効にするかどうかを指定します。
`ignoredExitCodes`
タイプ: 整数配列
必須: いいえ
Amazon ECS が無視し、再起動を試みない終了コードのリスト。最大 50 個のコンテナ終了コードを指定できます。デフォルトでは、Amazon ECS はいずれの終了コードも無視しません。
`restartAttemptPeriod`
タイプ: 整数
必須: いいえ
再起動を試みる前にコンテナが実行する必要がある時間 (秒単位）。コンテナを再起動できるのは、`restartAttemptPeriod` 秒に 1 回のみです。コンテナがこの期間実行できずに早く終了した場合、コンテナは再起動されません。最小の `restartAttemptPeriod` は 60 秒、最大の `restartAttemptPeriod` は 1,800 秒を指定できます。デフォルトでは、コンテナは再起動の前に 300 秒間実行する必要があります。
#### ヘルスチェック
`healthCheck`
コンテナに対するヘルスチェックのコマンドと、コンテナのための関連する設定パラメータです。詳細については、「[コンテナのヘルスチェックを使用して Amazon ECS タスク状態を判定する](healthcheck.md)」を参照してください。
`command`
正常状態かどうかを決定するために、コンテナが実行するコマンドが格納された文字列配列。この文字列配列の先頭には、コマンド引数を直接実行するための `CMD`、またはコンテナのデフォルトシェルでコマンドを実行するための `CMD-SHELL` を付加できます。これらのいずれも指定しない場合は `CMD` が使用されます。
AWS マネジメントコンソール にタスク定義を登録する場合は、カンマで区切ったコマンドリストを使用してください。これらのコマンドは、タスク定義が作成された後に文字列に変換されます。ヘルスチェックに対する入力の例を次に示します。
```
CMD-SHELL, curl -f http://localhost/ || exit 1
```
AWS マネジメントコンソール JSON パネル、AWS CLI、または API を使用してタスク定義を登録するときは、コマンドのリストを角かっこで囲みます。ヘルスチェックに対する入力の例を次に示します。
```
[ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ]
```
`stderr` が出力されない終了コード 0 は成功を示し、0 以外の終了コードは失敗を示します。
`interval`
各ヘルスチェック間の時間間隔 (秒単位)。5 〜 300 秒を指定できます。デフォルトの値は 30 秒です。
`timeout`
成功まで待機しているヘルスチェックが、失敗したと見なされるまでの期間 (秒単位) です。2 〜 60 秒を指定できます。デフォルト値は 5 秒です。
`retries`
コンテナが異常と見なされるまでに、失敗したヘルスチェックを再試行する回数です。1〜10 回を指定できます。デフォルト値は 3 回の再試行です。
`startPeriod`
失敗したヘルスチェックの再試行が最大回数に達する前に、コンテナにブートストラップための時間を提供するオプションの猶予期間です。0～300 秒の値を指定できます。デフォルトでは、`startPeriod` は無効となっています。
ヘルスチェックが `startPeriod` 内で成功した場合、コンテナは正常であるとみなされ、その後の失敗は最大再試行回数にカウントされます。
#### 環境
`cpu`
タイプ: 整数
必須: いいえ
Amazon ECS コンテナエージェントがコンテナ用に予約した `cpu` ユニットの数。Linux では、このパラメータは「[Create a container](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate)」セクションの `CpuShares` にマッピングされます。
Fargate を使用するタスクでは、このフィールドは省略可能です。タスク内のすべてのコンテナのために予約されている CPU の合計量は、タスクレベルの `cpu` 値以上にはできません。
Linux コンテナは、割り当てられた CPU ユニットと同じ比率を使用して、割り当てられていない CPU ユニットをコンテナインスタンス上の他コンテナと共有します。例えば、そのコンテナ用に 512 個の CPU ユニットが指定された単一コアインスタンスタイプで、唯一のコンテナタスクを実行するとします。さらに、そのタスクはコンテナインスタンスで実行される唯一のタスクです。この場合のコンテナは、1,024 個の CPU ユニット配分を任意のタイミングで使用できます。一方、そのコンテナインスタンスで同じタスクのコピーを別途起動したと仮定します。各タスクには、必要に応じて少なくとも 512 個の CPU ユニットが保証されます。同様に、その他のコンテナが残りの CPU を使用していない場合、各コンテナは CPU 使用率を高められます。ただし、両方のタスクが常に 100% アクティブである場合、使用できるのは 512 CPU ユニットに制限されます。
Linux コンテナインスタンスでは、コンテナインスタンス上の Docker デーモンは、CPU 値を使用して、実行中のコンテナに対する相対 CPU 配分比率を計算します。Linux カーネルが許可する最小の有効な CPU 共有値は 2 で、Linux カーネルが許可する最大の有効な CPU 共有値は 262,144 です。ただし、CPU のパラメータは必須ではなく、コンテナ定義では 2 未満の CPU 値および 262144 より大きな CPU 値を使用できます。CPU 値が 2 未満 (null を含む) および 262144 より大きな値である場合、動作は Amazon ECS コンテナエージェントのバージョンによって異なります。
Windows コンテナインスタンスでは、CPU クォータは絶対クォータとして適用されます。Windows コンテナは、タスク定義で定義されている指定された量の CPU にのみアクセスできます。null またはゼロの CPU 値が `0` として Docker に渡されます。次に Windows はこの値を 1 つの CPU の 1% として解釈します。
その他の例については、「[Amazon ECS で CPU およびメモリリソースの管理方法](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/)」を参照してください。
`gpu`
このパラメータは、Fargate でホストされているコンテナではサポートされていません。
タイプ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) オブジェクト
必須: いいえ
Amazon ECS コンテナエージェントがコンテナ用に予約した物理 `GPUs` の数。タスク内でコンテナ用に予約されているすべての GPU の数は、タスクが起動されたコンテナインスタンスで使用できる GPU の数を超えることはできません。詳細については、「[GPU ワークロード向けの Amazon ECS タスク定義](ecs-gpu.md)」を参照してください。
`Elastic Inference accelerator`
このパラメータは、Fargate でホストされているコンテナではサポートされていません。
タイプ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) オブジェクト
必須: いいえ
`InferenceAccelerator` タイプでは、`value` はタスク定義で指定される `InferenceAccelerator` の `deviceName` と一致します。詳細については、「[Elastic Inference アクセラレーター名 (廃止)](#elastic-Inference-accelerator)」を参照してください。
`essential`
タイプ: ブール値
必須: いいえ
コンテナの `essential` パラメーターが `true` としてマークされており、そのコンテナが何らかの理由で失敗するか停止するとします。その後、タスクの一部である他のすべてのコンテナが停止されます。コンテナの `essential` パラメータを `false` にマークしておくと、そのコンテナ失敗はタスク内にある残りのコンテナに影響を与えません。このパラメータを省略した場合、コンテナは必須と見なされます。
すべてのタスクには少なくとも 1 つの必須コンテナが必要です。複数のコンテナで構成されるアプリケーションがあるとします。次に、共通の目的で使用されるコンテナをコンポーネントにグループ化し、さまざまなコンポーネントを複数のタスク定義に分離します。詳細については、「[Amazon ECS 用のアプリケーションの構築](application_architecture.md)」を参照してください。
```
"essential": true|false
```
`entryPoint`
初期のバージョンの Amazon ECS コンテナエージェントは、`entryPoint` パラメータを正しく処理しません。`entryPoint` の使用時に問題が発生する場合は、コンテナエージェントを更新するか、代わりに `command` 配列項目としてコマンドと引数を入力します。
タイプ: 文字列配列
必須: いいえ
コンテナに渡されるエントリポイント。
```
"entryPoint": ["string", ...]
```
`command`
タイプ: 文字列配列
必須: いいえ
コンテナに渡されるコマンド。このパラメータは create-container コマンドの `Cmd` にマッピングされ、 `COMMAND` パラメータは docker run にマッピングされます。複数の引数がある場合、各引数は配列内で、区切られた文字列により指定する必要があります。
```
"command": ["string", ...]
```
`workingDirectory`
タイプ: 文字列
必須: いいえ
コマンドを実行するコンテナ内の作業ディレクトリ。このパラメータは、[Docker Remote API](https://docs.docker.com/reference/api/engine/version/v1.38/) の [コンテナの作成](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) セクションにある `WorkingDir` にマッピングされ、`--workdir` オプションは [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) にマッピングされます。
```
"workingDirectory": "string"
```
`environmentFiles`
これは Fargate の Windows コンテナでは使用できません
タイプ: オブジェクト配列
必須: いいえ
コンテナに渡す環境変数が含まれるファイルのリスト。このパラメータは docker run コマンドの `--env-file` オプションにマッピングされます。
最大 10 個の環境ファイルを指定できます。ファイルには、ファイル拡張子 `.env` が必要です。環境ファイルの各行には、`VARIABLE=VALUE` 形式で環境変数が含まれています。`#` で始まる行はコメントとして扱われ、無視されます。
コンテナ定義に個別の環境変数が指定されている場合は、環境ファイルに含まれる変数よりも優先されます。同じ変数を含む複数の環境ファイルが指定されている場合、それらのファイルは上から下に処理されます。一意の変数名を使用することをお勧めします。詳細については、「[個々の環境変数を Amazon ECS コンテナに渡す](taskdef-envfiles.md)」を参照してください。
`value`
タイプ: 文字列
必須: はい
環境変数ファイルを含む Amazon S3 オブジェクトの Amazon リソースネーム (ARN)。
`type`
タイプ: 文字列
必須: はい
使用するファイルのタイプ。`s3` はサポートされる唯一の値です。
`environment`
タイプ: オブジェクト配列
必須: いいえ
コンテナに渡す環境変数。このパラメータは docker create-container コマンドの `Env` にマッピングされ、`--env` オプションは docker run コマンドにマッピングされます。
認証情報データなどの機密情報にプレーンテキストの環境変数を使用することはお勧めしません。
`name`
タイプ: 文字列
必須: はい (`environment` を使用する場合)
環境変数の名前。
`value`
タイプ: 文字列
必須: はい (`environment` を使用する場合)
環境変数の値。
```
"environment" : [
{ "name" : "string", "value" : "string" },
{ "name" : "string", "value" : "string" }
]
```
`secrets`
タイプ: オブジェクト配列
必須: いいえ
コンテナに公開するシークレットを表すオブジェクトです。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
`name`
タイプ: 文字列
必須: はい
コンテナの環境変数として設定する値。
`valueFrom`
タイプ: 文字列
必須: はい
コンテナに公開するシークレット。サポートされている値は、AWS Secrets Manager シークレットの完全な Amazon リソースネーム (ARN)、または AWS Systems Manager Parameter Store 内のパラメータの完全な ARN のいずれかです。
起動するタスクと同じ AWS リージョン に Systems Manager パラメータストアのパラメータまたは Secrets Manager のパラメータが存在する場合は、シークレットの完全な ARN または名前のいずれかを使用できます。パラメータが別のリージョンに存在する場合は、完全な ARN を指定する必要があります。
```
"secrets": [
{
"name": "environment_variable_name",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
}
]
```
#### ネットワーク設定
`disableNetworking`
このパラメータは、Fargate で実行されるタスクではサポートされていません。
タイプ: ブール値
必須: いいえ
このパラメータが true のとき、ネットワークはコンテナ内でオフになります。
デフォルト: `false`。
```
"disableNetworking": true|false
```
`links`
このパラメータは、`awsvpc` ネットワークモードを使用するタスクではサポートされません。
タイプ: 文字列配列
必須: いいえ
`link` パラメータでは、コンテナがポートマッピングを必要とせずに互いに通信することを許可します。このパラメータは、タスク定義のネットワークモードが `bridge` に設定されている場合にのみサポートされます。`name:internalName` コンストラクトは Docker リンクの `name:alias` に似ています。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコアを使用できます。
同じコンテナインスタンスに配置されたコンテナ同士は、リンクやホストポートマッピングを必要とせずに、互いに通信する場合があります。コンテナインスタンスでのネットワークの分離は、セキュリティグループと VPC 設定によって制御されます。
```
"links": ["name:internalName", ...]
```
`hostname`
タイプ: 文字列
必須: いいえ
コンテナに使用するホスト名。このパラメータは docker create-container の `Hostname` にマッピングされ、`--hostname` オプションは docker run にマッピングされます。
`awsvpc` ネットワークモードを使用している場合、`hostname` パラメータはサポートされません。
```
"hostname": "string"
```
`dnsServers`
このパラメータは、Fargate で実行されるタスクではサポートされません。
タイプ: 文字列配列
必須: いいえ
コンテナに提示する DNS サーバーのリスト。
```
"dnsServers": ["string", ...]
```
`extraHosts`
このパラメータは、`awsvpc` ネットワークモードを使用するタスクではサポートされていません。
タイプ: オブジェクト配列
必須: いいえ
コンテナ上の `/etc/hosts` ファイルに追加する、ホスト名と IP アドレスのマッピングリスト。
このパラメータは docker create-container コマンドの `ExtraHosts` にマッピングされ、`--add-host` オプションは docker run にマッピングされます。
```
"extraHosts": [
{
"hostname": "string",
"ipAddress": "string"
}
...
]
```
`hostname`
タイプ: 文字列
必須: はい (`extraHosts` を使用する場合)
`/etc/hosts` エントリで使用するホスト名。
`ipAddress`
タイプ: 文字列
必須: はい (`extraHosts` を使用する場合)
`/etc/hosts` エントリで使用する IP アドレス。
#### ストレージとログ記録
`readonlyRootFilesystem`
タイプ: ブール値
必須: いいえ
このパラメータが true のとき、コンテナはそのルートファイルシステムへの読み取り専用アクセスを許可されます。このパラメータは docker create-container コマンドの `ReadonlyRootfs` にマッピングされ、`--read-only` オプションは docker run にマッピングされます。
このパラメータは Windows コンテナではサポートされません。
デフォルト: `false`。
```
"readonlyRootFilesystem": true|false
```
`mountPoints`
タイプ: オブジェクト配列
必須: いいえ
コンテナでのデータボリュームのマウントポイント。このパラメータは creat-container Docker API の `Volumes` にマッピングされ、docker run の `--volume` オプションにマッピングされます。
Windows コンテナは `$env:ProgramData` と同じドライブに全部のディレクトリをマウントできます。Windows コンテナは、別のドライブにディレクトリをマウントすることはできません。また、マウントポイントは複数のドライブにまたがることはできません。Amazon EBS ボリュームを Amazon ECS タスクに直接アタッチするには、マウントポイントを指定する必要があります。
`sourceVolume`
タイプ: 文字列
必須: はい (`mountPoints` を使用する場合)
マウントするボリュームの名前。
`containerPath`
タイプ: 文字列
必須: はい (`mountPoints` を使用する場合)
ボリュームをマウントするコンテナ内のパス。
`readOnly`
タイプ: ブール値
必須: いいえ
この値が `true` の場合、コンテナはボリュームへの読み取り専用アクセスを許可されます。この値が `false` の場合、コンテナはボリュームに書き込むことができます。デフォルト値は `false` です。
Windows オペレーティングシステムを実行している EC2 インスタンスで実行されるタスクの場合、 値をデフォルト の `false` のままにします。
`volumesFrom`
タイプ: オブジェクト配列
必須: いいえ
別コンテナからマウントするデータボリューム。このパラメータは docker create-container コマンドの `VolumesFrom` にマッピングされ、`--volumes-from` オプションは docker run にマッピングされます。
`sourceContainer`
タイプ: 文字列
必須: はい (`volumesFrom` を使用する場合)
ボリュームのマウント元のコンテナの名前。
`readOnly`
タイプ: ブール値
必須: いいえ
この値が `true` の場合、コンテナはボリュームへの読み取り専用アクセスを許可されます。この値が `false` の場合、コンテナはボリュームに書き込むことができます。デフォルト値は `false` です。
```
"volumesFrom": [
{
"sourceContainer": "string",
"readOnly": true|false
}
]
```
`logConfiguration`
タイプ: [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) オブジェクト
必須: いいえ
コンテナに対するログ構成の仕様です。
ログ設定を使用したタスク定義の例については、「[Amazon ECS のタスク定義の例](example_task_definitions.md)」を参照してください。
このパラメータは docker create-container コマンドの `LogConfig` にマッピングされ、`--log-driver` オプションは docker run にマッピングされます。デフォルトでは、コンテナは Docker デーモンで使用されるのと同じロギングドライバーを使用します。ただし、コンテナ定義の中で、このパラメータによりログドライバーを指定することで、Docker デーモンとは異なるログドライバーをコンテナに使用させることも可能です。コンテナに異なるロギングドライバーを使用するには、コンテナインスタンス (またはリモートログ記録オプションの別のログサーバー) でログシステムを適切に設定する必要があります。
コンテナのログ設定を指定する際には、以下の点に注意してください。
+ 現在、Amazon ECS では Docker デーモンに使用可能なログドライバーがいくつかサポートされています。
+ このパラメータを使用するには、コンテナインスタンスで Docker Remote API のバージョン 1.18 以降が必要です。
+ 追加のソフトウェアは、タスクの外部にインストールする必要があります。例えば、Fluentd 出力アグリゲータであるか、Gelf ログの送信先として Logstash を実行しているリモートホストです。
```
"logConfiguration": {
"logDriver": "awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens",
"options": {"string": "string"
...},
"secretOptions": [{
"name": "string",
"valueFrom": "string"
}]
}
```
`logDriver`
タイプ: 文字列
有効な値: `"awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens"`
必須: はい (`logConfiguration` を使用する場合)
コンテナに使用するログドライバー。デフォルトでは、上記の有効な値は Amazon ECS コンテナエージェントが通信できるログドライバーです。
サポートされているログドライバーは `awslogs`、`splunk`、`awsfirelens` です。
タスク定義で `awslogs` ログドライバーを使用してコンテナログを CloudWatch Logs に送信する方法については、「[Amazon ECS ログを CloudWatch に送信する](using_awslogs.md)」を参照してください。
`awsfirelens` ログドライバーの使用の詳細については、「[カスタムログのルーティング](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html)」を参照してください。
上記に示されていないカスタムドライバーがある場合、[GitHub で入手できる](https://github.com/aws/amazon-ecs-agent) Amazon ECS コンテナエージェントプロジェクトを fork し、そのドライバーを使用するようにカスタマイズできます。含めたい変更については、プルリクエストを送信することをお勧めします。ただし、現時点では、このソフトウェアの変更されたコピーの実行はサポートされていません。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.18 以上を使用する必要があります。
`options`
タイプ: 文字列間のマッピング
必須: いいえ
ログドライバーに送信する設定オプションの Key-Value マップ。
指定できるオプションは、ログドライバーに応じて異なります。`awslogs` ルーターを使用して Amazon CloudWatch にログをルーティングするときに指定できるオプションには、以下が含まれます。
`awslogs-create-group`
必須: いいえ
ロググループを自動的に作成させるかどうかを指定します。このオプションを指定しない場合、デフォルトは `false` です。
`awslogs-create-group` を使用する前に、IAM ポリシーにはアクセス許可 `logs:CreateLogGroup` が含まれている必要があります。
`awslogs-region`
必須: はい
`awslogs` ログドライバが Docker ログを送信する先の、AWS リージョン を指定します。CloudWatch Logs では、異なるリージョンのクラスターからすべてのログを 1 つのリージョンに送信するように選択できます。これにより、すべてのログを一元的な場所で確認できるようになります。他にも、リージョンごとにそれらを分離して、より細分化することが可能です。このオプションで指定するリージョンに、対象のロググループが存在することを確認してください。
`awslogs-group`
必須: はい
`awslogs` ログドライバーがログストリームを送信する先の、ロググループを指定する必要があります。
`awslogs-stream-prefix`
必須: はい
指定したプレフィックス、コンテナ名、コンテナが属する Amazon ECS タスクの ID にログストリームを関連付けるには、`awslogs-stream-prefix` オプションを使用します。このオプションでプレフィックスを指定した場合、ログストリームの形式は以下のようになります。
```
prefix-name/container-name/ecs-task-id
```
このオプションでプレフィックスを指定しない場合、ログストリームには、コンテナインスタンスの Docker デーモンによって割り当てられたコンテナ ID に基づいた名前が付けられます。Docker コンテナ ID (コンテナインスタンスでのみ使用可能) だけでそのログを送信したコンテナを追跡するのは難しいため、このオプションでプレフィックスを指定することをお勧めします。
Amazon ECS サービスでは、サービス名をプレフィックスとして使用できます。これにより、コンテナが属するサービスへのログストリームと、それを送信したコンテナの名前、そのコンテナが所属するタスクの ID を追跡できます。
Amazon ECS コンソールを使用する際に [Log] ペインにログを表示するためには、ログのストリームプレフィックスを指定する必要があります。
`awslogs-datetime-format`
必須: いいえ
このオプションは、Python `strftime` 形式で複数行起動パターンを定義します。ログメッセージは、パターンに一致する 1 行と、それに続くパターンに一致しない行で構成されます。一致する 1 行とは、ログメッセージ間の区切りです。
この形式を使用する場合のユースケースの例としては、スタックダンプなどの解析された出力があり、これを使用しなければ、複数のエントリに記録されることになります。適切なパターンにより、単一のエントリにキャプチャさせます。
詳細については、[awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format)を参照してください。
`awslogs-datetime-format` と `awslogs-multiline-pattern` オプションの両方を設定することはできません。
複数行のログ記録は、すべてのログメッセージの正規表現の解析とマッチングを実行します。これによりログ記録のパフォーマンスに悪影響が及ぶ可能性があります。
`awslogs-multiline-pattern`
必須: いいえ
このオプションでは、正規表現を使用する複数行起動パターンを定義します。ログメッセージは、パターンに一致する 1 行と、それに続くパターンに一致しない行で構成されます。一致する 1 行とは、ログメッセージ間の区切りです。
詳細については、「[awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern)」を参照してください。
`awslogs-datetime-format` も設定されている場合は、このオプションは無視されます。
`awslogs-datetime-format` と `awslogs-multiline-pattern` オプションの両方を設定することはできません。
複数行のログ記録は、すべてのログメッセージの正規表現の解析とマッチングを実行します。これによりログ記録のパフォーマンスに悪影響が及ぶ可能性があります。
以下のオプションは、サポートされているすべてのログドライバーに適用されます。
`mode`
必須: いいえ
有効な値: `non-blocking` \$1 `blocking`
このオプションは、コンテナから `logDriver` で指定したログドライバーへのログメッセージの配信モードを定義します。選択した配信モードは、コンテナからンテナーからのログの流れが中断されたときのアプリケーションの可用性に影響します。
`blocking` モードを使用していて、ログのフローが中断された場合、`stdout` ストリームと `stderr` ストリームに書き込むためのコンテナコードからの呼び出しがブロックされます。その結果、アプリケーションのロギングスレッドがブロックされます。これにより、アプリケーションが応答しなくなり、コンテナのヘルスチェックが失敗する可能性があります。
`non-blocking` モードを使用する場合、コンテナのログは代わりに `max-buffer-size` オプションで設定されたメモリ内の中間バッファに保存されます。これにより、ログを送信できない場合にアプリケーションが応答しなくなるのを防ぐことができます。サービスの可用性を確保したいが、多少のログ損失があっても問題ない場合は、このモードを使用することをおすすめします。詳細については、「[Preventing log loss with non-blocking mode in the `awslogs` container log driver](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/)」を参照してください。
`defaultLogDriverMode` アカウント設定を使用して、特定の AWS リージョンにあるすべてのコンテナのデフォルトの `mode` を設定できます。`logConfiguration` で `mode` オプションを指定しない場合、またはアカウント設定を構成しない場合、Amazon ECS はデフォルトで `non-blocking` モードになります。アカウント設定の詳細については、「[デフォルトのログドライバーモード](ecs-account-settings.md#default-log-driver-mode)」を参照してください。
`non-blocking` モードが使用されている場合、`max-buffer-size` ログオプションは、中間メッセージ用のストレージに使用されるバッファのサイズを制御します。アプリケーションに基づいて、必ず適切なバッファサイズを指定してください。タスクレベルで割り当てられるメモリの合計量は、ログドライバーのメモリバッファに加えて、すべてのコンテナに割り当てられたメモリ量よりも大きくなければなりません。
2025 年 6 月 25 日、Amazon ECS はデフォルトのログドライバーモードが `blocking` から `non-blocking` に変更され、ログ記録よりもタスクの可用性が優先されるようになりました。この変更以降も `blocking` モードを引き続き使用するには、次のいずれかを実行してください。
+ コンテナ定義の `logConfiguration` の `mode` オプションを `blocking` に設定します。
+ `defaultLogDriverMode` アカウント設定を `blocking` に設定します。
`max-buffer-size`
必須: いいえ
デフォルト値: `10m`
`non-blocking` モードが使用されている場合、`max-buffer-size` ログオプションは、中間メッセージ用のストレージに使用されるバッファのサイズを制御します。アプリケーションに基づいて、必ず適切なバッファサイズを指定してください。バッファがいっぱいになると、それ以上ログを保存できなくなります。保存できないログは失われます。
`splunk` ログルーターを使用してログをルーティングするには、`splunk-token` と `splunk-url` を指定する必要があります。
ログの保存と分析のための AWS のサービスまたは AWS Partner Networkを送信先としたログのルーティングに `awsfirelens` ログルーターを使用するときは、`log-driver-buffer-limit` オプションを設定して、イベントがログルーターコンテナに送信される前に、メモリでバッファリングされるログのライン数を制限できます。この制限は、スループットが高い場合に発生する可能性がある、Docker 内のバッファのメモリ不足による、潜在的なログ損失の問題を解決するのに役立ちます。詳細については、「[高スループットの Amazon ECS ログの設定](firelens-docker-buffer-limit.md)」を参照してください。
`awsfirelens` を使用してログをルーティングするときに指定できるその他のオプションは、送信先に応じて異なります。Amazon Data Firehose にログをエクスポートするときは、`region` を使用して AWS リージョンを指定し、`delivery_stream` を使用してログストリームの名前を指定することができます。
Amazon Kinesis Data Streams にログをエクスポートするときは、`region` を使用して AWS リージョンを指定し、`stream` を使用してデータストリーム名を指定することができます。
Amazon OpenSearch Service にログをエクスポートするときは、`Name`、`Host` (プロトコルを使用しない OpenSearch Service エンドポイント)、`Port`、`Index`、`Type`、`Aws_auth`、`Aws_region`、`Suppress_Type_Name`、および `tls` といったオプションを指定できます。
Amazon S3 にログをエクスポートするときは、`bucket` オプションを使用してバケットを指定できます。また、`region`、`total_file_size`、`upload_timeout`、および `use_put_object` をオプションとして指定することもできます。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.19 以上を使用する必要があります。
`secretOptions`
タイプ: オブジェクト配列
必須: いいえ
ログ設定に渡すシークレットを示すオブジェクト。ログ構成で使用されるシークレットには、認証トークン、証明書、または暗号化キーを含められます。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
`name`
タイプ: 文字列
必須: はい
コンテナの環境変数として設定する値。
`valueFrom`
タイプ: 文字列
必須: はい
コンテナのログ設定に公開するシークレット。
```
"logConfiguration": {
"logDriver": "splunk",
"options": {
"splunk-url": "https://cloud.splunk.com:8080",
"splunk-token": "...",
"tag": "...",
...
},
"secretOptions": [{
"name": "splunk-token",
"valueFrom": "/ecs/logconfig/splunkcred"
}]
}
```
`firelensConfiguration`
タイプ: [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html) オブジェクト
必須: いいえ
コンテナの FireLens 構成。これは、コンテナログのログルーターの指定と設定に使用されます。詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。
```
{
"firelensConfiguration": {
"type": "fluentd",
"options": {
"KeyName": ""
}
}
}
```
`options`
タイプ: 文字列間のマッピング
必須: いいえ
ログルーターの設定時に使用するオプションの Key-Value マップ。このフィールドはオプションで、カスタム設定ファイルを指定するか、タスク、タスク定義、クラスター、コンテナインスタンスの詳細などのメタデータをログイベントに追加するために使用できます。指定した場合、使用する構文は `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}` です。詳細については、「[Amazon ECS タスク定義の例: FireLens にログをルーティングする](firelens-taskdef.md)」を参照してください。
`type`
タイプ: 文字列
必須: はい
使用するログルーター。有効な値は `fluentd` または `fluentbit` です。
#### セキュリティ
コンテナセキュリティの詳細については、「[Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-tasks-containers.html)」を参照してください。
`credentialSpecs`
タイプ: 文字列配列
必須: いいえ
Active Directory 認証用のコンテナを設定する認証情報仕様 (`CredSpec`) ファイルへの SSM または Amazon S3 の ARN のリスト。`dockerSecurityOptions` の代わりに、このパラメータを使用することをお勧めします。ARN の最大数は 1 です。
各 ARN には 2 つの形式があります。
credentialspecdomainless:MyARN
Secrets Manager にシークレットの追加セクションを持つ `CredSpec` を提供するために `credentialspecdomainless:MyARN` を使用します。シークレットでドメインへのログイン認証情報を指定します。
任意のコンテナインスタンスで実行される各タスクは、異なるドメインに参加できます。
この形式は、コンテナインスタンスをドメインに結合しなくても使用できます。
credentialspec:MyARN
単一ドメインに対して `CredSpec` を提供するために `credentialspec:MyARN` を使用します。
このタスク定義を使用するタスクを開始する前に、コンテナインスタンスをドメインに参加させる必要があります。
どちらの形式でも、SSM または Amazon S3 で `MyARN` を ARN に置き換えます。
`credspec` は、ユーザー名、パスワード、接続先のドメインを含むシークレットの ARN を Secrets Manager に提供する必要があります。セキュリティ向上のため、インスタンスはドメインレス認証のドメインに参加しません。インスタンス上の他のアプリケーションは、ドメインレス認証情報を使用できません。このパラメータを使用すると、タスクが別のドメインに参加する必要がある場合でも、同じインスタンスでタスクを実行できます。詳細については、「[Windows コンテナでの gMSAs の使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html)」および「[Linux コンテナ向け gMSAs を使用する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/linux-gmsa.html)」を参照してください。
`user`
タイプ: 文字列
必須: いいえ
コンテナ内で使用するユーザー。このパラメータは docker create-container コマンドの `User` にマッピングされ、`--user` オプションは docker run にマッピングされます。
`host` ネットワークモードを使用してタスクを実行する場合は、ルートユーザー (UID 0) を使用してコンテナを実行しないでください。セキュリティのベストプラクティスとしては、常にルート以外のユーザーを使用します。
以下の形式を使用して、`user` を指定できます。UID または GID を指定する場合は、正の整数として指定する必要があります。
+ `user`
+ `user:group`
+ `uid`
+ `uid:gid`
+ `user:gid`
+ `uid:group`
このパラメータは Windows コンテナではサポートされません。
```
"user": "string"
```
#### リソースの制限
`ulimits`
タイプ: オブジェクト配列
必須: いいえ
コンテナに定義する `ulimit` 値の一覧。この値は、オペレーティングシステムのデフォルトのリソースクォータ設定を上書きします。このパラメータは docker create-container コマンドの `Ulimits` にマッピングされ、`--ulimit` オプションは docker run にマッピングされます。
Fargate でホストされる Amazon ECS タスクは、オペレーションシステムで設定されたデフォルトのリソース制限値を使用します。ただし、`nofile` リソース制限パラメータを除きます。`nofile` リソース制限は、コンテナが使用できるオープンファイルの数の制限を設定します。Fargate では、デフォルトの `nofile` ソフト制限は ` 65535` で、ハード制限は `65535` です。両方の制限の値を設定できます (最大 `1048576`)。詳細については、「[タスクリソースの制限](fargate-tasks-services.md#fargate-resource-limits)」を参照してください。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.18 以上を使用する必要があります。
このパラメータは Windows コンテナではサポートされません。
```
"ulimits": [
{
"name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack",
"softLimit": integer,
"hardLimit": integer
}
...
]
```
`name`
タイプ: 文字列
有効な値: `"core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"`
必須: はい (`ulimits` を使用する場合)
`ulimit` の `type`。
`hardLimit`
タイプ: 整数
必須: はい (`ulimits` を使用する場合)
`ulimit` タイプのハード制限。値は、`ulimit` の `type` に応じて、バイト、秒、またはカウントとして指定できます。
`softLimit`
タイプ: 整数
必須: はい (`ulimits` を使用する場合)
`ulimit` タイプのソフト制限。値は、`ulimit` の `type` に応じて、バイト、秒、またはカウントとして指定できます。
#### Docker のラベル
`dockerLabels`
タイプ: 文字列間のマッピング
必須: いいえ
コンテナに追加するラベルのキー/値マップ。このパラメータは docker create-container コマンドの `Labels` にマッピングされ、`--label` オプションは docker run にマッピングされます。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.18 以上を使用する必要があります。
```
"dockerLabels": {"string": "string"
...}
```
### その他のコンテナ定義のパラメータ
以下のコンテナ定義パラメータは、**[Configure via JSON]** (JSON による設定) オプションを使用して、Amazon ECS コンソールでタスク定義を登録する際に使用できます。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
**Topics**
+ [Linux パラメータ](#container_definition_linuxparameters)
+ [コンテナの依存関係](#container_definition_dependson)
+ [[コンテナのタイムアウト]](#container_definition_timeout)
+ [システムコントロール](#container_definition_systemcontrols)
+ [インタラクティブ](#container_definition_interactive)
+ [擬似ターミナル](#container_definition_pseudoterminal)
#### Linux パラメータ
`linuxParameters`
型: [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) オブジェクト
必須: いいえ
[KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) など、コンテナに適用される Linux 固有のオプション。
このパラメータは Windows コンテナではサポートされません。
```
"linuxParameters": {
"capabilities": {
"add": ["string", ...],
"drop": ["string", ...]
}
}
```
`capabilities`
型: [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) オブジェクト
必須: いいえ
Docker によって提供されているデフォルト設定から削除されたコンテナ用の Linux 機能。これらの Linux 機能の詳細については、Linux マニュアルページの「[機能 (7)](http://man7.org/linux/man-pages/man7/capabilities.7.html)」を参照してください。
`add`
タイプ: 文字列配列
有効な値: `"SYS_PTRACE"`
必須: いいえ
Docker によって提供されているデフォルト設定のコンテナに追加する Linux 機能。このパラメータは docker create-container コマンドの `CapAdd` にマッピングされ、`--cap-add` オプションは docker run にマッピングされます。
`drop`
タイプ: 文字列配列
有効な値: `"ALL" | "AUDIT_CONTROL" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"`
必須: いいえ
Docker によって提供されているデフォルト設定のコンテナから削除する Linux 機能。このパラメータは docker create-container コマンドの `CapDrop` にマッピングされ、`--cap-drop` オプションは docker run にマッピングされます。
`devices`
コンテナに公開するすべてのホストデバイス。このパラメータは docker create-container コマンドの `Devices` にマッピングされ、`--device` オプションは docker run にマッピングされます。
Fargate 起動タイプを使用する場合、`devices` パラメータはサポートされません。
タイプ: [デバイス](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html)オブジェクト配列
必須: いいえ
`hostPath`
ホストコンテナインスタンス上のデバイスのパス。
タイプ: 文字列
必須: はい
`containerPath`
ホストデバイスを公開する先のコンテナ内のパス。
タイプ: 文字列
必須: いいえ
`permissions`
デバイス用のコンテナに提供する明示的な許可。デフォルトでは、コンテナにはデバイスの `read`、`write`、および `mknod` のアクセス許可があります。
型: 文字列の配列
有効な値: `read` \$1 `write` \$1 `mknod`
`initProcessEnabled`
信号を転送しプロセスを利用するコンテナ内で、`init` を実行。このパラメータは docker run の `--init` オプションにマッピングされます。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.25 以上を使用する必要があります。
`maxSwap`
このパラメータは、Fargate で実行されるタスクではサポートされません。
コンテナが使用できるスワップメモリの合計 (MiB 単位)。このパラメータは、docker run の `--memory-swap` オプションに変換されます。値はコンテナメモリの合計に `maxSwap` の値を加えた値です。
`0` の `maxSwap` 値を指定した場合、コンテナはスワップを使用しません。許容値は、`0` または任意の正の整数です。`maxSwap` パラメータを省略すると、コンテナは実行中のコンテナインスタンスのスワップ設定を使用します。`swappiness` パラメータを使用するには、`maxSwap` 値を設定する必要があります。
`sharedMemorySize`
`/dev/shm` ボリュームのサイズ値 (MiB) です。このパラメータは docker run の `--shm-size` オプションにマッピングされます。
Fargate を使用するタスクを使用している場合、`sharedMemorySize` パラメータはサポートされません。
タイプ: 整数
`tmpfs`
tmpfs マウントのコンテナパス、マウントオプション、および最大サイズ (MiB) です。このパラメータは docker run の `--tmpfs` オプションにマッピングされます。
型: [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) オブジェクト配列
必須: いいえ
`containerPath`
tmpfs ボリュームがマウントされる絶対ファイルパスです。
タイプ: 文字列
必須: はい
`mountOptions`
tmpfs ボリュームのマウントオプションのリストです。
型: 文字列の配列
必須: いいえ
有効な値: `"defaults" | "ro" | "rw" | "suid" | "nosuid" | "dev" | "nodev" | "exec" | "noexec" | "sync" | "async" | "dirsync" | "remount" | "mand" | "nomand" | "atime" | "noatime" | "diratime" | "nodiratime" | "bind" | "rbind" | "unbindable" | "runbindable" | "private" | "rprivate" | "shared" | "rshared" | "slave" | "rslave" | "relatime" | "norelatime" | "strictatime" | "nostrictatime" | "mode" | "uid" | "gid" | "nr_inodes" | "nr_blocks" | "mpol"`
`size`
tmpfs ボリュームの最大サイズ (MiB) です。
タイプ: 整数
必須: はい
#### コンテナの依存関係
`dependsOn`
型: [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) オブジェクトの配列
必須: いいえ
コンテナの起動と停止に定義されている依存関係。コンテナには複数の依存関係を含めることができます。依存関係がコンテナの起動に対して定義されている場合、コンテナの停止の場合、依存関係は逆になります。例については、[コンテナの依存関係](example_task_definitions.md#example_task_definition-containerdependency)を参照してください。
あるコンテナが依存関係における制限事項を満たさない場合、または制限を満たす前にタイムアウトした場合、Amazon ECS は、依存関係にある他のコンテナの状態も次に遷移させることはしません。
このパラメータでは、タスクまたはサービスがプラットフォームバージョン `1.3.0` 以降（Linux）または `1.0.0`（Windows）を使用している必要があります。
```
"dependsOn": [
{
"containerName": "string",
"condition": "string"
}
]
```
`containerName`
タイプ: 文字列
必須: はい
コンテナ名が指定された条件を満たしている必要があります。
`condition`
タイプ: 文字列
必須: はい
コンテナの依存関係の条件です。使用可能な条件とその動作を以下に示します。
+ `START` - この条件は、すぐに現在のリンクとボリュームの動作をエミュレートします。この条件は、他のコンテナの開始を許可する前に、依存コンテナが開始されていることを検証します。
+ `COMPLETE` - この条件は、他のコンテナの開始を許可する前に、依存コンテナの実行が完了 (終了) することを検証します。これは、スクリプトを実行して終了するだけの、重要性の低いコンテナのために便利です。この条件は、必須コンテナには設定できません。
+ `SUCCESS` - この条件は `COMPLETE` と同じですが、コンテナが `zero` ステータスで終了していることも必要です。この条件は、必須コンテナには設定できません。
+ `HEALTHY` — この条件は、他のコンテナの開始を許可する前に、依存コンテナがそのコンテナのヘルスチェックに合格したことを検証します。これには、タスク定義に設定されているヘルスチェックが依存コンテナにある必要があります。タスクの起動時にのみ、この条件が確認されます。
#### [コンテナのタイムアウト]
`startTimeout`
タイプ: 整数
必須: いいえ
値の例: `120`
コンテナの依存関係解決の再試行を止めるまでの待機時間 (秒)。
例えば、タスク定義内に 2 つのコンテナを指定するとします。`containerA` は、`COMPLETE`、`SUCCESS`、または `HEALTHY` のいずれかのステータスに到達する `containerB` に依存関係を持ちます。`startTimeout` の値に `containerB` が指定されていて、コンテナが時間内に目標のステータスまで到達しない場合、`containerA` は開始しません。
あるコンテナが依存関係における制限事項を満たさない場合、または制限を満たす前にタイムアウトした場合、Amazon ECS は、依存関係にある他のコンテナの状態も次に遷移させることはしません。
このパラメータでは、タスクまたはサービスがプラットフォームバージョン `1.3.0` 以降（Linux）を使用している必要があります。最大値は 120 秒です。
`stopTimeout`
タイプ: 整数
必須: いいえ
値の例: `120`
コンテナが正常に終了しなかった場合にコンテナが強制終了されるまでの待機時間 (秒)。
このパラメータでは、タスクまたはサービスがプラットフォームバージョン `1.3.0` 以降（Linux）を使用している必要があります。このパラメータを指定しない場合には、デフォルト値の 30 秒が適用されます。最大値は 120 秒です。
#### システムコントロール
`systemControls`
型: [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) オブジェクト
必須: いいえ
コンテナ内で設定する名前空間カーネルパラメータのリスト。このパラメータは docker create-container コマンドの `Sysctls` にマッピングされ、`--sysctl` オプションは docker run にマッピングされます。例えば、接続をより長く維持するように `net.ipv4.tcp_keepalive_time` 設定を構成できます。
`awsvpc` または `host` ネットワークモードも使用する単一のタスクで、複数のコンテナに対してネットワーク関連の `systemControls` パラメータを指定することは推奨されません。これを行うと、次のような欠点があります。
+ `systemControls` をいずれかのコンテナ用に設定した場合、タスク内のすべてのコンテナに適用されます。単一のタスクの複数のコンテナに対して異なる `systemControls` を設定すると、最後に開始されたコンテナによって、有効になる `systemControls` が決定します。
タスク内でコンテナに使用するため IPC リソース名前空間を設定している場合、システムコントロールには以下の条件が適用されます。詳細については、「[IPC モード](#task_definition_ipcmode)」を参照してください。
+ `host` IPC モードを使用するタスクの場合、IPC 名前空間の `systemControls` はサポートされていません。
+ `task` IPC モードを使用するタスクでは、IPC 名前空間の `systemControls` 値が、タスク内のすべてのコンテナに適用されます。
このパラメータは Windows コンテナではサポートされません。
このパラメータは、プラットフォームバージョン `1.4.0` 以降 (Linux) を使用する場合に、AWS Fargate でホストされたタスクでのみサポートされます。このパラメータは Fargate 上の Windows コンテナではサポートされません。
```
"systemControls": [
{
"namespace":"string",
"value":"string"
}
]
```
`namespace`
タイプ: 文字列
必須: いいえ
`value` を設定する名前空間カーネルパラメータ。
有効な IPC 名前空間の値: `"fs.mqueue.*"` で開始する `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"`、および `Sysctls`
有効なネットワーク名前空間値: `"net.*"` で始まる `Sysctls`。Fargate では、コンテナ内に存在する名前空間 `Sysctls` のみが受け入れられます。
これらの値はすべて Fargate でサポートされています。
`value`
タイプ: 文字列
必須: いいえ
`namespace` で指定された名前空間カーネルパラメータの値。
#### インタラクティブ
`interactive`
タイプ: ブール値
必須: いいえ
このパラメータが `true` の場合、`stdin` または `tty` を割り当てる必要がある、コンテナ化されたアプリケーションをデプロイすることができます。このパラメータは docker create-container コマンドの `OpenStdin` にマッピングされ、`--interactive` オプションは docker run にマッピングされます。
デフォルト: `false`。
#### 擬似ターミナル
`pseudoTerminal`
タイプ: ブール値
必須: いいえ
このパラメータが `true` の場合、TTY が割り当てられます。このパラメータは docker create-container コマンドの `Tty` にマッピングされ、`--tty` オプションは docker run にマッピングされます。
デフォルト: `false`。
## Elastic Inference アクセラレーター名 (廃止)
タスク定義用の Elastic Inference アクセラレーターのリソース要件。
**注記**
Amazon Elastic Inference (EI) は利用できなくなりました。
以下のパラメータをタスク定義で使用できます。
`deviceName`
タイプ: 文字列
必須: はい
Elastic Inference アクセラレーターのデバイス名。`deviceName` は、コンテナ定義でも参照されます。[Elastic Inference accelerator](#ContainerDefinition-elastic-inference) を参照してください。
`deviceType`
タイプ: 文字列
必須: はい
使用する Elastic Inference アクセラレーター。
## プロキシ設定
`proxyConfiguration`
タイプ: [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) オブジェクト
必須: いいえ
App Mesh プロキシ設定の詳細。
このパラメータは Windows コンテナではサポートされません。
```
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "string",
"properties": [
{
"name": "string",
"value": "string"
}
]
}
```
`type`
タイプ: 文字列
重要な値: `APPMESH`
必須: いいえ
プロキシのタイプ。`APPMESH` はサポートされる唯一の値です。
`containerName`
タイプ: 文字列
必須: はい
App Mesh プロキシとして機能するコンテナの名前です。
`properties`
タイプ: [パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KeyValuePair.html)オブジェクトの配列
必須: いいえ
Container Network Interface(CNI) プラグインを提供するネットワーク構成パラメータのセットで、キーと値のペアとして指定されます。
+ `IgnoredUID` - (必須) コンテナ定義の `user` パラメータで定義されるプロキシコンテナのユーザー ID (UID)。これは、プロキシがそれ自体のトラフィックを無視するようにするために使用されます。`IgnoredGID` を指定した場合は、このフィールドは空にできます。
+ `IgnoredGID` - (必須) コンテナ定義の `user` パラメータで定義されるプロキシコンテナのグループ ID (GID)。これは、プロキシがそれ自体のトラフィックを無視するようにするために使用されます。`IgnoredUID` を指定した場合は、このフィールドは空にできます。
+ `AppPorts` - (必須) アプリケーションが使用するポートのリスト。これらのポートへのネットワークトラフィックは `ProxyIngressPort` および `ProxyEgressPort` に転送されます。
+ `ProxyIngressPort` - (必須) `AppPorts` への着信トラフィックが誘導されるポートを指定します。
+ `ProxyEgressPort` - (必須) `AppPorts` からの発信トラフィックが誘導されるポートを指定します。
+ `EgressIgnoredPorts` – (必須) 指定されたこれらのポートに向かうアウトバウンドトラフィックは無視され、`ProxyEgressPort` にリダイレクトされません。空のリストを指定できます。
+ `EgressIgnoredIPs` – (必須) 指定されたこれらの IP アドレスに向かうアウトバウンドトラフィックは無視され、`ProxyEgressPort` にリダイレクトされません。空のリストを指定できます。
`name`
タイプ: 文字列
必須: いいえ
キーと値のペアの名前。
`value`
タイプ: 文字列
必須: いいえ
キーと値のペアの値。
## ボリューム
タスク定義を登録する際、コンテナインスタンスの Docker デーモンに渡されるボリュームのリストを任意で指定することができます。すると、同じコンテナインスタンス上の他のコンテナで使用できるようになります。
使用できるデータボリュームの種類は以下のとおりです。
+ Amazon EBS ボリューム – データ集約型のコンテナ化されたワークロード向けに、費用対効果が高く、耐久性があり、高性能なブロックストレージを提供します。スタンドアロンタスクを実行するとき、またはサービスを作成または更新するときに、Amazon ECS タスクごとに 1 つの Amazon EBS ボリュームをアタッチできます。Amazon EBS ボリュームは、Fargate でホストされている Linux タスクでサポートされています。詳細については、「[Amazon ECS での Amazon EBS ボリュームの使用](ebs-volumes.md)」を参照してください。
+ Amazon EFS ボリューム - Amazon ECS タスクで使用するためのシンプルかつスケーラブルで、永続的なファイルストレージを提供します。Amazon EFSでは、ストレージ容量は伸縮性があります。この容量は、ファイルの追加や削除に伴い自動的に拡大および縮小されます。アプリケーションは、必要なときに必要なストレージを確保できます。Amazon EFS ボリュームは、Fargate でホストされるタスクでサポートされます。詳細については、「[Amazon ECS での Amazon EFS ボリュームの使用](efs-volumes.md)」を参照してください。
+ FSx for Windows File Server ボリューム – 完全マネージド型の Microsoft Windows ファイルサーバーを提供します。これらのファイルサーバは、Windows ファイルシステムによってバックアップされています。Amazon ECS と共に FSx for Windows File Server を使用する場合、永続的、分散型、共有型、および静的なファイルストレージを使用して、Windows タスクをプロビジョニングすることが可能です。詳細については、「[Amazon ECS での FSx for Windows File Server ボリュームの使用](wfsx-volumes.md)」を参照してください。
このオプションは Fargate の Windows コンテナではサポートされません。
+ バインドマウント – ホストマシン上のファイルやディレクトリがコンテナにマウントされます。バインドマウントホストボリュームは、タスク実行時にサポートされます。バインドマウントのホストボリュームを使用するには、タスク定義で `host` およびオプションの `sourcePath` 値を使用します。
詳細については、「[Amazon ECS タスクのストレージオプション](using_data_volumes.md)」を参照してください。
以下のパラメータをコンテナ定義で使用できます。
`name`
タイプ: 文字列
必須: いいえ
ボリュームの名前。最大 255 文字の英字 (大文字と小文字の区別あり)、数字、ハイフン (`-`)、アンダースコア (`_`) を使用できます。この名前は、コンテナ定義 `mountPoints` オブジェクトの `sourceVolume` パラメータで参照されます。
`host`
必須: いいえ
`host` パラメーターは、バインドマウントのライフサイクルを、タスクではなくホスト Amazon EC2 インスタンスと、それが格納されている場所に関連付けるために使用されます。`host` パラメーターが空の場合、Docker デーモンはデータボリュームのホストパスを割り当てますが、関連付けられたコンテナの実行が停止した後にデータが保持されるとは限りません。
Windows コンテナは `$env:ProgramData` と同じドライブに全部のディレクトリをマウントできます。
`sourcePath` パラメータは、Amazon EC2 インスタンスまたは Amazon ECS マネージドインスタンスでホストされているタスクを使用する場合にのみサポートされます。
`sourcePath`
タイプ: 文字列
必須: いいえ
`host` パラメータを使用する場合は、`sourcePath` を指定して、コンテナに表示されるホスト Amazon EC2 インスタンスのパスを宣言します。このパラメータが空の場合は、Docker デーモンによってホストパスが割り当てられます。`host` パラメータに `sourcePath` の場所が含まれている場合、データボリュームは手動で削除するまでホスト Amazon EC2 インスタンスの指定された場所に保持されます。`sourcePath` の値がホスト Amazon EC2 インスタンスに存在しない場合は、Docker デーモンによって作成されます。その場所が存在する場合は、ソースパスフォルダの内容がエクスポートされます。
`configuredAtLaunch`
タイプ: ブール値
必須: いいえ
起動時にボリュームを設定可能にするかどうかを指定します。`true` に設定すると、スタンドアロンタスクを実行するとき、またはサービスを作成または更新するときにボリュームを設定できます。`true` に設定すると、タスク定義内で別のボリューム設定を提供することはできません。タスクにアタッチする Amazon EBS ボリュームを設定するには、このパラメータを `true` に設定する必要があります。`configuredAtLaunch` を `true` に設定し、ボリューム設定を起動フェーズに先送りすることで、ボリュームタイプや特定のボリューム設定に限定されないタスク定義を作成できます。こうすることで、タスク定義をさまざまな実行環境で再利用できるようになります。詳細については、「[Amazon EBS ボリューム](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html)」を参照してください。
`dockerVolumeConfiguration`
タイプ: [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) オブジェクト
必須: いいえ
このパラメータは、Docker ボリュームを使用する場合に指定します。Docker ボリュームは、EC2 インスタンスでタスクを実行する場合にのみサポートされます。Windows コンテナでは、`local` ドライバーの使用のみがサポートされます。バインドマウントを使用するには、代わりに `host` を指定します。
`scope`
タイプ: 文字列
有効な値: `task` \$1 `shared`
必須: いいえ
Docker ボリュームのスコープ。これにより、ボリュームのライフサイクルが決定されます。Docker ボリュームの範囲が `task` の場合は、タスクが開始すると自動的にプロビジョンされ、タスクが停止すると破棄されます。Docker ボリュームの範囲が `shared` の場合は、タスクの停止後も保持されます。
`autoprovision`
タイプ: ブール値
デフォルト値: `false`
必須: いいえ
この値が `true` の場合、既に存在していない場合は Docker ボリュームが作成されます。このフィールドは、`scope` が `shared` の場合にのみ使用されます。`scope` が `task` の場合、このパラメータは省略する必要があります。
`driver`
タイプ: 文字列
必須: いいえ
使用する Docker ボリュームドライバー。この名前はタスク配置に使用されるため、ドライバー値は Docker で提供されているドライバー名と一致する必要があります。ドライバーが Docker プラグイン CLI を使用してインストールされた場合は、`docker plugin ls` を使用してコンテナインスタンスからドライバー名を取得します。ドライバーが別の方法でインストール済みである場合は、Docker プラグイン検出を使用してドライバー名を取得します。
`driverOpts`
タイプ: 文字列
必須: いいえ
パススルーする Docker ドライバー固有のオプションのマップ。このパラメータは、Docker の「Create a volume」セクションの `DriverOpts` にマッピングされます。
`labels`
タイプ: 文字列
必須: いいえ
Docker ボリュームに追加するカスタムメタデータ。
`efsVolumeConfiguration`
タイプ: [EFSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) オブジェクト
必須: いいえ
このパラメータは、Amazon EFS ボリュームを使用する場合に指定します。
`fileSystemId`
タイプ: 文字列
必須: はい
使用する Amazon EFS ファイルシステムの ID。
`rootDirectory`
タイプ: 文字列
必須: いいえ
ホスト内にルートディレクトリとしてマウントする Amazon EFS ファイルシステム内のディレクトリ。このパラメータを省略すると、Amazon EFS ボリュームのルートが使用されます。`/` を指定すると、このパラメータを省略した場合と同じ結果になります。
`authorizationConfig` で EFS アクセスポイントが指定されている場合は、ルートディレクトリパラメータを省略するか `/` に設定して、EFS アクセスポイントにパスを設定する必要があります。
`transitEncryption`
タイプ: 文字列
有効な値: `ENABLED` \$1 `DISABLED`
必須: いいえ
Amazon ECS ホストと Amazon EFS サーバー間で、転送中の Amazon EFS データの暗号化を有効にするかどうかを指定します。Amazon EFS IAM 認可を使用する場合は、転送中の暗号化を有効にする必要があります。このパラメータを省略すると、`DISABLED` のデフォルト値が使用されます。詳細については、*Amazon Elastic ファイルシステムユーザーガイド*の「[転送中データの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html)」を参照してください。
`transitEncryptionPort`
タイプ: 整数
必須: いいえ
Amazon ECS ホストと Amazon EFS サーバーとの間で、暗号化されたデータを送信するときに使用するポート。転送暗号化ポートを指定しない場合、タスクでは Amazon EFS マウントヘルパーが使用するポート選択戦略が使用されます。詳細については、*[Amazon Elastic File System User Guide]* (Amazon Elastic File System ユーザーガイド) の[[EFS Mount Helper]](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) (EFS マウントヘルパー) を参照してください。
`authorizationConfig`
タイプ: [EFSAuthorizationConfig](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSAuthorizationConfig.html) オブジェクト
必須: いいえ
Amazon EFS ファイルシステムに対する認可構成の詳細。
`accessPointId`
タイプ: 文字列
必須: いいえ
使用するアクセスポイント ID。アクセスポイントが指定されている場合は、`efsVolumeConfiguration` のルートディレクトリ値を省略するか `/` に設定して、EFS アクセスポイントにパスを設定する必要があります。アクセスポイントを使用する場合は、`EFSVolumeConfiguration` で転送中の暗号化を有効にする必要があります。詳細については、*Amazon Elastic ファイルシステムユーザーガイド*の [Amazon EFS アクセスポイントの使用](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html)を参照してください。
`iam`
タイプ: 文字列
有効な値: `ENABLED` \$1 `DISABLED`
必須: いいえ
タスク定義で定義した Amazon ECS タスクの IAM ロールを、Amazon EFS ファイルシステムのマウント時に使用するかどうかを指定します。使用する場合は、`EFSVolumeConfiguration` で転送中の暗号化を有効にする必要があります。このパラメータを省略すると、`DISABLED` のデフォルト値が使用されます。詳細については、「[タスク用の IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)」を参照してください。
`FSxWindowsFileServerVolumeConfiguration`
タイプ: [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) オブジェクト
必須: はい
このパラメータは、タスクストレージに [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) ファイルシステムを使用する場合に指定します。
`fileSystemId`
タイプ: 文字列
必須: はい
使用する FSx for Windows File Server ファイルシステムID。
`rootDirectory`
タイプ: 文字列
必須: はい
ホスト内にルートディレクトリとしてマウントする FSx for Windows File Server ファイルシステム内のディレクトリ。
`authorizationConfig`
`credentialsParameter`
タイプ: 文字列
必須: はい
認可の認証情報オプション。
**options:**
+ [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) シークレットの Amazon リソースネーム (ARN)。
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html) パラメータの ARN。
`domain`
タイプ: 文字列
必須: はい
[AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD) ディレクトリまたはセルフホスト型 EC2 Active Directory によってホストされる完全修飾ドメイン名。
## タグ
タスク定義の登録する際、タスク定義に適用されるメタデータタグをオプションで指定できます。タグは、タスク定義を分類して組織化するのに役立ちます。各タグは、キーおよび値 (オプション) で構成されます。両方を定義します。詳細については、「[Amazon ECS リソースにタグ付けする](ecs-using-tags.md)」を参照してください。
**重要**
タグには、個人が特定可能な情報や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグは、多くの AWS のサービス (請求など) からアクセスできます。タグは、プライベートデータや機密データに使用することを意図していません。
タグオブジェクトでは、次のパラメータを使用できます。
`key`
タイプ: 文字列
必須: いいえ
タグを構成するキーと値のペアの一部。キーは、より具体的なタグ値のカテゴリのように動作する、一般的なラベルです。
`value`
タイプ: 文字列
必須: いいえ
タグを構成するキーと値のペアのオプションの一部。値はタグカテゴリ (キー) の記述子として機能します。
## その他のタスク定義パラメータ
以下のタスク定義パラメータは、Amazon ECS コンソールから、**[Configure via JSON (JSON による設定)]** オプションを使用してタスク定義を登録する際に使用します。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
**Topics**
+ [エフェメラルストレージ](#task_definition_ephemeralStorage)
+ [IPC モード](#task_definition_ipcmode)
+ [PID モード](#task_definition_pidmode)
+ [フォールトインジェクション](#task_definition_faultInjection)
### エフェメラルストレージ
`ephemeralStorage`
タイプ: [EphemeralStorage](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EphemeralStorage.html) オブジェクト
必須: いいえ
タスクに割り当てるエフェメラルストレージの容量(GB 単位)。このパラメーターは、AWS Fargate でホストされるタスクにおいて、利用可能なエフェメラルストレージの総量をデフォルトの容量を超えて拡張する際に使用します。詳細については、「[Amazon ECS でのバインドマウントの使用](bind-mounts.md)」を参照してください。
このパラメータは、プラットフォームバージョン `1.4.0` 以降 (Linux) または `1.0.0` 以降 (Windows) でのみサポートされます。
### IPC モード
`ipcMode`
このパラメータは、Fargate で実行されるタスクではサポートされません。
タイプ: 文字列
必須: いいえ
タスクのコンテナで使用する IPC リソースの名前空間。有効な値は `host`、`task` または `none` です。`host` が指定されている場合、同一のコンテナインスタンス上にある (`host` IPC モードを指定した) タスク内のすべてのコンテナは、ホスト Amazon EC2 インスタンスと同じ IPC リソースを共有します。`task` が指定されている場合、指定されたタスク内のすべてのコンテナは同じ IPC リソースを共有します。`none` が指定されている場合、タスクのコンテナ内の IPC リソースはプライベートです。タスク内またはコンテナインスタンスの他のコンテナと共有されることはありません。値を指定しない場合、IPC リソース名前空間の共有はコンテナインスタンスの Docker デーモンの設定によって異なります。
`host` IPC モードを使用する場合は、意図せず IPC 名前空間が公開されるリスクが高いことに注意してください。
タスク内のコンテナに、`systemControls` を使用して名前空間のカーネルパラメータを設定している場合は、以下の点が IPC リソース名前空間に適用されます。
+ `host` IPC モードを使用するタスクの場合、`systemControls` に関連する IPC 名前空間はサポートされません。
+ `task` IPC モードを使用するタスクでは、IPC 名前空間に関連する `systemControls` が、タスク内のすべてのコンテナに適用されます。
**注記**
このパラメータは、Windows コンテナ、または Fargate 起動タイプを使用するタスクではサポートされていません。
### PID モード
`pidMode`
タイプ: 文字列
有効な値: `host` \$1 `task`
必須: いいえ
タスクのコンテナで使用するプロセス名前空間。有効な値は `host` または `task` です。Linuxコンテナでは、有効な値は `task` のみです。例えば、サイドカーのモニタリングでは、`pidMode` が同じタスクで実行されている他のコンテナに関する情報にアクセスする必要がある場合があります。
`task` が指定されている場合、指定したタスク内のすべてのコンテナは同じプロセス名前空間を共有します。
値が指定されていない場合、デフォルトは各コンテナのプライベート名前空間です。
**注記**
このパラメータは、プラットフォームバージョン `1.4.0` 以降 (Linux) を使用する場合に、AWS Fargate でホストされたタスクでのみサポートされます。このパラメータは Fargate 上の Windows コンテナではサポートされません。
### フォールトインジェクション
`enableFaultInjection`
タイプ: ブール値
有効な値: `true` \$1 `false`
必須: いいえ
このパラメータが `true` に設定されている場合、タスクのペイロードで、Amazon ECS と Fargate はタスクのコンテナからのフォールトインジェクションリクエストを受け入れます。デフォルトでは、このパラメータは `false` に設定されます。
# Amazon EC2 における Amazon ECS タスク定義パラメータ
タスク定義は、タスクファミリー、AWS Identity and Access Management (IAM) タスクロール、ネットワークモード、コンテナ定義、ボリューム、タスク配置の制約、容量に分類されます。ファミリとコンテナの定義は、タスク定義の必須項目です。これに対して、タスクロール、ネットワークモード、ボリューム、タスク配置の制約、起動タイプは省略することができます。
これらのパラメータを JSON ファイルで使用し、タスク定義を設定できます。
Amazon EC2 の各タスク定義パラメータについて、以下に詳述します。
## ファミリー
`family`
タイプ: 文字列
必須: はい
タスク定義を登録するときに、ファミリー (複数バージョンのタスク定義の名前のようなもの) を指定する必要があります。登録したタスク定義には、リビジョン番号が与えられます。特定のファミリーに登録した最初のタスク定義には、リビジョン 1 が与えられます。その後に登録したタスク定義には、連番でリビジョン番号が与えられます。
## Capacity
タスク定義の登録時、Amazon ECS がタスク定義の検証基準となる容量を指定できます。タスク定義が指定された互換性を検証しない場合、クライアント例外が返されます。
タスク定義では、以下のパラメータが使用できます。
`requiresCompatibilities`
タイプ: 文字列配列
必須: いいえ
有効な値: `EC2`
タスク定義が検証された容量。これにより、タスク定義で使用されているすべてのパラメータが、Amazon EC2 の要件を満たしていることの確認処理が開始されます。
## タスクロール
`taskRoleArn`
タイプ: 文字列
必須: いいえ
タスク定義を登録するときに、IAM ロールのタスクロールを割り当てて、タスクのコンテナに、関連するポリシーに指定された AWS API を呼び出すためのアクセス権限を付与できます。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
Amazon ECS に最適化された Windows Server AMI を起動する場合、Windows タスク向けの IAM ロールでは、`-EnableTaskIAMRole` オプションが設定されている必要があります。また、コンテナでは、この機能を利用するために一部の構成コードを実行する必要があります。詳細については、「[Amazon EC2 Windows インスタンスの追加設定](task-iam-roles.md#windows_task_IAM_roles)」を参照してください。
## タスク実行ロール
`executionRoleArn`
タイプ: 文字列
必須: 条件による
ユーザーに代わって AWS API コールを実行するアクセス許可を Amazon ECS コンテナエージェントに付与するタスク実行ロールの Amazon リソースネーム (ARN)。
タスク実行 IAM ロールは、タスクの要件に応じて必要です。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。
## ネットワークモード
`networkMode`
タイプ: 文字列
必須: いいえ
タスクのコンテナで使用する Docker ネットワークモード。Amazon EC2 Linux インスタンスでホストされている Amazon ECS タスクの場合、有効な値は `none`、`bridge`、`awsvpc`、`host` です。ネットワークモードが指定されていない場合、デフォルトのネットワークモードは `bridge` です。Amazon EC2 Windows インスタンスでホストされる Amazon ECS タスクの場合、有効な値は `default` と `awsvpc` です。ネットワークモードが指定されていない場合、`default` ネットワークモードが使用されます。
ネットワークモードに `none` を設定した場合、タスクのコンテナは外部への接続を持たないため、コンテナ定義でポートマッピングを指定することはできません。
ネットワークモードが `bridge` の場合、タスクはそのタスクをホストする各 Amazon EC2 インスタンス内で実行される、Linux 上の Docker の組み込み仮想ネットワークを使用します。Linux の組み込み仮想ネットワークでは、`bridge` Docker ネットワークドライバーが使用されます。
ネットワークモードが `host` の場合、タスクはそのタスクをホストする Amazon EC2 インスタンスの ENI にコンテナポートを直接マッピングすることで Docker の組み込み仮想ネットワークをバイパスする、ホストのネットワークを使用します。ダイナミックポートマッピングは、このネットワークモードでは使用できません。このモードを使用するタスク定義内のコンテナには、特定の `hostPort` 番号を指定する必要があります。ホストのポート番号は、複数のタスクで使用できません。その結果として、1 つの Amazon EC2 インスタンスで同じタスク定義のタスクを複数実行することはできません。
`host` ネットワークモードをによりタスクを実行する場合、より良いセキュリティーのために、ルートユーザー (UID 0) を使用してコンテナを実行しないでください。セキュリティのベストプラクティスとしては、常にルート以外のユーザーを使用します。
ネットワークモードが `awsvpc` の場合は、タスクに Elastic Network Interface が割り当てられるため、タスク定義を使用したサービスの作成時またはタスクの実行時に `NetworkConfiguration` を指定する必要があります。詳細については、「[EC2 の Amazon ECS タスクネットワークオプション](task-networking.md)」を参照してください。
ネットワークモードが `default` の場合、タスクはそのタスクをホストする各 Amazon EC2 インスタンス内で実行される、Windows 上の Docker の組み込み仮想ネットワークを使用します。Windows の組み込み仮想ネットワークは `nat` Docker ネットワークドライバーを使用します。
`host` および `awsvpc` のネットワークモードは、Amazon EC2 のネットワークスタックを使用するので、コンテナのネットワークパフォーマンスが最大限発揮されます。`host` および `awsvpc` ネットワークモードにおいて公開されるコンテナポートは、対応するホストポート (`host` ネットワークモードの場合)、またはアタッチされた Elastic Network Interface ポート (`awsvpc` ネットワークモードの場合) に直接マッピングされます。このため、動的ホストポートマッピングは使用できません。
使用可能なネットワークモードは、基板となる EC2 インスタンスのオペレーティングシステムによって異なります。Linux の場合は、どのネットワークモードも使用できます。Windows の場合、`default` および`awsvpc` モードを使用できます。
## ランタイムプラットフォーム
`operatingSystemFamily`
タイプ: 文字列
必須: 条件による
デフォルト: LINUX
タスク定義を登録する際、オペレーティングシステムファミリを指定します。
有効な値は、`LINUX`、`WINDOWS_SERVER_2025_FULL`、`WINDOWS_SERVER_2025_CORE`、`WINDOWS_SERVER_2022_CORE`、`WINDOWS_SERVER_2022_FULL`、`WINDOWS_SERVER_2019_FULL`、および `WINDOWS_SERVER_2019_CORE`、`WINDOWS_SERVER_2016_FULL`、`WINDOWS_SERVER_2004_CORE`、および `WINDOWS_SERVER_20H2_CORE` です。
サービスで使用されるすべてのタスク定義は、このパラメータに対して同じ値を設定する必要があります。
タスク定義がサービスの一部である場合、この値はサービスの `platformFamily` 値と一致する必要があります。
`cpuArchitecture`
タイプ: 文字列
必須: 条件による
タスク定義を登録する際は、CPU アーキテクチャを指定できます。有効な値は `X86_64` および `ARM64` です。値を指定しない場合、Amazon ECS はキャパシティプロバイダーの設定に基づいて、使用可能な CPU アーキテクチャにタスクを配置しようとします。タスクが特定の CPU アーキテクチャに配置されるようにするには、タスク定義で `cpuArchitecture` の値を指定します。
サービスで使用されるすべてのタスク定義は、このパラメータに対して同じ値を設定する必要があります。
Linux タスクがある場合は、値を `ARM64` に設定できます。詳細については、「[64 ビット ARM ワークロードでの Amazon ECS タスク定義](ecs-arm64.md)」を参照してください。
## タスクサイズ
タスク定義の登録時に、そのタスクが使用する CPU とメモリの合計量を指定できます。これは、コンテナ定義レベルの `cpu` および `memory` の値とは異なります。Amazon EC2 インスタンスでホストされるタスクの場合、これらのフィールドは省略可能です。
**注記**
タスクレベル CPU およびメモリのパラメータは Windows コンテナでは無視されます。Windows コンテナではコンテナレベルリソースを指定することをお勧めします。
`cpu`
タイプ: 文字列
必須: 条件による
このパラメータは Windows コンテナではサポートされません。
タスクに適用される CPU ユニットのハード制限。JSON ファイルでは、CPU 値を CPU ユニットまたは仮想 CPU (vCPU) の文字列として指定できます。例えば、CPU 値を `1 vCPU` (vCPU) または `1024` (CPU ユニット) として指定できます。タスク定義が登録されると、vCPU 値は、CPU ユニットを示す整数に変換されます。
このフィールドはオプションです。クラスターに、要求された CPU ユニットが利用できる登録済みのコンテナインスタンスがない場合、タスクは失敗します。サポートされている値は、`0.125` vCPU から `192` vCPU までです。
`memory`
タイプ: 文字列
必須: 条件による
このパラメータは Windows コンテナではサポートされません。
タスクに適用されるメモリのハード制限です。タスク定義のメモリの値は、メビバイト (MiB) またはギガバイト (GB) の文字列として指定できます。例えば、メモリの値を `3072` (MiB) または `3 GB` (GB) のいずれかで指定できます。タスク定義が登録されると、GB 値は、MiB を示す整数に変換されます。
このフィールドはオプションです。任意の値を使用できます。タスクレベルでメモリ値が指定されている場合、コンテナレベルのメモリ値の設定は省略可能です。クラスターに、要求されたメモリが利用できる登録済みのコンテナインスタンスがない場合、タスクは失敗します。特定のインスタンスタイプについて、タスクにできるだけ多くのメモリを提供することで、リソースの使用率を最大化することができます。詳細については、「[Amazon ECS Linux コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。
## コンテナ定義
タスク定義を登録するときは、コンテナインスタンスの Docker デーモンに渡されるコンテナ定義のリストを指定する必要があります。以下のパラメータをコンテナ定義で使用できます。
**Topics**
+ [標準のコンテナ定義のパラメータ](#standard_container_definition_params_ec2)
+ [詳細コンテナ定義パラメータ](#advanced_container_definition_params_ec2)
+ [その他のコンテナ定義のパラメータ](#other_container_definition_params_ec2)
### 標準のコンテナ定義のパラメータ
以下のタスク定義のパラメータは必須であるか、ほとんどのコンテナ定義で使用されます。
**Topics**
+ [名前](#container_definition_name_ec2)
+ [Image](#container_definition_image_ec2)
+ [メモリ](#container_definition_memory_ec2)
+ [ポートマッピング](#container_definition_portmappings_ec2)
+ [プライベートリポジトリの認証情報](#container_definition_repositoryCredentials_ec2)
#### 名前
`name`
タイプ: 文字列
必須: はい
コンテナの名前。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコアを使用できます。タスク定義で複数のコンテナをリンクしている場合、あるコンテナの `name` を別のコンテナの `links` に入力できます。これにより、コンテナ同士を接続します。
#### Image
`image`
タイプ: 文字列
必須: はい
コンテナの開始に使用するイメージ。この文字列は Docker デーモンに直接渡されます。デフォルトでは、Docker Hub レジストリのイメージを使用できます。`repository-url/image:tag` または `repository-url/image@digest` で他のリポジトリを指定することもできます。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコア、コロン、ピリオド、スラッシュ、シャープ記号を使用できます。このパラメータは、docker create-container コマンドの `Image` と docker run コマンドの `IMAGE` パラメータにマッピングされます。
+ 新しいタスクが開始されると、Amazon ECS コンテナエージェントは、指定されたイメージおよびタグの最新バージョンをプルしてコンテナで使用します。ただし、リポジトリイメージの後続の更新がすでに実行されているタスクに反映されることはありません。
+ タスク定義のイメージパスでタグまたはダイジェストを指定しない場合、Amazon ECS コンテナエージェントは `latest` タグを使用して指定されたイメージを取り込みます。
+ リポジトリイメージに後から加えられた更新内容が、実行中のタスクに反映されることはありません。
+ プライベートレジストリのイメージがサポートされています。詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。
+ Amazon ECR リポジトリのイメージは、`registry/repository:tag` または `registry/repository@digest` の完全な命名規則 (例えば、`aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app:latest` や、`aws_account_id.dkr.ecr.region.amazonaws.com``/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`) を使用して指定します。
+ Docker Hub の公式リポジトリのイメージでは、1 つの名前 (例: `ubuntu` または `mongo`) を使用します。
+ Docker Hub の他のリポジトリのイメージは、組織名で修飾されます (例: `amazon/amazon-ecs-agent`)。
+ 他のオンラインリポジトリのイメージは、さらにドメイン名で修飾されます (例: `quay.io/assemblyline/ubuntu`)。
`versionConsistency`
タイプ: 文字列
有効な値: `enabled`\$1`disabled`
必須: いいえ
コンテナ定義で指定されたコンテナイメージタグを Amazon ECS がイメージダイジェストに解決するかどうかを指定します。デフォルトでは、この動作は `enabled` です。コンテナの値を `disabled` として設定した場合、Amazon ECS はコンテナイメージタグをダイジェストに解決せず、コンテナ定義で指定された元のイメージ URI をデプロイ用に使用します。コンテナイメージの解決の詳細については、「[コンテナイメージの解決](deployment-type-ecs.md#deployment-container-image-stability)」を参照してください。
#### メモリ
`memory`
タイプ: 整数
必須: いいえ
コンテナに適用されるメモリの量 (MiB 単位)。コンテナは、ここで指定したメモリを超えようとすると、強制終了されます。タスク内のすべてのコンテナ用に予約されるメモリの合計量は、タスクの `memory` 値より小さくする必要があります (指定されている場合)。このパラメータは docker create-container コマンドの `Memory` にマッピングされ、`--memory` オプションは docker run にマッピングされます。
タスクレベルのメモリ値またはコンテナレベルのメモリ値を指定する必要があります。`memory` コンテナレベルと `memoryReservation` 値の両方を指定する場合、`memory` 値は `memoryReservation` 値より大きくする必要があります。`memoryReservation` を指定する場合、コンテナが配置されているコンテナインスタンスで使用可能なメモリリソース量から、上記の値が減算されます。それ以外の場合は、`memory` の値が使用されます。
Docker デーモン 20.10.0 以降によって、コンテナ用として 6 MiB 以上のメモリが予約されます。従って、このコンテナに対しては 6 MiB 未満のメモリは指定しないようにします。
Docker デーモン 19.03.13-ce 以降では、コンテナ用として 4 MiB 以上のメモリが予約されます。このため、このコンテナ用には 4 MiB 未満のメモリを指定しないようにします。
リソースの使用率を最大化することを目的に、特定のインスタンスタイプにおいて、タスクにできるだけ多くのメモリを提供する場合には、「[Amazon ECS Linux コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。
`memoryReservation`
タイプ: 整数
必須: いいえ
コンテナ用に予約するメモリのソフト制限 (MiB 単位)。システムメモリに競合がある場合、Docker はコンテナのメモリ量をこのソフト制限値内に維持しようとします。ただし、コンテナは必要に応じてより多くのメモリを使用することができます。コンテナは、`memory` パラメーターで指定されたハード制限 (該当する場合) またはコンテナインスタンス上の利用可能なすべてのメモリのいずれか早く達する方まで使用できます。このパラメータは docker create-container コマンドの `MemoryReservation` にマッピングされ、`--memory-reservation` オプションは docker run にマッピングされます。
タスクレベルでメモリ値を指定しない場合、コンテナ定義で `memory` または `memoryReservation` の一方または両方に 0 以外の整数を指定する必要があります。両方を指定する場合、`memory` は `memoryReservation` より大きいことが必要です。`memoryReservation` を指定する場合、コンテナが配置されているコンテナインスタンスで使用可能なメモリリソース量から、上記の値が減算されます。それ以外の場合は、`memory` の値が使用されます。
例えば、コンテナが通常 128 MiB のメモリを使用しているが、短期間にメモリが 256 MiB にバーストする場合があるとします。128 MiB の `memoryReservation` と 300 MiB の `memory` ハード制限を設定できます。この設定では、コンテナが、コンテナインスタンスの残りのリソースから 128 MiB のメモリのみを予約できます。同時に、この構成により、コンテナは必要に応じてより多くのメモリ リソースを使用できるようになります。
このパラメータは Windows コンテナではサポートされません。
Docker デーモン 20.10.0 以降によって、コンテナ用として 6 MiB 以上のメモリが予約されます。従って、このコンテナに対しては 6 MiB 未満のメモリは指定しないようにします。
Docker デーモン 19.03.13-ce 以降では、コンテナ用として 4 MiB 以上のメモリが予約されます。このため、このコンテナ用には 4 MiB 未満のメモリを指定しないようにします。
リソースの使用率を最大化することを目的に、特定のインスタンスタイプにおいて、タスクにできるだけ多くのメモリを提供する場合には、「[Amazon ECS Linux コンテナインスタンスのメモリを予約する](memory-management.md)」を参照してください。
#### ポートマッピング
`portMappings`
タイプ: オブジェクト配列
必須: いいえ
ポートマッピングは、コンテナのネットワークポートを外部に公開します。これは、クライアントがアプリケーションにアクセスすることを可能にします。これは、同じタスク内にあるコンテナ間の通信にも使用されます。
`awsvpc` ネットワークモードを使用するタスク定義では、`containerPort` のみを指定します。`hostPort` は常に無視され、コンテナポートはホスト上の番号が大きいランダムなポートに自動的にマップされます。
Windows のポートマッピングでは、`localhost` の代わりに `NetNAT` ゲートウェイを使用します。Windows のポートマッピングにはループバックが存在しないため、ホスト自体からコンテナのマッピングされたポートにアクセスはできません。
このパラメータのほとんどのフィールド (`containerPort`、`hostPort`、`protocol` を含む) は docker create-container コマンドの `PortBindings` にマッピングされ、`--publish` オプションは docker run にマッピングされます。タスク定義でネットワークモードを `host` に設定している場合、ホストポートは未定義とするか、ポートマッピングのコンテナポートと一致させる必要があります。
タスクが `RUNNING` ステータスに達すると、手動および自動で割り当てられたホストとコンテナポートが次の場所で表示されます:
+ コンソール: 指定されたタスクのコンテナ詳細の [**Network Bindings**] セクション。
+ AWS CLI: `networkBindings` コマンド出力の **describe-tasks** セクション。
+ API: `DescribeTasks` レスポンス。
+ メタデータ: タスクメタデータのエンドポイント。
`appProtocol`
タイプ: 文字列
必須: いいえ
ポートマッピングに使用されるアプリケーションプロトコル。このパラメータは Service Connect にのみ適用されます。アプリケーションが使用するプロトコルと一貫性を持つように、このパラメータを設定することをお勧めします。このパラメータを設定すると、Amazon ECS はサーバー コネクト プロキシにプロトコル固有の接続処理を追加します。このパラメータを設定すると、Amazon ECS は Amazon ECS コンソールと CloudWatch にプロトコル固有のテレメトリを追加します。
このパラメータ値を設定しないと、TCP が使用されます。ただし、Amazon ECS では、TCP 用のプロトコル固有のテレメトリーは追加されません。
詳細については、「[Service Connect を使用して Amazon ECS サービスを短縮名で接続する](service-connect.md)」を参照してください。
有効なプロトコル値: `"http" | "http2" | "grpc" `
`containerPort`
タイプ: 整数
必須: はい (`portMappings` を使用する場合)
ユーザーが指定したホストポートまたは自動的に割り当てられたホストポートにバインドされるコンテナポートの番号。
`awsvpc` ネットワークモードを使用するタスクの場合は、`containerPort` を使用して公開ポートを指定します。
EC2 キャパシティプロバイダーのタスクでコンテナを使用しており、ホストポートではなくコンテナポートを指定するとします。その後、コンテナはエフェメラルポート範囲内のホストポートを自動で受け取ります。詳細については、「`hostPort`」を参照してください。この方法で自動的に割り当てられるれるポートマッピングは、コンテナインスタンスの予約済みポート数 100 個のクォータに対してはカウントされません。
`containerPortRange`
タイプ: 文字列
必須: いいえ
動的にマッピングされたホストポート範囲にバインドされるコンテナのポート番号の範囲。
このパラメータは、`register-task-definition` API を使用してのみ設定できます。このオプションは、`portMappings` パラメータで使用できます。詳細については、「*AWS Command Line Interface リファレンス*」の「[register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html)」を参照してください。
`containerPortRange` を指定するときは、以下のルールが適用されます。
+ `bridge` ネットワークモードまたは `awsvpc` ネットワークモードのいずれかを使用する必要があります。
+ このパラメータは、Linux と Windows の両オペレーティングシステムで使用できます。
+ コンテナインスタンスには、少なくともコンテナエージェントのバージョン 1.67.0 と `ecs-init` パッケージのバージョン 1.67.0-1 が必要です。
+ 各コンテナにつき、最大 100 のポートレンジを指定できます。
+ `hostPortRange` は指定しません。`hostPortRange` の値は次のように設定されます。
+ `awsvpc` ネットワークモードのタスク内のコンテナでは、`hostPort` は `containerPort` と同じ値に設定されます。これは静的マッピング戦略です。
+ `bridge` ネットワークモードのタスク内のコンテナの場合、Amazon ECS エージェントはデフォルトの一時範囲から開いているホストポートを見つけ、それを docker に渡してコンテナポートにバインドします。
+ `containerPortRange` の有効な値は 1～65535 です。
+ 1 つのポートは、コンテナごとに 1 つのポートマッピングにのみ含められます。
+ 重複するポート範囲は指定できません。
+ 範囲内の最初のポートは、最後のポートよりも小さくなければなりません。
+ Docker では、ポートの数が多い場合は、Docker デーモン設定ファイルの docker-proxy をオフにすることをお勧めします。
詳細については、GitHub の [Issue \$111185](https://github.com/moby/moby/issues/11185) を参照してください。
Docker デーモン設定ファイルの docker-proxy をオフにする方法については、*Amazon ECS 開発者ガイド*の「[Docker デーモン](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bootstrap_container_instance.html#bootstrap_docker_daemon)」を参照してください。
[DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) を呼び出すと、コンテナポートにバインドされているホストポートである `hostPortRange` を表示できます。
ポート範囲は、EventBridge に送信される Amazon ECS タスクイベントに含まれません。詳細については、「[EventBridge を使用して Amazon ECS エラーへの対応を自動化する](cloudwatch_event_stream.md)」を参照してください。
`hostPortRange`
タイプ: 文字列
必須: いいえ
ネットワークバインディングで使用されるホストのポート番号範囲。これは Docker によって割り当てられ、Amazon ECS エージェントによって配信されます。
`hostPort`
タイプ: 整数
必須: いいえ
コンテナ用に予約するコンテナインスタンスのポート番号。
コンテナポートマッピングに、予約されていないホストポートを指定できます。これは、*静的*ホストポートマッピングと呼ばれます。または、`containerPort` を指定するときに `hostPort` を省略 (または `0` に設定) できます。コンテナは、コンテナインスタンスのオペレーティングシステムと Docker バージョンに応じたエフェメラルポート範囲のポートを自動で受け取ります。これは、*動的*ホストポートマッピングと呼ばれます。
Docker バージョン 1.6.0 以降のデフォルトの一時ポート範囲は、インスタンスの `/proc/sys/net/ipv4/ip_local_port_range` にリストされています。このカーネルパラメータが使用できない場合、`49153–65535` から始まるデフォルトのエフェメラルポート範囲が使用されます。エフェメラルポート範囲では、ホストポートを指定しないでください。これらの範囲は自動割り当て用に予約済みです。一般的に、`32768` より小さい番号のポートは一時ポート範囲に含まれません。ECS コンテナエージェント設定内の `ECS_DYNAMIC_HOST_PORT_RANGE` 設定を使用して、動的に割り当てられたホストポートのカスタム範囲を指定できます。これは、エフェメラルポート範囲からのポートも使用するアウトバウンド接続など、コンテナインスタンス上の他のプロセスとのポート競合が原因でタスクが開始されない場合に役立ちます。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
デフォルトの予約済みポートは、SSH 用の `22`、Docker ポートの `2375` および `2376`、Amazon ECS コンテナエージェントポートの `51678-51680` です。実行中のタスクに対して以前にユーザーが指定したホストポートも、タスクの実行中に予約されます。タスクが停止すると、ホストポートはリリースされます。現在の予約済みポートは、**describe-container-instances** 出力の `remainingResources` に表示されます。コンテナインスタンスには、デフォルトの予約済みポートを含めて、一度に最大 100 個の予約済みポートを割り当てられます。自動的に割り当てられるポートは、この 100 個の予約済みポートクォータにはカウントされません。
`name`
タイプ: 文字列
必須: いいえ。サービスに Service Connect および VPC Lattice を設定する場合は必要です。
ポートマッピングに使用される名前。このパラメータは Service Connect および VPC Lattice にのみ適用されます。このパラメータは、サービスの Service Connect および VPC Lattice 設定で使用する名前です。
詳細については、「[Service Connect を使用して Amazon ECS サービスを短縮名で接続する](service-connect.md)」を参照してください。
次の例では、Service Connect および VPC Lattice の 2 つの必須フィールドが使用されています。
```
"portMappings": [
{
"name": string,
"containerPort": integer
}
]
```
`protocol`
タイプ: 文字列
必須: いいえ
ポートマッピングに使用されるプロトコル。有効な値は、`tcp` および `udp` です。デフォルト: `tcp`。
`tcp` は Service Connect でのみサポートされます。このフィールドが設定されていない場合は、`tcp` が暗示されることに注意してください。
UDP サポートは、バージョン 1.2.0 以降の Amazon ECS コンテナエージェント (`amzn-ami-2015.03.c-amazon-ecs-optimized` AMI など)、またはバージョン 1.3.0 以降に更新したコンテナエージェントで起動されたコンテナインスタンスでのみ使用できます。コンテナエージェントを最新バージョンに更新するには、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。
ホストポートを指定する際は、以下の構文を使用します。
```
"portMappings": [
{
"containerPort": integer,
"hostPort": integer
}
...
]
```
自動割り当てのホストポートが必要な場合は、以下の構文を使用します。
```
"portMappings": [
{
"containerPort": integer
}
...
]
```
#### プライベートリポジトリの認証情報
`repositoryCredentials`
タイプ: [RepositoryCredentials](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RepositoryCredentials.html) オブジェクト
必須: いいえ
プライベートレジストリ認証用のリポジトリ認証情報。
詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。
`credentialsParameter`
タイプ: 文字列
必須: はい (`repositoryCredentials` を使用する場合)
プライベートリポジトリの認証情報が含まれているシークレットの Amazon リソースネーム (ARN)。
詳細については、「[Amazon ECS での AWS 以外のコンテナイメージの使用](private-auth.md)」を参照してください。
Amazon ECS API、AWS CLI、または AWS SDK を使用する場合、起動するタスクと同じリージョンにシークレットが存在する場合は、シークレットの完全な ARN または名前のどちらも使用できます。AWS マネジメントコンソール を使用する場合は、シークレットの完全な ARN を指定する必要があります。
必要なパラメータが含まれるタスク定義のスニペットを、以下に示します。
```
"containerDefinitions": [
{
"image": "private-repo/private-image",
"repositoryCredentials": {
"credentialsParameter": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
}
}
]
```
### 詳細コンテナ定義パラメータ
以下のコンテナ定義用の詳細パラメータは、Amazon ECS コンテナインスタンスでのコンテナの起動に使用する docker run コマンドの拡張機能を追加します。
**Topics**
+ [再起動ポリシー](#container_definition_restart_policy_ec2)
+ [ヘルスチェック](#container_definition_healthcheck_ec2)
+ [環境](#container_definition_environment_ec2)
+ [ネットワーク設定](#container_definition_network_ec2)
+ [ストレージとログ記録](#container_definition_storage_ec2)
+ [セキュリティ](#container_definition_security_ec2)
+ [リソースの制限](#container_definition_limits_ec2)
+ [Docker のラベル](#container_definition_labels_ec2)
#### 再起動ポリシー
`restartPolicy`
コンテナ再起動ポリシーと関連する設定パラメータ。コンテナの再起動ポリシーを設定すると、Amazon ECS はタスクを置き換えることなくコンテナを再起動できます。詳細については、「[コンテナ再起動ポリシーを使用して Amazon ECS タスク内の個々のコンテナを再起動する](container-restart-policy.md)」を参照してください。
`enabled`
タイプ: ブール値
必須: はい
コンテナに対して再起動ポリシーを有効にするかどうかを指定します。
`ignoredExitCodes`
タイプ: 整数配列
必須: いいえ
Amazon ECS が無視し、再起動を試みない終了コードのリスト。最大 50 個のコンテナ終了コードを指定できます。デフォルトでは、Amazon ECS はいずれの終了コードも無視しません。
`restartAttemptPeriod`
タイプ: 整数
必須: いいえ
再起動を試みる前にコンテナが実行する必要がある時間 (秒単位）。コンテナを再起動できるのは、`restartAttemptPeriod` 秒に 1 回のみです。コンテナがこの期間実行できずに早く終了した場合、コンテナは再起動されません。最小の `restartAttemptPeriod` は 60 秒、最大の `restartAttemptPeriod` は 1,800 秒を指定できます。デフォルトでは、コンテナは再起動の前に 300 秒間実行する必要があります。
#### ヘルスチェック
`healthCheck`
コンテナに対するヘルスチェックのコマンドと、コンテナのための関連する設定パラメータです。詳細については、「[コンテナのヘルスチェックを使用して Amazon ECS タスク状態を判定する](healthcheck.md)」を参照してください。
`command`
正常状態かどうかを決定するために、コンテナが実行するコマンドが格納された文字列配列。この文字列配列の先頭には、コマンド引数を直接実行するための `CMD`、またはコンテナのデフォルトシェルでコマンドを実行するための `CMD-SHELL` を付加できます。これらのいずれも指定しない場合は `CMD` が使用されます。
AWS マネジメントコンソール にタスク定義を登録する場合は、カンマで区切ったコマンドリストを使用してください。これらのコマンドは、タスク定義が作成された後に文字列に変換されます。ヘルスチェックに対する入力の例を次に示します。
```
CMD-SHELL, curl -f http://localhost/ || exit 1
```
AWS マネジメントコンソール JSON パネル、AWS CLI、または API を使用してタスク定義を登録するときは、コマンドのリストを角かっこで囲みます。ヘルスチェックに対する入力の例を次に示します。
```
[ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ]
```
`stderr` が出力されない終了コード 0 は成功を示し、0 以外の終了コードは失敗を示します。
`interval`
各ヘルスチェック間の時間間隔 (秒単位)。5 〜 300 秒を指定できます。デフォルトの値は 30 秒です。
`timeout`
成功まで待機しているヘルスチェックが、失敗したと見なされるまでの期間 (秒単位) です。2 〜 60 秒を指定できます。デフォルト値は 5 秒です。
`retries`
コンテナが異常と見なされるまでに、失敗したヘルスチェックを再試行する回数です。1〜10 回を指定できます。デフォルト値は 3 回の再試行です。
`startPeriod`
失敗したヘルスチェックの再試行が最大回数に達する前に、コンテナにブートストラップための時間を提供するオプションの猶予期間です。0 〜 300 秒を指定できます。デフォルトでは、`startPeriod` は無効となっています。
ヘルスチェックが `startPeriod` 内で成功した場合、コンテナは正常であるとみなされ、その後の失敗は最大再試行回数にカウントされます。
#### 環境
`cpu`
タイプ: 整数
必須: いいえ
Amazon ECS コンテナエージェントがコンテナ用に予約した `cpu` ユニットの数。Linux では、このパラメータは「[Create a container](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate)」セクションの `CpuShares` にマッピングされます。
Amazon EC2 インスタンスタイプごとに使用可能な CPU ユニットの数を決定できます。これを行うには、[Amazon EC2 インスタンス](https://aws.amazon.com/ec2/instance-types/)の詳細ページでそのインスタンスタイプにリストされている vCPU の数を 1,024 倍します。
Linux コンテナは、割り当てられた CPU ユニットと同じ比率を使用して、割り当てられていない CPU ユニットをコンテナインスタンス上の他コンテナと共有します。例えば、そのコンテナ用に 512 個の CPU ユニットが指定された単一コアインスタンスタイプで、唯一のコンテナタスクを実行するとします。さらに、そのタスクはコンテナインスタンスで実行される唯一のタスクです。この場合のコンテナは、1,024 個の CPU ユニット配分を任意のタイミングで使用できます。一方、そのコンテナインスタンスで同じタスクのコピーを別途起動したと仮定します。各タスクには、必要に応じて少なくとも 512 個の CPU ユニットが保証されます。同様に、その他のコンテナが残りの CPU を使用していない場合、各コンテナは CPU 使用率を高められます。ただし、両方のタスクが常に 100% アクティブである場合、使用できるのは 512 CPU ユニットに制限されます。
Linux コンテナインスタンスでは、コンテナインスタンス上の Docker デーモンは、CPU 値を使用して、実行中のコンテナに対する相対 CPU 配分比率を計算します。Linux カーネルが許可する最小の有効な CPU 共有値は 2 で、Linux カーネルが許可する最大の有効な CPU 共有値は 262,144 です。ただし、CPU のパラメータは必須ではなく、コンテナ定義では 2 未満の CPU 値および 262144 より大きな CPU 値を使用できます。CPU 値が 2 未満 (null を含む) および 262144 より大きな値である場合、動作は Amazon ECS コンテナエージェントのバージョンによって異なります。
+ **Agent versions <= 1.1.0:** Null およびゼロの CPU 値は Docker に 0 として渡され、Docker は 1,024 個の CPU 配分に変換します。1 の CPU 値は、Docker に対しては 1 として渡され、Linux カーネルではそれが 2 個の CPU 配分に変換されます。
+ **エージェントバージョン >= 1.2.0:** Null、0、および 1 の CPU 値は、Docker に 2 個の CPU 配分として渡されます。
+ **エージェントバージョン >= 1.84.0:** 256 vCPU を超える CPU 値は Docker に 256 として渡されます。これは 262144 CPU 共有に相当します。
Windows コンテナインスタンスでは、CPU クォータは絶対クォータとして適用されます。Windows コンテナは、タスク定義で定義されている指定された量の CPU にのみアクセスできます。null またはゼロの CPU 値が `0` として Docker に渡されます。次に Windows はこの値を 1 つの CPU の 1% として解釈します。
その他の例については、「[Amazon ECS で CPU およびメモリリソースの管理方法](https://aws.amazon.com/blogs/containers/how-amazon-ecs-manages-cpu-and-memory-resources/)」を参照してください。
`gpu`
タイプ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) オブジェクト
必須: いいえ
Amazon ECS コンテナエージェントがコンテナ用に予約した物理 `GPUs` の数。タスク内でコンテナ用に予約されているすべての GPU の数は、タスクが起動されたコンテナインスタンスで使用できる GPU の数を超えることはできません。詳細については、「[GPU ワークロード向けの Amazon ECS タスク定義](ecs-gpu.md)」を参照してください。
このパラメータは Windows コンテナではサポートされません。
`Elastic Inference accelerator`
タイプ: [ResourceRequirement](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ResourceRequirement.html) オブジェクト
必須: いいえ
`InferenceAccelerator` タイプでは、`value` はタスク定義で指定される `InferenceAccelerator` の `deviceName` と一致します。詳細については、「[Elastic Inference アクセラレーター名 (廃止)](task_definition_parameters.md#elastic-Inference-accelerator)」を参照してください。
このパラメータは Windows コンテナではサポートされません。
`essential`
タイプ: ブール値
必須: いいえ
コンテナの `essential` パラメーターが `true` としてマークされており、そのコンテナが何らかの理由で失敗するか停止するとします。その後、タスクの一部である他のすべてのコンテナが停止されます。コンテナの `essential` パラメータを `false` にマークしておくと、そのコンテナ失敗はタスク内にある残りのコンテナに影響を与えません。このパラメータを省略した場合、コンテナは必須と見なされます。
すべてのタスクには少なくとも 1 つの必須コンテナが必要です。複数のコンテナで構成されるアプリケーションがあるとします。次に、共通の目的で使用されるコンテナをコンポーネントにグループ化し、さまざまなコンポーネントを複数のタスク定義に分離します。詳細については、「[Amazon ECS 用のアプリケーションの構築](application_architecture.md)」を参照してください。
```
"essential": true|false
```
`entryPoint`
初期のバージョンの Amazon ECS コンテナエージェントは、`entryPoint` パラメータを正しく処理しません。`entryPoint` の使用時に問題が発生する場合は、コンテナエージェントを更新するか、代わりに `command` 配列項目としてコマンドと引数を入力します。
タイプ: 文字列配列
必須: いいえ
コンテナに渡されるエントリポイント。
```
"entryPoint": ["string", ...]
```
`command`
タイプ: 文字列配列
必須: いいえ
コンテナに渡されるコマンド。このパラメータは create-container コマンドの `Cmd` にマッピングされ、 `COMMAND` パラメータは docker run にマッピングされます。複数の引数がある場合、各引数は配列内で、区切られた文字列により指定する必要があります。
```
"command": ["string", ...]
```
`workingDirectory`
タイプ: 文字列
必須: いいえ
コマンドを実行するコンテナ内の作業ディレクトリ。このパラメータは、[Docker Remote API](https://docs.docker.com/reference/api/engine/version/v1.38/) の [コンテナの作成](https://docs.docker.com/reference/api/engine/version/v1.38/#operation/ContainerCreate) セクションにある `WorkingDir` にマッピングされ、`--workdir` オプションは [https://docs.docker.com/reference/cli/docker/container/run/](https://docs.docker.com/reference/cli/docker/container/run/) にマッピングされます。
```
"workingDirectory": "string"
```
`environmentFiles`
タイプ: オブジェクト配列
必須: いいえ
コンテナに渡す環境変数が含まれるファイルのリスト。このパラメータは docker run コマンドの `--env-file` オプションにマッピングされます。
FIPS が有効化されている場合、ピリオド (.) が使用されているバケット名 (amzn-s3-demo-bucket1.name.example など) はサポートされません。バケット名にピリオド (.) を使用すると、エージェントが Amazon S3 から環境変数ファイルを取得できなくなるため、タスクが開始されません。
これは Windows コンテナには使用できません。
最大 10 個の環境ファイルを指定できます。ファイルには、ファイル拡張子 `.env` が必要です。環境ファイルの各行には、`VARIABLE=VALUE` 形式で環境変数が含まれています。`#` で始まる行はコメントとして扱われ、無視されます。
コンテナ定義に個別の環境変数が指定されている場合は、環境ファイルに含まれる変数よりも優先されます。同じ変数を含む複数の環境ファイルが指定されている場合、それらのファイルは上から下に処理されます。一意の変数名を使用することをお勧めします。詳細については、「[個々の環境変数を Amazon ECS コンテナに渡す](taskdef-envfiles.md)」を参照してください。
`value`
タイプ: 文字列
必須: はい
環境変数ファイルを含む Amazon S3 オブジェクトの Amazon リソースネーム (ARN)。
`type`
タイプ: 文字列
必須: はい
使用するファイルのタイプ。`s3` はサポートされる唯一の値です。
`environment`
タイプ: オブジェクト配列
必須: いいえ
コンテナに渡す環境変数。このパラメータは docker create-container コマンドの `Env` にマッピングされ、`--env` オプションは docker run コマンドにマッピングされます。
認証情報データなどの機密情報にプレーンテキストの環境変数を使用することはお勧めしません。
`name`
タイプ: 文字列
必須: はい (`environment` を使用する場合)
環境変数の名前。
`value`
タイプ: 文字列
必須: はい (`environment` を使用する場合)
環境変数の値。
```
"environment" : [
{ "name" : "string", "value" : "string" },
{ "name" : "string", "value" : "string" }
]
```
`secrets`
タイプ: オブジェクト配列
必須: いいえ
コンテナに公開するシークレットを表すオブジェクトです。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
`name`
タイプ: 文字列
必須: はい
コンテナの環境変数として設定する値。
`valueFrom`
タイプ: 文字列
必須: はい
コンテナに公開するシークレット。サポートされている値は、AWS Secrets Manager シークレットの完全な Amazon リソースネーム (ARN)、または AWS Systems Manager Parameter Store 内のパラメータの完全な ARN のいずれかです。
起動するタスクと同じ AWS リージョン に Systems Manager パラメータストアのパラメータまたは Secrets Manager のパラメータが存在する場合は、シークレットの完全な ARN または名前のいずれかを使用できます。パラメータが別のリージョンに存在する場合は、完全な ARN を指定する必要があります。
```
"secrets": [
{
"name": "environment_variable_name",
"valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
}
]
```
#### ネットワーク設定
`disableNetworking`
タイプ: ブール値
必須: いいえ
このパラメータが true のとき、ネットワークはコンテナ内でオフになります。
`awsvpc` ネットワークモードを使用するタスクもしくは Windows コンテナでは、このパラメータはサポートされません。
デフォルト: `false`。
```
"disableNetworking": true|false
```
`links`
タイプ: 文字列配列
必須: いいえ
`link` パラメータでは、コンテナがポートマッピングを必要とせずに互いに通信することを許可します。このパラメータは、タスク定義のネットワークモードが `bridge` に設定されている場合にのみサポートされます。`name:internalName` コンストラクトは Docker リンクの `name:alias` に似ています。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコアを使用できます。
`awsvpc` ネットワークモードを使用するタスクもしくは Windows コンテナでは、このパラメータはサポートされません。
同じコンテナインスタンスに配置されたコンテナ同士は、リンクやホストポートマッピングを必要とせずに、互いに通信する場合があります。コンテナインスタンスでのネットワークの分離は、セキュリティグループと VPC 設定によって制御されます。
```
"links": ["name:internalName", ...]
```
`hostname`
タイプ: 文字列
必須: いいえ
コンテナに使用するホスト名。このパラメータは docker create-container の `Hostname` にマッピングされ、`--hostname` オプションは docker run にマッピングされます。
`awsvpc` ネットワークモードを使用している場合、`hostname` パラメータはサポートされません。
```
"hostname": "string"
```
`dnsServers`
タイプ: 文字列配列
必須: いいえ
コンテナに提示する DNS サーバーのリスト。
`awsvpc` ネットワークモードを使用するタスクもしくは Windows コンテナでは、このパラメータはサポートされません。
```
"dnsServers": ["string", ...]
```
`dnsSearchDomains`
タイプ: 文字列配列
必須: いいえ
パターン: ^[a-zA-Z0-9-.]\$10,253\$1[a-zA-Z0-9]\$1
コンテナに提示する DNS 検索ドメインのリスト。このパラメータは docker create-container コマンドの `DnsSearch` にマッピングされ、`--dns-search` オプションは docker run にマッピングされます。
このパラメータは Windows コンテナまたは、`awsvpc` ネットワークモードを使用するタスクではサポートされていません。
```
"dnsSearchDomains": ["string", ...]
```
`extraHosts`
タイプ: オブジェクト配列
必須: いいえ
コンテナ上の `/etc/hosts` ファイルに追加する、ホスト名と IP アドレスのマッピングリスト。
このパラメータは docker create-container コマンドの `ExtraHosts` にマッピングされ、`--add-host` オプションは docker run にマッピングされます。
このパラメータは Windows コンテナまたは、`awsvpc` ネットワークモードを使用するタスクではサポートされていません。
```
"extraHosts": [
{
"hostname": "string",
"ipAddress": "string"
}
...
]
```
`hostname`
タイプ: 文字列
必須: はい (`extraHosts` を使用する場合)
`/etc/hosts` エントリで使用するホスト名。
`ipAddress`
タイプ: 文字列
必須: はい (`extraHosts` を使用する場合)
`/etc/hosts` エントリで使用する IP アドレス。
#### ストレージとログ記録
`readonlyRootFilesystem`
タイプ: ブール値
必須: いいえ
このパラメータが true のとき、コンテナはそのルートファイルシステムへの読み取り専用アクセスを許可されます。このパラメータは docker create-container コマンドの `ReadonlyRootfs` にマッピングされ、`--read-only` オプションは docker run にマッピングされます。
このパラメータは Windows コンテナではサポートされません。
デフォルト: `false`。
```
"readonlyRootFilesystem": true|false
```
`mountPoints`
タイプ: オブジェクト配列
必須: いいえ
コンテナでのデータボリュームのマウントポイント。このパラメータは creat-container Docker API の `Volumes` にマッピングされ、docker run の `--volume` オプションにマッピングされます。
Windows コンテナは `$env:ProgramData` と同じドライブに全部のディレクトリをマウントできます。Windows コンテナは、別のドライブにディレクトリをマウントすることはできません。また、マウントポイントは複数のドライブにまたがることはできません。Amazon EBS ボリュームを Amazon ECS タスクに直接アタッチするには、マウントポイントを指定する必要があります。
`sourceVolume`
タイプ: 文字列
必須: はい (`mountPoints` を使用する場合)
マウントするボリュームの名前。
`containerPath`
タイプ: 文字列
必須: はい (`mountPoints` を使用する場合)
ボリュームをマウントするコンテナ内のパス。
`readOnly`
タイプ: ブール値
必須: いいえ
この値が `true` の場合、コンテナはボリュームへの読み取り専用アクセスを許可されます。この値が `false` の場合、コンテナはボリュームに書き込むことができます。デフォルト値は `false` です。
Windows オペレーティングシステムを実行しているタスクの場合、 値をデフォルト の `false` のままにします。
`volumesFrom`
タイプ: オブジェクト配列
必須: いいえ
別コンテナからマウントするデータボリューム。このパラメータは docker create-container コマンドの `VolumesFrom` にマッピングされ、`--volumes-from` オプションは docker run にマッピングされます。
`sourceContainer`
タイプ: 文字列
必須: はい (`volumesFrom` を使用する場合)
ボリュームのマウント元のコンテナの名前。
`readOnly`
タイプ: ブール値
必須: いいえ
この値が `true` の場合、コンテナはボリュームへの読み取り専用アクセスを許可されます。この値が `false` の場合、コンテナはボリュームに書き込むことができます。デフォルト値は `false` です。
```
"volumesFrom": [
{
"sourceContainer": "string",
"readOnly": true|false
}
]
```
`logConfiguration`
タイプ: [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) オブジェクト
必須: いいえ
コンテナに対するログ構成の仕様です。
ログ設定を使用したタスク定義の例については、「[Amazon ECS のタスク定義の例](example_task_definitions.md)」を参照してください。
このパラメータは docker create-container コマンドの `LogConfig` にマッピングされ、`--log-driver` オプションは docker run にマッピングされます。デフォルトでは、コンテナは Docker デーモンで使用されるのと同じロギングドライバーを使用します。ただし、コンテナ定義の中で、このパラメータによりログドライバーを指定することで、Docker デーモンとは異なるログドライバーをコンテナに使用させることも可能です。コンテナに異なるロギングドライバーを使用するには、コンテナインスタンス (またはリモートログ記録オプションの別のログサーバー) でログシステムを適切に設定する必要があります。
コンテナのログ設定を指定する際には、以下の点に注意してください。
+ 現在、Amazon ECS では Docker デーモンに使用可能なログドライバーがいくつかサポートされています。
+ このパラメータを使用するには、コンテナインスタンスで Docker Remote API のバージョン 1.18 以降が必要です。
+ コンテナインスタンスで実行される Amazon ECS コンテナエージェントは、そのインスタンスに配置されたコンテナがこれらのログ設定オプションを使用できるようにする前に、そのインスタンスで使用可能なログドライバーを `ECS_AVAILABLE_LOGGING_DRIVERS` 環境変数に登録する必要があります。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
```
"logConfiguration": {
"logDriver": "awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens",
"options": {"string": "string"
...},
"secretOptions": [{
"name": "string",
"valueFrom": "string"
}]
}
```
`logDriver`
タイプ: 文字列
有効な値: `"awslogs","fluentd","gelf","json-file","journald","splunk","syslog","awsfirelens"`
必須: はい (`logConfiguration` を使用する場合)
コンテナに使用するログドライバー。デフォルトでは、上記の有効な値は Amazon ECS コンテナエージェントが通信できるログドライバーです。
サポートされているログドライバーは `awslogs`、`fluentd`、`gelf`、`json-file`、`journald`、`syslog`、`splunk`、`awsfirelens` です。
タスク定義で `awslogs` ログドライバーを使用してコンテナログを CloudWatch Logs に送信する方法については、「[Amazon ECS ログを CloudWatch に送信する](using_awslogs.md)」を参照してください。
`awsfirelens` ログドライバーの使用の詳細については、「[カスタムログのルーティング](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html)」を参照してください。
上記に示されていないカスタムドライバーがある場合、[GitHub で入手できる](https://github.com/aws/amazon-ecs-agent) Amazon ECS コンテナエージェントプロジェクトを fork し、そのドライバーを使用するようにカスタマイズできます。含めたい変更については、プルリクエストを送信することをお勧めします。ただし、現時点では、このソフトウェアの変更されたコピーの実行はサポートされていません。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.18 以上を使用する必要があります。
`options`
タイプ: 文字列間のマッピング
必須: いいえ
ログドライバーに送信する設定オプションの Key-Value マップ。
指定できるオプションは、ログドライバーに応じて異なります。`awslogs` ルーターを使用して Amazon CloudWatch にログをルーティングするときに指定できるオプションには、以下が含まれます。
`awslogs-create-group`
必須: いいえ
ロググループを自動的に作成させるかどうかを指定します。このオプションを指定しない場合、デフォルトは `false` です。
`awslogs-create-group` を使用する前に、IAM ポリシーにはアクセス許可 `logs:CreateLogGroup` が含まれている必要があります。
`awslogs-region`
必須: はい
`awslogs` ログドライバが Docker ログを送信する先の、AWS リージョン を指定します。CloudWatch Logs では、異なるリージョンのクラスターからすべてのログを 1 つのリージョンに送信するように選択できます。これにより、すべてのログを一元的な場所で確認できるようになります。他にも、リージョンごとにそれらを分離して、より細分化することが可能です。このオプションで指定するリージョンに、対象のロググループが存在することを確認してください。
`awslogs-group`
必須: はい
`awslogs` ログドライバーがログストリームを送信する先の、ロググループを指定する必要があります。
`awslogs-stream-prefix`
必須：オプション
指定したプレフィックス、コンテナ名、コンテナが属する Amazon ECS タスクの ID にログストリームを関連付けるには、`awslogs-stream-prefix` オプションを使用します。このオプションでプレフィックスを指定した場合、ログストリームの形式は以下のようになります。
```
prefix-name/container-name/ecs-task-id
```
このオプションでプレフィックスを指定しない場合、ログストリームには、コンテナインスタンスの Docker デーモンによって割り当てられたコンテナ ID に基づいた名前が付けられます。Docker コンテナ ID (コンテナインスタンスでのみ使用可能) だけでそのログを送信したコンテナを追跡するのは難しいため、このオプションでプレフィックスを指定することをお勧めします。
Amazon ECS サービスでは、サービス名をプレフィックスとして使用できます。これにより、コンテナが属するサービスへのログストリームと、それを送信したコンテナの名前、そのコンテナが所属するタスクの ID を追跡できます。
Amazon ECS コンソールを使用する際に [Log] ペインにログを表示するためには、ログのストリームプレフィックスを指定する必要があります。
`awslogs-datetime-format`
必須: いいえ
このオプションは、Python `strftime` 形式で複数行起動パターンを定義します。ログメッセージは、パターンに一致する 1 行と、それに続くパターンに一致しない行で構成されます。一致する 1 行とは、ログメッセージ間の区切りです。
この形式を使用する場合のユースケースの例としては、スタックダンプなどの解析された出力があり、これを使用しなければ、複数のエントリに記録されることになります。適切なパターンにより、単一のエントリにキャプチャさせます。
詳細については、[awslogs-datetime-format](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-datetime-format)を参照してください。
`awslogs-datetime-format` と `awslogs-multiline-pattern` オプションの両方を設定することはできません。
複数行のログ記録は、すべてのログメッセージの正規表現の解析とマッチングを実行します。これによりログ記録のパフォーマンスに悪影響が及ぶ可能性があります。
`awslogs-multiline-pattern`
必須: いいえ
このオプションでは、正規表現を使用する複数行起動パターンを定義します。ログメッセージは、パターンに一致する 1 行と、それに続くパターンに一致しない行で構成されます。一致する 1 行とは、ログメッセージ間の区切りです。
詳細については、「[awslogs-multiline-pattern](https://docs.docker.com/engine/logging/drivers/awslogs/#awslogs-multiline-pattern)」を参照してください。
`awslogs-datetime-format` も設定されている場合は、このオプションは無視されます。
`awslogs-datetime-format` と `awslogs-multiline-pattern` オプションの両方を設定することはできません。
複数行のログ記録は、すべてのログメッセージの正規表現の解析とマッチングを実行します。これによりログ記録のパフォーマンスに悪影響が及ぶ可能性があります。
以下のオプションは、サポートされているすべてのログドライバーに適用されます。
`mode`
必須: いいえ
有効な値: `non-blocking` \$1 `blocking`
このオプションは、コンテナから `logDriver` で指定したログドライバーへのログメッセージの配信モードを定義します。選択した配信モードは、コンテナからンテナーからのログの流れが中断されたときのアプリケーションの可用性に影響します。
`blocking` モードを使用していて、ログのフローが中断された場合、`stdout` ストリームと `stderr` ストリームに書き込むためのコンテナコードからの呼び出しがブロックされます。その結果、アプリケーションのロギングスレッドがブロックされます。これにより、アプリケーションが応答しなくなり、コンテナのヘルスチェックが失敗する可能性があります。
`non-blocking` モードを使用する場合、コンテナのログは代わりに `max-buffer-size` オプションで設定されたメモリ内の中間バッファに保存されます。これにより、ログを送信できない場合にアプリケーションが応答しなくなるのを防ぐことができます。サービスの可用性を確保したいが、多少のログ損失があっても問題ない場合は、このモードを使用することをおすすめします。詳細については、「[Preventing log loss with non-blocking mode in the `awslogs` container log driver](https://aws.amazon.com/blogs/containers/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/)」を参照してください。
`defaultLogDriverMode` アカウント設定を使用して、特定の AWS リージョンにあるすべてのコンテナのデフォルトの `mode` を設定できます。`logConfiguration` で `mode` オプションを指定しない場合、またはアカウント設定を構成しない場合、Amazon ECS はデフォルトで `non-blocking` モードになります。アカウント設定の詳細については、「[デフォルトのログドライバーモード](ecs-account-settings.md#default-log-driver-mode)」を参照してください。
`non-blocking` モードが使用されている場合、`max-buffer-size` ログオプションは、中間メッセージ用のストレージに使用されるバッファのサイズを制御します。アプリケーションに基づいて、必ず適切なバッファサイズを指定してください。タスクレベルで割り当てられるメモリの合計量は、ログドライバーのメモリバッファに加えて、すべてのコンテナに割り当てられたメモリ量よりも大きくなければなりません。
2025 年 6 月 25 日、Amazon ECS はデフォルトのログドライバーモードが `blocking` から `non-blocking` に変更され、ログ記録よりもタスクの可用性が優先されるようになりました。この変更以降も `blocking` モードを引き続き使用するには、次のいずれかを実行してください。
+ コンテナ定義の `logConfiguration` の `mode` オプションを `blocking` に設定します。
+ `defaultLogDriverMode` アカウント設定を `blocking` に設定します。
`max-buffer-size`
必須: いいえ
デフォルト値: `10 m`
`non-blocking` モードが使用されている場合、`max-buffer-size` ログオプションは、中間メッセージ用のストレージに使用されるバッファのサイズを制御します。アプリケーションに基づいて、必ず適切なバッファサイズを指定してください。バッファがいっぱいになると、それ以上ログを保存できなくなります。保存できないログは失われます。
`splunk` ログルーターを使用してログをルーティングするには、`splunk-token` と `splunk-url` を指定する必要があります。
ログの保存と分析のための AWS のサービスまたは AWS Partner Networkを送信先としたログのルーティングに `awsfirelens` ログルーターを使用するときは、`log-driver-buffer-limit` オプションを設定して、イベントがログルーターコンテナに送信される前に、メモリでバッファリングされるログのライン数を制限できます。この制限は、スループットが高い場合に発生する可能性がある、Docker 内のバッファのメモリ不足による、潜在的なログ損失の問題を解決するのに役立ちます。詳細については、「[高スループットの Amazon ECS ログの設定](firelens-docker-buffer-limit.md)」を参照してください。
`awsfirelens` を使用してログをルーティングするときに指定できるその他のオプションは、送信先に応じて異なります。Amazon Data Firehose にログをエクスポートするときは、`region` を使用して AWS リージョンを指定し、`delivery_stream` を使用してログストリームの名前を指定することができます。
Amazon Kinesis Data Streams にログをエクスポートするときは、`region` を使用して AWS リージョンを指定し、`stream` を使用してデータストリーム名を指定することができます。
Amazon OpenSearch Service にログをエクスポートするときは、`Name`、`Host` (プロトコルを使用しない OpenSearch Service エンドポイント)、`Port`、`Index`、`Type`、`Aws_auth`、`Aws_region`、`Suppress_Type_Name`、および `tls` といったオプションを指定できます。
Amazon S3 にログをエクスポートするときは、`bucket` オプションを使用してバケットを指定できます。また、`region`、`total_file_size`、`upload_timeout`、および `use_put_object` をオプションとして指定することもできます。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.19 以上を使用する必要があります。
`secretOptions`
タイプ: オブジェクト配列
必須: いいえ
ログ設定に渡すシークレットを示すオブジェクト。ログ構成で使用されるシークレットには、認証トークン、証明書、または暗号化キーを含められます。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
`name`
タイプ: 文字列
必須: はい
コンテナの環境変数として設定する値。
`valueFrom`
タイプ: 文字列
必須: はい
コンテナのログ設定に公開するシークレット。
```
"logConfiguration": {
"logDriver": "splunk",
"options": {
"splunk-url": "https://cloud.splunk.com:8080",
"splunk-token": "...",
"tag": "...",
...
},
"secretOptions": [{
"name": "splunk-token",
"valueFrom": "/ecs/logconfig/splunkcred"
}]
}
```
`firelensConfiguration`
タイプ: [FirelensConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FirelensConfiguration.html) オブジェクト
必須: いいえ
コンテナの FireLens 構成。これは、コンテナログのログルーターの指定と設定に使用されます。詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。
```
{
"firelensConfiguration": {
"type": "fluentd",
"options": {
"KeyName": ""
}
}
}
```
`options`
タイプ: 文字列間のマッピング
必須: いいえ
ログルーターの設定時に使用するオプションの Key-Value マップ。このフィールドはオプションで、カスタム設定ファイルを指定するか、タスク、タスク定義、クラスター、コンテナインスタンスの詳細などのメタデータをログイベントに追加するために使用できます。指定した場合、使用する構文は `"options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf|filepath"}` です。詳細については、「[Amazon ECS タスク定義の例: FireLens にログをルーティングする](firelens-taskdef.md)」を参照してください。
`type`
タイプ: 文字列
必須: はい
使用するログルーター。有効な値は `fluentd` または `fluentbit` です。
#### セキュリティ
コンテナセキュリティの詳細については、「[Amazon ECS タスクおよびコンテナのセキュリティのベストプラクティス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-tasks-containers.html)」を参照してください。
`credentialSpecs`
タイプ: 文字列配列
必須: いいえ
Active Directory 認証用のコンテナを設定する認証情報仕様 (`CredSpec`) ファイルへの SSM または Amazon S3 の ARN のリスト。`dockerSecurityOptions` の代わりに、このパラメータを使用することをお勧めします。ARN の最大数は 1 です。
各 ARN には 2 つの形式があります。
credentialspecdomainless:MyARN
Secrets Manager にシークレットの追加セクションを持つ `CredSpec` を提供するために `credentialspecdomainless:MyARN` を使用します。シークレットでドメインへのログイン認証情報を指定します。
任意のコンテナインスタンスで実行される各タスクは、異なるドメインに参加できます。
この形式は、コンテナインスタンスをドメインに結合しなくても使用できます。
credentialspec:MyARN
単一ドメインに対して `CredSpec` を提供するために `credentialspec:MyARN` を使用します。
このタスク定義を使用するタスクを開始する前に、コンテナインスタンスをドメインに参加させる必要があります。
どちらの形式でも、SSM または Amazon S3 で `MyARN` を ARN に置き換えます。
`credspec` は、ユーザー名、パスワード、接続先のドメインを含むシークレットの ARN を Secrets Manager に提供する必要があります。セキュリティ向上のため、インスタンスはドメインレス認証のドメインに参加しません。インスタンス上の他のアプリケーションは、ドメインレス認証情報を使用できません。このパラメータを使用すると、タスクが別のドメインに参加する必要がある場合でも、同じインスタンスでタスクを実行できます。詳細については、「[Windows コンテナでの gMSAs の使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html)」および「[Linux コンテナ向け gMSAs を使用する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/linux-gmsa.html)」を参照してください。
`privileged`
タイプ: ブール値
必須: いいえ
このパラメータが true のとき、コンテナには、ホストコンテナインスタンスに対する昇格されたアクセス権限 (`root` ユーザーと同様) が付与されます。`privileged` でコンテナを実行することはお勧めしません。ほとんどの場合、`privileged` を使用する代わりに特定のパラメータを使用することで、必要な権限を正確に指定できます。
このパラメータは docker create-container コマンドの `Privileged` にマッピングされ、`--privileged` オプションは docker run にマッピングされます。
このパラメータは、Windows コンテナ、または Fargate 起動タイプを使用するタスクではサポートされていません。
デフォルト: `false`。
```
"privileged": true|false
```
`user`
タイプ: 文字列
必須: いいえ
コンテナ内で使用するユーザー。このパラメータは docker create-container コマンドの `User` にマッピングされ、`--user` オプションは docker run にマッピングされます。
`host` ネットワークモードを使用してタスクを実行する場合は、ルートユーザー (UID 0) を使用してコンテナを実行しないでください。セキュリティのベストプラクティスとしては、常にルート以外のユーザーを使用します。
以下の形式を使用して、`user` を指定できます。UID または GID を指定する場合は、正の整数として指定する必要があります。
+ `user`
+ `user:group`
+ `uid`
+ `uid:gid`
+ `user:gid`
+ `uid:group`
このパラメータは Windows コンテナではサポートされません。
```
"user": "string"
```
`dockerSecurityOptions`
タイプ: 文字列配列
有効な値: "no-new-privileges" \$1 "apparmor:PROFILE" \$1 "label:*value*" \$1 "credentialspec:*CredentialSpecFilePath*"
必須: いいえ
複数のセキュリティシステムのカスタム設定を指定する文字列のリスト。
Linux タスクの場合、このパラメータを使用して、SELinux および AppArmor マルチレベルセキュリティシステムのカスタムラベルを参照できます。
このパラメータを使用して、Active Directory 認証用のコンテナを設定する認証情報仕様ファイルを参照できます。詳細については、「[Amazon ECS の EC2 Windows コンテナで gMSA を使用する方法について説明します。](windows-gmsa.md)」および「[Amazon EC2 の Linux コンテナで gMSA を使用する](linux-gmsa.md)」を参照してください。
このパラメータは docker create-container コマンドの `SecurityOpt` にマッピングされ、`--security-opt` オプションは docker run にマッピングされます。
```
"dockerSecurityOptions": ["string", ...]
```
コンテナインスタンスで実行される Amazon ECS コンテナエージェントは、`ECS_SELINUX_CAPABLE=true` または `ECS_APPARMOR_CAPABLE=true` 環境変数を登録する必要があります。これにより、そのインスタンスに配置されたコンテナが、これらのセキュリティオプションを使用できるようになります。詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。
#### リソースの制限
`ulimits`
タイプ: オブジェクト配列
必須: いいえ
コンテナに定義する `ulimit` 値の一覧。この値は、オペレーティングシステムのデフォルトのリソースクォータ設定を上書きします。このパラメータは docker create-container コマンドの `Ulimits` にマッピングされ、`--ulimit` オプションは docker run にマッピングされます。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.18 以上を使用する必要があります。
このパラメータは Windows コンテナではサポートされません。
```
"ulimits": [
{
"name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack",
"softLimit": integer,
"hardLimit": integer
}
...
]
```
`name`
タイプ: 文字列
有効な値: `"core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"`
必須: はい (`ulimits` を使用する場合)
`ulimit` の `type`。
`hardLimit`
タイプ: 整数
必須: はい (`ulimits` を使用する場合)
`ulimit` タイプのハード制限。値は、`ulimit` の `type` に応じて、バイト、秒、またはカウントとして指定できます。
`softLimit`
タイプ: 整数
必須: はい (`ulimits` を使用する場合)
`ulimit` タイプのソフト制限。値は、`ulimit` の `type` に応じて、バイト、秒、またはカウントとして指定できます。
#### Docker のラベル
`dockerLabels`
タイプ: 文字列間のマッピング
必須: いいえ
コンテナに追加するラベルのキー/値マップ。このパラメータは docker create-container コマンドの `Labels` にマッピングされ、`--label` オプションは docker run にマッピングされます。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.18 以上を使用する必要があります。
```
"dockerLabels": {"string": "string"
...}
```
### その他のコンテナ定義のパラメータ
以下のコンテナ定義パラメータは、**[Configure via JSON]** (JSON による設定) オプションを使用して、Amazon ECS コンソールでタスク定義を登録する際に使用できます。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
**Topics**
+ [Linux パラメータ](#container_definition_linuxparameters_ec2)
+ [コンテナの依存関係](#container_definition_dependson_ec2)
+ [[コンテナのタイムアウト]](#container_definition_timeout_ec2)
+ [システムコントロール](#container_definition_systemcontrols_ec2)
+ [インタラクティブ](#container_definition_interactive_ec2)
+ [擬似ターミナル](#container_definition_pseudoterminal_ec2)
#### Linux パラメータ
`linuxParameters`
型: [LinuxParameters](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html) オブジェクト
必須: いいえ
[KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities.html) など、コンテナに適用される Linux 固有のオプション。
このパラメータは Windows コンテナではサポートされません。
```
"linuxParameters": {
"capabilities": {
"add": ["string", ...],
"drop": ["string", ...]
}
}
```
`capabilities`
型: [KernelCapabilities](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KernelCapabilities_ec2.html) オブジェクト
必須: いいえ
Docker によって提供されているデフォルト設定に対して追加または削除する、コンテナ用の Linux 機能。これらの Linux 機能の詳細については、Linux マニュアルページの「[機能 (7)](http://man7.org/linux/man-pages/man7/capabilities.7.html)」を参照してください。
`add`
タイプ: 文字列配列
有効な値: `"ALL" | "AUDIT_CONTROL" | "AUDIT_READ" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"`
必須: いいえ
Docker によって提供されているデフォルト設定に追加する、コンテナ用の Linux 機能。このパラメータは docker create-container コマンドの `CapAdd` にマッピングされ、`--cap-add` オプションは docker run にマッピングされます。
`add`
タイプ: 文字列配列
有効な値: `"SYS_PTRACE"`
必須: いいえ
Docker によって提供されているデフォルト設定のコンテナに追加する Linux 機能。このパラメータは docker create-container コマンドの `CapAdd` にマッピングされ、`--cap-add` オプションは docker run にマッピングされます。
`drop`
タイプ: 文字列配列
有効な値: `"ALL" | "AUDIT_CONTROL" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"`
必須: いいえ
Docker によって提供されているデフォルト設定のコンテナから削除する Linux 機能。このパラメータは docker create-container コマンドの `CapDrop` にマッピングされ、`--cap-drop` オプションは docker run にマッピングされます。
`devices`
コンテナに公開するすべてのホストデバイス。このパラメータは docker create-container コマンドの `Devices` にマッピングされ、`--device` オプションは docker run にマッピングされます。
タイプ: [デバイス](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Device.html)オブジェクト配列
必須: いいえ
`hostPath`
ホストコンテナインスタンス上のデバイスのパス。
タイプ: 文字列
必須: はい
`containerPath`
ホストデバイスを公開する先のコンテナ内のパス。
タイプ: 文字列
必須: いいえ
`permissions`
デバイス用のコンテナに提供する明示的な許可。デフォルトでは、コンテナにはデバイスの `read`、`write`、および `mknod` のアクセス許可があります。
型: 文字列の配列
有効な値: `read` \$1 `write` \$1 `mknod`
`initProcessEnabled`
信号を転送しプロセスを利用するコンテナ内で、`init` を実行。このパラメータは docker run の `--init` オプションにマッピングされます。
このパラメータは、コンテナインスタンスで Docker Remote API バージョン 1.25 以上を使用する必要があります。
`maxSwap`
コンテナが使用できるスワップメモリの合計 (MiB 単位)。このパラメータは、docker run の `--memory-swap` オプションに変換されます。値はコンテナメモリの合計に `maxSwap` の値を加えた値です。
`0` の `maxSwap` 値を指定した場合、コンテナはスワップを使用しません。許容値は、`0` または任意の正の整数です。`maxSwap` パラメータを省略すると、コンテナは実行中のコンテナインスタンスのスワップ設定を使用します。`swappiness` パラメータを使用するには、`maxSwap` 値を設定する必要があります。
`sharedMemorySize`
`/dev/shm` ボリュームのサイズ値 (MiB) です。このパラメータは docker run の `--shm-size` オプションにマッピングされます。
タイプ: 整数
`swappiness`
このパラメータにより、コンテナのメモリスワップ動作を調整できます。`swappiness` の値が `0` であると、必要な場合を除きスワップは発生しません。`swappiness` の値が `100` であると、ページのスワップが頻繁に行われます。使用できる値は、`0` と `100` の間の整数です。値を指定しない場合、デフォルト値の `60` が適用されます。また、`maxSwap` の値が指定されていない場合、このパラメータは無視されます。このパラメータは docker run の `--memory-swappiness` オプションにマッピングされます。
Amazon Linux 2023 でタスクを使用している場合、`swappiness` パラメータはサポートされていません。
`tmpfs`
tmpfs マウントのコンテナパス、マウントオプション、および最大サイズ (MiB) です。このパラメータは docker run の `--tmpfs` オプションにマッピングされます。
型: [Tmpfs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Tmpfs.html) オブジェクト配列
必須: いいえ
`containerPath`
tmpfs ボリュームがマウントされる絶対ファイルパスです。
タイプ: 文字列
必須: はい
`mountOptions`
tmpfs ボリュームのマウントオプションのリストです。
型: 文字列の配列
必須: いいえ
有効な値: `"defaults" | "ro" | "rw" | "suid" | "nosuid" | "dev" | "nodev" | "exec" | "noexec" | "sync" | "async" | "dirsync" | "remount" | "mand" | "nomand" | "atime" | "noatime" | "diratime" | "nodiratime" | "bind" | "rbind" | "unbindable" | "runbindable" | "private" | "rprivate" | "shared" | "rshared" | "slave" | "rslave" | "relatime" | "norelatime" | "strictatime" | "nostrictatime" | "mode" | "uid" | "gid" | "nr_inodes" | "nr_blocks" | "mpol"`
`size`
tmpfs ボリュームの最大サイズ (MiB) です。
タイプ: 整数
必須: はい
#### コンテナの依存関係
`dependsOn`
型: [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) オブジェクトの配列
必須: いいえ
コンテナの起動と停止に定義されている依存関係。コンテナには複数の依存関係を含めることができます。依存関係がコンテナの起動に対して定義されている場合、コンテナの停止の場合、依存関係は逆になります。例については、[コンテナの依存関係](example_task_definitions.md#example_task_definition-containerdependency)を参照してください。
あるコンテナが依存関係における制限事項を満たさない場合、または制限を満たす前にタイムアウトした場合、Amazon ECS は、依存関係にある他のコンテナの状態も次に遷移させることはしません。
コンテナの依存関係を有効にするには、インスタンスにバージョン `1.26.0` 以上のコンテナエージェントが必要です。ただし、最新のコンテナエージェントのバージョンを使用することをお勧めします。エージェントのバージョンの確認と最新バージョンへの更新については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。Amazon ECS に最適化された Amazon Linux AMI を使用している場合、インスタンスでは、`ecs-init` パッケージの `1.26.0-1` バージョン以降が必要です。バージョン `20190301` 以降から起動されるコンテナインスタンスには、必要なバージョンのコンテナエージェントや `ecs-init` が含まれています。詳細については、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」を参照してください。
```
"dependsOn": [
{
"containerName": "string",
"condition": "string"
}
]
```
`containerName`
タイプ: 文字列
必須: はい
コンテナ名が指定された条件を満たしている必要があります。
`condition`
タイプ: 文字列
必須: はい
コンテナの依存関係の条件です。使用可能な条件とその動作を以下に示します。
+ `START` - この条件は、すぐに現在のリンクとボリュームの動作をエミュレートします。この条件は、他のコンテナの開始を許可する前に、依存コンテナが開始されていることを検証します。
+ `COMPLETE` - この条件は、他のコンテナの開始を許可する前に、依存コンテナの実行が完了 (終了) することを検証します。これは、スクリプトを実行して終了するだけの、重要性の低いコンテナのために便利です。この条件は、必須コンテナには設定できません。
+ `SUCCESS` - この条件は `COMPLETE` と同じですが、コンテナが `zero` ステータスで終了していることも必要です。この条件は、必須コンテナには設定できません。
+ `HEALTHY` — この条件は、他のコンテナの開始を許可する前に、依存コンテナがそのコンテナのヘルスチェックに合格したことを検証します。これには、タスク定義に設定されているヘルスチェックが依存コンテナにある必要があります。タスクの起動時にのみ、この条件が確認されます。
#### [コンテナのタイムアウト]
`startTimeout`
タイプ: 整数
必須: いいえ
値の例: `120`
コンテナの依存関係解決の再試行を止めるまでの待機時間 (秒)。
例えば、タスク定義内に 2 つのコンテナを指定するとします。`containerA` は、`COMPLETE`、`SUCCESS`、または `HEALTHY` のいずれかのステータスに到達する `containerB` に依存関係を持ちます。`startTimeout` の値に `containerB` が指定されていて、コンテナが時間内に目標のステータスまで到達しない場合、`containerA` は開始しません。
あるコンテナが依存関係における制限事項を満たさない場合、または制限を満たす前にタイムアウトした場合、Amazon ECS は、依存関係にある他のコンテナの状態も次に遷移させることはしません。
最大値は 120 秒です。
`stopTimeout`
タイプ: 整数
必須: いいえ
値の例: `120`
コンテナが正常に終了しなかった場合にコンテナが強制終了されるまでの待機時間 (秒)。
`stopTimeout` パラメータが指定されていない場合、Amazon ECS コンテナエージェント構成変数 `ECS_CONTAINER_STOP_TIMEOUT` に設定された値がデフォルトで使用されます。`stopTimeout` パラメータまたは `ECS_CONTAINER_STOP_TIMEOUT` エージェント設定変数のいずれも設定されていない場合、Linux コンテナと Windows コンテナに対して、デフォルト値の 30 秒が適用されます。コンテナインスタンスには、コンテナ停止タイムアウト値を有効にするために、コンテナエージェントのバージョン 1.26.0 以上が必要です。ただし、最新のコンテナエージェントのバージョンを使用することをお勧めします。エージェントのバージョンの確認方法と最新バージョンへの更新方法については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。Amazon ECS に最適化された Linux Amazon AMI を使用している場合、インスタンスには、少なくとも `ecs-init` パッケージの 1.26.0-1 バージョン以上が必要です。バージョン `20190301` 以降から起動されるコンテナインスタンスには、必要なバージョンのコンテナエージェントや `ecs-init` が含まれています。詳細については、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」を参照してください。
#### システムコントロール
`systemControls`
型: [SystemControl](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_SystemControl.html) オブジェクト
必須: いいえ
コンテナ内で設定する名前空間カーネルパラメータのリスト。このパラメータは docker create-container コマンドの `Sysctls` にマッピングされ、`--sysctl` オプションは docker run にマッピングされます。例えば、接続をより長く維持するように `net.ipv4.tcp_keepalive_time` 設定を構成できます。
`awsvpc` または `host` ネットワークモードも使用する単一のタスクで、複数のコンテナに対してネットワーク関連の `systemControls` パラメータを指定することは推奨されません。これを行うと、次のような欠点があります。
+ `awsvpc` ネットワークモードを使用するタスクの場合、`systemControls` をコンテナ用に設定した場合、タスク内のすべてのコンテナに適用されます。単一のタスクの複数のコンテナに対して異なる `systemControls` を設定すると、最後に開始されたコンテナによって、有効になる `systemControls` が決定します。
+ `host` ネットワークモードを使用するタスクでは、ネットワーク名前空間の `systemControls` はサポートされていません。
タスク内でコンテナに使用するため IPC リソース名前空間を設定している場合、システムコントロールには以下の条件が適用されます。詳細については、「[IPC モード](task_definition_parameters.md#task_definition_ipcmode)」を参照してください。
+ `host` IPC モードを使用するタスクの場合、IPC 名前空間の `systemControls` はサポートされていません。
+ `task` IPC モードを使用するタスクでは、IPC 名前空間の `systemControls` 値が、タスク内のすべてのコンテナに適用されます。
このパラメータは Windows コンテナではサポートされません。
```
"systemControls": [
{
"namespace":"string",
"value":"string"
}
]
```
`namespace`
タイプ: 文字列
必須: いいえ
`value` を設定する名前空間カーネルパラメータ。
有効な IPC 名前空間の値: `"fs.mqueue.*"` で開始する `"kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced"`、および `Sysctls`
有効なネットワーク名前空間値: `"net.*"` で始まる `Sysctls`
`value`
タイプ: 文字列
必須: いいえ
`namespace` で指定された名前空間カーネルパラメータの値。
#### インタラクティブ
`interactive`
タイプ: ブール値
必須: いいえ
このパラメータが `true` の場合、`stdin` または `tty` を割り当てる必要がある、コンテナ化されたアプリケーションをデプロイすることができます。このパラメータは docker create-container コマンドの `OpenStdin` にマッピングされ、`--interactive` オプションは docker run にマッピングされます。
デフォルト: `false`。
#### 擬似ターミナル
`pseudoTerminal`
タイプ: ブール値
必須: いいえ
このパラメータが `true` の場合、TTY が割り当てられます。このパラメータは docker create-container コマンドの `Tty` にマッピングされ、`--tty` オプションは docker run にマッピングされます。
デフォルト: `false`。
## Elastic Inference アクセラレーター名 (廃止)
タスク定義用の Elastic Inference アクセラレーターのリソース要件。
**注記**
Amazon Elastic Inference (EI) は利用できなくなりました。
以下のパラメータをタスク定義で使用できます。
`deviceName`
タイプ: 文字列
必須: はい
Elastic Inference アクセラレーターのデバイス名。`deviceName` は、コンテナ定義でも参照されます。[Elastic Inference accelerator](task_definition_parameters.md#ContainerDefinition-elastic-inference) を参照してください。
`deviceType`
タイプ: 文字列
必須: はい
使用する Elastic Inference アクセラレーター。
## タスク配置の制約事項
タスク定義の登録時、Amazon ECS でのタスク配置方法をカスタマイズするタスク配置の制約を指定できます。
アベイラビリティーゾーン、インスタンスタイプ、またはカスタム属性に基づいたタスク配置の制約を使用できます。詳細については、「[Amazon ECS がタスクに使用するコンテナインスタンスを定義する](task-placement-constraints.md)」を参照してください。
以下のパラメータをコンテナ定義で使用できます。
`expression`
タイプ: 文字列
必須: いいえ
制約に適用されるクラスタークエリ言語表現。詳細については、「[Amazon ECS タスク用のコンテナインスタンスを定義する式を作成する](cluster-query-language.md)」を参照してください。
`type`
タイプ: 文字列
必須: はい
制約のタイプ。選択対象を有効な候補グループに制約するには、`memberOf` を使用します。
## プロキシ設定
`proxyConfiguration`
タイプ: [ProxyConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ProxyConfiguration.html) オブジェクト
必須: いいえ
App Mesh プロキシ設定の詳細。
EC2 を使用するタスクでプロキシ設定を有効にする場合、コンテナインスタンスには、コンテナエージェントのバージョン 1.26.0 以上と `ecs-init` パッケージのバージョン 1.26.0-1 以上が必要です。コンテナインスタンスが Amazon ECS に最適化された AMI バージョン `20190301` 以降から起動される場合、コンテナエージェントおよび `ecs-init` の必要なバージョンが含まれます。詳細については、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」を参照してください。
このパラメータは Windows コンテナではサポートされません。
```
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "string",
"properties": [
{
"name": "string",
"value": "string"
}
]
}
```
`type`
タイプ: 文字列
重要な値: `APPMESH`
必須: いいえ
プロキシのタイプ。`APPMESH` はサポートされる唯一の値です。
`containerName`
タイプ: 文字列
必須: はい
App Mesh プロキシとして機能するコンテナの名前です。
`properties`
タイプ: [パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_KeyValuePair.html)オブジェクトの配列
必須: いいえ
Container Network Interface(CNI) プラグインを提供するネットワーク構成パラメータのセットで、キーと値のペアとして指定されます。
+ `IgnoredUID` - (必須) コンテナ定義の `user` パラメータで定義されるプロキシコンテナのユーザー ID (UID)。これは、プロキシがそれ自体のトラフィックを無視するようにするために使用されます。`IgnoredGID` を指定した場合は、このフィールドは空にできます。
+ `IgnoredGID` - (必須) コンテナ定義の `user` パラメータで定義されるプロキシコンテナのグループ ID (GID)。これは、プロキシがそれ自体のトラフィックを無視するようにするために使用されます。`IgnoredUID` を指定した場合は、このフィールドは空にできます。
+ `AppPorts` - (必須) アプリケーションが使用するポートのリスト。これらのポートへのネットワークトラフィックは `ProxyIngressPort` および `ProxyEgressPort` に転送されます。
+ `ProxyIngressPort` - (必須) `AppPorts` への着信トラフィックが誘導されるポートを指定します。
+ `ProxyEgressPort` - (必須) `AppPorts` からの発信トラフィックが誘導されるポートを指定します。
+ `EgressIgnoredPorts` – (必須) 指定されたこれらのポートに向かうアウトバウンドトラフィックは無視され、`ProxyEgressPort` にリダイレクトされません。空のリストを指定できます。
+ `EgressIgnoredIPs` – (必須) 指定されたこれらの IP アドレスに向かうアウトバウンドトラフィックは無視され、`ProxyEgressPort` にリダイレクトされません。空のリストを指定できます。
`name`
タイプ: 文字列
必須: いいえ
キーと値のペアの名前。
`value`
タイプ: 文字列
必須: いいえ
キーと値のペアの値。
## ボリューム
タスク定義を登録する際、コンテナインスタンスの Docker デーモンに渡されるボリュームのリストを任意で指定することができます。すると、同じコンテナインスタンス上の他のコンテナで使用できるようになります。
使用できるデータボリュームの種類は以下のとおりです。
+ Amazon EBS ボリューム – データ集約型のコンテナ化されたワークロード向けに、費用対効果が高く、耐久性があり、高性能なブロックストレージを提供します。スタンドアロンタスクを実行するとき、またはサービスを作成または更新するときに、Amazon ECS タスクごとに 1 つの Amazon EBS ボリュームをアタッチできます。Amazon EBS ボリュームは、Linux タスクでサポートされています。詳細については、「[Amazon ECS での Amazon EBS ボリュームの使用](ebs-volumes.md)」を参照してください。
+ Amazon EFS ボリューム - Amazon ECS タスクで使用するためのシンプルかつスケーラブルで、永続的なファイルストレージを提供します。Amazon EFSでは、ストレージ容量は伸縮性があります。この容量は、ファイルの追加や削除に伴い自動的に拡大および縮小されます。アプリケーションは、必要なときに必要なストレージを確保できます。Amazon EFS ボリュームがサポートされています。詳細については、「[Amazon ECS での Amazon EFS ボリュームの使用](efs-volumes.md)」を参照してください。
+ FSx for Windows File Server ボリューム – 完全マネージド型の Microsoft Windows ファイルサーバーを提供します。これらのファイルサーバは、Windows ファイルシステムによってバックアップされています。Amazon ECS と共に FSx for Windows File Server を使用する場合、永続的、分散型、共有型、および静的なファイルストレージを使用して、Windows タスクをプロビジョニングすることが可能です。詳細については、「[Amazon ECS での FSx for Windows File Server ボリュームの使用](wfsx-volumes.md)」を参照してください。
このオプションは Fargate の Windows コンテナではサポートされません。
+ Docker ボリューム – ホストの Amazon EC2 インスタンスで `/var/lib/docker/volumes` に作成される Docker マネージドボリューム。Docker ボリュームドライバー (プラグインとも呼ばれる) は、ボリュームを外部ストレージシステム (Amazon EBS など) と統合するために使用します。組み込みの `local` ボリュームドライバーまたはサードパーティーのボリュームドライバーを使用できます。Docker ボリュームは、Amazon EC2 インスタンスでタスクを実行する場合にのみサポートされます。Windows コンテナでは、`local` ドライバーの使用のみがサポートされます。Docker ボリュームを使用するには、タスク定義で `dockerVolumeConfiguration` を指定します。
+ バインドマウント – ホストマシン上のファイルやディレクトリがコンテナにマウントされます。バインドマウントホストボリュームがサポートされています。バインドマウントのホストボリュームを使用するには、タスク定義で `host` およびオプションの `sourcePath` 値を使用します。
詳細については、「[Amazon ECS タスクのストレージオプション](using_data_volumes.md)」を参照してください。
以下のパラメータをコンテナ定義で使用できます。
`name`
タイプ: 文字列
必須: いいえ
ボリュームの名前。最大 255 文字の英字 (大文字と小文字の区別あり)、数字、ハイフン (`-`)、アンダースコア (`_`) を使用できます。この名前は、コンテナ定義 `mountPoints` オブジェクトの `sourceVolume` パラメータで参照されます。
`host`
必須: いいえ
`host` パラメーターは、バインドマウントのライフサイクルを、タスクではなくホスト Amazon EC2 インスタンスと、それが格納されている場所に関連付けるために使用されます。`host` パラメーターが空の場合、Docker デーモンはデータボリュームのホストパスを割り当てますが、関連付けられたコンテナの実行が停止した後にデータが保持されるとは限りません。
Windows コンテナは `$env:ProgramData` と同じドライブに全部のディレクトリをマウントできます。
`sourcePath` パラメータは、Amazon EC2 インスタンスまたは Amazon ECS マネージドインスタンスでホストされているタスクを使用する場合にのみサポートされます。
`sourcePath`
タイプ: 文字列
必須: いいえ
`host` パラメータを使用する場合は、`sourcePath` を指定して、コンテナに表示されるホスト Amazon EC2 インスタンスのパスを宣言します。このパラメータが空の場合は、Docker デーモンによってホストパスが割り当てられます。`host` パラメータに `sourcePath` の場所が含まれている場合、データボリュームは手動で削除するまでホスト Amazon EC2 インスタンスの指定された場所に保持されます。`sourcePath` の値がホスト Amazon EC2 インスタンスに存在しない場合は、Docker デーモンによって作成されます。その場所が存在する場合は、ソースパスフォルダの内容がエクスポートされます。
`configuredAtLaunch`
タイプ: ブール値
必須: いいえ
起動時にボリュームを設定可能にするかどうかを指定します。`true` に設定すると、スタンドアロンタスクを実行するとき、またはサービスを作成または更新するときにボリュームを設定できます。`true` に設定すると、タスク定義内で別のボリューム設定を提供することはできません。タスクにアタッチする Amazon EBS ボリュームを設定するには、このパラメータを `true` に設定する必要があります。`configuredAtLaunch` を `true` に設定し、ボリューム設定を起動フェーズに先送りすることで、ボリュームタイプや特定のボリューム設定に限定されないタスク定義を作成できます。こうすることで、タスク定義をさまざまな実行環境で再利用できるようになります。詳細については、「[Amazon EBS ボリューム](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html)」を参照してください。
`dockerVolumeConfiguration`
タイプ: [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html) オブジェクト
必須: いいえ
このパラメータは、Docker ボリュームを使用する場合に指定します。Docker ボリュームは、EC2 インスタンスでタスクを実行する場合にのみサポートされます。Windows コンテナでは、`local` ドライバーの使用のみがサポートされます。バインドマウントを使用するには、代わりに `host` を指定します。
`scope`
タイプ: 文字列
有効な値: `task` \$1 `shared`
必須: いいえ
Docker ボリュームのスコープ。これにより、ボリュームのライフサイクルが決定されます。Docker ボリュームの範囲が `task` の場合は、タスクが開始すると自動的にプロビジョンされ、タスクが停止すると破棄されます。Docker ボリュームの範囲が `shared` の場合は、タスクの停止後も保持されます。
`autoprovision`
タイプ: ブール値
デフォルト値: `false`
必須: いいえ
この値が `true` の場合、既に存在していない場合は Docker ボリュームが作成されます。このフィールドは、`scope` が `shared` の場合にのみ使用されます。`scope` が `task` の場合、このパラメータは省略する必要があります。
`driver`
タイプ: 文字列
必須: いいえ
使用する Docker ボリュームドライバー。この名前はタスク配置に使用されるため、ドライバー値は Docker で提供されているドライバー名と一致する必要があります。ドライバーが Docker プラグイン CLI を使用してインストールされた場合は、`docker plugin ls` を使用してコンテナインスタンスからドライバー名を取得します。ドライバーが別の方法でインストール済みである場合は、Docker プラグイン検出を使用してドライバー名を取得します。
`driverOpts`
タイプ: 文字列
必須: いいえ
パススルーする Docker ドライバー固有のオプションのマップ。このパラメータは、Docker の「Create a volume」セクションの `DriverOpts` にマッピングされます。
`labels`
タイプ: 文字列
必須: いいえ
Docker ボリュームに追加するカスタムメタデータ。
`efsVolumeConfiguration`
タイプ: [EFSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSVolumeConfiguration.html) オブジェクト
必須: いいえ
このパラメータは、Amazon EFS ボリュームを使用する場合に指定します。
`fileSystemId`
タイプ: 文字列
必須: はい
使用する Amazon EFS ファイルシステムの ID。
`rootDirectory`
タイプ: 文字列
必須: いいえ
ホスト内にルートディレクトリとしてマウントする Amazon EFS ファイルシステム内のディレクトリ。このパラメータを省略すると、Amazon EFS ボリュームのルートが使用されます。`/` を指定すると、このパラメータを省略した場合と同じ結果になります。
`authorizationConfig` で EFS アクセスポイントが指定されている場合は、ルートディレクトリパラメータを省略するか `/` に設定して、EFS アクセスポイントにパスを設定する必要があります。
`transitEncryption`
タイプ: 文字列
有効な値: `ENABLED` \$1 `DISABLED`
必須: いいえ
Amazon ECS ホストと Amazon EFS サーバー間で、転送中の Amazon EFS データの暗号化を有効にするかどうかを指定します。Amazon EFS IAM 認可を使用する場合は、転送中の暗号化を有効にする必要があります。このパラメータを省略すると、`DISABLED` のデフォルト値が使用されます。詳細については、*Amazon Elastic ファイルシステムユーザーガイド*の「[転送中データの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html)」を参照してください。
`transitEncryptionPort`
タイプ: 整数
必須: いいえ
Amazon ECS ホストと Amazon EFS サーバーとの間で、暗号化されたデータを送信するときに使用するポート。転送暗号化ポートを指定しない場合、タスクでは Amazon EFS マウントヘルパーが使用するポート選択戦略が使用されます。詳細については、*[Amazon Elastic File System User Guide]* (Amazon Elastic File System ユーザーガイド) の[[EFS Mount Helper]](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) (EFS マウントヘルパー) を参照してください。
`authorizationConfig`
タイプ: [EFSAuthorizationConfig](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_EFSAuthorizationConfig.html) オブジェクト
必須: いいえ
Amazon EFS ファイルシステムに対する認可構成の詳細。
`accessPointId`
タイプ: 文字列
必須: いいえ
使用するアクセスポイント ID。アクセスポイントが指定されている場合は、`efsVolumeConfiguration` のルートディレクトリ値を省略するか `/` に設定して、EFS アクセスポイントにパスを設定する必要があります。アクセスポイントを使用する場合は、`EFSVolumeConfiguration` で転送中の暗号化を有効にする必要があります。詳細については、*Amazon Elastic ファイルシステムユーザーガイド*の [Amazon EFS アクセスポイントの使用](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html)を参照してください。
`iam`
タイプ: 文字列
有効な値: `ENABLED` \$1 `DISABLED`
必須: いいえ
タスク定義で定義した Amazon ECS タスクの IAM ロールを、Amazon EFS ファイルシステムのマウント時に使用するかどうかを指定します。使用する場合は、`EFSVolumeConfiguration` で転送中の暗号化を有効にする必要があります。このパラメータを省略すると、`DISABLED` のデフォルト値が使用されます。詳細については、「[タスク用の IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)」を参照してください。
`FSxWindowsFileServerVolumeConfiguration`
タイプ: [FSxWindowsFileServerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_FSxWindowsFileServerVolumeConfiguration.html) オブジェクト
必須: はい
このパラメータは、タスクストレージに [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) ファイルシステムを使用する場合に指定します。
`fileSystemId`
タイプ: 文字列
必須: はい
使用する FSx for Windows File Server ファイルシステムID。
`rootDirectory`
タイプ: 文字列
必須: はい
ホスト内にルートディレクトリとしてマウントする FSx for Windows File Server ファイルシステム内のディレクトリ。
`authorizationConfig`
`credentialsParameter`
タイプ: 文字列
必須: はい
認可の認証情報オプション。
**options:**
+ [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) シークレットの Amazon リソースネーム (ARN)。
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html) パラメータの ARN。
`domain`
タイプ: 文字列
必須: はい
[AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD) ディレクトリまたはセルフホスト型 EC2 Active Directory によってホストされる完全修飾ドメイン名。
## タグ
タスク定義の登録する際、タスク定義に適用されるメタデータタグをオプションで指定できます。タグは、タスク定義を分類して組織化するのに役立ちます。各タグは、キーおよび値 (オプション) で構成されます。両方を定義します。詳細については、「[Amazon ECS リソースにタグ付けする](ecs-using-tags.md)」を参照してください。
**重要**
タグには、個人が特定可能な情報や、機密情報あるいは秘匿性の高い情報は追加しないでください。タグは、多くの AWS のサービス (請求など) からアクセスできます。タグは、プライベートデータや機密データに使用することを意図していません。
タグオブジェクトでは、次のパラメータを使用できます。
`key`
タイプ: 文字列
必須: いいえ
タグを構成するキーと値のペアの一部。キーは、より具体的なタグ値のカテゴリのように動作する、一般的なラベルです。
`value`
タイプ: 文字列
必須: いいえ
タグを構成するキーと値のペアのオプションの一部。値はタグカテゴリ (キー) の記述子として機能します。
## その他のタスク定義パラメータ
以下のタスク定義パラメータは、Amazon ECS コンソールから、**[Configure via JSON (JSON による設定)]** オプションを使用してタスク定義を登録する際に使用します。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
**Topics**
+ [IPC モード](#task_definition_ipcmode_ec2)
+ [PID モード](#task_definition_pidmode_ec2)
+ [フォールトインジェクション](#task_definition_faultInjection_ec2)
### IPC モード
`ipcMode`
タイプ: 文字列
必須: いいえ
タスクのコンテナで使用する IPC リソースの名前空間。有効な値は `host`、`task` または `none` です。`host` が指定されている場合、同一のコンテナインスタンス上にある (`host` IPC モードを指定した) タスク内のすべてのコンテナは、ホスト Amazon EC2 インスタンスと同じ IPC リソースを共有します。`task` が指定されている場合、指定されたタスク内のすべてのコンテナは同じ IPC リソースを共有します。`none` が指定されている場合、タスクのコンテナ内の IPC リソースはプライベートです。タスク内またはコンテナインスタンスの他のコンテナと共有されることはありません。値を指定しない場合、IPC リソース名前空間の共有はコンテナインスタンスの Docker デーモンの設定によって異なります。
`host` IPC モードを使用する場合は、意図せず IPC 名前空間が公開されるリスクが高いことに注意してください。
タスク内のコンテナに、`systemControls` を使用して名前空間のカーネルパラメータを設定している場合は、以下の点が IPC リソース名前空間に適用されます。
+ `host` IPC モードを使用するタスクの場合、`systemControls` に関連する IPC 名前空間はサポートされません。
+ `task` IPC モードを使用するタスクでは、IPC 名前空間に関連する `systemControls` が、タスク内のすべてのコンテナに適用されます。
### PID モード
`pidMode`
タイプ: 文字列
有効な値: `host` \$1 `task`
必須: いいえ
タスクのコンテナで使用するプロセス名前空間。有効な値は `host` または `task` です。例えば、サイドカーのモニタリングでは、`pidMode` が同じタスクで実行されている他のコンテナに関する情報にアクセスする必要がある場合があります。
`host` が指定されている場合、同じコンテナインスタンスで `host` PID モードを指定したタスク内のすべてのコンテナは、ホスト Amazon EC2 インスタンスと同じプロセス名前空間を共有します。
`task` が指定されている場合、指定したタスク内のすべてのコンテナは同じプロセス名前空間を共有します。
値が指定されていない場合、デフォルトは各コンテナのプライベート名前空間です。
`host` PID モードを使用する場合は、意図せずプロセス名前空間が公開されるリスクが高いことに注意してください。
**注記**
このパラメータは Windows コンテナではサポートされません。
### フォールトインジェクション
`enableFaultInjection`
タイプ: ブール値
有効な値: `true` \$1 `false`
必須: いいえ
タスクのペイロードでこのパラメータが `true` 設定されている場合、Amazon ECS はタスクのコンテナからのフォールトインジェクションリクエストを受け入れます。デフォルトでは、このパラメータは `false` に設定されます。
# Amazon ECS タスク定義テンプレート
以下に示しているのは、空のタスク定義テンプレートです。このテンプレートを使用してタスク定義を作成します。これにより、コンソールの JSON 入力領域に貼り付けるか、ファイルに保存して AWS CLI の `--cli-input-json` オプションで使用できるようになります。詳細については、「[Fargate での Amazon ECS タスク定義パラメータ](task_definition_parameters.md)」を参照してください。
**EC2 テンプレート**
```
{
"family": "",
"taskRoleArn": "",
"executionRoleArn": "",
"networkMode": "none",
"containerDefinitions": [
{
"name": "",
"image": "",
"repositoryCredentials": {
"credentialsParameter": ""
},
"cpu": 0,
"memory": 0,
"memoryReservation": 0,
"links": [""],
"portMappings": [
{
"containerPort": 0,
"hostPort": 0,
"protocol": "tcp"
}
],
"restartPolicy": {
"enabled": true,
"ignoredExitCodes": [0],
"restartAttemptPeriod": 180
},
"essential": true,
"entryPoint": [""],
"command": [""],
"environment": [
{
"name": "",
"value": ""
}
],
"environmentFiles": [
{
"value": "",
"type": "s3"
}
],
"mountPoints": [
{
"sourceVolume": "",
"containerPath": "",
"readOnly": true
}
],
"volumesFrom": [
{
"sourceContainer": "",
"readOnly": true
}
],
"linuxParameters": {
"capabilities": {
"add": [""],
"drop": [""]
},
"devices": [
{
"hostPath": "",
"containerPath": "",
"permissions": ["read"]
}
],
"initProcessEnabled": true,
"sharedMemorySize": 0,
"tmpfs": [
{
"containerPath": "",
"size": 0,
"mountOptions": [""]
}
],
"maxSwap": 0,
"swappiness": 0
},
"secrets": [
{
"name": "",
"valueFrom": ""
}
],
"dependsOn": [
{
"containerName": "",
"condition": "COMPLETE"
}
],
"startTimeout": 0,
"stopTimeout": 0,
"hostname": "",
"user": "",
"workingDirectory": "",
"disableNetworking": true,
"privileged": true,
"readonlyRootFilesystem": true,
"dnsServers": [""],
"dnsSearchDomains": [""],
"extraHosts": [
{
"hostname": "",
"ipAddress": ""
}
],
"dockerSecurityOptions": [""],
"interactive": true,
"pseudoTerminal": true,
"dockerLabels": {
"KeyName": ""
},
"ulimits": [
{
"name": "nofile",
"softLimit": 0,
"hardLimit": 0
}
],
"logConfiguration": {
"logDriver": "splunk",
"options": {
"KeyName": ""
},
"secretOptions": [
{
"name": "",
"valueFrom": ""
}
]
},
"healthCheck": {
"command": [""],
"interval": 0,
"timeout": 0,
"retries": 0,
"startPeriod": 0
},
"systemControls": [
{
"namespace": "",
"value": ""
}
],
"resourceRequirements": [
{
"value": "",
"type": "InferenceAccelerator"
}
],
"firelensConfiguration": {
"type": "fluentbit",
"options": {
"KeyName": ""
}
}
}
],
"volumes": [
{
"name": "",
"host": {
"sourcePath": ""
},
"configuredAtLaunch": true,
"dockerVolumeConfiguration": {
"scope": "shared",
"autoprovision": true,
"driver": "",
"driverOpts": {
"KeyName": ""
},
"labels": {
"KeyName": ""
}
},
"efsVolumeConfiguration": {
"fileSystemId": "",
"rootDirectory": "",
"transitEncryption": "DISABLED",
"transitEncryptionPort": 0,
"authorizationConfig": {
"accessPointId": "",
"iam": "ENABLED"
}
},
"fsxWindowsFileServerVolumeConfiguration": {
"fileSystemId": "",
"rootDirectory": "",
"authorizationConfig": {
"credentialsParameter": "",
"domain": ""
}
}
}
],
"placementConstraints": [
{
"type": "memberOf",
"expression": ""
}
],
"requiresCompatibilities": ["EC2"],
"cpu": "",
"memory": "",
"tags": [
{
"key": "",
"value": ""
}
],
"pidMode": "task",
"ipcMode": "task",
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "",
"properties": [
{
"name": "",
"value": ""
}
]
},
"inferenceAccelerators": [
{
"deviceName": "",
"deviceType": ""
}
],
"ephemeralStorage": {
"sizeInGiB": 0
},
"runtimePlatform": {
"cpuArchitecture": "X86_64",
"operatingSystemFamily": "WINDOWS_SERVER_20H2_CORE"
}
}
```
**Fargate テンプレート**
**重要**
Fargate では、以下のいずれかの値を持つ `operatingSystemFamily` パラメータを含める必要があります。
`LINUX`
`WINDOWS_SERVER_2019_FULL`
`WINDOWS_SERVER_2019_CORE`
`WINDOWS_SERVER_2022_FULL`
`WINDOWS_SERVER_2022_CORE`
```
{
"family": "",
"runtimePlatform": {"operatingSystemFamily": ""},
"taskRoleArn": "",
"executionRoleArn": "",
"networkMode": "awsvpc",
"platformFamily": "",
"containerDefinitions": [
{
"name": "",
"image": "",
"repositoryCredentials": {"credentialsParameter": ""},
"cpu": 0,
"memory": 0,
"memoryReservation": 0,
"links": [""],
"portMappings": [
{
"containerPort": 0,
"hostPort": 0,
"protocol": "tcp"
}
],
"essential": true,
"entryPoint": [""],
"command": [""],
"environment": [
{
"name": "",
"value": ""
}
],
"environmentFiles": [
{
"value": "",
"type": "s3"
}
],
"mountPoints": [
{
"sourceVolume": "",
"containerPath": "",
"readOnly": true
}
],
"volumesFrom": [
{
"sourceContainer": "",
"readOnly": true
}
],
"linuxParameters": {
"capabilities": {
"add": [""],
"drop": [""]
},
"devices": [
{
"hostPath": "",
"containerPath": "",
"permissions": ["read"]
}
],
"initProcessEnabled": true,
"sharedMemorySize": 0,
"tmpfs": [
{
"containerPath": "",
"size": 0,
"mountOptions": [""]
}
],
"maxSwap": 0,
"swappiness": 0
},
"secrets": [
{
"name": "",
"valueFrom": ""
}
],
"dependsOn": [
{
"containerName": "",
"condition": "HEALTHY"
}
],
"startTimeout": 0,
"stopTimeout": 0,
"hostname": "",
"user": "",
"workingDirectory": "",
"disableNetworking": true,
"privileged": true,
"readonlyRootFilesystem": true,
"dnsServers": [""],
"dnsSearchDomains": [""],
"extraHosts": [
{
"hostname": "",
"ipAddress": ""
}
],
"dockerSecurityOptions": [""],
"interactive": true,
"pseudoTerminal": true,
"dockerLabels": {"KeyName": ""},
"ulimits": [
{
"name": "msgqueue",
"softLimit": 0,
"hardLimit": 0
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {"KeyName": ""},
"secretOptions": [
{
"name": "",
"valueFrom": ""
}
]
},
"healthCheck": {
"command": [""],
"interval": 0,
"timeout": 0,
"retries": 0,
"startPeriod": 0
},
"systemControls": [
{
"namespace": "",
"value": ""
}
],
"resourceRequirements": [
{
"value": "",
"type": "GPU"
}
],
"firelensConfiguration": {
"type": "fluentd",
"options": {"KeyName": ""}
}
}
],
"volumes": [
{
"name": "",
"host": {"sourcePath": ""},
"configuredAtLaunch":true,
"dockerVolumeConfiguration": {
"scope": "task",
"autoprovision": true,
"driver": "",
"driverOpts": {"KeyName": ""},
"labels": {"KeyName": ""}
},
"efsVolumeConfiguration": {
"fileSystemId": "",
"rootDirectory": "",
"transitEncryption": "ENABLED",
"transitEncryptionPort": 0,
"authorizationConfig": {
"accessPointId": "",
"iam": "ENABLED"
}
}
}
],
"requiresCompatibilities": ["FARGATE"],
"cpu": "",
"memory": "",
"tags": [
{
"key": "",
"value": ""
}
],
"ephemeralStorage": {"sizeInGiB": 0},
"pidMode": "task",
"ipcMode": "none",
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "",
"properties": [
{
"name": "",
"value": ""
}
]
},
"inferenceAccelerators": [
{
"deviceName": "",
"deviceType": ""
}
]
}
```
このタスク定義テンプレートは、以下の AWS CLI コマンドにより生成できます。
```
aws ecs register-task-definition --generate-cli-skeleton
```
# Amazon ECS のタスク定義の例
これらの例とスニペットをコピーして、ユーザー自身のタスク定義の作成を開始することができます。
例をコピーして、コンソールで **[JSON 経由の設定]** オプションを使用するときに貼り付けることができます。アカウント ID を使用するなど、例を必ずカスタマイズしてください。スニペットはタスク定義 JSON に含めることができます。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」および「[Fargate での Amazon ECS タスク定義パラメータ](task_definition_parameters.md)」を参照してください。
その他のタスク定義の例については、GitHub の「[AWS のタスク定義例](https://github.com/aws-samples/aws-containers-task-definitions)」を参照してください。
**Topics**
+ [Web サーバー](#example_task_definition-webserver)
+ [`splunk` ログドライバー](#example_task_definition-splunk)
+ [`fluentd` ログドライバー](#example_task_definition-fluentd)
+ [`gelf` ログドライバー](#example_task_definition-gelf)
+ [外部インスタンス上のワークロード](#ecs-anywhere-runtask)
+ [Amazon ECR イメージとタスク定義 IAM ロール](#example_task_definition-iam)
+ [コマンドによるエントリポイント](#example_task_definition-ping)
+ [コンテナの依存関係](#example_task_definition-containerdependency)
+ [タスク定義のボリューム](#volume_sample_task_defs)
+ [Windows のサンプルのタスク定義](#windows_sample_task_defs)
## Web サーバー
以下は、Web サーバーをセットアップするために、Fargate で Linux コンテナを使用するタスク定義の例です。
```
{
"containerDefinitions": [
{
"command": [
"/bin/sh -c \"echo ' Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
' > /usr/local/apache2/htdocs/index.html && httpd-foreground\""
],
"entryPoint": [
"sh",
"-c"
],
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:2.4",
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group" : "/ecs/fargate-task-definition",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
},
"name": "sample-fargate-app",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
]
}
],
"cpu": "256",
"executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
"family": "fargate-task-definition",
"memory": "512",
"networkMode": "awsvpc",
"runtimePlatform": {
"operatingSystemFamily": "LINUX"
},
"requiresCompatibilities": [
"FARGATE"
]
}
```
以下は、Web サーバーをセットアップするために、Fargate で Windows コンテナを使用するタスク定義の例です。
```
{
"containerDefinitions": [
{
"command": ["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value ' Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
'; C:\\ServiceMonitor.exe w3svc"],
"entryPoint": [
"powershell",
"-Command"
],
"essential": true,
"cpu": 2048,
"memory": 4096,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"name": "sample_windows_app",
"portMappings": [
{
"hostPort": 80,
"containerPort": 80,
"protocol": "tcp"
}
]
}
],
"memory": "4096",
"cpu": "2048",
"networkMode": "awsvpc",
"family": "windows-simple-iis-2019-core",
"executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
"runtimePlatform": {"operatingSystemFamily": "WINDOWS_SERVER_2019_CORE"},
"requiresCompatibilities": ["FARGATE"]
}
```
## `splunk` ログドライバー
以下のスニペットでは、タスク定義で、リモートサービスにログを送信する `splunk` ログドライバーを使用する方法を示しています。Splunk トークンパラメータは、機密データとして扱われる可能性があるため、シークレットのオプションとして指定しています。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
```
"containerDefinitions": [{
"logConfiguration": {
"logDriver": "splunk",
"options": {
"splunk-url": "https://cloud.splunk.com:8080",
"tag": "tag_name",
},
"secretOptions": [{
"name": "splunk-token",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:splunk-token-KnrBkD"
}],
```
## `fluentd` ログドライバー
以下のスニペットでは、タスク定義で、リモートサービスにログを送信する `fluentd` ログドライバーを使用する方法を示しています。`fluentd-address` 値は機密データとして扱われる可能性があるため、シークレットのオプションとして指定しています。詳細については、「[Amazon ECS コンテナに機密データを渡す](specifying-sensitive-data.md)」を参照してください。
```
"containerDefinitions": [{
"logConfiguration": {
"logDriver": "fluentd",
"options": {
"tag": "fluentd demo"
},
"secretOptions": [{
"name": "fluentd-address",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:fluentd-address-KnrBkD"
}]
},
"entryPoint": [],
"portMappings": [{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
},
{
"hostPort": 24224,
"protocol": "tcp",
"containerPort": 24224
}]
}],
```
## `gelf` ログドライバー
以下のスニペットでは、タスク定義で、Gelf ログを入力として受け取る Logstash を実行しているリモートホストにログを送信する `gelf` ログドライバーを使用する方法を示しています。詳細については、「[logConfiguration](task_definition_parameters.md#ContainerDefinition-logConfiguration)」を参照してください。
```
"containerDefinitions": [{
"logConfiguration": {
"logDriver": "gelf",
"options": {
"gelf-address": "udp://logstash-service-address:5000",
"tag": "gelf task demo"
}
},
"entryPoint": [],
"portMappings": [{
"hostPort": 5000,
"protocol": "udp",
"containerPort": 5000
},
{
"hostPort": 5000,
"protocol": "tcp",
"containerPort": 5000
}
]
}],
```
## 外部インスタンス上のワークロード
Amazon ECS タスク定義を登録するときは、`requiresCompatibilities`パラメーターを選択し、`EXTERNAL`で、外部インスタンスで Amazon ECS ワークロードを実行するときに、タスク定義が使用できる互換性があることを検証します。コンソールを使用してタスク定義を登録する場合は、JSON エディターを使用する必要があります。詳細については、「[コンソールを使用した Amazon ECS タスク定義の作成](create-task-definition.md)」を参照してください。
**重要**
タスクにタスク実行 IAM ロールが必要な場合は、タスク定義で指定されていることを確認してください。
ワークロードをデプロイするときは、`EXTERNAL`起動タイプを、サービスの作成時またはスタンドアロンタスクの実行時に選択します。
以下は、タスク定義の例です。
------
#### [ Linux ]
```
{
"requiresCompatibilities": [
"EXTERNAL"
],
"containerDefinitions": [{
"name": "nginx",
"image": "public.ecr.aws/nginx/nginx:latest",
"memory": 256,
"cpu": 256,
"essential": true,
"portMappings": [{
"containerPort": 80,
"hostPort": 8080,
"protocol": "tcp"
}]
}],
"networkMode": "bridge",
"family": "nginx"
}
```
------
#### [ Windows ]
```
{
"requiresCompatibilities": [
"EXTERNAL"
],
"containerDefinitions": [{
"name": "windows-container",
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"memory": 256,
"cpu": 512,
"essential": true,
"portMappings": [{
"containerPort": 80,
"hostPort": 8080,
"protocol": "tcp"
}]
}],
"networkMode": "bridge",
"family": "windows-container"
}
```
------
## Amazon ECR イメージとタスク定義 IAM ロール
以下のスニペットでは、`aws-nodejs-sample` という名前の Amazon ECR イメージで、`123456789012.dkr.ecr.us-west-2.amazonaws.com` レジストリの `v1` タグを使用しています。このタスクのコンテナは、`arn:aws:iam::123456789012:role/AmazonECSTaskS3BucketRole` ロールから IAM アクセス許可を継承します。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。
```
{
"containerDefinitions": [
{
"name": "sample-app",
"image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/aws-nodejs-sample:v1",
"memory": 200,
"cpu": 10,
"essential": true
}
],
"family": "example_task_3",
"taskRoleArn": "arn:aws:iam::123456789012:role/AmazonECSTaskS3BucketRole"
}
```
## コマンドによるエントリポイント
以下のスニペットでは、エントリポイントとコマンド引数を使用する Docker コンテナの構文を示しています。このコンテナは `example.com` に対して ping を 4 回実行してから終了します。
```
{
"containerDefinitions": [
{
"memory": 32,
"essential": true,
"entryPoint": ["ping"],
"name": "alpine_ping",
"readonlyRootFilesystem": true,
"image": "alpine:3.4",
"command": [
"-c",
"4",
"example.com"
],
"cpu": 16
}
],
"family": "example_task_2"
}
```
## コンテナの依存関係
このスニペットでは、コンテナの依存関係が指定されている複数のコンテナを含むタスク定義の構文を示しています。次のタスク定義では、`app` コンテナ が開始される前に、`envoy` コンテナが必要とされるコンテナのヘルスチェックパラメータにより決定される正常なステータスに達する必要があります。詳細については、「[コンテナの依存関係](task_definition_parameters.md#container_definition_dependson)」を参照してください。
```
{
"family": "appmesh-gateway",
"runtimePlatform": {
"operatingSystemFamily": "LINUX"
},
"proxyConfiguration":{
"type": "APPMESH",
"containerName": "envoy",
"properties": [
{
"name": "IgnoredUID",
"value": "1337"
},
{
"name": "ProxyIngressPort",
"value": "15000"
},
{
"name": "ProxyEgressPort",
"value": "15001"
},
{
"name": "AppPorts",
"value": "9080"
},
{
"name": "EgressIgnoredIPs",
"value": "169.254.170.2,169.254.169.254"
}
]
},
"containerDefinitions": [
{
"name": "app",
"image": "application_image",
"portMappings": [
{
"containerPort": 9080,
"hostPort": 9080,
"protocol": "tcp"
}
],
"essential": true,
"dependsOn": [
{
"containerName": "envoy",
"condition": "HEALTHY"
}
]
},
{
"name": "envoy",
"image": "840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.15.1.0-prod",
"essential": true,
"environment": [
{
"name": "APPMESH_VIRTUAL_NODE_NAME",
"value": "mesh/meshName/virtualNode/virtualNodeName"
},
{
"name": "ENVOY_LOG_LEVEL",
"value": "info"
}
],
"healthCheck": {
"command": [
"CMD-SHELL",
"echo hello"
],
"interval": 5,
"timeout": 2,
"retries": 3
}
}
],
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"networkMode": "awsvpc"
}
```
## タスク定義のボリューム
以下の情報を参考にして、タスクでボリュームを指定する方法を理解してください。
+ Amazon EBS ボリュームの設定方法については、「[Amazon ECS のデプロイ時に Amazon EBS ボリューム設定を指定する](configure-ebs-volume.md)」を参照してください。
+ Amazon EFS ボリュームの設定方法については、「[コンソールを使用した Amazon ECS での Amazon EFS ファイルシステムの設定](tutorial-efs-volumes.md)」を参照してください。
+ FSx for Windows File Server ボリュームの設定方法については、「[Amazon ECS 用の FSx for Windows File Server ファイルシステムを設定する方法について説明します。](tutorial-wfsx-volumes.md)」を参照してください。
+ Docker ボリュームの設定方法については、「[Amazon ECS の Docker ボリュームの例](docker-volume-examples.md)」を参照してください。
+ バインドマウントの設定方法の詳細については、「[Amazon ECS のバインドマウントの例](bind-mount-examples.md)」を参照してください。
## Windows のサンプルのタスク定義
Amazon ECS で Windows コンテナを使い始める際に役立つタスク定義サンプルを以下に示します。
**Example Windows 用の Amazon ECS コンソールサンプルアプリケーション**
次のタスク定義は、Amazon ECS の初回実行ウィザードで生成される Amazon ECS コンソールのサンプルアプリケーションです。`microsoft/iis` Windows コンテナイメージを使用するために移植されています。
```
{
"family": "windows-simple-iis",
"containerDefinitions": [
{
"name": "windows_sample_app",
"image": "mcr.microsoft.com/windows/servercore/iis",
"cpu": 1024,
"entryPoint":["powershell", "-Command"],
"command":["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value '
Amazon ECS Sample App Amazon ECS Sample App
Congratulations!
Your application is now running on a container in Amazon ECS.
'; C:\\ServiceMonitor.exe w3svc"],
"portMappings": [
{
"protocol": "tcp",
"containerPort": 80
}
],
"memory": 1024,
"essential": true
}
],
"networkMode": "awsvpc",
"memory": "1024",
"cpu": "1024"
}
```