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": 443, "containerPort": 80, "protocol": "tcp" } ], "mountPoints": [ { "sourceVolume": "myEBSVolume", "containerPath": "drive:\ebs", "readOnly": true } ] } ], "volumes": [ { "name": "myEBSVolume", "configuredAtLaunch": true } ], "requiresCompatibilities": [ "FARGATE", "EC2" ], "cpu": "1024", "memory": "3072", "networkMode": "awsvpc" } ``` `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` のままにします。 `name` タイプ: 文字列 必須: いいえ ボリュームの名前。最大 255 文字の英字 (大文字と小文字の区別あり)、数字、ハイフン (`-`)、アンダースコア (`_`) を使用できます。この名前は、コンテナ定義 `mountPoints` オブジェクトの `sourceVolume` パラメータで参照されます。 `configuredAtLaunch` タイプ: ブール値 必須: はい。EBS ボリュームをタスクに直接アタッチしたい場合には必須です。 起動時にボリュームを設定可能にするかどうかを指定します。`true` に設定すると、スタンドアロンタスクを実行するとき、またはサービスを作成または更新するときにボリュームを設定できます。`false` に設定すると、タスク定義内で別のボリューム設定を提供することはできません。タスクにアタッチする Amazon EBS ボリュームを設定するには、このパラメータを `true` に設定する必要があります。 # Amazon ECS タスクにアタッチされた Amazon EBS ボリュームに保存されているデータの暗号化 AWS Key Management Service (AWS KMS) を使用して、データを保護する暗号化キーを作成および管理できます。Amazon EBS ボリュームは、保管時には AWS KMS keys を使用して暗号化されます。以下の種類のデータが暗号化されます。 + ボリュームに保管されているデータ + ディスク I/O + ボリュームから作成されるスナップショット + 暗号化されたスナップショットから作成された新しいボリューム タスクにアタッチされている Amazon EBS ボリュームは、エイリアス `alias/aws/ebs` の付いたデフォルトのAWS マネージドキー か、もしくはボリューム設定に指定されているカスタマーマネージド対称キーを使用して暗号化できます。デフォルトの AWS マネージドキー はそれぞれの AWS リージョン ごとの AWS アカウント に対して固有で、自動的に作成されます。カスタマーマネージド型の対称キーを作成するには、「*AWS KMS デベロッパーガイド*」の「[対称暗号化 KMS キーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)」に記載の手順に従ってください。 Amazon EBS 暗号化をデフォルトで設定できます。これにより、特定の AWS リージョン 内のタスクにアタッチされた新しいボリュームはすべて、アカウントに設定した KMS キーを使用して暗号化されます。Amazon EBS の暗号化およびデフォルトの暗号化の詳細については、「*Amazon EBS ユーザーガイド*」の「[Amazon EBS の暗号化](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html)」を参照してください。 ## Amazon ECS マネージドインスタンスの動作 デフォルトで暗号化を有効にするか、暗号化したいボリュームの作成時に都度有効化することで、Amazon EBS ボリュームを暗号化することが可能です。(アカウントレベルで) デフォルトでの暗号化を有効にする方法について、詳細は「*Amazon EBS ユーザーガイド*」の「[暗号化をデフォルトで有効にする](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html)」を参照してください。 これらのキーは任意の組み合わせで設定できます。KMS キーの優先順位は次のとおりです。 1. ボリューム設定で指定された KMS キー。ボリューム設定で KMS キーを指定すると、Amazon EBS のデフォルトとアカウントレベルで指定した KMS キーがオーバーライドされます。 1. アカウントレベルで指定された KMS キー。Amazon ECS マネージドストレージのクラスターレベルの暗号化に KMS キーを指定すると、Amazon EBS のデフォルトの暗号化はオーバーライドされますが、ボリューム設定に指定した KMS キーはオーバーライドされません。 1. Amazon EBS のデフォルトの暗号化。デフォルトの暗号化は、アカウントレベルの KMS キーまたはボリューム設定でキーを指定しない場合に適用されます。Amazon EBS 暗号化をデフォルトで有効にすると、デフォルトの暗号化用に指定した KMS キーがデフォルトになります。それ以外の場合、デフォルトはエイリアス `alias/aws/ebs` の AWS マネージドキー になります。 **注記** `encrypted` をボリューム設定の `false` に設定し、アカウントレベルの KMS キーを指定せずにデフォトで Amazon EBS 暗号化を有効にすると、そのボリュームはデフォルトで Amazon EBS 暗号化に指定されたキーで暗号化されます。 ## Amazon ECS 以外のマネージドインスタンスの動作 クラスターを作成または更新する時に、Amazon ECS マネージドストレージの Amazon ECS クラスターレベルの暗号化を設定することもできます。クラスターレベルの暗号化はタスクレベルで適用され、指定された KMS キーを使用することで、特定のクラスター上で実行する各タスクにアタッチされた Amazon EBS ボリュームの暗号化を行うことができます。各タスクに対するクラスターレベルでの暗号化設定について、詳細は「*Amazon ECS API リファレンス*」の「[マネージドストレージ設定](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedStorageConfiguration.html)」を参照してください。 これらのキーは任意の組み合わせで設定できます。KMS キーの優先順位は次のとおりです。 1. ボリューム設定で指定された KMS キー。ボリューム設定で KMS キーを指定すると、Amazon EBS のデフォルトとクラスターレベルで指定した KMS キーがオーバーライドされます。 1. クラスターレベルで指定された KMS キー。Amazon ECS マネージドストレージのクラスターレベルの暗号化に KMS キーを指定すると、Amazon EBS のデフォルトの暗号化はオーバーライドされますが、ボリューム設定に指定した KMS キーはオーバーライドされません。 1. Amazon EBS のデフォルトの暗号化。デフォルトの暗号化は、クラスターレベルの KMS キーまたはボリューム設定でキーを指定しない場合に適用されます。Amazon EBS 暗号化をデフォルトで有効にすると、デフォルトの暗号化用に指定した KMS キーがデフォルトになります。それ以外の場合、デフォルトはエイリアス `alias/aws/ebs` の AWS マネージドキー になります。 **注記** `encrypted` を ボリューム設定 の `false` に設定し、クラスターレベルの KMS キーを指定せずにデフォトで Amazon EBS 暗号化を有効にすると、そのボリュームはデフォルトで Amazon EBS 暗号化に指定されたキーで暗号化されます。 ## カスタマーマネージド型 KMS キーのポリシー カスタマーマネージド型キーを使用してタスクにアタッチされている EBS ボリュームを暗号化するには、KMS キーポリシーを設定して、ボリューム設定に使用する IAM ロールにキーの使用に必要な権限を付与する必要があります。キーポリシーには、`kms:CreateGrant` と `kms:GenerateDataKey*` 両方のアクセス許可を含める必要があります。スナップショットを使用して作成されたボリュームを暗号化するには、`kms:ReEncryptTo` および `kms:ReEncryptFrom` のアクセス許可が必要です。アタッチする新しい空のボリュームのみを設定して暗号化する場合は、`kms:ReEncryptTo` および `kms:ReEncryptFrom` のアクセス許可は除外できます。 以下の JSON スニペットは、KMS キーポリシーにアタッチするキーポリシーステートメントを示します。これらのステートメントにより、Amazon ECS がキーを使用して EBS ボリュームを暗号化できるようになります。ここに挙げたポリシーステートメントを実行するには、`user input placeholders` をユーザー自身の情報に置き換えます。他の場合と同様に、必要な権限のみを設定してください。 ``` { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": "kms:DescribeKey", "Resource":"*" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": [ "kms:GenerateDataKey*", "kms:ReEncryptTo", "kms:ReEncryptFrom" ], "Resource":"*", "Condition": { "StringEquals": { "kms:CallerAccount": "aws_account_id", "kms:ViaService": "ec2.region.amazonaws.com" }, "ForAnyValue:StringEquals": { "kms:EncryptionContextKeys": "aws:ebs:id" } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" }, "Action": "kms:CreateGrant", "Resource":"*", "Condition": { "StringEquals": { "kms:CallerAccount": "aws_account_id", "kms:ViaService": "ec2.region.amazonaws.com" }, "ForAnyValue:StringEquals": { "kms:EncryptionContextKeys": "aws:ebs:id" }, "Bool": { "kms:GrantIsForAWSResource": true } } } ``` キーポリシーとアクセス許可について、詳しくは「*AWS KMS デベロッパーガイド*」の「[AWS KMS のキーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)」および「[AWS KMS のアクセス許可](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html)」を参照してください。キーのアクセス許可に関連する EBS ボリュームアタッチメントのトラブルシューティングについては、「[Amazon ECS タスクへの Amazon EBS ボリュームのアタッチに関するトラブルシューティング](troubleshoot-ebs-volumes.md)」を参照してください。 # Amazon ECS のデプロイ時に Amazon EBS ボリューム設定を指定する `configuredAtLaunch` パラメータを `true` に設定してタスク定義を登録すると、デプロイ時にスタンドアロンタスクを実行するとき、またはサービスを作成または更新するときに Amazon EBS ボリュームを設定できます。`configuredAtLaunch` パラメータを使用してボリューム設定を起動時間まで延長する方法について、詳細は「[ボリューム設定を Amazon ECS のタスク定義の起動時刻まで延期する](specify-ebs-config.md)」を参照してください。 ボリュームを設定するには、Amazon ECS API を使用するか、あるいは次の AWS CLI コマンドの入力として JSON ファイルを渡します。 + スタンドアロン ECS タスクを実行するための `[run-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html)`。 + 特定のコンテナインスタンスでスタンドアロン ECS タスクを実行するための `[start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html)`。このコマンドは Fargate のタスクには適用されません。 + 新しい ECS サービスを作成するための `[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)`。 + 既存のサービスを更新するための `[update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)`。 **注記** マウント済みの Amazon EBS ボリュームへタスク内のコンテナが書き込みを行うには、適切なファイルシステムのアクセス許可を所持している必要があります。コンテナ定義で非ルートユーザーを指定すると、Amazon ECS は、指定されたユーザーがボリュームを読み書きできるようにするグループベースのアクセス許可でボリュームを自動的に設定します。ユーザーを指定しない場合、コンテナはルートとして実行され、ボリュームへのフルアクセスを持ちます。 あるいは、AWS マネジメントコンソール を使用して Amazon EBS ボリュームを設定することもできます。詳細については[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)、[Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)、および[Amazon ECS サービスを更新する](update-service-console-v2.md)を参照してください。 以下の JSON スニペットは、デプロイ時に設定可能なすべての Amazon EBS ボリュームパラメータを示します。ボリューム設定でこれらのパラメータを使用するには、`user input placeholders` をユーザー自身の情報に置き換えます。これらのパラメータの詳細については、「[ボリュームの設定](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-volumeConfigurations)」を参照してください。 ``` "volumeConfigurations": [ { "name": "ebs-volume", "managedEBSVolume": { "encrypted": true, "kmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "volumeType": "gp3", "sizeInGiB": 10, "snapshotId": "snap-12345", "volumeInitializationRate":100, "iops": 3000, "throughput": 125, "tagSpecifications": [ { "resourceType": "volume", "tags": [ { "key": "key1", "value": "value1" } ], "propagateTags": "NONE" } ], "roleArn": "arn:aws:iam::1111222333:role/ecsInfrastructureRole", "terminationPolicy": { "deleteOnTermination": true//can't be configured for service-managed tasks, always true }, "filesystemType": "ext4" } } ] ``` **重要** 設定内で指定する `volumeName` は、タスク定義で指定する `volumeName` と同じであること。 ボリュームアタッチメントのステータスの確認については、「[Amazon ECS タスクへの Amazon EBS ボリュームのアタッチに関するトラブルシューティング](troubleshoot-ebs-volumes.md)」を参照してください。EBS ボリュームのアタッチメントに必要な Amazon ECS インフラストラクチャ AWS Identity and Access Management (IAM) ロールの詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。 Amazon EBS ボリュームの設定内容を示す JSON スニペットの例を以下に挙げます。これらの例は、スニペットを JSON ファイルに保存し、そのファイルを AWS CLI コマンドのパラメータ (`--cli-input-json file://filename` パラメータを使用) として渡すことで使用できます。`user input placeholders` を、ユーザー自身の情報に置き換えます。 ## スタンドアロンタスク向けボリュームの設定 以下のスニペットは、Amazon EBS ボリュームをスタンドアロンタスクにアタッチする設定の構文を示します。以下の JSON スニペットは、`volumeType`、`sizeInGiB`、`encrypted`、`kmsKeyId` の各設定を構成するための構文を示します。JSON ファイルに指定された設定を使用して EBS ボリュームを作成し、スタンドアロンタスクにアタッチします。 ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "volumeConfigurations": [ { "name": "datadir", "managedEBSVolume": { "volumeType": "gp3", "sizeInGiB": 100, "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "encrypted": true, "kmsKeyId": "arn:aws:kms:region:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } } ] } ``` ## サービス作成時のボリューム設定 以下のスニペットは、サービスで管理されるタスクにアタッチする Amazon EBS ボリュームを設定する構文を示します。ボリュームは、`snapshotId` パラメータを使用して指定されたスナップショットから 200 MiB/秒のレートで取得されます。JSON ファイルに指定された設定を使用して EBS ボリュームを作成し、サービスで管理される各タスクにアタッチします。 ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "serviceName": "mysvc", "desiredCount": 2, "volumeConfigurations": [ { "name": "myEbsVolume", "managedEBSVolume": { "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "snapshotId": "snap-12345", "volumeInitializationRate": 200 } } ] } ``` ## サービス更新時のボリューム設定 以下の JSON スニペットは、これまでタスクへのアタッチ用に Amazon EBS ボリュームが設定されていなかったサービスを更新するための構文を示します。`configuredAtLaunch` を `true` に設定したタスク定義リビジョンの ARN を提供する必要があります。以下の JSON スニペットは、`volumeType`、`sizeInGiB`、`throughput`、`iops`、および `filesystemType` 設定を構成する構文を示します。これらの設定を使用して EBS ボリュームを作成し、サービスで管理される各タスクにアタッチします。 ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "service": "mysvc", "desiredCount": 2, "volumeConfigurations": [ { "name": "myEbsVolume", "managedEBSVolume": { "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole", "volumeType": "gp3", "sizeInGiB": 100, "iops": 3000, "throughput": 125, "filesystemType": "ext4" } } ] } ``` ### Amazon EBS ボリュームを使用しないようにサービスを設定する 以下の JSON スニペットは、Amazon EBS ボリュームをそれ以上使用しないようにサービスを更新するための構文を示します。`configuredAtLaunch` を `false` に設定したタスク定義の ARN 、または `configuredAtLaunch` パラメータのないタスク定義を提供する必要があります。空の `volumeConfigurations` オブジェクトも提供する必要があります。 ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "service": "mysvc", "desiredCount": 2, "volumeConfigurations": [] } ``` ## Amazon EBS ボリュームの終了ポリシー Amazon ECS タスクが終了すると、Amazon ECS は `deleteOnTermination` の値に基づいて、終了したタスクに関連付けられている Amazon EBS ボリュームを削除する必要があるかどうかを判断します。デフォルトでは、タスクにアタッチされている EBS ボリュームは、タスクが終了すると削除されます。スタンドアロンタスクの場合、タスク終了時にボリュームを保存するように設定を変更することができます。 **注記** サービスにより管理されるタスクにアタッチされたボリュームは保存されず、タスク終了時に必ず削除されます。 ## Amazon EBS ボリュームのタグ付け `tagSpecifications` オブジェクトを使用して Amazon EBS ボリュームにタグを付けることができます。このオブジェクトを使用すると、ボリュームがスタンドアロンタスクにアタッチされているか、あるいはサービス内のタスクにアタッチされているかに応じて、独自のタグを提供したり、あるいはタスク定義またはサービスからタグを伝播するよう設定することができます。1 つのボリュームにアタッチできるタグの最大数は 50 個です。 **重要** Amazon ECS は、`AmazonECSCreated` および `AmazonECSManaged` のリザーブドタグを Amazon EBS ボリュームに自動的にアタッチするので、1 つのボリュームにユーザーが追加できるタグの最大数は 48 個になります。追加できるタグは、ユーザー定義タグ、ECS マネージド型タグ、または伝播されたタグのいずれです。 Amazon ECS マネージド型タグをボリュームに追加する場合は、`UpdateService`、`CreateService`、`RunTask`、`StartTask` の呼び出しの `enableECSManagedTags` を `true` に設定する必要があります。Amazon ECS マネージド型タグをオンにすると、Amazon ECS はボリュームにクラスターとサービスの情報 (`aws:ecs:clusterName` と `aws:ecs:serviceName`) を自動的にタグ付けします。Amazon ECS リソースへのタグ付けの詳細については、「[Amazon ECS リソースのタグ付け](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html)」を参照してください。 以下の JSON スニペットは、サービス内の各タスクにアタッチされた Amazon EBS ボリュームにユーザー定義タグを付ける構文を示します。この例を使用してサービスを作成するには、`user input placeholders` をユーザー自身の情報に置き換えます。 ``` { "cluster": "mycluster", "taskDefinition": "mytaskdef", "serviceName": "mysvc", "desiredCount": 2, "enableECSManagedTags": true, "volumeConfigurations": [ { "name": "datadir", "managedEBSVolume": { "volumeType": "gp3", "sizeInGiB": 100, "tagSpecifications": [ { "resourceType": "volume", "tags": [ { "key": "key1", "value": "value1" } ], "propagateTags": "NONE" } ], "roleArn":"arn:aws:iam:1111222333:role/ecsInfrastructureRole", "encrypted": true, "kmsKeyId": "arn:aws:kms:region:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } } ] } ``` **重要** Amazon EBS ボリュームにタグを付けるには、`volume` リソースタイプを指定する必要があります。 # Fargate オンデマンドタスク向け Amazon EBS ボリュームのパフォーマンス Fargate オンデマンドタスクで使用できる Amazon EBS ボリュームのベースライン IOPS とスループットは、タスクにリクエストする CPU ユニット数の合計によって異なります。Fargate タスクに 0.25 ユニット、0.5 ユニット、または 1 ユニットの仮想 CPU (vCPU) をリクエストする場合は、汎用 SSD ボリューム (`gp2` または `gp3`) もしくはハードディスクドライブ (HDD) ボリューム (`st1` または `sc1`) を設定することをお勧めします。Fargate タスク向けに 1 ユニットを超える vCPU をリクエストする場合、タスクにアタッチされる Amazon EBS ボリュームには以下のベースラインパフォーマンス制限が適用されます。EBS のパフォーマンスは、一時的には以下の制限値よりも高くなる場合がありますが、これらの制限値に基づいてワークロードを計画することをお勧めします。 | リクエストされる CPU (vCPU) ユニット数 | Amazon EBS のベースライン IOPS (16 KiB I/O) | Amazon EBS のベースラインスループット (MiBps、128 KiB I/O) | ベースライン帯域幅 (Mbps) | | --- | --- | --- | --- | | 2 | 3,000 | 75 | 360 | | 4 | 5,000 | 120 | 1,150 | | 8 | 10,000 | 250 | 2,300 | | 16 | 15,000 | 500 | 4,500 | **注記** Fargate タスクにアタッチする Amazon EBS ボリュームを設定すると、その Fargate タスク向け Amazon EBS パフォーマンス制限は、タスクの一時ストレージとアタッチされたボリューム間で共有されます。 # EC2 タスクの Amazon EBS ボリュームのパフォーマンス Amazon EBS の提供するボリュームタイプはそれぞれパフォーマンス特性や料金が異なるため、アプリケーションのニーズに応じてストレージのパフォーマンスやコストを調整してください。ボリュームごとの IOPS やスループットなどのパフォーマンスについて、詳細は「*Amazon Elastic Block Store ユーザーガイド*」の「[Amazon EBS ボリュームタイプ](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)」を参照してください。 # Amazon ECS マネージドインスタンスタスクの Amazon EBS ボリュームのパフォーマンス Amazon EBS の提供するボリュームタイプはそれぞれパフォーマンス特性や料金が異なるため、アプリケーションのニーズに応じてストレージのパフォーマンスやコストを調整してください。ボリュームごとの IOPS やスループットなどのパフォーマンスについて、詳細は「*Amazon Elastic Block Store ユーザーガイド*」の「[Amazon EBS ボリュームタイプ](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)」を参照してください。 # Amazon ECS タスクへの Amazon EBS ボリュームのアタッチに関するトラブルシューティング 場合により、Amazon EBS ボリュームの Amazon ECS タスクへのアタッチをトラブルシューティングまたは検証しなければならない場合があります。 ## ボリュームのアタッチメントステータスを確認する AWS マネジメントコンソールを使用して、Amazon EBS ボリュームの Amazon ECS タスクへのアタッチのステータスを確認できます。タスクが開始されたがアタッチメントが機能しない場合は、表示されるステータス理由を確認してトラブルシューティングに活用してください。作成されたボリュームは削除され、タスクは停止します。ステータス理由の詳細については、「[Amazon ECS タスクへの Amazon EBS ボリュームアタッチメントのステータス理由](troubleshoot-ebs-volumes-scenarios.md)」を参照してください。 **コンソール上でボリュームのアタッチステータスとステータス理由を確認するには** 1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。 1. **[クラスター]** ページで、タスクが実行されているクラスターを選択します。クラスターの詳細ページが表示されます。 1. クラスターの詳細ページで、**[タスク]** タブを選択します。 1. ボリュームアタッチメントステータスを確認したいタスクを選択します。確認したいタスクが停止している場合には、**[表示するステータスを絞り込む]** で **[停止]** を選択しなければならない場合があります。 1. タスクの詳細ページで、**[ボリューム]** タブを選択します。Amazon EBS ボリュームのアタッチメントステータスは、**[アタッチメントステータス]** で確認できます。ボリュームがタスクにアタッチされない場合は、**[アタッチメントのステータス]** でステータスを選択して、失敗の原因を表示できます。 または、[DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) API を使用して、タスクのボリュームアタッチメントステータスおよび関連するステータス理由を確認することもできます。 ## サービスとタスクの失敗 Amazon EBS ボリュームに固有ではないサービスまたはタスクの失敗が発生して、ボリュームのアタッチメントに影響を及ぼす場合があります。詳細については、以下を参照してください。 + [サービスイベントメッセージ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-event-messages.html) + [停止したタスクのエラーコード](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html) + [API 失敗の理由](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/api_failures_messages.html) # コンテナが Amazon EBS ボリュームに書き込めない 適切なアクセス許可のない非ルートユーザー コンテナ定義で非ルートユーザーを指定すると、Amazon ECS は書き込みアクセスを許可するグループベースのアクセス許可でボリュームを自動的に設定します。アクセス許可の問題がまだ解決しない場合: + `uid:gid` フォーマット (例: `1001:1001`) を使用して、`user` パラメータがコンテナ定義で正しく指定されていることを確認してください。 + ボリュームのマウント後に、ユーザーのアクセス許可がコンテナイメージに上書きされないようにしてください。 + コンテナログを調べるか、Amazon ECS Exec を使用して実行中のコンテナを調べることで、アプリケーションが想定されたユーザー ID で実行されていることを確認します。 アクセス許可の問題があるルートユーザー コンテナ定義でユーザーの指定がされていない場合、コンテナはルートとして実行され、ボリュームへのフルアクセスが必要になります。問題が発生した場合: + コンテナ内のマウントポイントを確認して、ボリュームが正しくマウントされていることを確認します。 + マウントポイント設定で、ボリュームの設定が読み取り専用でないことを確認してください。 ユーザーが異なる複数コンテナタスク 複数のコンテナが異なるユーザーとして実行されるタスクでは、Amazon ECS はグループアクセス許可を自動的に管理し、指定されたすべてのユーザーのボリュームへの書き込みを許可します。コンテナが書き込めない場合: + 書き込みアクセスを必要とするすべてのコンテナに `user` パラメータが正しく設定されていることを確認してください。 + ボリュームへのアクセスが必要なすべてのコンテナにボリュームがマウントされていることを確認してください。 コンテナ定義でユーザーを設定する方法について、詳細は「[Fargate の Amazon ECS タスク定義パラメータ](https://docs.aws.amazon.com/./task_definition_parameters.html)」を参照してください。 # Amazon ECS タスクへの Amazon EBS ボリュームアタッチメントのステータス理由 Amazon ECS タスクにアタッチする Amazon EBS ボリュームを設定する際に AWS マネジメントコンソール上にステータス理由として表示されるエラーを解決するには、以下の情報を参照してください。コンソール上でこれらのステータス理由を見つける方法については、「[ボリュームのアタッチメントステータスを確認する](troubleshoot-ebs-volumes.md#troubleshoot-ebs-volumes-location)」を参照してください。 ECS は、設定された ECS インフラストラクチャロール「arn:aws:iam::*111122223333*:role/*ecsInfrastructureRole*」を引き受けることができませんでした。渡されるロールが Amazon ECS と適切な信頼関係にあることを確認してください。 このステータス理由は以下のシナリオにおいて発生します。 + 必要な信頼ポリシーをアタッチせずに IAM ロールを提供した場合。ロールに必要な信頼ポリシーがない場合、Amazon ECS は提供された Amazon ECS インフラストラクチャ IAM ロールにアクセスできません。タスクが `DEPROVISIONING` 状態でスタックすることがあります。必要な信頼ポリシーの詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。 + IAM ユーザーが、Amazon ECS インフラストラクチャロールを Amazon ECS に渡すアクセス許可を持っていません。タスクが `DEPROVISIONING` 状態でスタックすることがあります。この問題を回避するには、ユーザーに `PassRole` 許可を付与します。詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。 + IAM ロールが、Amazon EBS ボリュームのアタッチメントに必要なアクセス許可を持っていません。タスクが `DEPROVISIONING` 状態でスタックすることがあります。Amazon EBS ボリュームをタスクにアタッチするために必要なアクセス許可の詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。 このエラーメッセージは、ロールの伝播が遅れている場合にも表示されることがあります。数分待ってからロールを使用しても問題が解決しない場合は、ロールの信頼ポリシーが誤って設定されている可能性があります。 ECS が EBS ボリュームを設定できません。「IdempotentParameterMismatch が発生しました」。「指定したクライアントトークンは、すでに削除されているリソースに関連付けられています。別のクライアントトークンを使用してください。」 以下のような AWS KMS キーシナリオでは、`IdempotentParameterMismatch` メッセージが表示されることがあります。 + 無効な KMS キー ARN、ID、またはエイリアスが指定されました。このシナリオでは、一見タスクが正常に起動したように見えますが、AWS は KMS キーを非同期で認証するため、タスクは最終的に失敗します。詳細は「*Amazon EC2 ユーザーガイド*」の「[Amazon EBS 暗号化](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html)」を参照してください。 + Amazon ECS インフラストラクチャ IAM ロールがそのキーを暗号化に使用することを許可する権限を持たないカスタマーマネージド型キーが提供されました。キーポリシー権限に関する問題を回避するには、「[Amazon EBS ボリュームのデータ暗号化](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html#ebs-kms-encryption)」の AWS KMS キーポリシー例を参照してください。 Amazon EBS ボリュームイベントと Amazon ECS タスク状態変更イベントを Amazon CloudWatch グループなどのターゲットに送信するように Amazon EventBridge を設定できます。その後、これらのイベントを使用して、ボリュームアタッチメントに影響を及ぼしているカスタマーマネージド型キーに関する問題を特定することができます。詳細については、以下を参照してください。 + AWS re: Post 上の「[EventBridge ルールのターゲットとして使用する CloudWatch ロググループをどのように作成できますか?](https://repost.aws/knowledge-center/cloudwatch-log-group-eventbridge)」。 + [タスク状態変更イベント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html#ecs_task_events)。 + [Amazon EBS の Amazon EventBridge イベント](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-cloud-watch-events.html) (*Amazon EBS ユーザーガイド*)。 タスクへの EBS ボリュームアタッチメントの設定中に ECS がタイムアウトしました。 このメッセージは、ファイルシステム形式に関する以下のシナリオにおいて発生します。 + 設定時に指定されたファイルシステム形式は、[タスクのオペレーティングシステム](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RuntimePlatform.html)と互換性がありません。 + Amazon EBS ボリュームをスナップショットから作成するように設定しましたが、スナップショットのファイルシステム形式にはタスクのオペレーティングシステムとの互換性がありません。スナップショットから作成されたボリュームでは、スナップショットの作成時にボリュームが使用していたのと同じファイルシステムタイプを指定する必要があります。 Amazon ECS コンテナエージェントのログを利用して、EC2 のタスクに関するメッセージのトラブルシューティングを行うことができます。詳細については、「[Amazon ECS ログファイルの場所](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logs.html)」と「[Amazon ECS ログコレクター](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-logs-collector.html)」を参照してください。 # Amazon ECS での Amazon EFS ボリュームの使用 Amazon Elastic File System (Amazon EFS) では、Amazon ECS タスクで使用するためのシンプルでスケーラブルなファイルストレージを提供します。Amazon EFSでは、ストレージ容量は伸縮性があります。この容量は、ファイルの追加や削除に伴い自動的に拡大および縮小されます。アプリケーションは、必要な時点で必要なストレージを確保できます。 Amazon EFS ファイルシステムを Amazon ECS で使用して、コンテナインスタンスのフリート全体のファイルシステムデータをエクスポートできます。これにより、タスクは、配置されているインスタンスにかかわらず、同じ永続的ストレージにアクセスできます。ファイルシステムを使用するには、タスク定義からコンテナインスタンスのボリュームマウントを参照する必要があります。 チュートリアルについては、「[コンソールを使用した Amazon ECS での Amazon EFS ファイルシステムの設定](tutorial-efs-volumes.md)」を参照してください。 ## 考慮事項 Amazon EFS ボリュームを使用する場合には、以下の点を考慮してください。 + EC2 上で実行されるタスク向けに、Amazon EFS ファイルシステムサポートは、コンテナエージェントバージョン 1.35.0 を搭載した Amazon ECS 最適化 AMI バージョン `20191212` とともに、パブリックプレビューとして追加されました。ただし、Amazon EFS ファイルシステムのサポートは、コンテナエージェントバージョンが 1.38.0 の Amazon ECS 最適化 AMI バージョン `20200319` (Amazon EFS アクセスポイントと IAM 認可機能が含まれるもの) で一般提供されています。これらの機能を使用する際には、Amazon ECS 最適化 AMI バージョン `20200319` 以降の使用をお勧めします。詳細については、「[Amazon ECS に最適化された Linux AMI](ecs-optimized_AMI.md)」を参照してください。 **注記** 独自の AMI を作成する場合、コンテナエージェント 1.38.0 以降、`ecs-init` バージョン 1.38.0-1 以降を使用し、Amazon EC2 インスタンスで以下のコマンドを実行して、Amazon ECS ボリュームプラグインを有効にする必要があります。コマンドは、ベースイメージとして Amazon Linux 2 と Amazon Linux のどちらを使用しているかによって異なります。 Amazon Linux 2 ``` yum install amazon-efs-utils systemctl enable --now amazon-ecs-volume-plugin ``` Amazon Linux ``` yum install amazon-efs-utils sudo shutdown -r now ``` + Fargate でホストされるタスクの場合、プラットフォームバージョン 1.4.0 以降 (Linux) で、Amazon EFS ファイルシステムがサポートされます。詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。 + Fargate でホストされるタスクに Amazon EFS ボリュームを使用する場合、Fargate は Amazon EFS ボリュームの管理を担当するスーパーバイザーコンテナを作成します。スーパーバイザーコンテナは、タスクのメモリと CPU を少量使用します。スーパーバイザーコンテナは、タスクメタデータバージョン 4 エンドポイントにクエリを実行するときに表示されます。さらに、CloudWatch Container Insights では、コンテナ名 `aws-fargate-supervisor` として表示されます。EC2 の使用時について、詳細は「[Amazon ECS タスクメタデータエンドポイントバージョン 4](task-metadata-endpoint-v4.md)」を参照してください。Fargate の使用時について、詳細は「[Fargate のタスク用の Amazon ECS タスクメタデータエンドポイントバージョン 4](task-metadata-endpoint-v4-fargate.md)」を参照してください。 + Amazon EFS ボリュームの使用または `EFSVolumeConfiguration` の指定は、外部インスタンスではサポートされていません。 + Amazon EFS ボリュームの使用は、Amazon ECS マネージドインスタンスで実行されるタスクでサポートされています。 + エージェント設定ファイルの `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` パラメータは、デフォルトよりも小さい値 (約 1 時間) に設定することをお勧めします。この変更は、EFS マウント認証情報の有効期限切れを防ぎ、使用されていないマウントをクリーンアップするのに役立ちます。 詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。 ## Amazon EFS アクセスポイントの使用 Amazon EFS アクセスポイントは、EFS ファイルシステムへのアプリケーション固有のエントリポイントです。これにより、共有データセットへのアプリケーションによるアクセスを管理します。Amazon EFS アクセスポイントの詳細およびアクセス制御方法については、*Amazon Elastic File System ユーザーガイド*の「[Amazon EFS アクセスポイントの使用](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html)」を参照してください。 アクセスポイントを使用すると、アクセスポイントを介したすべてのファイルシステム要求に対してユーザーアイデンティティ (ユーザーの POSIX グループなど) を適用できます。また、アクセスポイントでは、ファイルシステムに対して別のルートディレクトリを適用することも可能です。クライアントは、指定したディレクトリまたはそのサブディレクトリ内のデータに対してのみアクセスが可能なためです。 **注記** EFS アクセスポイントを作成する際は、ファイルシステム上でルートディレクトリとして機能するパスを指定します。Amazon ECS タスク定義内でアクセスポイント ID を持つ EFS ファイルシステムを参照する場合、ルートディレクトリは省略するか、EFS アクセスポイントに設定されたパスを適用するために `/` を設定する必要があります。 Amazon ECS タスクの IAM ロールを使用して、特定のアプリケーションで使用するアクセスポイントを限定できます。IAM ポリシーとアクセスポイントを組み合わせると、アプリケーションによる特定のデータセットへのアクセスを保護できます。タスクIAM ロールの使用方法については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。 # Amazon ECS で Amazon EFS ボリュームを使用する場合のベストプラクティス Amazon ECS で Amazon EFS を使用する場合は、以下のベストプラクティス推奨事項に留意すること。 ## Amazon EFS ボリュームのセキュリティとアクセスコントロール Amazon EFS には、Amazon EFS ファイルシステムに保存されているデータのセキュリティを確保し、それを必要とするアプリケーションからのみアクセスを許可するためのアクセス制御機能があります。保管中と転送中両方の暗号化を有効にすることで、データのセキュリティを確保します。詳細については、*Amazon Elastic File System ユーザーガイド* の「[Amazon EFS でのデータの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)」を参照してください。 データの暗号化に加えて、Amazon EFS を使用してファイルシステムへのアクセスを制限することもできます。EFS にアクセス制御を実装するには 3 つの方法があります。 + **セキュリティグループ** — Amazon EFS マウントターゲットでは、ネットワークトラフィックを許可または拒否するのに使用するセキュリティグループを設定できます。Amazon EFS にアタッチされるセキュリティグループを設定することにより、Amazon ECS インスタンス、もしくは `awsvpc` ネットワークモードを使用している場合は Amazon ECS タスクにアタッチされているセキュリティグループからの NFS トラフィック (ポート 2049) を許可できます。 + **IAM** — IAM を使用して Amazon EFS ファイルシステムへのアクセスを制限できます。Amazon ECS タスクを設定すると、EFS ファイルシステムをマウントするためにファイルシステムにアクセスする IAM ロールが必要になります。詳細は「*Amazon Elastic File System ユーザーガイド*」の「[Using IAM to control file system data access](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html)」を参照してください。 IAM ポリシーでは、Amazon EFS ファイルシステムへの接続時に TLS の使用をクライアントに要求するなど、あらかじめ定義された条件を執行することもできます。詳細は「*Amazon Elastic File System ユーザーガイド*」の「[Amazon EFS condition keys for clients](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html#efs-condition-keys-for-nfs)」を参照してください。 + **Amazon EFS アクセスポイント** — Amazon EFS アクセスポイントとは、アプリケーション固有の Amazon EFS ファイルシステムへのエントリポイントです。アクセスポイントを使用すると、そのアクセスポイントを介したすべてのファイルシステム要求に対してユーザーアイデンティティ (ユーザーの POSIX グループなど) を適用することができます。また、アクセスポイントでは、ファイルシステムに対して別のルートディレクトリを適用することも可能です。これは、クライアントは指定したディレクトリまたはそのサブディレクトリ内のデータにしかアクセスできないためです。 ### IAM ポリシー IAM ポリシーを使用すると、Amazon EFS ファイルシステムへのアクセスを制御できます。 ファイルシステムポリシーを使用してファイルシステムにアクセスするクライアントに対して、以下のアクションを指定できます。 | Action | 説明 | | --- | --- | | `elasticfilesystem:ClientMount` | ファイルシステムへの読み取り専用アクセス許可を付与します。 | | `elasticfilesystem:ClientWrite` | ファイルシステムへの書き込みアクセス許可を付与します。 | | `elasticfilesystem:ClientRootAccess` | ファイルシステムへのアクセス時にルートユーザーの使用を許可します。 | ポリシーで各アクションを指定する必要があります。ポリシーは次の方法で定義できます。 + クライアントベース – ポリシーをタスクロールにアタッチします タスク定義の作成時に **[IAM 認可]** オプションを設定します。 + リソースベース – Amazon EFS ファイルシステムにポリシーをアタッチします リソースベースのポリシーが存在しない場合、ファイルシステム作成時にデフォルトですべてのプリンシパル (\$1) にアクセス許可が付与されます。 **[IAM 認可]** オプションを設定すると、タスクロールに関連付けられたポリシーと Amazon EFS リソースベースのポリシーがマージされます。**[IAM 認可]** オプションは、このポリシーを持つタスクアイデンティティ (タスクロール) を Amazon EFS に渡します。この結果、Amazon EFS リソースベースのポリシーに、ポリシーで指定された IAM ユーザーまたはロールのコンテキストを入れることができます。このオプションを設定しない場合、Amazon EFS リソースレベルのポリシーは IAM ユーザーを「匿名」として識別します。 セキュリティを最大化するため、Amazon EFS ファイルシステムに 3 つのアクセス制御すべてを実装することを検討してください。たとえば、Amazon EFS マウントポイントにアタッチされるセキュリティグループを設定することで、コンテナインスタンスまたは Amazon ECS タスクに関連付けられたセキュリティグループからの進入 NFS トラフィックのみを許可することができます。さらに、Amazon EFS の設定により、許可されたセキュリティグループからの接続であっても、ファイルシステムにアクセスするための IAM ロールを要求することができます。最後に、Amazon EFS アクセスポイントの使用により、POSIX ユーザー権限を執行してアプリケーション向けルートディレクトリを指定することができます。 以下のタスク定義スニペットは、アクセスポイントを使用して Amazon EFS ファイルシステムをマウントする方法を示します。 ``` "volumes": [ { "efsVolumeConfiguration": { "fileSystemId": "fs-1234", "authorizationConfig": { "accessPointId": "fsap-1234", "iam": "ENABLED" }, "transitEncryption": "ENABLED", "rootDirectory": "" }, "name": "my-filesystem" } ] ``` ## Amazon EFS ボリュームパフォーマンス Amazon EFS には、汎用と Max I/O の 2 つのパフォーマンスモードがあり、汎用モードは、コンテンツ管理システムや CI/CD ツールなどのレイテンシーの影響を受けやすいアプリケーションに適しています。これとは対照的に、Max I/O ファイルシステムは、データ分析、メディア処理、機械学習などのワークロードに適しています。これらのワークロードは、数百または数千のコンテナからの並列演算を実行する必要があり、可能な限り高い総スループットと IOPS を必要とします。詳細は「*Amazon Elastic File System ユーザーガイド*」の「[Amazon EFS performance modes](https://docs.aws.amazon.com/efs/latest/ug/performance.html#performancemodes)」を参照してください。 レイテンシーの影響を受けやすいワークロードには、Max I/O パフォーマンスモードによる高い I/O レベルと、汎用パフォーマンスモードによる低レイテンシーの両方が必要です。このタイプのワークロードでは、複数の[General Purpose(汎用)]パフォーマンスモードファイルシステムを作成することをお勧めします。この場合、ワークロードとアプリケーションでサポート可能な限り、すべてのファイルシステム全体にアプリケーションのワークロードを分散することをお勧めします。 ## Amazon EFS ボリュームスループット すべての Amazon EFS ファイルシステムには、*Provisioned Throughput* を使用したファイルシステムのプロビジョニングされたスループットの量、または *Bursting Throughput* を使用したファイルシステムの EFS 標準または One Zone ストレージクラスに保存されたデータの量のいずれかにより決定される、関連するメータリングスループットがあります。詳細は「*Amazon Elastic File System ユーザーガイド*」の「[メータリングスループットについて理解する](https://docs.aws.amazon.com/efs/latest/ug/performance.html#read-write-throughput)」を参照してください。 Amazon EFS ファイルシステムのデフォルトのスループットモードはバーストモードです。バーストモードでは、ファイルシステムが利用できるスループットは、ファイルシステムの拡大に応じてスケールインまたはスケールアウトされます。ファイルベースのワークロードは通常スパイクが発生する、つまり、特定の時間のみ高レベルのスループットを必要とし、残りの時間は低レベルのスループットになることが多いため、Amazon EFS は一定期間高いスループットレベルにバーストできるように設計されています。さらに、多くのワークロードは読み取り負荷が高いため、読み取り操作は他の NFS 操作 (書き込みなど) と 1:3 の比率でメータリングされます。 Amazon EFS ファイルシステムは、すべての Amazon EFS 標準ストレージまたは Amazon EFS One Zone ストレージについて 1 TB ごとに 50 MB/秒という安定したベースラインパフォーマンスを提供します。サイズに関係なく、すべてのファイルシステムは 100 MB/秒までバーストできます。1 TB を超える EFS 標準ストレージまたは EFS One Zone ストレージを持つファイルシステムでは、1 TB ごとに 100 MB/秒までバーストできます。読み取り操作は 1:3 の比率でメータリングされるため、読み取りスループットは 1 TiB ごとに最大 300 MiB/秒を駆動できます。ファイルシステムにデータを追加すると、そのファイルシステムで使用できる最大スループットは、Amazon EFS 標準ストレージクラスのストレージに比例して自動的にスケーリングされます。保存されているデータ量で達成できる以上に高いスループットが必要な場合は、ワークロードが必要とする量に合わせてプロビジョンドスループットを設定できます。 ファイルシステムのスループットは、ファイルシステムに接続されたすべての Amazon EC2 インスタンス間で共有されます。たとえば、100 MB/秒のスループットまでバーストできる 1 TB のファイルシステムでは、1 つの Amazon EC2 インスタンスから 10 MB/秒を駆動できます。詳細については、Amazon Elastic File System ユーザーガイドの「[Amazon EFS のパフォーマンス](https://docs.aws.amazon.com/efs/latest/ug/performance.html)」を参照してください。 ## Amazon EFS ボリュームのコストの最適化 Amazon EFS はストレージのスケーリングを簡素化します。Amazon EFS ファイルシステムは、データを追加すると自動的に拡張されます。特に Amazon EFS の *Bursting Throughput* モードでは、Amazon EFS のスループットは、標準ストレージクラスのファイルシステムのサイズが大きくなるにつれて拡大します。EFS ファイルシステムのプロビジョンドスループットに追加費用を支払わずにスループットを向上させるには、Amazon EFS ファイルシステムを複数のアプリケーション間で共有することができます。Amazon EFS アクセスポイントを使用して、共有 Amazon EFS ファイルシステムにストレージ分離を実装できます。そうすることで、アプリケーション間で同じファイルシステムを共有していても、ユーザーが許可しない限りデータにアクセスできなくなります。 データが大きくなると、Amazon EFS ではアクセス頻度の低いファイルを自動的に下位のストレージクラスに移動できます。Amazon EFS 標準の低頻度アクセス (IA) ストレージクラスは、毎日アクセスされないファイルのストレージコストを削減します。これにより、Amazon EFS が提供する高可用性、高耐久性、伸縮性、および POSIX ファイルシステムへのアクセス性が損なわれることはありません。詳細については、「*Amazon Elastic File System ユーザーガイド*」の「[Amazon EFS ストレージクラス](https://docs.aws.amazon.com/efs/latest/ug/features.html)」を参照してください。 Amazon EFS ライフサイクルポリシーを使用してアクセス頻度の低いファイルを Amazon EFS IA ストレージに移動することで、自動的にコストを節約することを検討してください。詳細は「*Amazon Elastic File System ユーザーガイド*」の「[Amazon EFS のライフサイクル管理](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html)」を参照してください。 Amazon EFS ファイルシステムを作成する場合、Amazon EFS でデータを複数のアベイラビリティーゾーン (標準) に複製するか、あるいは単一のアベイラビリティーゾーン内でデータを冗長的に保存するかを選択できます。Amazon EFS One Zone ストレージクラスは、Amazon EFS 標準ストレージクラスと比較してストレージコストを大幅に削減できます。マルチ AZ の耐障害性を必要としないワークロードには Amazon EFS One Zone ストレージクラスの使用を検討してください。アクセス頻度の低いファイルを Amazon EFS One Zone の低頻度アクセスストレージに移動することで、Amazon EFS One Zone ストレージのコストをさらに削減できます。詳細については、「[Amazon EFS 低頻度アクセス](https://aws.amazon.com/efs/features/infrequent-access/)」を参照してください。 ## Amazon EFS ボリュームデータ保護 Amazon EFS は、標準ストレージクラスを使用するファイルシステムについては、複数のアベイラビリティーゾーン間でデータを冗長的に保存します。Amazon EFS One Zone ストレージクラスを選択した場合、単一のアベイラビリティーゾーン内でデータを冗長的に保存します。さらに、Amazon EFS は、1 年間に 99.999999999% (9 が 11 桁) の耐久性を保証するよう設計されています。 どの環境でもそうですが、データのバックアップを取り、誤って削除されないように保護することがベストプラクティスです。Amazon EFS データのベストプラクティスには、正常に機能し定期的にテストされている AWS Backup 型バックアップの使用が含まれます。Amazon EFS One Zone ストレージクラスを使用するファイルシステムは、意図的に無効にしない限り、ファイルシステムの作成時にデフォルトでファイルを自動的にバックアップするように設定されています。詳細は「*Amazon Elastic File System ユーザーガイド*」の「[EFS ファイルシステムのバックアップ](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)」を参照してください。 # タスク定義内での Amazon EFS ファイルシステムの指定 コンテナに Amazon EFS ファイルシステムボリュームを使用するには、タスク定義でボリュームとマウントポイントの設定を指定する必要があります。次のスニペットの JSON によるタスク定義では、コンテナの `volumes` と `mountPoints` オブジェクトの構文を示しています。 ``` { "containerDefinitions": [ { "name": "container-using-efs", "image": "public.ecr.aws/amazonlinux/amazonlinux:latest", "entryPoint": [ "sh", "-c" ], "command": [ "ls -la /mount/efs" ], "mountPoints": [ { "sourceVolume": "myEfsVolume", "containerPath": "/mount/efs", "readOnly": true } ] } ], "volumes": [ { "name": "myEfsVolume", "efsVolumeConfiguration": { "fileSystemId": "fs-1234", "rootDirectory": "/path/to/my/data", "transitEncryption": "ENABLED", "transitEncryptionPort": integer, "authorizationConfig": { "accessPointId": "fsap-1234", "iam": "ENABLED" } } } ] } ``` `efsVolumeConfiguration` タイプ: オブジェクト 必須: いいえ このパラメータは、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` タイプ: オブジェクト 必須: いいえ 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)」を参照してください。 # コンソールを使用した Amazon ECS での Amazon EFS ファイルシステムの設定 Amazon ECS で Amazon Elastic File System (Amazon EFS) ファイルシステムを使用する方法について説明します。 ## ステップ 1: Amazon ECS クラスターを作成する 次の手順に従って Amazon ECS クラスターを作成します。 **新しいクラスターを作成するには (Amazon ECS コンソール)** 開始する前に、適切な IAM アクセス許可を割り当ててください。詳細については、「[Amazon ECS クラスターの例](security_iam_id-based-policy-examples.md#IAM_cluster_policies)」を参照してください。 1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。 1. ナビゲーションバーから、使用するリージョンを選択します。 1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。 1. **[Clusters]** (クラスター) ページで、**[Create Cluster]** (クラスターの作成) を選択します。 1. **[クラスター設定]** の **[クラスター名]** に、名前として「`EFS-tutorial`」を入力します。 1. (オプション) タスクとサービスが起動する VPC とサブネットを変更するには、**[Networking]** (ネットワーク) で、次のいずれかのオペレーションを実行します。 + サブネットを削除するには、**[Subnets]** (サブネット) で、削除するサブネットごとに **[X]** を選択します。 + **[デフォルト]** VPC 以外の VPC に変更するには、**[VPC]** で既存の **[VPC]** を選択し、**[サブネット]** で各サブネットを選択します。 1. クラスターに Amazon EC2 インスタンスを追加するには、**[インフラストラクチャー]** を展開して **[Amazon EC2 インスタンス]** を選択します。次に、キャパシティープロバイダーとして機能する Auto Scaling グループを設定します。 1. Auto Scaling グループを作成するには、**Auto Scaling group(ASG)** (Auto Scaling グループ) から、**[Create new group]** (新しいグループの作成) を選択し、グループに関する以下の詳細情報を入力します。 + **[オペレーティングシステム/アーキテクチャ]** で、[Amazon Linux 2] を選択します。 + [**EC2 instance type**] で、[`t2.micro`] を選択します。 **[SSH key pair]** (SSH キーペア) を使用する場合、インスタンスに接続する際に ID を証明するペアを選択してください。 + **[キャパシティ]** に、「`1`」と入力します。 1. **[作成]** を選択します。 ## ステップ 2: Amazon EC2 インスタンスと Amazon EFS ファイルシステムのセキュリティグループを作成する このステップでは、ポート 80 でのインバウンドネットワークトラフィックを許可する Amazon EC2 インスタンスと、コンテナインスタンスからのインバウンドアクセスを許可する Amazon EFS ファイルシステムのセキュリティグループを作成します。 以下のオプションを使用して Amazon EC2 インスタンスのセキュリティグループを作成します。 + **[セキュリティグループ名]** — セキュリティグループの名前を入力します。 + **[VPC]** - クラスター用に前に特定した VPC を選択します。 + **インバウンドルール** + **タイプ** - **HTTP** + **ソース** - **0.0.0.0/0** 以下のオプションを使用して Amazon EFS ファイルシステムのセキュリティグループを作成します。 + **[セキュリティグループ名]** — セキュリティグループの名前を入力します。例えば、`EFS-access-for-sg-dc025fa2`。 + **[VPC]** - クラスター用に前に特定した VPC を選択します。 + **インバウンドルール** + **[タイプ]** – **[NFS]** + **ソース** - **[カスタム]**で、インスタンス用に作成したセキュリティグループの ID を使用します。 セキュリティグループの作成方法について、詳細は「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 インスタンス用のセキュリティグループの作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-security-group.html)」を参照してください。 ## ステップ 3:Amazon EFS ファイルシステムを作成する このステップでは、Amazon EFS ファイルシステムを作成します。 **Amazon ECS タスク用の Amazon EFS ファイルシステムを作成するには** 1. Amazon Elastic File System コンソール ([https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/)) を開きます。 1. [**Create file system**] を選択します。 1. ファイルシステムの名前を入力し、コンテナインスタンスをホストする VPC を選択します。デフォルトでは、指定した VPC の各サブネットに、その VPC のデフォルトセキュリティグループを使用するマウントターゲットが割り当てられます。次に **[カスタマイズ]** を選択します。 **注記** このチュートリアルでは、Amazon EFS ファイルシステム、Amazon ECS クラスター、コンテナインスタンス、およびタスクが同じ VPC 内に存在することを前提としています。別の VPC からファイルシステムをマウントする方法について、詳細は「*Amazon EFS ユーザーガイド*」の「[Walkthrough: Mount a file system from a different VPC](https://docs.aws.amazon.com/efs/latest/ug/efs-different-vpc.html)」を参照してください。 1. **[ファイルシステムの設定]** ページでオプション設定を行い、**[パフォーマンス設定]** でファイルシステムの**[バースト]** スループットモードを選択します。設定が完了したら、**[次へ]** を選択します。 1. (オプション) ファイルシステムのタグを追加します。例えば、ファイルシステムの一意の名前を指定するには、[**名前**] キーの横にある [**値**] 列にその名前を入力します。 1. (オプション) ライフサイクル管理を有効にして、アクセス頻度の低いストレージのコストを節約します。詳細については、[Amazon Elastic File System User Guide](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) の「*EFS のライフサイクル管理*」を参照してください。 1. (オプション) 暗号化を有効にします。保管時の Amazon EFS ファイルシステムの暗号化を有効にするチェックボックスを選択します。 1. **[ネットワークアクセス]**ページの **[マウントターゲット]** で、各アベイラビリティーゾーンの既存のセキュリティグループ設定を、[ステップ 2: Amazon EC2 インスタンスと Amazon EFS ファイルシステムのセキュリティグループを作成する](#efs-security-group) でファイルシステム用に作成したセキュリティグループに置き換え、**[次へ]** を選択します。 1. このチュートリアルでは**[ファイルシステムポリシー]**を設定する必要はないので、**[次へ]** を選択すればセクションをスキップできます。 1. ファイルシステムのオプションを確認し、**[作成]** を選択してプロセスを完了します。 1. **[ファイルシステム]** 画面から、**ファイルシステム ID** を書き留めます。次のステップで、Amazon ECS タスク定義で、この値をリファレンスします。 ## ステップ 4: Amazon EFS ファイルシステムにコンテンツを追加する このステップでは、Amazon EFS ファイルシステムを Amazon EC2 インスタンスにマウントし、コンテンツを追加します。これは、このチュートリアルでデータの永続的な性質を示すことを目的としたテストです。この機能を使用する場合は、通常、Amazon EFS ファイルシステムにデータを書き込むためのアプリケーションや別の方法があります。 **Amazon EC2 インスタンスを作成し、Amazon EFS ファイルシステムをマウントします。** 1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。 1. [**インスタンスの作成**] を選択してください。 1. **[アプリケーションおよび OS イメージ (Amazon マシンイメージ)]** で、**[Amazon Linux 2 AMI (HVM)]** を選択します。 1. **[インスタンス タイプ]** で、デフォルトのインスタンスタイプ `t2.micro` をそのまま使用します。 1. **[キーペア (ログイン)]** で、インスタンスへの SSH アクセス用のキーペアを選択します。 1. **[ネットワーク設定]** で、Amazon EFS ファイルシステムおよび Amazon ECS クラスター用に指定した VPC を選択します。サブネットと、[ステップ 2: Amazon EC2 インスタンスと Amazon EFS ファイルシステムのセキュリティグループを作成する](#efs-security-group) で作成したインスタンスセキュリティグループを選択します。インスタンスのセキュリティグループを設定します。**[パブリック IP の自動割り当て]** が有効になっていることを確認します。 1. **[ストレージの設定]** で、ファイルシステムの **[編集]** ボタンを選択し、**[EFS]** を選択します。[ステップ 3:Amazon EFS ファイルシステムを作成する](#efs-create-filesystem) で作成したファイルシステムを選択します。必要に応じて、マウントポイントを変更したり、デフォルト値をそのまま使用したりできます。 **重要** インスタンスにファイルシステムを追加する前に、サブネットを選択する必要があります。 1. **[セキュリティグループを自動的に作成してアタッチする]** をオフにします。もう 1 つのチェックボックスはオンのままにしておきます。**[Add shared file system]** (共有ファイルシステムの追加) を選択します。 1. [**Advanced Details**] で、Amazon EFS ファイルシステムのマウント ステップを使用してユーザー データスクリプトが自動的に入力されていることを確認します。 1. **[概要]** で、**[インスタンス数]** が **1** であることを確認します。**[インスタンスを起動]** を選択してください。 1. **[インスタンスを起動]** ページで、**[すべてのインスタンスを表示]** を選択して、インスタンスのステータスを表示します。最初、**[インスタンスの状態]** ステータスは `PENDING` です。状態が `RUNNING` に変わり、インスタンスがすべてのステータスチェックに合格すると、インスタンスは使用可能になります。 次に、Amazon EC2 インスタンスに接続し、コンテンツを Amazon EFS ファイルシステムに追加します。 **Amazon EC2 インスタンスに接続し、コンテンツを Amazon EFS ファイルシステムに追加するには** 1. 作成した Amazon EC2 インスタンスに SSH 接続します。詳細については、「Amazon EC2 ユーザーガイド」の「[SSH を使用した Linux インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)」を参照してください。 1. ターミナルウィンドウから、**df -T** コマンドを実行して、Amazon EFS ファイルシステムがマウントされていることを確認します。次の出力では、Amazon EFS ファイルシステムのマウントを強調表示しています。 ``` $ df -T Filesystem Type 1K-blocks Used Available Use% Mounted on devtmpfs devtmpfs 485468 0 485468 0% /dev tmpfs tmpfs 503480 0 503480 0% /dev/shm tmpfs tmpfs 503480 424 503056 1% /run tmpfs tmpfs 503480 0 503480 0% /sys/fs/cgroup /dev/xvda1 xfs 8376300 1310952 7065348 16% / 127.0.0.1:/ nfs4 9007199254739968 0 9007199254739968 0% /mnt/efs/fs1 tmpfs tmpfs 100700 0 100700 0% /run/user/1000 ``` 1. Amazon EFS ファイルシステムのマウント先のディレクトリに移動します。上の例では `/mnt/efs/fs1` に移動します。 1. 以下の内容で `index.html` という名前のファイルを作成します。 ```You are using an Amazon EFS file system for persistent container storage.
``` ## ステップ 5: タスク定義を作成する 次のタスク定義は、`efs-html` というデータボリュームを作成します。`nginx` コンテナは、ホストデータボリュームを NGINX ルート `/usr/share/nginx/html` にマウントします。 **Amazon ECS コンソールを使用して新しいタスク定義を作成するには** 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 テキストをコピーして貼り付けます。`fileSystemId` は、実際の Amazon EFS ファイルシステムの ID に置き換えます。 ``` { "containerDefinitions": [ { "memory": 128, "portMappings": [ { "hostPort": 80, "containerPort": 80, "protocol": "tcp" } ], "essential": true, "mountPoints": [ { "containerPath": "/usr/share/nginx/html", "sourceVolume": "efs-html" } ], "name": "nginx", "image": "public.ecr.aws/docker/library/nginx:latest" } ], "volumes": [ { "name": "efs-html", "efsVolumeConfiguration": { "fileSystemId": "fs-1324abcd", "transitEncryption": "ENABLED" } } ], "family": "efs-tutorial", "executionRoleArn":"arn:aws:iam::111122223333:role/ecsTaskExecutionRole" } ``` **注記** Amazon ECS タスク実行 IAM ロールでは、Amazon EFS ファイルシステムをマウントするにあたり、特定の Amazon EFS 関連のアクセス許可は必要ありません。Amazon EFS のリソースベースのポリシーが存在しない場合、デフォルトで、ファイルシステム作成時にすべてのプリンシパル (\$1) にアクセス許可が付与されます。 Amazon ECS タスクロールは、Amazon ECS タスク定義で「EFS IAM 認可」が有効になっている場合にのみ必要です。有効な場合、Amazon EFS のリソースベースのポリシーで タスクロール ID に対して Amazon EFS ファイルシステムへのアクセスを許可する必要があり、匿名アクセスは無効にする必要があります。 1. **[作成]** を選択します。 ## ステップ 6: タスクを実行して結果を表示する さて、Amazon EFS ファイルシステムが作成され、NGINX コンテナのウェブコンテンツが用意されたので、作成したタスク定義を使用してタスクを実行できます。NGINX ウェブサーバーは、シンプルな HTML ページを提供します。Amazon EFS ファイルシステムのコンテンツを更新した場合、それらの変更は、そのファイルシステムがマウントされているすべてのコンテナにも伝達されます。 タスクは、クラスターのために定義したサブネットで実行されます。 **コンソールを使用してタスクを実行し結果を表示するには** 1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。 1. **[Clusters]** (クラスター) ページで、スタンドアロンタスクを実行するクラスターを選択します。 サービスを起動するリソースを決定します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. (オプション) スケジュールされたタスクをクラスターのインフラストラクチャ全体に分散する方法を選択します。**[Compute configuration]** (コンピュート設定) を展開し、以下の操作を実行します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. **Application type(アプリケーションの種類)**で、**Task(タスク)**を選択します。 1. **[タスク定義]** で、先に作成した `efs-tutorial` タスク定義を選択します。 1. **[必要なタスク]** に、「`1`」と入力します。 1. **[作成]** を選択します。 1. **[クラスター]** ページで、**[インフラストラクチャ]** を選択します。 1. **[コンテナインスタンス]** で、接続先となるコンテナインスタンスを選択します。 1. **[コンテナインスタンス]** ページの インスタンスの **[ネットワーキング]** で、インスタンスの **[パブリック IP]** を書き留めます。 1. ブラウザを開き、パブリック IP アドレスを入力します。次のメッセージが表示されます。 ``` It works! You are using an Amazon EFS file system for persistent container storage. ``` **注記** メッセージが表示されない場合は、コンテナインスタンスのセキュリティグループがポート 80 でインバウンドネットワークトラフィックを許可しており、ファイルシステムのセキュリティグループがコンテナインスタンスからのインバウンドアクセスを許可していることを確認してください。 # Amazon ECS での FSx for Windows File Server ボリュームの使用 FSx for Windows File Server は、Windows ファイルシステムによってバックアップされるフルマネージド型 Windows ファイルサーバーを提供します。ECS と共に FSx for Windows File Server を使用する場合、永続的、分散、共有、静的ファイルストレージで Windows タスクをプロビジョニングできます。詳細については、[FSx for Windows File Serverとは？](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)を参照してください。 **注記** FSx for Windows File Server ECS のタスクボリュームは、Amazon ECS に最適化された Windows Server 2016 Full AMI を使用する EC2 インスタンスではサポートされていません。 Fargate 設定上の Windows コンテナで、FSx for Windows File Server ボリュームを使用することはできません。代わりに、[起動時にコンテナをマウントするように変更できます](https://aws.amazon.com/blogs/containers/use-smb-storage-with-windows-containers-on-aws-fargate/)。 FSx for Windows File Server を使用すると、共有外部ストレージ、リージョン別の高可用ストレージ、または高スループットストレージへのアクセスを必要とする Windows ワークロードのデプロイが行えます。Amazon ECS Windows インスタンスで実行されている Amazon ECS コンテナには、1 つ以上の FSx for Windows File Server ファイルシステムボリュームをマウントできます。1 つの Amazon ECS タスク内の複数の Amazon ECS コンテナ間で、FSx for Windows File Server ファイルシステムボリュームを共有できます。 ECS で FSx for Windows File Server を使用できるようにするには、次のタスク定義 JSON スニペット例に示すように、タスク定義に FSx for Windows File Server ファイルシステム ID と関連情報を含める必要があります。この例を、次のタスク定義 JSON スニペットで示します。タスク定義を作成して実行する際には、以下を用意しておきます。 + 有効なドメインに参加している ECS Windows EC2 インスタンス。これは [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) や、オンプレミスまたは Amazon EC2 上でセルフホストされたアクティブディレクトリのいずれかで、ホストされます。 + Active Directory ドメインの接続と FSx for Windows File Server ファイルシステムのアタッチに使用される、認証情報を含む AWS Secrets Manager シークレットまたは Systems Manager パラメータ。認証情報値は、アクティブディレクトリの作成時に入力した名前とパスワードの認証情報です。 関連チュートリアルについては、「[Amazon ECS 用の FSx for Windows File Server ファイルシステムを設定する方法について説明します。](tutorial-wfsx-volumes.md)」を参照してください。 ## 考慮事項 FSx for Windows File Server ボリュームを使用する際は、以下の点を考慮します。 + Windows Amazon EC2 インスタンスでは、FSx for Windows File Server ボリュームが Amazon ECS でネイティブにサポートされるため、Amazon ECS がタスク定義設定を通じてマウントを自動的に管理します。 Linux Amazon EC2 インスタンスでは、Amazon ECS がタスク定義を通じて FSx for Windows File Server ボリュームを自動的にマウントすることができません。ただし、ホストレベルで Linux EC2 インスタンスに FSx for Windows File Server ファイル共有を手動でマウントし、そのパスを Amazon ECS コンテナにバインドマウントすることは可能です。詳細については、「[Linux からの Amazon FSx ファイル共有のマウント](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/map-shares-linux.html)」を参照してください。 **重要** これは、セルフマネージド型の設定です。Linux での FSx for Windows File Server ファイル共有のマウントとメンテナンスに関するガイダンスについては、[FSx for Windows File Server ドキュメント](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/)を参照してください。 **重要** Linux EC2 インスタンスに手動でマウントされた FSx for Windows File Server 共有を使用する場合は、Amazon ECS と FSx for Windows File Server がそれぞれ単独で動作するため、Amazon ECS は Amazon FSx マウントを監視せず、FSx for Windows File Server は Amazon ECS タスクの配置やライフサイクルイベントを追跡しません。Amazon ECS コンテナインスタンスと Amazon FSx ファイルシステム間におけるネットワーク到達可能性の確保、マウントヘルスチェックの実装、およびフェイルオーバーイベントを許容するための再接続ロジックの処理は、お客様の責任になります。 + Amazon ECS を使用した FSx for Windows File Server は AWS Fargate をサポートしません。 + Amazon ECS において、FSx for Windows File Server は Amazon ECS マネージドインスタンスではサポートされていません。 + `awsvpc` ネットワークモードで Amazon ECS を使用した FSx for Windows File Server はコンテナエージェントのバージョン `1.54.0` 以降が必要です。 + Amazon ECS タスクに使用できるドライブ文字の最大数は 23 です。FSx for Windows File Server ボリュームを持つ各タスクには、ドライブ文字が割り当てられます。 + デフォルトで、タスクのリソースのクリーンアップ時間は、タスク終了後の 3 時間後に設定されます。タスクによって作成されたファイルマッピングは、使用するタスクが存在しなくなっても 3 時間は保持されます。デフォルトのクリーンアップ時間は、Amazon ECS 環境変数を使用して、設定することができます。`ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`詳細については、「[Amazon ECS コンテナエージェントの設定](ecs-agent-config.md)」を参照してください。 + 通常、タスクは FSx for Windows File Server ファイルシステムと同じ VPC でのみ実行されます。ただし、Amazon ECS クラスター VPC と FSx for Windows File Server ファイルシステムの間に VPC ピアリングを介してネットワーク接続が確立されている場合は、クロス VPC の実行がサポートされます。 + VPC セキュリティグループを設定することにより、ネットワークレベルで FSx for Windows File Server ファイルシステムへのアクセスを制御します。Active Directory セキュリティグループが正しく設定された Active Directory ドメインに参加している EC2 インスタンスでホストされているタスクのみが、FSx for Windows File Server ファイル共有にアクセスできます。セキュリティグループの設定が正確でない場合、Amazon ECS はタスクの起動に失敗し、次のエラーメッセージを表示します:「`unable to mount file system fs-id`」。 + FSx for Windows File Server は、AWS Identity and Access Management(IAM) を使用して、IAM ユーザーおよびグループが Windows ファイルサーバーリソースに対して特定の FSx で実行可能なアクションを制御します。クライアント認可を使用すると、ユーザーは、特定の FSx for Windows File Server ファイルシステムへのアクセスを許可または拒否する IAM ロールを定義できます。オプションとして、読み取り専用アクセスを必要とし、またクライアントからのファイルシステムへの root アクセスを許可または禁止することができます。詳細については、Amazon FSx Windows ユーザーガイドの「[Security](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/security.html)」を参照してください。 # Amazon ECS での FSx for Windows File Server の使用に関するベストプラクティス Amazon ECS で FSx for Windows File Server を使用する場合は以下のベストプラクティスに従うことをお勧めします。 ## FSx for Windows File Server のセキュリティとアクセス制御 FSx for Windows File Server には、FSx for Windows File Server ファイルシステムに保存されるデータのセキュリティを保証し、それを必要とするアプリケーションからのみアクセス可能とするために使用できる以下のアクセス制御機能があります。 ### FSx for Windows File Server ボリュームのデータ暗号化 FSx for Windows File Server は、2 つのファイルシステム向け暗号化形式をサポートしています。つまり、保管中および転送中のデータの暗号化です。転送中のデータの暗号化は、SMB プロトコル 3.0 以降をサポートするコンテナインスタンスにマップされたファイル共有でサポートされます。保管中のデータの暗号化は、Amazon FSx ファイルシステムの作成時に自動的に有効になります。Amazon FSx は、アプリケーションを変更することなくファイルシステムにアクセスする際に、SMB 暗号化を使用して転送中のデータを自動的に暗号化します。詳細は「*Amazon FSx for Windows File Server ユーザーガイド*」の「[Amazon FSx でのデータ暗号化](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption.html)」を参照してください。 ### フォルダレベルのアクセス制御に Windows ACL を使用する Windows Amazon EC2 インスタンスは、Active Directory 認証情報を使用して Amazon FSx ファイル共有にアクセスします。きめ細かいファイルレベルおよびフォルダレベルのアクセス制御には、標準の Windows アクセス制御リスト (ACL) を使用します。複数の認証情報を作成でき、それぞれの認証情報は、特定のタスクに対応する共有内の特定のフォルダ向けとなります。 以下の例では、タスクは Secrets Manager に保存されている認証情報を使用してフォルダ `App01` にアクセスできます。Amazon リソースネーム (ARN) は `1234` です。 ``` "rootDirectory": "\\path\\to\\my\\data\App01", "credentialsParameter": "arn-1234", "domain": "corp.fullyqualified.com", ``` 別の例では、タスクは Secrets Manager に保存されている認証情報を使用してフォルダ `App02` にアクセスできます。その ARN は `6789` です。 ``` "rootDirectory": "\\path\\to\\my\\data\App02", "credentialsParameter": "arn-6789", "domain": "corp.fullyqualified.com", ``` # Amazon ECS タスク定義で FSx for Windows File Server ファイルシステムを指定する コンテナに FSx for Windows File Server ファイルシステムボリュームを使用するには、タスク定義でボリュームとマウントポイントの設定を指定します。次のスニペットの JSON によるタスク定義では、コンテナの `volumes` と `mountPoints` オブジェクトの構文を示しています。 ``` { "containerDefinitions": [ { "entryPoint": [ "powershell", "-Command" ], "portMappings": [], "command": ["New-Item -Path C:\\fsx-windows-dir\\index.html -ItemType file -Value '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* をクラスターの名前に置き換えます。 ```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)」を参照してください。