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` 유형: 객체 배열 필수 여부: 아니요 컨테이너에서 데이터 볼륨의 탑재 지점입니다. 이 파라미터는 create-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` 유형: Boolean 필수: 예. 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)의 단계를 따르세요. 특정 AWS 리전에서 생성 후 태스크에 연결된 모든 새 볼륨이 계정에 구성된 KMS 키를 사용하여 암호화되도록 기본적으로 Amazon EBS 암호화를 구성할 수 있습니다. 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 참조*의 [ManagedStorageConfiguration](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 볼륨을 암호화하려면 볼륨 구성에 사용하는 IAM 역할이 키를 사용하는 데 필요한 권한을 보유하도록 KMS 키 정책을 구성해야 합니다. 키 정책에는 `kms:CreateGrant` 및 `kms:GenerateDataKey*` 권한이 포함되어야 합니다. `kms:ReEncryptTo` 및 `kms:ReEncryptFrom` 권한은 스냅샷을 사용하여 생성된 볼륨을 암호화하는 데 필요합니다. 연결을 위해 새로운 빈 볼륨만 구성하고 암호화하려는 경우 `kms:ReEncryptTo` 및 `kms:ReEncryptFrom` 권한을 제외할 수 있습니다. 다음 JSON 코드 조각은 KMS 키 정책에 연결할 수 있는 키 정책 명령을 보여줍니다. 이한 명령을 사용하면 EBS 볼륨을 암호화하려는 경우 Amazon ECS에서 키를 사용할 수 있는 액세스 권한이 제공됩니다. 정책 명령 예제를 사용하려면 `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 개발자 안내서*의 [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) 및 [AWS KMS permissions](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 파일을 전달할 수 있습니다. + `[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)` -특정 컨테이너 인스턴스에서 독립 실행형 ECS 작업을 실행합니다. 이 명령은 Fargate 태스크에 적용할 수 없습니다. + `[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)` - 새 ECS 서비스를 생성합니다. + `[update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)` - 기존 서비스를 업데이트합니다. **참고** 태스크의 컨테이너에서 탑재된 Amazon EBS 볼륨에 쓰려면 컨테이너에 적절한 파일 시스템 권한이 있어야 합니다. 컨테이너 정의에 루트가 아닌 사용자를 지정하면 Amazon ECS는 지정된 사용자가 볼륨을 읽고 쓸 수 있도록 허용하는 그룹 기반 권한으로 볼륨을 자동으로 구성합니다. 사용자가 지정되지 않은 경우 컨테이너는 루트로 실행되고 볼륨에 대한 전체 액세스 권한을 갖습니다. 또한 AWS Management Console을 사용하여 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 파일에 저장하고 `--cli-input-json file://filename` 파라미터를 사용하여 파일을 AWS CLI 명령의 파라미터로 전달하여 이 예제를 사용할 수 있습니다. `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` 파라미터를 사용하여 지정된 스냅샷에서 200MiB/s의 속도로 소싱됩니다. 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`로 설정된 작업 정의 또는 `configuredAtLaunch` 파라미터가 없는 작업 정의의 ARN을 제공해야 합니다. 또한 빈 `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 볼륨에 태그를 지정할 수 있습니다. 객체를 사용하여 볼륨이 독립 실행형 작업에 연결되었는지 또는 서비스 내 작업에 연결되었는지에 따라 자체 태그를 제공하고 작업 정의 또는 서비스에서 태그 전파를 설정할 수 있습니다. 볼륨에 연결할 수 있는 최대 태그 수는 50개입니다. **중요** Amazon ECS는 Amazon EBS 볼륨에 예약된 태그 `AmazonECSCreated` 및 `AmazonECSManaged`를 자동으로 연결합니다. 즉, 볼륨에 최대 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 작업에 2 이상의 vCPU를 요청하는 경우 작업에 연결된 Amazon EBS 볼륨에 다음과 같은 기준 성능 제한이 적용됩니다. 일시적으로 다음 제한보다 높은 EBS 성능을 얻을 수 있습니다. 그러나 이러한 제한에 따라 워크로드를 계획하는 것이 좋습니다. | 요청된 CPU 단위(vCPU 단위) | 기준 Amazon EBS IOPS(16KiB I/O) | 기준 Amazon EBS 처리량(MBPS 단위, 128KiB 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 | **참고** Amazon EBS 볼륨을 Fargate 태스크에 연결하도록 구성하면 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 Management Console을 사용하여 Amazon ECS 작업에 대한 Amazon EBS 볼륨 연결 상태를 볼 수 있습니다. 작업이 시작되고 연결이 실패하는 경우 문제 해결에 사용할 수 있는 상태 이유도 표시됩니다. 생성된 볼륨이 삭제되고 작업이 중지됩니다. 상태 이유에 대한 자세한 내용은 [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` 형식을 사용하여 컨테이너 정의에 `user` 파라미터가 올바르게 지정되었는지 확인합니다(예: `1001:1001`). + 볼륨이 탑재된 후 컨테이너 이미지가 사용자 권한을 재정의하지 않는지 확인합니다. + 컨테이너 로그를 검사하거나 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 Management Console에서 상태 이유의 형태로 발생할 수 있는 문제를 해결하기 위해 다음 참조를 사용합니다. 콘솔에서 이러한 상태 이유를 찾는 방법에 대한 자세한 내용은 [볼륨 연결 상태 확인](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 볼륨을 설정하지 못했습니다. Encountered 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 EBS를 위한 Amazon EventBridge 이벤트](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-cloud-watch-events.html)를 참조하세요. 작업에 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 ECS에서 Amazon EFS 파일 시스템을 사용하여 컨테이너 인스턴스 집합 간에 파일 시스템 데이터를 내보낼 수 있습니다. 이렇게 하면 태스크는 해당 태스크가 차지한 인스턴스와 상관없이 동일한 영구 스토리지에 액세스할 수 있습니다. 태스크 정의는 컨테이너 인스턴스에서 볼륨 마운트를 참조하여 파일 시스템을 사용해야 합니다. 자습서는 [콘솔을 사용하여 Amazon ECS에 대한 Amazon EFS 파일 시스템 구성](tutorial-efs-volumes.md)을 참조하세요. ## 고려 사항 Amazon EFS 볼륨을 사용할 때는 다음 사항을 고려해야 합니다. + EC2에서 실행되는 태스크의 경우 Amazon EFS 파일 시스템 지원이 컨테이너 에이전트 버전이 1.35.0인 Amazon ECS 최적화 AMI 버전 `20191212`의 공개 미리 보기로 추가되었습니다. 그러나 Amazon EFS 파일 시스템 지원은 Amazon EFS 액세스 포인트 및 IAM 권한 부여 기능이 포함된 컨테이너 에이전트 버전이 1.38.0인 Amazon ECS 최적화 AMI 버전 `20200319`의 정식 출시를 시작했습니다. 이러한 기능을 사용하려면 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에서 호스팅되는 태스크의 경우 Amazon EFS 파일 시스템이 플랫폼 버전 1.4.0 이상(Linux)에서 지원됩니다. 자세한 내용은 [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 ECS 관리형 인스턴스에서 실행되는 태스크에 대해 Amazon EFS 볼륨 사용이 지원됩니다. + 에이전트 구성 파일의 `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 그룹을 포함한 사용자 ID를 적용할 수 있습니다. 또한 파일 시스템에 대해 다른 루트 디렉터리를 적용할 수 있습니다. 이는 클라이언트가 지정된 디렉터리 또는 하위 디렉터리의 데이터에만 액세스할 수 있도록 합니다. **참고** 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에서 액세스 제어를 구현하는 세 가지 방법이 있습니다. + **보안 그룹** - Amazon EFS 탑재 대상을 사용하면 네트워크 트래픽을 허용 및 거부하는 데 사용되는 보안 그룹을 구성할 수 있습니다. Amazon EFS에 연결된 보안 그룹이 Amazon ECS 인스턴스에 연결된 보안 그룹의 NFS 트래픽(포트 2049)을 허용하도록 구성하거나 `awsvpc` 네트워크 모드를 사용하는 경우 Amazon ECS 작업을 허용하도록 구성할 수 있습니다. + **IAM** - IAM을 사용하여 Amazon EFS 파일 시스템에 대한 액세스를 제한할 수 있습니다. 이 기능이 구성된 경우 Amazon ECS 작업에는 EFS 파일 시스템을 탑재하도록 파일 시스템 액세스를 위한 IAM 역할이 필요합니다. 자세한 내용은 *Amazon Elastic 파일 시스템 사용 설명서*의 [IAM을 사용하여 파일 시스템 데이터 액세스 제어](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html)를 참조하세요. IAM 정책은 Amazon EFS 파일 시스템에 연결할 때 클라이언트가 TLS를 사용하도록 요구하는 등의 사전 정의된 조건을 적용할 수도 있습니다. 자세한 내용은 *Amazon Elastic File System 사용 설명서*의 [클라이언트에 대한 Amazon EFS 조건 키](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 파일 시스템에 대한 액세스를 제어할 수 있습니다. 파일 시스템 정책을 사용하여 클라이언트의 파일 시스템 액세스에 대해 다음 작업을 지정할 수 있습니다. | 작업 | 설명 | | --- | --- | | `elasticfilesystem:ClientMount` | 파일 시스템에 대한 읽기 전용 액세스를 제공합니다. | | `elasticfilesystem:ClientWrite` | 파일 시스템에 대한 쓰기 권한을 제공합니다. | | `elasticfilesystem:ClientRootAccess` | 파일 시스템에 액세스할 때 루트 사용자를 사용할 수 있는 기능을 제공합니다. | 정책의 각 작업을 지정해야 합니다. 정책은 다음과 같은 방법으로 정의할 수 있습니다. + 클라이언트 기반 - 정책을 작업 역할에 연결합니다. 태스크 정의를 생성할 때 **IAM 권한 부여** 옵션을 설정합니다. + 리소스 기반 - Amazon EFS 파일 시스템에 정책을 연결합니다. 리소스 기반 정책이 없는 경우 파일 시스템 생성 시 기본적으로 모든 보안 주체(\$1)에게 액세스 권한이 부여됩니다. **IAM 권한 부여** 옵션을 설정할 때 작업 역할과 관련된 정책과 Amazon EFS 리소스 기반 정책을 병합합니다. **IAM 권한 부여** 옵션은 정책과 함께 작업 ID(작업 역할)를 Amazon EFS로 전달합니다. 이를 통해 Amazon EFS 리소스 기반 정책이 정책에 지정된 IAM 사용자 또는 역할에 대한 컨텍스트를 사용할 수 있습니다. 이 옵션을 설정하지 않으면 Amazon EFS 리소스 수준 정책이 IAM 사용자를 "익명"으로 식별합니다. 보안을 극대화하려면 Amazon EFS 파일 시스템에 세 가지 액세스 제어를 모두 구현하는 방법을 고려합니다. 예를 들어, Amazon EFS 탑재 지점에 연결된 보안 그룹이 컨테이너 인스턴스 또는 Amazon ECS 작업과 연결된 보안 그룹의 수신 NFS 트래픽만 허용하도록 구성할 수 있습니다. 또한 허용된 보안 그룹에서 시작된 연결이더라도 파일 시스템에 액세스하는 데 IAM 역할을 요구하도록 Amazon EFS를 구성할 수 있습니다. 마지막으로 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는 범용 및 최대 I/O라는 두 가지 성능 모드를 제공합니다. 범용은 콘텐츠 관리 시스템 및 CI/CD 도구와 같이 지연 시간에 민감한 애플리케이션에 적합합니다. 반면 최대 I/O 파일 시스템은 데이터 분석, 미디어 처리, 기계 학습과 같은 워크로드에 적합합니다. 이러한 워크로드는 수백 또는 수천 개의 컨테이너에서 병렬 작업을 수행해야 하며 가능한 가장 높은 총 처리량과 IOPS를 요구합니다. 자세한 내용은 *Amazon Elastic File System 사용 설명서*의 [Amazon EFS performance modes](https://docs.aws.amazon.com/efs/latest/ug/performance.html#performancemodes)를 참조하세요. 지연 시간에 민감한 일부 워크로드는 최대 I/O 성능 모드에서 제공하는 더 높은 I/O 수준과 범용 성능 모드에서 제공하는 더 낮은 지연 시간이 필요합니다. 이러한 유형의 워크로드에는 여러 범용 성능 모드 파일 시스템을 생성하는 것이 좋습니다. 이 경우 워크로드 및 애플리케이션이 지원할 수 있는 한, 모든 파일 시스템에 애플리케이션 워크로드를 분산시키는 것이 좋습니다. ## Amazon EFS 볼륨 처리량 모든 Amazon EFS 파일 시스템에는 측정된 처리량이 연결되어 있습니다. 이 처리량은 프로비저닝된 처리량을 사용하는 파일 시스템의 프로비저닝된 처리량의 크기 또는 버스팅 처리량을 사용하는 파일 시스템의 EFS Standard 또는 One Zone 스토리지 클래스에 저장된 데이터의 크기에 따라 결정됩니다.**** 자세한 내용은 *Amazon Elastic File System 사용 설명서*의 [Understanding metered throughput](https://docs.aws.amazon.com/efs/latest/ug/performance.html#read-write-throughput)을 참조하세요. Amazon EFS 파일 시스템의 기본 처리량 모드는 버스팅 모드입니다. 버스팅 모드를 사용하면 파일 시스템이 확장됨에 따라 파일 시스템에서 사용할 수 있는 처리량이 스케일 인 또는 스케일 아웃합니다. 파일 기반 워크로드는 일반적으로 급증하기 때문에 일정 기간 높은 수준의 처리량이 필요하고 나머지 시간에는 낮은 수준의 처리량을 지원하면 되므로 Amazon EFS에는 일정 기간 높은 처리량 수준을 허용하도록 버스트 기능이 설계되었습니다. 또한 많은 워크로드에서 읽기 작업이 많기 때문에 읽기 작업은 다른 NFS 작업(예: 쓰기)에 비해 1:3 비율로 측정됩니다. 모든 Amazon EFS 파일 시스템은 Amazon EFS Standard 또는 Amazon EFS One Zone 스토리지의 각 TB에 대해 50MB/s의 일관된 기준 성능을 제공합니다. 크기에 관계없이 모든 파일 시스템은 100MB/s까지 버스트할 수 있습니다. EFS Standard 또는 EFS One Zone 스토리지에서 1TB를 초과하는 파일 시스템은 TB당 100MB/s까지 버스트할 수 있습니다. 읽기 작업은 1:3 비율로 측정되므로 읽기 처리량의 각 TiB에 대해 최대 300MiBS/s까지 지원할 수 있습니다. 파일 시스템에 데이터를 추가하면 파일 시스템에서 사용할 수 있는 최대 처리량 규모가 Amazon EFS Standard 스토리지 클래스의 스토리지에서 선형적으로 자동 조정됩니다. 저장된 데이터 크기보다 많은 처리량이 필요한 경우 워크로드에 필요한 특정 크기만큼 프로비저닝된 처리량을 구성할 수 있습니다. 파일 시스템 처리량은 파일 시스템에 연결된 모든 Amazon EC2 인스턴스에서 공유됩니다. 예를 들어, 100MB/s의 처리량까지 버스트할 수 있는 1TB 파일 시스템은 단일 Amazon EC2 인스턴스에서 100MB/s를 지원할 수 있습니다(각각 10MB/s 지원 가능). 자세한 내용은 *Amazon Elastic 파일 시스템 사용 설명서*의 [Amazon EFS 성능](https://docs.aws.amazon.com/efs/latest/ug/performance.html)을 참조하세요. ## Amazon EFS 볼륨에 대한 비용 최적화 Amazon EFS는 스토리지 규모 조정을 단순화합니다. Amazon EFS 파일 시스템은 데이터를 추가하면 자동으로 확장됩니다. 특히 Amazon EFS 버스팅 처리량 모드에서는 Standard 스토리지 클래스의 파일 시스템 크기가 커짐에 따라 처리량 규모가 조정됩니다.** EFS 파일 시스템의 프로비저닝된 처리량에 대해 추가 비용을 지불하지 않고도 처리량을 향상시키기 위해 Amazon EFS 파일 시스템을 여러 애플리케이션과 공유할 수 있습니다. Amazon EFS 액세스 포인트를 사용하면 공유 Amazon EFS 파일 시스템에서 스토리지 격리를 구현할 수 있습니다. 이렇게 하면 애플리케이션이 여전히 동일한 파일 시스템을 공유하더라도 사용자가 권한을 부여하지 않으면 데이터에 액세스할 수 없습니다. 데이터가 증가하면 Amazon EFS를 통해 자주 액세스하지 않는 파일을 하위 스토리지 클래스로 자동으로 이동할 수 있습니다. Amazon EFS Standard-Infrequent Access(IA) 스토리지 클래스는 매일 액세스하지 않는 파일의 스토리지 비용을 줄여줍니다. 또한 Amazon EFS가 제공하는 고가용성, 높은 내구성, 탄력성 및 POSIX 파일 시스템 액세스에 손상을 주지 않습니다. 자세한 내용은 *Amazon Elastic File System 사용 설명서*의 [EFS 스토리지 클래스](https://docs.aws.amazon.com/efs/latest/ug/features.html)를 참조하세요. Amazon EFS 수명 주기 정책을 사용하여 자주 액세스하지 않는 파일을 Amazon EFS IA 스토리지로 이동해 비용을 자동으로 절약하는 방법을 고려합니다. 자세한 내용을 알아보려면 *Amazon Elastic File System User Guide*(Amazon Elastic File System 사용 설명서)의 [Amazon EFS lifecycle management](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html)(EFS 수명 주기 관리)를 참조하세요. Amazon EFS 파일 시스템을 생성할 때 Amazon EFS가 여러 가용 영역(Standard)에 데이터를 복제할지 또는 단일 가용 영역 내에 데이터를 중복 저장할지 선택할 수 있습니다. Amazon EFS One Zone 스토리지 클래스는 Amazon EFS Standard 스토리지 클래스에 비해 스토리지 비용을 크게 절감할 수 있습니다. 다중 AZ 복원력이 필요하지 않은 워크로드에는 Amazon EFS One Zone 스토리지 클래스를 사용하는 방법을 고려합니다. 자주 액세스하지 않는 파일을 Amazon EFS One Zone-Infrequent Access로 이동하여 Amazon EFS One Zone 스토리지 비용을 더욱 절감할 수 있습니다. 자세한 내용은 [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/)를 참조하세요. ## Amazon EFS 볼륨 데이터 보호 Amazon EFS는 Standard 스토리지 클래스를 사용하는 파일 시스템에서 여러 가용 영역에 걸쳐 데이터를 저장합니다. 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 ECS 작업 정의에서 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 File System 사용 설명서*의 [전송 중 데이터 암호화(Encrypting Data in Transit)](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html)를 참조하세요. `transitEncryptionPort` 유형: 정수 필수 여부: 아니요 Amazon ECS 호스트와 Amazon EFS 서버 간에 암호화된 데이터를 전송할 때 사용할 포트입니다. 전송 중 데이터 암호화 포트를 지정하지 않으면 Amazon EFS 탑재 헬퍼가 사용하는 포트 선택 전략이 사용됩니다. 자세한 내용은 *Amazon Elastic File System 사용 설명서*의 [EFS 탑재 헬퍼](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html)를 참조하세요. `authorizationConfig` 유형: 객체 필수 여부: 아니요 Amazon EFS 파일 시스템에 대한 권한 부여 구성 세부 정보입니다. `accessPointId` 유형: 문자열 필수 여부: 아니요 사용할 액세스 포인트 ID입니다. 액세스 포인트를 지정하는 경우 `efsVolumeConfiguration`의 루트 디렉터리 값을 생략하거나 `/`로 설정하여 EFS 액세스 포인트에 설정된 경로를 적용해야 합니다. 액세스 포인트를 사용하는 경우 `EFSVolumeConfiguration`에서 전송 중 데이터 암호화를 활성화해야 합니다. 자세한 내용은 *Amazon Elastic File System 사용 설명서*의 [Amazon EFS 액세스 포인트 태스크](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html)를 참조세요. `iam` 유형: 문자열 유효한 값: `ENABLED` \$1 `DISABLED` 필수 여부: 아니요 Amazon EFS 파일 시스템을 탑재할 때 태스크 정의에 정의된 Amazon ECS 태스크 IAM 역할을 사용할지 여부를 지정합니다. 활성화된 경우 `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. 탐색 창에서 **클러스터**를 선택합니다. 1. **클러스터(Clusters)** 페이지에서 **클러스터 생성(Create cluster)**을 선택합니다. 1. **Cluster configuration**(클러스터 구성) 아래의 **Cluster name**(클러스터 이름)에 클러스터 이름으로 `EFS-tutorial`을 입력합니다. 1. (선택 사항) 태스크와 서비스가 시작되는 VPC와 서브넷을 변경하려면 **네트워킹(Networking)**에서 다음 태스크 중 하나를 수행합니다. + 서브넷을 제거하려면 **서브넷(Subnets)**에서 제거하려는 각 서브넷에 대해 **X**를 선택합니다. + **기본** VPC가 아닌 다른 VPC로 변경하려면 **VPC**에서 기존 **VPC**를 선택한 다음 **서브넷**에서 각 서브넷을 선택합니다. 1. Amazon EC2 인스턴스를 클러스터에 추가하려면 **인프라**를 확장한 다음 **Amazon EC2 인스턴스스**를 선택합니다. 다음으로 용량 공급자 역할을 하는 Auto Scaling 그룹을 구성합니다. 1. Auto Scaling 그룹을 생성하려면 **Auto Scaling 그룹(ASG)(Auto Scaling group (ASG))**에서 **새 그룹 생성(Create new group)**을 선택한 후 그룹에 대한 다음 세부 정보를 제공합니다. + **Operating system/Architecture**(운영 체제/아키텍처)에서 Amazon Linux 2를 선택합니다. + **EC2 인스턴스 유형(EC2 instance type)**에 `t2.micro`를 선택합니다. **SSH 키 페어(SSH key pair)**에서 인스턴스에 연결할 때 자격 증명을 증명하는 페어를 선택합니다. + **용량**에 `1`을 입력합니다. 1. **생성(Create)**을 선택합니다. ## 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. (선택 사항) 파일 시스템에 대한 태그를 추가합니다. 예를 들어, **이름(Name)** 키 옆에 있는 **값(Value)** 열에 해당 이름을 입력하여 파일 시스템에 대한 고유한 이름을 지정할 수 있습니다. 1. (선택 사항) 수명 주기 관리를 통해 자주 액세스하지 않는 스토리지에 드는 비용을 절감할 수 있습니다. 자세한 정보는 *Amazon Elastic File System User Guide*의 [EFS 수명 주기 관리](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html)를 참조하세요. 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. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다. 1. **인스턴스 시작**을 선택합니다. 1. **애플리케이션 및 OS 이미지(Amazon Machine Image)**에서 **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. **보안 그룹 자동 생성 및 연결**을 선택 취소합니다. 다른 확인란은 선택된 상태로 둡니다. **공유 파일 시스템 추가(Add shared file system)**를 선택합니다. 1. **고급 세부 정보(Advanced Details)**에서 Amazon EFS 파일 시스템 탑재 단계를 사용하여 사용자 데이터 스크립트가 자동으로 채워져 있는지 확인합니다. 1. **요약**에서 **인스턴스 수**가 **1**인지 확인합니다. **인스턴스 시작**을 선택합니다. 1. **인스턴스 시작** 페이지에서 **모든 인스턴스 보기**를 선택하여 인스턴스의 상태를 확인합니다. 처음에는 **인스턴스 상태**가 `PENDING`입니다. 상태가 `RUNNING`으로 변경되고 인스턴스가 모든 상태 확인을 통과하면 인스턴스를 사용할 준비가 된 것입니다. 이제 Amazon EC2 인스턴스에 연결하고 Amazon EFS 파일 시스템에 콘텐츠를 추가합니다. **Amazon EC2 인스턴스에 연결하고 Amazon EFS 파일 시스템에 콘텐츠를 추가하려면** 1. SSH를 사용하여 생성된 Amazon EC2 인스턴스에 연결합니다. 자세한 내용은 *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)**, **JSON으로 새 태스크 정의 생성(Create new task definition with 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 태스크 정의에서 'EFS IAM 권한 부여'가 활성화된 경우에만 Amazon ECS 태스크 역할이 필요합니다. 활성화된 경우 Amazon EFS 리소스 기반 정책에서 태스크 역할 자격 증명에 대해 Amazon EFS 파일 시스템에 대한 액세스가 허용되어야 하며 익명 액세스는 비활성화되어야 합니다. 1. **생성(Create)**을 선택합니다. ## 6단계: 작업 실행 및 결과 보기 이제 Amazon EFS 파일 시스템이 생성되고 NGINX 컨테이너에 사용할 웹 콘텐츠가 있으므로 생성된 태스크 정의를 사용하여 태스크를 실행할 수 있습니다. NGINX 웹 서버는 간단한 HTML 페이지를 제공합니다. Amazon EFS 파일 시스템에서 콘텐츠를 업데이트한 경우 변경 사항이 해당 파일 시스템도 탑재한 컨테이너에 전파됩니다. 작업은 클러스터에 정의한 서브넷에서 실행됩니다. **콘솔을 사용하여 작업을 실행하고 결과를 보려면 다음을 수행하세요.** 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터** 페이지에서 독립 실행형 태스크를 실행하는 클러스터를 선택합니다. 서비스를 시작할 리소스를 결정합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. (선택 사항) 예약된 태스크가 클러스터 인프라에 배포되는 방식을 선택합니다. **컴퓨팅 구성(Compute configuration)**을 열고 다음을 수행합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 1. **애플리케이션 유형(Application type)**에서 **작업(Task)**을 선택합니다. 1. **작업 정의**의 경우 앞서 생성한 `efs-tutorial` 작업 정의를 선택합니다. 1. **Desired tasks**(원하는 작업)에 `1`을 입력합니다. 1. **생성(Create)**을 선택합니다. 1. **Cluster**(클러스터) 페이지에서 **Infrastructure**(인프라)를 선택합니다. 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 파일 서버를 제공합니다. FSx for Windows File Server와 ECS를 함께 사용하면 영구적이고 분산, 공유된 고정 파일 스토리지로 Windows 태스크를 프로비저닝할 수 있습니다. 자세한 정보는 [FSx for Windows File Server란 무엇인가요?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)를 참조하세요. **참고** Amazon ECS 최적화 Windows Server 2016 Full AMI을 사용하는 EC2 인스턴스는 FSx for Windows File Server ECS 태스크 볼륨을 지원하지 않습니다. Fargate 구성의 Windows 컨테이너에서 Windows 파일 서버 볼륨용 FSx를 사용할 수 없습니다. 대신 [시작 시 컨테이너를 탑재하도록 수정할 수 있습니다](https://aws.amazon.com/blogs/containers/use-smb-storage-with-windows-containers-on-aws-fargate/). FSx for Windows File Server를 사용하여 공유된 외부 스토리지, 고가용성 리전 스토리지, 고성능 스토리지에 액세스해야 하는 Windows 워크로드를 배포할 수 있습니다. 하나 이상의 FSx for Windows File Server 파일 시스템 볼륨을 Amazon ECS Windows 인스턴스에 실행되는 Amazon ECS 컨테이너에 탑재할 수 있습니다. 단일 Amazon ECS 작업 내 여러 Amazon ECS 컨테이너 사이에서 FSx for Windows File Server 파일 시스템 볼륨을 공유할 수 있습니다. ECS로 FSx for Windows File Server를 사용하도록 지원하려면 FSx for Windows File Server 파일 시스템 ID와 관련 정보를 태스크 정의에 포함해야 합니다. 다음은 태스크 정의 JSON 코드 조각의 예제입니다. 태스크 정의를 생성, 실행하기 전에 다음이 필요합니다. + 유효한 도메인에 가입된 ECS Windows EC2 인스턴스. Amazon EC2의 온프레미스 Active Directory 또는 자체 Active Directory인 [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)에서 호스팅할 수 있습니다. + Active Directory 도메인을 결합하고 FSx for Windows File Server 파일 시스템을 연결하는 데 사용하는 자격 증명이 포함된 AWS Secrets Manager 보안 암호 또는 Systems Manager 파라미터. 자격 증명 값은 Active Directory를 생성할 때 입력하는 이름과 암호 자격 증명입니다. 관련 자습서는 [Amazon ECS에 대한 FSx for Windows File Server 파일 시스템을 구성하는 방법 알아보기](tutorial-wfsx-volumes.md) 섹션을 참조하세요. ## 고려 사항 FSx for Windows File Server 볼륨을 사용할 때 다음을 고려하세요. + FSx for Windows File Server 볼륨은 Windows Amazon EC2 인스턴스에서 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 파일 시스템 간의 네트워크 연결을 보장하고, 탑재 상태 확인을 구현하며, 장애 조치 이벤트를 견딜 수 있도록 재연결 로직을 처리할 책임은 사용자에게 있습니다. + FSx for Windows File Server와 Amazon ECS는 AWS Fargate를 지원하지 않습니다. + Amazon ECS에서의 FSx for Windows File Server는 Amazon ECS 관리형 인스턴스에서 지원되지 않습니다. + `awsvpc` 네트워크 모드의 FSx for Windows File Server와 Amazon ECS는 컨테이너 에이전트의 버전 `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 사용자와 그룹이 특정 FSx for Windows File Server 리소스에 취할 수 있는 태스크를 제어합니다. 고객은 클라이언트 권한 부여로 특정 FSx for Windows File Server 파일 시스템에 대한 액세스를 허용하거나 거부하는 IAM 역할을 정의할 수 있고, 선택적으로 읽기 전용 액세스를 요구하고 클라이언트에서 파일 시스템에 대한 루트 액세스를 허용 또는 거부할 수 있습니다. 자세한 정보는 Amazon FSx Windows 사용 설명서의 [보안](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는 파일 시스템에 대해 두 가지 암호화 양식을 지원합니다. 저장 중 데이터 및 전송 중 데이터 암호화 기능이 이에 해당합니다. 전송 중 데이터의 암호화는 SMB 프로토콜 3.0 이상을 지원하는 컨테이너 인스턴스에 매핑된 파일 공유에서 지원됩니다. Amazon FSx 파일 시스템을 생성할 때 저장 데이터 암호화가 자동으로 활성화됩니다. Amazon FSx는 애플리케이션을 수정할 필요 없이 파일 시스템에 액세스할 때 SMB 암호화를 사용하여 전송 중 데이터를 자동으로 암호화합니다. 자세한 내용은 *Amazon FSx for Windows File Server 사용 설명서*의 [Data encryption in 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). + [Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html) 파라미터의 Amazon 리소스 이름(ARN). `domain` 유형: 문자열 필수 항목 여부: 예 셀프 호스팅된 EC2 Active Directory 또는 [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)(AWS Managed Microsoft AD) 디렉터리에서 호스팅하는 정규화된 도메인 이름입니다. ## FSx for Windows File Server 볼륨 자격 증명을 저장하는 방법 자격 증명 파라미터와 함께 사용할 자격 증명을 저장하는 방법에는 두 가지가 있습니다. + **AWS Secrets Manager 암호** 이 자격 증명은 *다른 암호 유형* 카테고리를 사용하여 AWS Secrets Manager 콘솔에서 생성할 수 있습니다. 각 키/값 쌍, 사용자 이름/관리자 및 암호/*암호*에 대한 열을 추가합니다. + **Systems Manager 파라미터** 이 자격 증명은 다음 예제 코드 조각에 표시된 형식으로 텍스트를 입력하여 Systems Manager 파라미터 콘솔에서 생성될 수 있습니다. ``` { "username": "admin", "password": "password" } ``` 태스크 정의 `FSxWindowsFileServerVolumeConfiguration` 파라미터의 `credentialsParameter`는 암호 ARN 또는 Systems Manager 파라미터 ARN을 보유합니다. 자세한 정보는 *Secrets Manager 사용 설명서*의 [AWS Secrets Manager란 무엇인가요?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 및 *Systems 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 관리형 Microsoft Active Directory를 생성합니다. 그런 다음 Amazon EC2 인스턴스 및 태스크 정의를 사용하여 FSx for Windows File Server 파일 시스템 및 클러스터를 생성합니다. FSx for Windows File Server 파일 시스템을 사용하도록 컨테이너에 대한 태스크 정의를 구성합니다. 마지막으로 파일 시스템을 테스트합니다. 이 태스크는 Active Directory 또는 FSx for Windows File Server 파일 시스템을 시작하거나 삭제할 때마다 20\$145분 정도 걸립니다. 자습서를 완료하거나 몇 세션 동안 자습서를 완료하기 위해 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)를 참조하세요. + 하나 이상의 퍼블릭 서브넷과 프라이빗 서브넷, 보안 그룹이 있는 VPC. 기본 VPC를 사용할 수 있습니다. NAT 게이트웨이 또는 장치가 필요하지 않습니다. Directory Service는 Active Directory에서 NAT(네트워크 주소 변환)를 지원하지 않습니다. 이 작업을 수행하려면 VPC 내에 Active Directory, FSx for Windows File Server 파일 시스템, ECS 클러스터 및 EC2 인스턴스가 있어야 합니다. VPC와 Active Directory에 대한 자세한 내용은 [VPC 생성](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) 및 [AWS 관리형 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 Management Console을 사용하여 클러스터를 생성합니다.** 1. ecsInstanceRole이 있는지 확인하고 없는 경우 생성 방법을 확인하려면 [Amazon ECS 컨테이너 인스턴스 IAM 역할](instance_IAM_role.md) 섹션을 참조하세요. 1. 실제 프로덕션 환경에서는 최소 사용 권한에 맞게 역할 정책을 사용자 지정하는 것이 좋습니다. 이 자습서를 통해 작업하기 위해 다음 AWS 관리형 정책이 ecsInstanceRole에 연결되었는지 확인합니다. 아직 연결되어 있지 않은 경우 정책을 연결합니다. + AmazonEC2ContainerServiceforEC2Role + AmazonSSMManagedInstanceCore + AmazonSSMDirectoryServiceAccess AWS 관리형 정책을 연결하려면 1. [IAM 콘솔(IAM console)](https://console.aws.amazon.com//iam/)을 엽니다. 1. 탐색 창에서 **역할**을 선택합니다. 1. **AWS 관리형 역할**을 선택합니다. 1. **권한, 정책 연결**을 선택합니다. 1. 연결에 사용할 수 있는 정책의 범위를 좁히려면 **필터(Filter)**를 사용합니다. 1. 적절한 정책을 선택하고 **정책 연결(Attach policy)**을 선택합니다. 1. ecsTaskExecutionRole이 있는지 확인하고 없는 경우 생성 방법을 확인하려면 [Amazon ECS 태스크 실행 IAM 역할](task_execution_IAM_role.md) 섹션을 참조하세요. 실제 프로덕션 환경에서는 최소 사용 권한에 맞게 역할 정책을 사용자 지정하는 것이 좋습니다. 이 자습서를 통해 작업하기 위해 다음 AWS 관리형 정책이 ecsTaskExecutionRole에 연결되었는지 확인합니다. 정책이 아직 연결되어 있지 않은 경우 정책을 연결합니다. 이전 섹션에 제시한 절차를 통해 AWS 관리형 정책에 연결합니다. + SecretsManagerReadWrite + AmazonFSxReadOnlyAccess + AmazonSSMReadOnlyAccess + AmazonECSTaskExecutionRolePolicy ## 2단계: Windows Active Directory(AD) 생성 1. AWS *Directory Service 관리 안내서*의 [AWS 관리형 Microsoft AD 생성](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_create_directory)에 설명된 단계를 따릅니다. 이 자습서에서 지정한 VPC를 사용합니다. *AWS 관리형 Microsoft 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. **새 보안 암호 저장(Store a new secret)**을 클릭합니다. 1. **다른 유형의 보안 암호(Other type of secrets)**를 선택합니다. 1. 첫 번째 행의 **보안 암호 키/값(Secret key/value)**에서 값이 **admin**인 키 **username**를 생성합니다. **\$1행 추가(\$1 Add row)**를 클릭합니다. 1. 새 행에서 키 **password**를 생성합니다. 값에 *AWS 관리형 AD 디렉터리 생성*의 3단계에서 입력한 암호를 입력합니다. 1. **다음(Next)** 버튼을 클릭합니다. 1. 보안 암호 이름 및 설명을 입력합니다. **다음(Next)**을 클릭합니다. 1. **다음**을 클릭합니다. **저장(Store)**을 클릭합니다. 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 파일 시스템, Active Directory 및 ECS 인스턴스에서 트래픽을 주고받을 수 있습니다. 다른 인바운드 규칙은 트래픽이 웹사이트 및 ECS 인스턴스에 연결하기 위한 RDP 액세스를 제공하도록 허용합니다. 다음 표에서는 이 자습서에 필요한 보안 그룹 인바운드 규칙을 보여 줍니다. | 유형 | 프로토콜 | 포트 범위 | 소스 | | --- | --- | --- | --- | | 모든 트래픽 | 모두 | 모두 | *보안 그룹(SG)* | | HTTPS | TCP | 443 | 0.0.0.0/0 | | RDP | TCP | 3389 | 랩톱 IP 주소 | 다음 표에서는 이 자습서에 필요한 보안 그룹 아웃바운드 규칙을 보여 줍니다. | Type | 프로토콜 | 포트 범위 | 대상 | | --- | --- | --- | --- | | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 1. [EC2 콘솔](https://console.aws.amazon.com//ec2/)을 열고 왼쪽 메뉴에서 **보안 그룹(Security Groups)**을 선택합니다. 1. 이제 표시된 보안 그룹 목록에서 이 자습서에서 사용하는 보안 그룹의 왼쪽에 있는 확인란을 선택합니다. 보안 그룹 정보가 표시됩니다. 1. **인바운드 규칙** 또는 **아웃바운드 규칙** 탭을 클릭하고 **인바운드 규칙 편집** 또는 **아웃바운드 규칙 편집** 버튼을 선택하여 인바운드 및 아웃바운드 규칙을 편집합니다. 이전 표에 표시된 규칙과 일치하도록 규칙을 편집합니다. 이 자습서의 뒷부분에서 EC2 인스턴스를 생성한 후, *Amazon EC2 사용 설명서*의 [RDP를 사용하여 Windows 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html)에서 설명한 것처럼 EC2 인스턴스의 퍼블릭 IP 주소로 인바운드 규칙 RDP 소스를 편집합니다. ## 4단계: Amazon FSx for Windows File Server 파일 시스템 생성 보안 그룹을 확인 및 업데이트하고 Active Directory를 생성하여 활성 상태가 되면 Active Directory와 동일한 VPC에 FSx for Windows File Server 파일 시스템을 생성합니다. 다음 단계에 따라 Windows File Server 파일 시스템을 Windows 작업에 사용할 FSx for Windows File Server 파일 시스템을 생성합니다. **첫 파일 시스템을 생성합니다.** 1. [Amazon FSx 콘솔](https://console.aws.amazon.com//fsx/)을 엽니다. 1. 대시보드에서 **파일 시스템 생성(Create file system)**을 선택해 파일 시스템 생성 마법사를 시작합니다. 1. **파일 시스템 유형 선택** 페이지에서 **FSx for Windows File Server**를 선택한 다음 **다음**을 선택합니다. **파일 시스템 생성** 페이지가 표시됩니다. 1. **파일 시스템 정보(File system details)** 섹션에서 파일 시스템의 이름을 입력합니다. 파일 시스템의 이름을 지정하면 파일 시스템을 보다 쉽게 찾고 관리할 수 있습니다. 최대 256자의 유니코드 문자를 사용할 수 있습니다. 허용되는 문자는 문자, 숫자, 공백과 특수 문자 \$1기호(\$1), 빼기 기호(-), 등호(=), 마침표(.), 밑줄(\$1), 콜론(:) 및 슬래시(/)입니다. 1. **배포 유형(Deployment type)**에서 **단일 AZ(Single-AZ)**를 사용하여 단일 가용 영역에 배포되는 파일 시스템을 배포합니다. *단일 AZ 2*는 단일 가용 영역 파일 시스템의 최신 세대이며 SSD 및 HDD 스토리지를 지원합니다. 1. **스토리지 유형(Storage type)**에서 **HDD**를 선택합니다. 1. **스토리지 용량(Storage capacity)**에 최소 스토리지 용량을 입력합니다. 1. **용량 처리량(Throughput capacity)**을 기본 설정으로 유지합니다. 1. **네트워크 및 보안(Network & security)** 섹션에서 Directory Service 디렉터리에 선택한 것과 동일한 Amazon VPC를 선택합니다. 1. **VPC 보안 그룹(VPC Security Groups)**에서 *3단계: 보안 그룹 확인 및 업데이트*에서 확인한 보안 그룹을 선택합니다. 1. **Windows 인증(Windows authentication)**에서 **AWS 관리형 Microsoft Active Directory**를 선택한 다음 목록에서 Directory Service 디렉터리를 선택합니다. 1. **암호화(Encryption)**에서 기본 **암호화 키(Encryption key)** 설정을 **aws/fsx(기본값)**로 그대로 사용합니다. 1. **유지 관리 기본 설정(Maintenance preferences)**의 기본 설정을 유지합니다. 1. **다음(Next)** 버튼을 클릭합니다. 1. **파일 시스템 생성** 페이지에 표시된 파일 시스템 구성을 검토합니다. 참조할 수 있도록 파일 시스템을 생성한 후 수정할 수 있는 파일 시스템 설정을 확인합니다. **파일 시스템 생성**을 선택합니다. 1. 파일 시스템 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. 탐색 창에서 **클러스터**를 선택합니다. 1. **클러스터(Clusters)** 페이지에서 **클러스터 생성(Create cluster)**을 선택합니다. 1. **클러스터 구성**의 **클러스터 이름**에 **windows-fsx-cluster**를 입력합니다. 1. **인프라**에서 AWS Fargate(서버리스)를 선택 취소한 다음 **Amazon EC2 인스턴스**를 선택합니다. 1. Auto Scaling 그룹을 생성하려면 **Auto Scaling 그룹(ASG)(Auto Scaling group (ASG))**에서 **새 그룹 생성(Create new group)**을 선택한 후 그룹에 대한 다음 세부 정보를 제공합니다. + **운영 체제/아키텍처의**에서 **Windows Server 2019 Core**를 선택합니다. + **EC2 인스턴스 유형**에서 t2.medium 또는 t2.micro를 선택합니다. 1. **생성(Create)**을 선택합니다. ## 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. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다. 1. 탐색 모음에서 사용할 리전을 선택합니다. 1. **EC2 대시보드**에서 **인스턴스 시작(Launch Instance)**을 선택합니다. 1. **Name**(이름)에 고유한 이름을 입력합니다. 1. **애플리케이션 및 OS 이미지(Amazon Machine Image)**에서 **검색** 필드에 첫 번째 단계에서 검색한 AMI 이름을 입력합니다. 1. **인스턴스 유형**에서 t2.medium 또는 t2.micro를 선택합니다. 1. **키 페어(로그인)**에서 키 페어를 선택합니다. 키 페어를 지정하지 않은 경우 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. **시작 유형(Launch Type)**을 **EC2**로 선택합니다. 1. 배포 구성에서 **작업 정의**에 대해 **fsx-windows**를 선택한 다음 **생성**을 선택합니다. 1. 작업 상태가 **RUNNING**이면 작업 ID를 선택합니다. 1. **컨테이너**에서 container1 상태가 **STOPPED**이면 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\$145분 정도 걸립니다. 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`에 생성됩니다. 도커 볼륨을 사용하려면 태스크 정의에서 `dockerVolumeConfiguration`을 지정합니다. 자세한 내용은 Docker 설명서 센터의 [볼륨](https://docs.docker.com/engine/storage/volumes/)을 참조하세요. Docker 볼륨의 몇 가지 일반 사용 사례는 다음과 같습니다. + 컨테이너에 사용할 영구 데이터 볼륨 제공 + 동일한 컨테이너 인스턴스의 컨테이너마다 다른 위치에서 정의된 데이터 볼륨 공유 + 비어있는 비영구 데이터 볼륨을 정의한 후 동일 태스크에 속하는 다수의 컨테이너에 탑재 + 타사 드라이버에서 관리하는 태스크에 데이터 볼륨을 제공하는 방법 ## Docker 볼륨 사용 시 고려 사항 Docker 볼륨을 사용할 때는 다음 사항을 고려해야 합니다. + EC2 시작 유형 또는 외부 인스턴스를 사용하는 경우에는 Docker 볼륨만 지원됩니다. + 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 볼륨의 범위입니다. 범위가 `task`로 지정된 Docker 볼륨은 태스크가 시작될 때 자동으로 프로비저닝되고, 태스크가 중단되면 삭제됩니다. 범위가 `shared`로 지정된 Docker 볼륨은 태스크 중단 후에도 유지됩니다. `autoprovision` 유형: Boolean 기본값: `false` 필수 여부: 아니요 이 값이 `true`인 경우 도커 볼륨이 아직 없으면 도커 볼륨이 생성됩니다. 이 필드는 `scope`가 `shared`인 경우에만 사용됩니다. `scope`가 `task`인 경우 이 파라미터를 생략해야 합니다. `driver` 유형: 문자열 필수 여부: 아니요 사용할 Docker 볼륨 드라이버입니다. Docker에서 제공하는 드라이버 이름이 작업 배치에 사용되므로 드라이버 값과 이 이름이 일치해야 합니다. Docker 플러그인 CLI를 사용하여 드라이버를 설치했다면 `docker plugin ls`를 사용하여 컨테이너 인스턴스에서 드라이버 이름을 검색합니다. 다른 방법을 사용하여 드라이버를 설치했다면 Docker 플러그인 검색을 사용하여 드라이버 이름을 검색합니다. `driverOpts` 유형: 문자열 필수 여부: 아니요 전달할 Docker 드라이버에 특정한 옵션 맵입니다. 이 파라미터는 Docker의 볼륨 생성의 `DriverOpts`에 매핑됩니다. `labels` 유형: 문자열 필수 여부: 아니요 Docker 볼륨에 추가할 사용자 지정 메타데이터입니다. `mountPoints` 유형: 객체 배열 필수 여부: 아니요 컨테이너에서 데이터 볼륨의 탑재 지점입니다. 이 파라미터는 create-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 볼륨을 사용하여 컨테이너에 임시구 스토리지를 제공하는 방법** 이 예에서 컨테이너는 태스크가 완료된 후 폐기되는 빈 데이터 볼륨을 사용합니다. 사용 사례 중 한 예로, 태스크 도중 Scratch 파일 스토리지 위치에 액세스해야 하는 컨테이너가 있을 수 있습니다. 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 볼륨을 사용하여 여러 컨테이너에 영구 스토리지 제공** 이번 예제에서는 다수의 컨테이너에서 공유 볼륨을 사용하고, 이 볼륨을 사용하는 단일 태스크가 중단된 후에도 볼륨을 유지하려고 합니다. 내장 `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" } ] } ] ``` **도커 볼륨을 사용하여 컨테이너에 NFS 영구 스토리지 제공** 이 예에서 컨테이너는 작업이 시작될 때 자동으로 탑재되고 작업이 중지될 때 탑재 해제되는 NFS 데이터 볼륨을 사용합니다. 도커 내장`local` 드라이버가 사용됩니다. 사용 사례 중 한 예로, ECS Anywhere 작업에서 해당 스토리지에 액세스해야 하는 경우가 있습니다. NFS 드라이버 옵션이 있는 도커 볼륨을 사용하면 이러한 작업을 수행할 수 있습니다. 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 설명서에서 [바인드 탑재](https://docs.docker.com/engine/storage/bind-mounts/)를 참조하세요. 바인드 탑재의 일반 사용 사례는 다음과 같습니다. + 하나 이상의 컨테이너에 마운트할 빈 데이터 볼륨을 제공합니다. + 하나 이상의 컨테이너에 호스트 데이터 볼륨을 마운트합니다. + 동일한 태스크의 다른 컨테이너에 소스 컨테이너의 데이터 볼륨을 공유합니다. + Dockerfile의 경로와 콘텐츠를 하나 이상의 컨테이너에 노출합니다. ## 바인드 탑재 사용 시 고려 사항 바인드 탑재를 사용할 때는 다음 사항을 고려해야 합니다. + 플랫폼 버전 `1.4.0` 이상(Linux) 또는 `1.0.0` 이상(Windows)을 사용하여 AWS Fargate에 호스팅되는 작업의 경우 기본적으로 바인드 탑재를 위해 최소 20GiB 이상의 임시 스토리지를 수신합니다. 임시 스토리지의 총량은 작업 정의에 `ephemeralStorage` 파라미터를 지정하여 최대 200GiB까지 늘릴 수 있습니다. + 태스크가 실행될 때 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 관리형 인스턴스에서 호스팅되는 태스크의 경우 루트 파일 시스템의 일부는 읽기 전용입니다. 읽기/쓰기 바인드 탑재는 영구 데이터를 위한 `/var` 또는 임시 데이터를 위한 `/tmp`와 같은 쓰기 가능한 디렉터리를 사용해야 합니다. 다른 디렉터리에 읽기/쓰기 바인드 탑재를 생성하려고 하면 다음과 유사한 오류와 함께 태스크 실행이 실패합니다. ``` 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` 설정은 컨테이너에 호스트에서의 루트 접근 권한과 동등한 확장된 권한을 부여합니다. 이 예제에서는 진단 목적으로 호스트의 탑재 테이블을 검사하는 데 사용됩니다. 자세한 내용은 [컨테이너를 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` 유형: 객체 배열 필수 여부: 아니요 컨테이너에서 데이터 볼륨의 탑재 지점입니다. 이 파라미터는 create-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)입니다. 이 파라미터는 플랫폼 버전 `1.4.0` 이상(Linux) 또는 `1.0.0` 이상(Windows)을 사용하는 AWS Fargate에서 호스팅되는 태스크에 대해 제공되는 임시 스토리지 총량을 기본 용량 이상으로 확장할 때 사용합니다. Copilot CLI, CloudFormation,AWS SDK 또는 CLI를 사용하여 바인드 탑재에 대한 임시 스토리지를 지정할 수 있습니다. # Amazon ECS에 대한 바인드 탑재 예제 다음 예제에서는 컨테이너에 바인드 탑재를 사용하는 일반적인 사용 사례를 다룹니다. **Fargate 태스크를 위한 임시 스토리지 스페이스의 증가된 양을 할당하는 방법** 플랫폼 버전 `1.4.0` 이상(Linux) 또는 `1.0.0` 이상(Windows)을 사용하여 Fargate에서 호스팅되는 Amazon ECS 태스크의 경우 태스크의 컨테이너에 사용할 임시 스토리지 공간의 기본 양 이상을 할당할 수 있습니다. 이 예제는 다른 예제에 포함하여 Fargate 태스크에 더 많은 임시 스토리지를 할당할 수 있습니다. + 태스크 정의에서 `ephemeralStorage` 객체를 정의합니다. `sizeInGiB`는 `21`과 `200` 값 사이의 정수여야 하며 GiB로 표현합니다. ``` "ephemeralStorage": { "sizeInGiB": integer } ``` **하나 이상의 컨테이너에 빈 데이터 볼륨을 제공하는 방법** 경우에 따라 태스크의 컨테이너에 스크래치 스페이스를 제공합니다. 예를 들어 태스크 도중 동일한 스크래치 파일 스토리지 위치에 액세스해야 하는 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`에 웹 사이트 데이터 폴더가 있습니다. 문서 루트가 서로 다른 두 웹 서버에 해당 데이터 볼륨을 읽기 전용으로 탑재할 수 있습니다. 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 인스턴스에서 호스팅되는 태스크의 경우 컨테이너에 하나 이상의 볼륨을 정의한 후 다른 컨테이너 정의(동일한 태스크 내)의 `volumesFrom` 파라미터를 사용하여 원래 정의된 탑재 지점에서 `sourceContainer`로부터 모든 볼륨을 탑재할 수 있습니다. `volumesFrom` 파라미터는 태스크 정의에 정의된 볼륨과 Dockerfile을 사용하여 이미지에 내장된 볼륨에 적용됩니다. 1. (선택 사항) 이미지에 내장된 볼륨을 공유하려면 Dockerfile의 명령인 `VOLUME`을 사용합니다. 다음 예제 Dockerfile은 `httpd` 이미지를 사용한 후 볼륨을 추가하고 Apache 문서 루트에서 `dockerfile_volume`에 탑재합니다. 이 폴더는 `httpd` 웹 서버에서 사용하는 폴더입니다. ``` FROM httpd VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"] ``` 이 Dockerfile을 사용하여 이미지를 만들어 Docker Hub와 같은 리포지토리에 푸시한 후 태스크 정의에서 사용할 수 있습니다. 다음 단계에서 사용된 `my-repo/httpd_dockerfile_volume` 이미지 예제는 위의 Dockerfile을 사용하여 구축되었습니다. 1. 컨테이너에 다른 볼륨 및 탑재 지점을 정의하는 태스크 정의를 생성합니다. 이 예제 `volumes` 섹션에서는 `empty`라는 빈 볼륨을 생성하며, Docker 대몬이 이 볼륨을 관리합니다. `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 } ] } ``` 이 태스크가 실행되면 두 컨테이너가 볼륨을 탑재하며, `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`이 되어 스와핑이 발생하지 않도록 합니다. `100`의 `swappiness` 값은 페이지가 적극적으로 스와핑되도록 합니다. 허용되는 값은 `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) 또는 [Amazon EC2 인스턴스에서 스왑 스페이스로 작동하도록 메모리를 할당하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/ec2-memory-swap-file)를 참조하세요. + 스왑 스페이스 컨테이너 정의 파라미터는 EC2를 지정하는 태스크 정의에 대해서만 지원됩니다. 이러한 파라미터는 Fargate의 Amazon ECS 사용 전용 작업 정의에는 지원되지 않습니다. + 이 기능은 Linux 컨테이너에서만 지원됩니다. 현재 Windows 컨테이너는 지원되지 않습니다. + 만약`maxSwap`과 `swappiness`컨테이너 정의 파라미터가 태스크 정의에서 생략되는 경우, 각 컨테이너는 `swappiness`의 기본값으로 `60`을 갖습니다. 또한 총 스왑 사용량은 컨테이너 메모리의 두 배로 제한됩니다. + 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 Management Console에서 **기능 필요** 필드에 `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 Management Console에서 **기능 필요** 필드에 `FARGATE`를 지정합니다. + AWS CLI에서 `--requires-compatibilities` 옵션을 지정합니다. + Amazon ECS API에서 `requiresCompatibilities` 플래그를 지정합니다. ## 운영 체제 및 아키텍처 AWS Fargate에 대한 태스크 및 컨테이너 정의를 구성할 때 컨테이너가 실행하는 운영 체제를 지정해야 합니다. AWS Fargate에서 지원되는 운영 체제는 다음과 같습니다. + Amazon Linux 2 **참고** Linux 컨테이너는 호스트 운영 체제의 커널 및 커널 구성만 사용합니다. 예를 들어 커널 구성에 `sysctl` 시스템 컨트롤이 포함됩니다. Linux 컨테이너 이미지는 모든 Linux 배포판의 파일 및 프로그램을 포함하는 기본 이미지로 만들 수 있습니다. CPU 아키텍처가 일치하면 모든 운영 체제의 모든 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 컨테이너를 실행할 때 X86\$164 CPU 아키텍처 또는 ARM 기반 애플리케이션용 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 값을 `1024`(CPU 단위) 또는 `1 vCPU`(vCPU)로 지정할 수 있습니다. | CPU 값 | 메모리 값 | AWS Fargate에 지원되는 운영 체제 | | --- | --- | --- | | 256(.25 vCPU) | 512MiB, 1GB, 2GB | Linux | | 512(.5 vCPU) | 1GB, 2GB, 3GB, 4GB | Linux | | 1024(1 vCPU) | 2GB, 3GB, 4GB, 5GB, 6GB, 7GB, 8GB | Linux, Windows | | 2048(2 vCPU) | 4\$116GB(1GB 증분) | Linux, Windows | | 4096(4 vCPU) | 8\$130GB(1GB 증분) | Linux, Windows | | 8192 (8 vCPU) 이 옵션은 Linux 플랫폼 `1.4.0` 이상이 필요합니다. | 16\$160GB(4GB 증분) | Linux | | 16384 (16vCPU) 이 옵션은 Linux 플랫폼 `1.4.0` 이상이 필요합니다. | 32\$1120GB(8GB 증분) | Linux | ## 태스크 네트워킹 AWS Fargate용 Amazon ECS 태스크에는 탄력적 네트워크 인터페이스를 각 태스크에 제공하는 `awsvpc` 네트워크 모드가 필요합니다. 이 네트워크 모드를 사용하여 태스크를 실행하거나 서비스를 생성할 때는 네트워크 인터페이스를 연결할 하나 이상의 서브넷과 네트워크 인터페이스에 적용할 하나 이상의 보안 그룹을 지정해야 합니다. 퍼블릭 서브넷을 사용하는 경우에는 네트워크 인터페이스에 퍼블릭 IP 주소를 제공할지를 결정합니다. 퍼블릭 서브넷의 Fargate 태스크가 컨테이너 이미지를 풀링하려면 인터넷에 대한 경로 또는 인터넷으로 요청을 라우팅할 수 있는 NAT 게이트웨이를 사용하여 태스크의 탄력적 네트워크 인터페이스에 퍼블릭 IP 주소를 할당해야 합니다. 프라이빗 서브넷의 Fargate 태스크가 컨테이너 이미지를 풀링하려면 인터넷으로 요청을 라우팅할 수 있는 NAT 게이트웨이가 서브넷에 있어야 합니다. Amazon ECR에서 컨테이너 이미지를 호스팅하면 인터페이스 VPC 엔드포인트를 사용하도록 Amazon ECR을 구성할 수 있습니다. 이 경우 태스크의 프라이빗 IPv4 주소는 이미지 풀링에 사용됩니다. Amazon ECR 인터페이스 엔드포인트에 대한 자세한 정보는 *Amazon Elastic Container Registry 사용자 설명서*의 [Amazon ECR 인터페이스 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`으로 설정할 수 있습니다. 두 배로 늘어난 사용자 지정 `nofile` 제한을 정의하는 방법을 나타내는 예제 태스크 정의 코드 조각은 다음과 같습니다. ``` "ulimits": [ { "name": "nofile", "softLimit": 2048, "hardLimit": 8192 } ] ``` 조정할 수 있는 다른 리소스 제한에 대한 자세한 정보는 [리소스 제한](task_definition_parameters.md#container_definition_limits) 섹션을 참조하세요. ## 로깅 ### 이벤트 로깅 Amazon ECS는 수행한 작업을 EventBridge에 기록합니다. EventBridge용 Amazon ECS 이벤트를 사용하여 Amazon ECS 클러스터, 서비스 및 작업의 현재 상태에 관해 실시간에 가까운 알림을 받을 수 있습니다. 또한 이러한 이벤트에 응답하도록 작업을 자동화할 수 있습니다. 자세한 내용은 [EventBridge를 사용하여 Amazon ECS 오류에 대한 응답 자동화](cloudwatch_event_stream.md) 섹션을 참조하세요. ### 작업 수명 주기 로깅 Fargate에서 실행되는 작업은 타임스탬프를 게시하여 작업 수명 주기의 상태를 통해 작업을 추적합니다. AWS Management Console의 작업 세부 정보 및 AWS CLI 및 SDK의 작업 설명에서 타임스탬프를 확인할 수 있습니다. 예를 들어 타임스탬프를 사용하여 컨테이너 이미지를 다운로드하는 데 소요된 시간을 평가하고 컨테이너 이미지 크기를 최적화할지 아니면 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 인덱스 매니페스트 v2만 사용할 수 있습니다. 이전에 Fargate에서 SOCI를 사용한 기존 고객은 SOCI 인덱스 매니페스트 v1을 계속 사용할 수 있지만, SOCI 인덱스 매니페스트 v2로 마이그레이션하는 것이 좋습니다. SOCI 인덱스 매니페스트 v2는 컨테이너 이미지와 해당 SOCI 인덱스 간에 명시적 관계를 생성하여 일관된 배포를 보장합니다. **고려 사항** Fargate가 SOCI 인덱스를 사용하여 작업에서 컨테이너 이미지를 느리게 로드하도록 하려면 다음 사항을 고려합니다. + Linux 플랫폼 버전 `1.4.0`에서 실행되는 작업만 SOCI 인덱스를 사용할 수 있습니다. Fargate 기반 Windows 컨테이너를 실행하는 작업은 지원되지 않습니다. + X86\$164 또는 ARM64 CPU 아키텍처에서 실행되는 작업은 지원됩니다. + 작업 정의의 컨테이너 이미지는 호환 가능한 이미지 레지스트리에 저장되어야 합니다. 호환 가능한 레지스트리 목록은 다음과 같습니다. + Amazon ECR 프라이빗 레지스트리 + gzip 압축을 사용하거나 압축되지 않은 컨테이너 이미지만 지원됩니다. zstd 압축을 사용하는 컨테이너 이미지는 지원되지 않습니다. + SOCI 인덱스 매니페스트 v2의 경우 SOCI 인덱스 매니페스트를 생성하면 SOCI 인덱스에 대한 주석을 추가할 때 컨테이너 이미지 매니페스트가 수정됩니다. 이를 통해 새 컨테이너 이미지 다이제스트가 생성됩니다. 컨테이너 이미지 파일 시스템 계층의 내용은 변경되지 않습니다. + SOCI 인덱스 매니페스트 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의 [CFN 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 참조 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)을 참조하세요.