모듈 1: Amazon ECS, ECR 및 AWS Fargate 이해
학습 모듈
개요
이 모듈에서는 Amazon ECS, AWS Fargate 기반 Amazon ECS 및 Amazon ECR을 소개합니다. Linux 및 Windows에서 실행되는 컨테이너에 대한 클러스터, 컨테이너 및 이미지, 태스크 및 태스크 정의, 서비스 및 시작 유형에 대해 알아봅니다. 마지막으로, 이러한 모든 요소를 종합하여 시나리오와 경로를 검토해 Amazon ECS를 사용하거나 또는 .NET 애플리케이션용 AWS Fargate 기반의 Amazon ECS를 사용하여 최상의 컨테이너 솔루션을 도출할 수 있는 방법을 살펴볼 것입니다.
소요 시간
30분
Amazon ECS 소개
Amazon ECS는 클라우드에서 컨테이너 기반 애플리케이션을 실행하는 데 사용되는 서비스입니다. 확장성이 뛰어나고 빠른 컨테이너 관리를 제공하며 다른 AWS 서비스와 통합하여 보안, 컨테이너 오케스트레이션, 지속적 통합 및 배포, 서비스 검색, 모니터링 및 관찰성을 제공합니다.
가상 머신 이미지에서 가상 머신을 시작하는 방법과 유사하게 컨테이너 이미지를 사용하여 컨테이너를 시작합니다. Amazon ECS는 Amazon Elastic Container Registry(Amazon ECR) 또는 Docker Hub에 배포된 컨테이너 이미지로부터 컨테이너를 배포하고 실행합니다.
Amazon ECS는 태스크 정의를 사용하여 애플리케이션을 구성하는 컨테이너를 정의합니다. 태스크 정의는 애플리케이션의 컨테이너가 실행되는 방식을 지정합니다. 실행 후 완료 시 중지되는 개별 태스크를 정의하여 사용하거나, 태스크가 서비스 내에서 실행되도록 정의할 수 있습니다. 서비스는 지정된 수의 태스크를 동시에 지속적으로 실행하고 유지 관리하므로 웹 애플리케이션과 같이 장시간 실행되는 애플리케이션에 적합합니다.
필요하다면 컨테이너를 호스팅하는 인프라를 구성 및 관리하거나 AWS Fargate에서 Amazon ECS를 사용하여 AWS에서 컨테이너 인프라를 관리하고 사용자는 애플리케이션에 집중하는 서버리스 접근 방식을 활용할 수 있습니다. Amazon ECS는 컨테이너 실행을 위한 두 가지 모델(시작 유형이라고 함)을 제공합니다.
EC2 시작 유형
EC2 시작 유형은 클러스터로 구성된 하나 이상의 Amazon Elastic Compute Cloud(EC2) 인스턴스에서 컨테이너를 실행하는 데 사용됩니다. EC2 시작 유형을 사용하면 컨테이너를 호스팅하는 인프라의 구성 및 관리를 완전히 제어할 수 있습니다.
인프라를 관리해야 하거나 애플리케이션에 지속적으로 높은 CPU 코어 및 메모리 사용량이 필요하거나 가격 최적화가 필요하거나 영구적인 스토리지가 필요하다면 컨테이너의 EC2 시작 유형을 선택하세요.
Fargate 시작 유형
Fargate 시작 유형은 컨테이너 실행을 위한 서버리스 종량제 옵션입니다. ‘서버리스’란 실행 중인 컨테이너를 호스팅하기 위해 인스턴스 클러스터를 구성하고 관리하는 방법을 파악해야 하는 EC2 시작 유형과는 달리, 컨테이너 인스턴스를 호스팅하기 위한 인프라를 구성할 필요가 없음을 의미합니다.
Amazon ECS 리소스
시작 유형을 사용하여 컨테이너 인프라를 관리하는 방법을 제어하는 것 외에도 Amazon ECS를 사용할 때에는 여러 유형의 리소스를 접하고 사용하게 됩니다.
클러스터
클러스터는 특정 리전에 있는 컴퓨팅 리소스의 논리적 그룹입니다. 클러스터는 애플리케이션 및 애플리케이션 구성 요소를 호스팅하는 실행 중 컨테이너 인스턴스를 보관하므로 동일한 기본 인프라를 사용하지 않도록 이들 인스턴스를 격리하는 데 도움이 됩니다. 이렇게 하면 애플리케이션을 호스팅하는 인프라의 특정 항목에 장애가 발생할 경우 가용성이 향상됩니다. 영향을 받은 클러스터만 다시 시작해야 합니다.
Amazon ECS를 사용하든 아니면 AWS Fargate 기반 Amazon ECS를 사용하든 관계없이 클러스터 작업을 수행하게 됩니다. 차이가 있다면 여러분에게 기대되는 관리 수준입니다. 클러스터를 생성할 때 EC2 시작 유형을 지정하면 해당 클러스터를 구성하고 관리해야 할 책임은 사용자에게 있습니다. 하지만 Fargate 시작 유형을 사용하는 경우, 이를 관리할 책임은 Fargate에 있습니다.
컨테이너
컨테이너에는 컨테이너의 애플리케이션 또는 애플리케이션 구성 요소가 실행해야 할 모든 코드, 런타임, 도구 및 시스템 라이브러리가 들어 있습니다. 애플리케이션을 호스팅하기 위해 컨테이너 인스턴스를 시작하면 이 인스턴스는 클러스터와 연결된 컴퓨팅 인프라에서 실행됩니다.
컨테이너 이미지라는 읽기 전용 템플릿은 컨테이너를 시작하는 데 사용됩니다. 이미지를 사용하여 컨테이너를 실행하려면 먼저 컨테이너 이미지를 레지스트리(예: Amazon Elastic Container Registry(Amazon ECR) 또는 Docker Hub) 에 배포해야 합니다.
Dockerfile이라는 리소스를 사용하여 컨테이너 이미지를 정의합니다. Dockerfile은 이미지에 포함하려는 모든 구성 요소와 리소스를 자세히 설명하는 텍스트 파일입니다. Amazon ECS는 다른 곳에서.NET 애플리케이션용 컨테이너 이미지를 정의할 때 사용한 것과 동일한 Dockerfile을 변경하지 않고 사용합니다. docker build 명령을 사용하면 Dockerfile에 정의된 명령 및 설정을 컨테이너 이미지로 변환하여 레지스트리로 푸시하거나 Docker에서 로컬로 실행할 수 있습니다. 모듈 2에 자세히 설명된 AWS에서 제공하는 컨테이너 도구는 이미지 빌드 및 푸시를 대신 처리하는 경우가 많습니다.
태스크 정의
태스크 정의는 애플리케이션을 구성하는 컨테이너를 설명하는 데 사용되는 JSON 형식의 텍스트 파일입니다. 단일 태스크 정의로 최대 10개의 컨테이너를 설명할 수 있습니다.
태스크 정의는 애플리케이션 및 운영 체제 매개변수를 지정하는 애플리케이션 환경 청사진으로 간주할 수 있습니다. 예를 들어 어떤 네트워크 포트를 열어야 하는지, 다른 리소스 중에서 연결해야 하는 데이터 볼륨이 있는지 등을 확인할 수 있습니다.
Amazon ECS는 애플리케이션을 단일 태스크 정의로 제한하지 않습니다. 실제로 애플리케이션의 일부를 형성하는 구성 요소에 대한 관련 컨테이너를 하나의 태스크 정의로 결합하고 여러 태스크 정의를 사용하여 전체 애플리케이션을 설명하는 것이 좋습니다. 이를 통해 애플리케이션을 구성하는 다양한 논리적 구성 요소를 독립적으로 확장할 수 있습니다.
웹 UI 프런트엔드 계층, API 계층, 중간 계층 및 데이터베이스 구성 요소 계층으로 구성된 일반적인 n계층 웹 애플리케이션을 생각해 보세요. 아래 이미지는 이러한 구성 요소 계층을 서로 다른 태스크 정의로 그룹화하는 방법을 보여줍니다. 이를 통해 이를테면 사용량이 급증하는 경우 웹 UI 계층을 다른 구성 요소와는 상관없이 수평적으로 확장할 수 있으며 그 반대의 경우도 마찬가지입니다. 단일 태스크 정의에서 모든 계층을 정의하면 사용량이 증가하지 않은 계층을 포함하여 전체 애플리케이션이 부하 시 확장되어 확장 소요 시간이 늘어나고 (애플리케이션이 큰 경우) 재정 비용이 증가할 수 있습니다.
아래에서 태스크 정의의 예를 찾을 수 있습니다. Fargate 시작 유형에서 Linux 컨테이너를 사용하여 웹 서버를 설정합니다.
{
"containerDefinitions": [
{
"command": [
"/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' > /usr/local/apache2/htdocs/index.html && httpd-foreground\""
],
"entryPoint": [
"sh",
"-c"
],
"essential": true,
"image": "httpd:2.4",
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group" : "/ecs/fargate-task-definition",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
},
"name": "sample-fargate-app",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
]
}
],
"cpu": "256",
"executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
"family": "fargate-task-definition",
"memory": "512",
"networkMode": "awsvpc",
"runtimePlatform": {
"operatingSystemFamily": "LINUX"
},
"requiresCompatibilities": [
"FARGATE"
]
}태스크
Amazon ECS는 태스크 정의를 인스턴스화할 때 클러스터 내에서 실행되는 하나 이상의 태스크를 생성합니다. 태스크는 실행 중인 컨테이너 인스턴스입니다. 태스크 정의는 그 밖의 환경 설정 외에도 클러스터에서 실행할 태스크 또는 컨테이너 인스턴스의 수를 지정합니다.
태스크를 독립적으로 실행되도록 구성하여 태스크가 완료될 때 컨테이너가 중지되도록 하거나 하나의 서비스로서 태스크를 계속 실행할 수 있습니다. 서비스의 일부로 실행되는 경우, Amazon ECS는 지정된 수의 태스크가 동시에 실행되도록 유지하면서 장애가 발생한 컨테이너를 자동으로 교체합니다.
계속 실행할 필요가 없는 애플리케이션 코드에는 독립형 태스크를 사용하십시오. 코드는 태스크 내에서 한 번 실행된 후 종료되어 컨테이너 인스턴스를 종료합니다. 예를 들면 일부 데이터의 배치 처리가 이에 해당됩니다.
예약된 태스크
운영자의 개입 없이 정기적으로 실행해야 하는 애플리케이션 코드에 대해 예약된 태스크를 사용하여 태스크를 수동으로 시작할 수 있습니다. 예제 시나리오는 로그 검사, 백업 작업 또는 주기적인 ETL(추출-변환-로드) 작업을 수행하는 코드입니다.
서비스
Amazon ECS는 클러스터의 각 컨테이너 인스턴스에서 에이전트를 실행합니다. 이 에이전트는 직접 설치하거나 유지 관리할 필요가 없습니다. 에이전트는 실행 중인 태스크 및 컨테이너 인스턴스의 사용률에 관한 정보를 보고하여 Amazon ECS가 실패하거나 중지된 태스크를 감지할 수 있도록 합니다. 이 경우 Amazon ECS는 실패한 태스크를 새 인스턴스로 교체하여 서비스에 지정된 수의 태스크를 유지하므로 사용자가 직접 모니터링하고 조치를 취할 필요가 없습니다.
지속적으로 실행해야 하는 애플리케이션 코드용 서비스를 사용하세요. 예를 들면, 웹 사이트 프런트 엔드 또는 웹 API가 있습니다.
애플리케이션 데이터 유지
실행 중인 컨테이너 인스턴스에는 데이터를 저장할 수 있는 쓰기 가능한 계층이 있습니다. 하지만 쓰기 가능한 계층은 일시적인 것이며 사용자 작업으로 인해 또는 인스턴스가 비정상화되어 Amazon ECS에서 이를 대체하여 컨테이너 인스턴스가 종료되면 삭제됩니다. 따라서 쓰기 가능한 계층은 데이터베이스의 데이터와 같은 장기 데이터 저장에 적합하지 않습니다. 또한 쓰기 가능한 계층의 데이터는 개별 컨테이너 인스턴스에서 실행되는 코드에서만 액세스할 수 있으므로 여러 컨테이너 인스턴스에 걸친 애플리케이션에서 공유해야 하는 데이터에는 적합하지 않습니다.
애플리케이션 데이터를 컨테이너 인스턴스의 수명보다 긴 기간 동안 저장하거나 여러 컨테이너 인스턴스에서 공유할 수 있도록 AWS는 몇 가지 스토리지 서비스를 제공합니다. 이러한 스토리지 서비스는 데이터 스토리지를 컴퓨팅 인스턴스에서 분리합니다. 컴퓨팅 인스턴스에서 분리된 스토리지를 사용하면 애플리케이션이 실행되는 컨테이너 인스턴스보다 애플리케이션 데이터를 더 오래 사용할 수 있으며 여러 인스턴스에서 데이터를 공유할 수 있습니다.
컨테이너화된 .NET 애플리케이션에서 사용할 수 있는 스토리지 서비스는 애플리케이션이 Linux 컨테이너에서 실행되는지 아니면 Windows 컨테이너에서 실행되는지 여부에 따라 달라집니다.
Linux 컨테이너를 위한 영구 스토리지 옵션
현재 Linux 컨테이너는 Amazon ECS에서 실행되거나 AWS Fargate 기반의 Amazon ECS에서 실행되는 경우 .NET 애플리케이션을 위한 가장 광범위한 스토리지 서비스를 지원합니다. 스토리지 서비스의 선택은 애플리케이션이 데이터에 대한 공유 및 동시 액세스를 필요로 하는지 여부에 따라 달라집니다.
Amazon Elastic Block Store(Amazon EBS)
Amazon Elastic Block Store(Amazon EBS)는 블록 레벨 스토리지 볼륨을 제공하는 스토리지 서비스입니다. EBS 볼륨은 일반 드라이브 디바이스처럼 액세스할 수 있는 Linux 컨테이너에 마운트할 수 있는 스토리지를 애플리케이션에 제공합니다. Amazon EBS는 가용 영역 내에서 EBS 볼륨의 데이터를 자동으로 복제하므로 스토리지 볼륨에 장애가 발생할 경우 애플리케이션 안정성을 개선하는 데 도움이 되는 안정적인 스토리지 솔루션이 됩니다.
EBS 볼륨은 동적으로 크기를 조정할 수 있고 암호화를 지원하며 복사본을 만들기 위한 스냅샷도 지원합니다. 필요하다면 컨테이너에서 볼륨을 분리하고 다른 볼륨에 다시 연결할 수 있습니다. 애플리케이션의 성능 및 가격 요구 사항에 맞게 Amazon EBS는 다양한 볼륨 유형을 제공합니다.
EBS 볼륨은 리전 내 특정 가용 영역에서 생성됩니다. 그런 다음, 태스크 정의의 설정을 사용하여 동일한 영역에서 실행되는 컨테이너 인스턴스에 볼륨을 마운트할 수 있습니다. 다른 가용 영역의 동일한 데이터에 액세스하려면 볼륨의 스냅샷을 생성하고 이 스냅샷을 사용하여 동일한 리전 또는 다른 리전의 다른 위치에 새 볼륨을 생성하십시오. 단일 스냅샷으로 가용 영역 및 리전 전체에 걸쳐 많은 볼륨을 생성할 수 있습니다. 이는 고가용성이 필요한 애플리케이션에서 사용하며 서로 다른 가용 영역과 리전에 걸쳐 있는 여러 컨테이너 인스턴스에 배포한 읽기 전용 애플리케이션 데이터에 대해 고려해야 할 접근 방식입니다.
Amazon EBS는 애플리케이션이 수평적으로 확장(즉, 여러 컨테이너 인스턴스에서 실행)하므로 동시에 공유되지 않는 데이터에 대해 짧은 지연 시간 내에 신속하게 액세스해야 하는 애플리케이션에 고려할 수 있는 좋은 스토리지 솔루션입니다. 예를 들면, 단일 컨테이너 인스턴스에서 액세스하는 일반 파일 시스템 및 데이터베이스가 이에 해당됩니다.
Amazon EBS는 볼륨에 대한 동시 액세스를 지원하지 않습니다. 애플리케이션이 여러 컨테이너에 마운트된 단일 파일 시스템을 공유해야 하는 애플리케이션의 경우, Amazon Elastic File Service 또는 Amazon FSx에서 제공하는 파일 시스템 중 하나를 고려해 보십시오.
Amazon Elastic File System(Amazon EFS)
Amazon EFS는 스토리지 관리가 필요 없는 네트워크 파일 시스템(NFS)을 사용하여 액세스할 수 있는 확장 가능한 파일 시스템 서비스를 제공합니다. Amazon EFS를 통해 관리되는 파일 시스템은 읽기/쓰기 일관성과 파일 잠금을 유지하면서 여러 Linux 기반 컨테이너 인스턴스에 동시에 연결할 수 있습니다. 이를 통해 확장 애플리케이션을 호스팅하는 여러 컨테이너에서 읽기 및 쓰기 액세스를 위해 드라이브의 데이터를 공유할 수 있습니다. 또한 Amazon EFS 스토리지는 동적이어서 애플리케이션 스토리지 요구 사항이 변경되면 자동으로 용량을 확장(및 축소)합니다.
애플리케이션에서 사용하는 스토리지에 대해서만 비용을 지불하면 됩니다. 기본적으로 Amazon EFS에서 생성된 파일 시스템의 데이터는 한 리전의 여러 가용 영역에 저장되어 복원력과 안정성을 제공합니다. Amazon EFS에서는 이 모드를 일컬어 표준 스토리지 클래스라고 합니다. 애플리케이션에 전체 다중 AZ 스토리지가 필요하지 않은 경우, 그 대신 One Zone 스토리지 클래스를 사용하여 비용을 절감하세요. 또한 Standard-Infrequent Access 및 One Zone-Infrequent Access 스토리지 클래스는 애플리케이션이 비정기적으로 액세스하는 데이터를 호스팅하여 추가 비용을 절감하는 데 사용할 수도 있습니다.
Amazon EFS 파일 시스템은 웹 애플리케이션, 콘텐츠 관리 시스템, 사용자용 홈 폴더, 일반 파일 서버를 비롯한 광범위한 애플리케이션에 적합합니다. 파일 시스템은 인증, 권한 부여 및 암호화를 지원합니다. 액세스 제어는 표준 POSIX 권한을 사용합니다.
아래 예제 태스크 정의 스니펫은 태스크에 EFS 파일 시스템을 마운트하는 방법을 보여줍니다.
"containerDefinitions":[
{
"mountPoints": [
{
"containerPath": "/opt/my-app",
"sourceVolume": "Shared-EFS-Volume"
}
}
]
...
"volumes": [
{
"efsVolumeConfiguration": {
"fileSystemId": "fs-1234",
"transitEncryption": "DISABLED",
"rootDirectory": ""
},
"name": "Shared-EFS-Volume"
}
]
Amazon FSx for Lustre
Lustre는 기계 학습, 고성능 컴퓨팅(HPC), 비디오 처리, 금융 모델링의 성능 요구 사항을 해결하도록 설계된 오픈 소스 파일 시스템입니다. 이러한 솔루션을 처리하는 .NET 애플리케이션 또는 밀리초 미만의 지연 시간을 요하는 기타 시나리오의 경우, Amazon FSx for Lustre는 Linux 컨테이너용 영구 스토리지 계층을 제공할 수 있습니다.
참고: 이 글을 쓰는 시점에서 AWS Fargate에서 실행되는 태스크는 FSx for Lustre 파일 시스템을 지원하지 않습니다.
FSx for Lustre에서 생성된 파일 시스템은 POSIX와 호환됩니다. 즉, Linux에서 실행되는 .NET 애플리케이션에서 이미 사용하고 있는 것과 동일하면서도 친숙한 파일 액세스 제어를 계속 사용할 수 있습니다. FSx for Lustre에서 호스팅되는 파일 시스템은 읽기/쓰기 일관성과 파일 잠금도 제공합니다.
애플리케이션의 요구 사항에 따라 다양한 워크로드 요구 사항에 맞게 최적화된 솔리드 스테이트 드라이브(SSD) 및 하드 드라이브(HDD) 스토리지를 선택할 수 있습니다. SSD 스토리지는 지연 시간에 민감하고 대체로 소규모 랜덤 액세스 파일 작업이 많은 IOPS 집약적 애플리케이션에 적합합니다. HDD 스토리지 유형은 일반적으로 크고 순차적인 파일 작업을 포함하는 높은 처리량 요구 사항이 있는 애플리케이션에 적합합니다. HDD 스토리지를 사용하면 HDD 스토리지의 20% 크기로 읽기 전용 SSD 캐시를 추가하여 밀리초 미만의 지연 시간과 더 높은 IOPS를 허용하여 자주 액세스하는 파일의 성능을 개선할 수도 있습니다.
FSx for Lustre의 파일 시스템은 전체 읽기/쓰기 액세스 권한이 있는 Amazon S3 버킷에도 연결할 수 있습니다. 이를 통해 .NET 애플리케이션은 S3 버킷의 객체를 마치 파일 시스템에 이미 있는 객체인 것처럼 처리할 수 있습니다. 이는 S3에 이미 있는 대규모 클라우드 기반 데이터 세트의 데이터를 처리하도록 구축된 애플리케이션을 위한 옵션이며, 액세스하고 업데이트하기 전에 해당 데이터를 파일 시스템에 복사할 필요가 없습니다.
lustre-client 패키지를 사용하여 Docker 컨테이너의 명령을 사용하여 Lustre 파일 시스템을 마운트할 수도 있습니다. 이렇게 하면 컨테이너 내에 파일 시스템을 동적으로 마운트할 수 있습니다.
Windows 컨테이너를 위한 영구 스토리지 옵션
.NET 및 .NET Framework 애플리케이션을 실행하는 Windows 컨테이너의 경우, Amazon FSx for Windows File Server에서 제공하는 파일 스토리지를 사용하여 태스크에서 실행되는 하나 이상의 컨테이너에서 데이터 지속성 및 데이터 공유를 수행할 수 있습니다.
Amazon FSx for Windows File Server
FSx for Windows File Server는 SMB를 통한 표준 Windows 파일 공유로 액세스할 수 있는 실제 Windows File Server 인스턴스를 사용하여 애플리케이션 데이터를 저장하고 제공합니다. 표준 Windows 파일 공유를 사용하면 섀도우 복사본, 사용자 할당량, 액세스 제어 목록(ACL)을 사용한 최종 사용자 파일 복원과 같이 Windows File Server 관리자에게 이미 익숙한 기능 및 관리 도구를 사용할 수 있습니다. 또한 SMB를 사용하면 Linux 컨테이너에서 FSx for Windows File Server에 연결할 수 있습니다.
FSx for Windows File Server의 파일 시스템은 데이터 중복 제거 및 압축을 사용하여 애플리케이션의 스토리지 비용을 절감하는 데 도움이 될 수 있습니다. 추가 기능으로는 데이터 암호화, 감사 가능한 파일 액세스 및 예약된 자동 백업이 있습니다. 파일 시스템 공유에 대한 액세스는 온프레미스 Microsoft Active Directory(AD) 또는 AWS 관리형 AD와의 통합을 통해 제어할 수 있습니다.
FSx for Windows File Server는 온프레미스 Windows 기반 파일 서버를 클라우드로 마이그레이션하여 컨테이너화된 .NET/.NET 프레임워크 애플리케이션과 함께 작동하는 데 적합합니다. 또한 하이브리드 클라우드 및 온프레미스 데이터 스토어(Amazon FSx File Gateway 사용)에 액세스해야 하는 .NET 및 .NET Framework 애플리케이션과 함께 사용하기에도 적합합니다. SQL Server를 사용하는 애플리케이션의 경우, FSx for Windows File Server를 사용하면 SQL Server Enterprise 라이선스 없이도 이러한 데이터베이스 워크로드를 실행할 수 있습니다.
아래 예제 태스크 정의 스니펫은 하나의 태스크에 대해 FSx for Windows File Server에서 생성한 파일 시스템을 마운트하는 방법을 보여줍니다.
{
"containerDefinitions": [
{
"entryPoint": [
"powershell",
"-Command"
],
"portMappings": [],
"command": [...' -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
}
]
},
...
],
"family": "fsx-windows",
"executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
"volumes": [
{
"name": "fsx-windows-vol",
"fsxWindowsFileServerVolumeConfiguration": {
"fileSystemId": "fs-0eeb5730b2EXAMPLE",
"authorizationConfig": {
"domain": "example.com",
"credentialsParameter": "arn:arn-1234"
},
"rootDirectory": "share"
}
}
]
}기타 영구 스토리지 옵션
AWS는 ECS 태스크의 영구 스토리지 요구 사항을 처리하기 위한 몇 가지 다른 특수 파일 시스템 서비스를 제공합니다. 이 과정에서는 이러한 파일 시스템 및 서비스를 다루지 않습니다. 그 대신 아래의 제품 세부 정보를 참조하시기 바랍니다.
- Amazon FSx for OpenZFS는 OpenZFS 파일 시스템을 사용하여 완전 관리형 파일 스토리지를 제공합니다. OpenZFS는 고성능 스토리지는 물론, 인스턴트 데이터 스냅샷, 암호화, 복제 등의 제반 기능도 필요한 워크로드를 위한 오픈 소스 파일 시스템입니다. OpenZFS 스토리지는 NFS를 사용하여 액세스할 수 있으며 Linux 파일 서버를 클라우드로 쉽게 마이그레이션하여 .NET 애플리케이션 컨테이너와 함께 사용할 수 있습니다.
- Amazon FSx for NetApp ONTAP은 데이터 액세스 및 관리 기능을 제공하는 또 다른 완전 관리형 파일 스토리지 서비스입니다. 애플리케이션은 NFS, SMB 및 iSCSI 프로토콜을 사용하여 NetApp ONTAP 파일 시스템에 액세스합니다.
AWS Fargate 소개
클라우드 인프라를 프로비저닝하고 관리하는 서버리스 접근 방식은 많은 개발자와 조직의 관심을 끌기에 충분합니다. 서버리스를 사용하면 AWS가 애플리케이션 호스팅을 위한 인프라 리소스의 차별화되지 않은 프로비저닝 및 관리를 처리합니다. 이를 통해 개발자는 각자가 개발 중인 애플리케이션에 집중할 수 있습니다. 애플리케이션을 실행하고 확장하기 위한 요구 사항을 지정합니다. 그 방법은 AWS의 책임에 속합니다.
AWS Fargate는 클라우드에서 컨테이너를 호스팅하기 위한 서버리스 접근 방식입니다. Amazon ECS 또는 Amazon EKS 기반 애플리케이션을 위한 Fargate를 선택하면 컨테이너 기반 애플리케이션을 호스팅하기 위해 Amazon EC2 인스턴스의 서버 또는 클러스터를 더 이상 관리할 필요가 없습니다. Fargate는 필요에 따라 컨테이너 인프라의 프로비저닝, 구성, 확장 및 축소를 처리합니다.
개발자는 Dockerfile을 사용하여 컨테이너 이미지의 빌드를 정의하고 이러한 빌드된 이미지를 Amazon ECR 또는 Docker Hub에 배포하는 것에 관심이 있습니다. 애플리케이션의 런타임 인프라의 경우 운영 체제, CPU 및 메모리, 네트워킹, IAM 정책을 지정하기만 하면 됩니다. 그런 다음, Fargate는 해당 요구 사항에 맞는 컨테이너 인프라를 프로비저닝하고 확장합니다. Fargate는 .NET 및 .NET Framework 애플리케이션을 서비스, 태스크 및 예약된 태스크로 실행하는 것을 지원합니다.
AWS Fargate 기반의 Amazon ECS를 사용하려는.NET 개발자는 Windows Server 또는 Linux 환경 중에서 선택할 수 있습니다. .NET 프레임워크 애플리케이션은 Windows Server 컨테이너를 사용해야 합니다. 그러나 .NET으로 구축된 애플리케이션은 Windows Server 또는 Linux 환경 중에서 한 가지를 선택할 수 있습니다.
참고: Windows Server와 Linux 컨테이너를 함께 사용하는 애플리케이션의 경우, 환경마다 별도의 태스크가 필요합니다.
AWS Fargate에서 Linux 컨테이너 기반의 .NET
.NET 기반 애플리케이션(.NET 6 이상)은 Fargate에서 프로비저닝하고 유지 관리하는 컨테이너 인프라를 사용할 수 있습니다. Fargate는 X86_64 또는 ARM64 아키텍처에서 사용할 수 있는 Amazon Linux 2를 사용합니다. 태스크 정의는 필요한 아키텍처를 지정합니다.
참고: Fargate에서 이전 .NET Core 3.1 및 .NET 5 기반 애플리케이션을 실행할 수도 있습니다. 그러나 이 두 버전 모두 Microsoft의 지원이 중단되었거나 곧 지원이 중단될 예정입니다. .NET 5는 장기 지원(LTS) 릴리스가 아니었으며 현재 지원이 중단되었습니다. 이 글을 쓰는 시점에서 .NET Core 3.1은 유지 관리 지원 단계에 있습니다. 즉, 지원 종료 후 경과한 시간이 6개월 이내이며 보안 문제에 대한 패치만 받고 있습니다.
AWS Fargate에서 Windows 컨테이너 기반의 .NET
Fargate 기반의 Windows 컨테이너는 .NET 프레임워크와 .NET 애플리케이션을 모두 실행할 수 있습니다. Fargate는 현재 애플리케이션용 Windows Server의 두 가지 버전 즉, Windows Server 2019 Full과 Windows Server 2019 Core를 지원합니다. 어떤 버전을 사용하든 AWS는 Windows 운영 체제 라이선스를 대신 관리합니다.
참고: Windows 서버의 모든 기능과 일부 AWS 기능을 AWS Fargate 기반의 Windows 컨테이너에서 사용할 수 있는 것은 아닙니다. 기능 제한 및 고려 사항에 관한 최신 정보는 서비스 설명서를 참조하십시오. 지원되지 않는 기능의 몇 가지 예를 열거하면 아래와 같습니다.
- 그룹 관리형 서비스 계정(gMSA).
- Amazon FSx 파일 시스템(FSx for Windows File Server 제외).
- 구성 가능한 임시 스토리지.
- Amazon Elastic File Store(Amazon EFS) 볼륨.
- 이미지 볼륨.
- 태스크를 위한 App Mesh 서비스 및 프록시 통합.
Amazon ECS와 AWS Fargate 기반 Amazon ECS 중에서 선택
.NET 애플리케이션을 호스팅하기 위해 Amazon ECS를 선택할지 아니면 AWS Fargate 기반의 Amazon ECS를 선택할지는 다음 절차에 따라 결정하세요.
- 클러스터 및 기타 인프라를 프로비저닝, 관리 및 확장하여 태스크를 호스팅하고 싶거나 이 인프라를 자체 관리해야 하는 경우 Amazon ECS를 선택하세요.
- 컨테이너식 애플리케이션을 지원하는 인프라를 AWS에서 프로비저닝, 관리 및 확장하도록 허용하려면 AWS Fargate를 선택하세요. AWS Fargate는 .NET Framework 또는 .NET 애플리케이션용 Windows 컨테이너를 지원하거나 .NET 애플리케이션용 Linux 컨테이너를 지원합니다.
- Amazon FSx for Windows File Server를 사용하여 컨테이너에 추가적인 영구 스토리지 볼륨을 제공하는 .NET 애플리케이션의 경우, Amazon ECS를 선택하세요. 이 글을 쓰는 시점에서 AWS Fargate는 이 스토리지 옵션을 지원하지 않습니다.
컨테이너 이미지와 Amazon Elastic Container Registry(Amazon ECR)
Amazon ECR은 Docker 및 Open Container Initiative(OCI) 컨테이너 이미지를 위한 안전하면서도 확장 가능한 완전 관리형 컨테이너 레지스트리입니다. 이 기능을 사용하면 Amazon ECS를 사용하든 AWS Fargate 기반의 Amazon ECS를 사용하든 관계없이 컨테이너 이미지를 쉽게 저장, 관리 및 배포할 수 있습니다. Amazon ECR은 완전 관리형 서비스이므로 레지스트리를 지원하는 데 필요한 인프라를 제공하고 관리하며 확장합니다.
참고: Amazon ECS와 AWS Fargate에서 작업할 때 Docker Hub를 사용하여 컨테이너 이미지를 저장할 수도 있습니다.
Amazon ECR은 각 AWS 리전의 기본 프라이빗 레지스트리를 모든 계정에 제공합니다. 이 레지스트리는 컨테이너 이미지를 보관하는 하나 이상의 프라이빗 리포지토리를 관리하는 데 사용됩니다. 이미지를 리포지토리로 푸시하거나 리포지토리에서 이미지를 가져오기 전에 클라이언트는 레지스트리에 대한 액세스를 인증하는 데 사용되는 권한 부여 토큰을 받아야 합니다. 이미지가 리포지토리로 푸시되면 Amazon ECR은 자동화된 취약성 검사를 선택적 기능으로 제공합니다. 또한 리포지토리는 AWS Key Management Service(KMS)를 통한 암호화를 지원하며, AWS에서 제공하는 키 또는 사용자 지정의 사용자 관리 키를 선택하여 사용할 수 있습니다.
액세스를 제어하기 위해 Amazon ECR은 AWS IAM과 통합합니다. 세분화된 리소스 기반 권한을 통해 컨테이너 이미지 및 리포지토리에 액세스할 수 있는 사용자(또는 대상)를 제어할 수 있습니다. Amazon ECR에서 제공하는 관리형 정책을 사용하여 다양한 액세스 수준을 제어할 수도 있습니다.
레지스트리별 설정을 사용하면 리전 및 기타 계정 간에 리포지토리를 복제할 수 있습니다. 추가적인 이미지 수명 주기 정책을 구성할 수도 있습니다. 예를 들어, 리포지토리에서 사용하지 않은 이미지를 정리하는 결과를 초래하는 수명 주기 정책을 구성(및 테스트)할 수 있습니다.
Amazon ECR에서는 퍼블릭 및 프라이빗 레지스트리를 모두 사용할 수 있습니다. 다른 퍼블릭 레지스트리에서 가져온 컨테이너 이미지용 풀스루 캐시도 사용할 수 있습니다. 풀스루 캐시는 업스트림 레지스트리 및 리포지토리의 중단으로부터 빌드 및 배포를 보호하고 종속성에 대한 규정 준수 감사를 받는 개발 팀을 지원합니다.
아래 기능을 검토하여 Amazon ECR의 퍼블릭 및 프라이빗 레지스트리는 물론, 이에 포함된 리포지토리, 풀스루 캐시 리포지토리에 대해 자세히 알아보세요.
프라이빗 레지스트리 및 리포지토리
AWS는 각 AWS 리전의 단일 프라이빗 레지스트리를 계정마다 제공하며, 각 레지스트리는 0개 이상의 리포지토리를 포함할 수 있습니다(이미지를 보관하려면 적어도 한 개 이상의 리포지토리가 필요함). 한 계정의 각 리전 레지스트리는 https://aws_account_id.dkr.ecr.region.amazonaws.com 형식의 URL(예: https://123456789012.dkr.ecr.us-west-2.amazonaws.com)을 사용하여 액세스할 수 있습니다.
프라이빗 레지스트리의 리포지토리에는 Docker 및 Open Container Initiative(OCI) 이미지와 아티팩트가 모두 들어 있습니다. 이미지와 아티팩트에 필요한 만큼의 리포지토리를 적게 또는 많이 사용할 수 있습니다. 예를 들어, 하나의 리포지토리를 사용하여 개발 단계의 이미지를 보관하고, 다른 리포지토리를 사용하여 테스트 단계의 이미지를 보관하며, 또 다른 리포지토리를 사용하여 프로덕션 단계에 릴리스된 이미지를 보관할 수 있습니다.
리포지토리 이미지 내의 이미지 이름은 고유한 이름이어야 하며 다만 Amazon ECR 리포지토리는 네임스페이스도 지원합니다. 이를 통해 다양한 이미지를 식별하는 이미지 이름을 단일 리포지토리 내에 있는 여러 환경 단계 또는 팀에서 재사용할 수 있습니다.
계정에는 기본적으로 프라이빗 레지스트리의 리포지토리에 대한 읽기 및 쓰기 액세스 권한이 있습니다. 하지만 IAM 보안 주체와 이 보안 주체의 범위 내에서 실행되는 도구들은 Amazon ECR의 API를 사용하고 리포지토리에 대해 Docker CLI와 같은 도구를 사용하여 pull/push 명령을 실행할 수 있는 권한을 얻어야 합니다. 이 과정의 모듈 2에서 자세히 설명하는 도구들 중 상당수는 사용자를 대신하여 이 인증 프로세스를 처리합니다.
프라이빗 리포지토리는 AWS Management Console의 Amazon ECR 대시보드를 사용하거나 AWS Toolkit for Visual Studio의 AWS 탐색기 보기를 통해 생성할 수 있으며, 또는 명령줄에서 AWS CLI 또는 AWS Tools for PowerShell을 사용하여 생성할 수 있습니다. 아래 스크린샷은 Visual Studio 내에서 프라이빗 리포지토리를 생성하는 방법을 보여줍니다. AWS 탐색기 보기에서 Amazon Elastic Container Service 항목을 확장하고 리포지토리 항목의 컨텍스트 메뉴에서 리포지토리 생성을 선택하면 됩니다.
Visual Studio용 AWS Toolkit은 ECR 퍼블릭 레지스트리 작업을 지원하지 않으며 프라이빗 레지스트리의 새 리포지토리에 대한 자동 스캔 및 리포지토리 암호화와 같은 기능을 활성화하는 작업을 지원하지 않습니다. 이러한 기능이 필요하다면 AWS Management Console이나 명령줄 도구(예: AWS CLI 및 AWS Tools for PowerShell) 를 사용하여 리포지토리를 생성하세요.
퍼블릭 레지스트리 및 리포지토리
Amazon ECR 퍼블릭 레지스트리 및 리포지토리를 사용하면 사용자가 게시한 이미지를 누구든지 가져올 수 있습니다. 각 계정에는 여러 퍼블릭 리포지토리를 포함할 수 있는 퍼블릭 레지스트리가 하나씩 제공됩니다. 프라이빗 리포지토리와 마찬가지로 퍼블릭 리포지토리에는 Docker 및 Open Container Initiative(OCI) 이미지와 아티팩트가 저장됩니다.
퍼블릭 레지스트리의 리포지토리는 Amazon ECR 퍼블릭 갤러리에 나열되어 있습니다. 이를 통해 커뮤니티는 퍼블릭 이미지를 찾고 가져올 수 있습니다. 퍼블릭 레지스트리를 소유한 AWS 계정은 이에 포함된 리포지토리에 대한 전체 읽기-쓰기 액세스 권한이 있습니다. 리포지토리에 액세스하는 IAM 보안 주체는 토큰으로 제공된 권한을 얻어야 하며, 프라이빗 리포지토리와 마찬가지로 해당 토큰을 사용하여 이미지를 푸시하도록 인증해야 합니다. 하지만 누구나 인증 여부에 관계없이 퍼블릭 리포지토리에서 이미지를 가져올 수 있습니다.
갤러리의 리포지토리는 https://gallery.ecr.aws/registry_alias/repository_name 형식의 URL을 사용하여 액세스할 수 있습니다. registry_alias는 첫 번째 퍼블릭 리포지토리가 생성될 때 생성되며 변경할 수 있습니다. 퍼블릭 리포지토리에서 이미지를 가져오는 URI의 형식은 public.ecr.aws/registry_alias/repository_name:image_tag입니다.
이미지를 퍼블릭 리포지토리로 푸시하려면 퍼블릭 레지스트리에 대한 권한 및 인증이 필요합니다. 권한은 레지스트리에 인증할 때 제공해야 하는 토큰으로 제공됩니다. 사전 인증을 사용하는지 여부와 관계없이 퍼블릭 리포지토리에서 이미지를 가져올 수 있습니다.
풀스루 캐시 리포지토리
풀스루 캐시는 업스트림 퍼블릭 레지스트리의 캐시 이미지를 Amazon ECR의 프라이빗 레지스트리로 가져옵니다. 현재 Amazon ECR은 Amazon ECR Public과 Quay를 업스트림 레지스트리로 지원합니다. Amazon ECR은 업스트림에서 새 이미지 버전을 확인하고 새 버전이 나오면 24시간마다 한 번씩 캐시를 업데이트합니다. 풀스루 캐시는 가동 중단이나 업스트림 레지스트리에 영향을 미치는 기타 문제로부터 빌드 및 배포 프로세스를 보호하는 데 도움이 될 수 있습니다.
캐시 리포지토리는 구성된 업스트림 레지스트리에서 이미지를 맨 처음 가져올 때 자동으로 생성됩니다. 이미지 가져오기는 AWS IP 주소를 사용하며 업스트림 레지스트리의 가져오기 속도 할당k량에 영향을 받지 않습니다. 캐시 리포지토리로 이미지 가져오기는 규칙을 사용하여 구성됩니다. 프라이빗 레지스트리에 대해 최대 10개의 풀스루 캐시 규칙을 구성할 수 있습니다.
아래 이미지는 두 가지 예제 규칙을 보여줍니다. 하나는 Amazon ECR Public의 이미지를 캐시하는 규칙이고 다른 하나는 Quay의 이미지를 캐시하기 위한 규칙입니다. 이 구성에서는 Amazon ECR Public에서 이미지를 맨 처음 가져올 때 업스트림 리포지토리의 이름을 사용하여 ecr-public 네임스페이스 아래에 리포지토리가 자동으로 생성되며, Quay에서 가져온 이미지의 경우에도 마찬가지입니다.
Visual Studio용 AWS Toolkit은 ECR 퍼블릭 레지스트리 작업을 지원하지 않으며 프라이빗 레지스트리의 새 리포지토리에 대한 자동 스캔 및 리포지토리 암호화와 같은 기능을 활성화하는 작업을 지원하지 않습니다. 이러한 기능이 필요하다면 AWS Management Console이나 명령줄 도구(예: AWS CLI 및 AWS Tools for PowerShell) 를 사용하여 리포지토리를 생성하세요.
업스트림 레지스트리에서 풀스루 캐시로 가져온 이미지는 복제 및 자동화된 취약성 검사와 같이 프라이빗 리포지토리에서 사용할 수 있는 추가 Amazon ECR 기능을 지원합니다.
이미지 푸시 및 가져오기
계정에는 기본적으로 프라이빗 및 퍼블릭 레지스트리의 리포지토리에 대한 읽기 및 쓰기 액세스 권한이 있습니다. 하지만 해당 계정 내 IAM 보안 주체와 이 IAM 보안 주체의 범위 내에서 실행되는 도구에는 푸시/풀 명령 및 Amazon ECR의 API를 사용할 수 있는 권한이 있어야 합니다. 이러한 권한은 권한 부여 토큰으로 제공되며, Amazon ECR 프라이빗 또는 퍼블릭 레지스트리에 대한 액세스를 인증할 때 제공해야 합니다.
참고: IAM 보안 주체는 프라이빗 리포지토리로 이미지를 푸시하고 가져오거나 퍼블릭 리포지토리로 이미지를 푸시할 수 있는 권한이 필요하지만 누구든지 인증 없이 한 계정의 퍼블릭 레지스트리에 있는 퍼블릭 리포지토리에서 이미지를 가져올 수 있는데, 이를 일컬어 ‘인증되지 않은 가져오기’라고 합니다.
명령줄에서 리포지토리 액세스 권한 부여
이 과정의 모듈 2에서 설명하는 대부분의 AWS 도구들은 토큰을 가져와 이를 사용하여 프라이빗 레지스트리를 인증하는 작업을 처리하지만, 필요하다면 동일한 단계를 직접 수행할 수 있습니다(예: CI/CD 파이프라인에서 레지스트리에 액세스할 때). 또는 GitHub에서 Amazon ECR 보안 인증 도우미 유틸리티를 사용할 수 있습니다. 자세한 내용은 Amazon ECR Docker 보안 인증 도우미를 참조하십시오(이 과정에서는 도우미 유틸리티 사용에 관한 자세한 내용은 다루지 않음).
AWS CLI와 AWS Tools for PowerShell에는 권한 부여 토큰을 쉽게 가져올 수 있는 명령이 포함되어 있습니다. 이 명령은 권한 부여 토큰을 Docker 클라이언트와 같은 도구와 함께 사용하여 이미지를 푸시하고 가져옵니다. 두 명령 모두 서비스의 출력을 처리하고 필요한 토큰을 내보냅니다. 명령줄을 사용하는 것이 적합하지 않은 시나리오나 사용자 지정 도구의 경우, Amazon ECR API 호출 GetAuthorizationToken을 사용할 수 있습니다.
참고: 권한 부여 토큰의 권한은 이 토큰을 요청하는 IAM 보안 주체에게 제공된 권한을 초과하지 않습니다. 토큰은 12시간 동안 유효합니다.
AWS CLI를 사용하여 Amazon ECR 레지스트리로 Docker를 인증하려면 get-login-password 명령을 사용하고 출력을 docker login으로 연결하여 AWS를 사용자 이름으로 지정하고 레지스트리 URL을 다음과 같이 지정합니다.
aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com
AWS Tools for PowerShell을 사용하여 Docker 클라이언트를 인증하려면 Get-ECRLoginCommand(AWS.Tools.ECR 모듈 또는 레거시 AWSPowerShell 및 AWSPowerShell.NetCore 모듈에서 사용 가능)를 사용하십시오. 출력 객체의 Password 속성을 docker login 명령에 연결하여 AWS를 사용자 이름으로 지정하고 레지스트리 URL을 다음과 같이 지정합니다.
(Get-ECRLoginCommand -Region region).Password | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com
Docker 클라이언트가 승인되면 레지스트리의 리포지토리로 이미지를 푸시하거나 이 리포지토리에서 이미지를 가져올 수 있습니다. 각 리전의 레지스트리에는 별도의 권한 부여 토큰이 필요합니다.
이미지 푸시
이미지를 프라이빗 리포지토리와 퍼블릭 리포지토리로 푸시하려면 IAM 권한이 필요합니다. 가장 좋은 방법은 IAM 보안 주체의 권한 범위를 특정 리포지토리로 좁히는 것입니다. 아래의 예제 정책은 보안 주체가 특정 리포지토리로 범위가 지정된 이미지를 푸시하는 데 필요한 Amazon ECR API 작업(“작업”)을 보여줍니다. 리포지토리를 지정하면 Amazon 리소스 이름(ARN)을 사용하여 리포지토리를 식별합니다. 단, (하나의 배열 요소에) 복수의 리포지토리를 지정하거나 와일드카드(*)를 사용하여 모든 리포지토리로 범위를 넓힐 수 있습니다.
아래의 정책을 사용하려면 111122223333을 AWS 계정 ID로 바꾸고 리전을 리포지토리가 있는 리전으로 바꾼 후 repository-name을 설정하십시오.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:CompleteLayerUpload",
"ecr:GetAuthorizationToken",
"ecr:UploadLayerPart",
"ecr:InitiateLayerUpload",
"ecr:BatchCheckLayerAvailability",
"ecr:PutImage"
],
"Resource":
"arn:aws:ecr:region:111122223333:repository/repository-name"
}
]
}위와 비슷한 IAM 정책을 적용한 상태에서 레지스트리에 대한 인증을 받으면 Docker CLI 또는 기타 도구를 사용하여 이미지를 푸시할 수 있습니다. 이미지를 리포지토리로 푸시하기 전에 레지스트리, 리포지토리 및 선택적 이미지 태그 이름으로 태그를 지정해야 합니다(이미지 태그 이름을 생략하면 최신 이미지로 간주됨). 다음 예는 Amazon ECR로 푸시하기 전에 로컬 이미지에 태그를 지정하는 태그 형식 및 명령을 보여줍니다.
111122223333을 AWS 계정 ID로 바꾸고, 리전은 리포지토리가 있는 리전의 식별자(us-east-1, us-west-2 등)로 바꾸며, repository-name은 리포지토리의 실제 이름으로 바꾸십시오.
docker tag ab12345ef 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag
마지막으로 이미지를 다음과 같이 푸시합니다.
docker push 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag
이미지 가져오기
이미지를 푸시할 때 사용한 것과 동일한 태깅 형식을 사용하여 이미지를 식별하면서 다음과 같이 이미지를 가져옵니다.
docker pull 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag
프라이빗 레지스트리에 있는 리포지토리의 경우, 이미지를 가져오기 전에 앞서 설명한 것처럼 레지스트리로 클라이언트를 인증해야 합니다. 퍼블릭 레지스트리의 경우, 인증을 사용하는지 여부에 관계없이 이미지를 가져올 수 있습니다.
지식 확인
Amazon ECS와 AWS Fargate를 소개하는 모듈 1을 완료했습니다. 다음 테스트를 통해 지금까지 배운 내용을 확인할 수 있습니다.
질문 1: Amazon Elastic Container Registry(ECR)란 무엇인가요?
a. 컨테이너 이미지를 저장하기 위한 레지스트리
b. 실행 중인 컨테이너의 레지스트리
c. 실행 중인 태스크의 레지스트리
d. 컨테이너에 매핑된 스토리지 볼륨의 레지스트리
질문 2: Amazon ECS에서 실행되는 Windows/Linux 컨테이너에 대한 영구 스토리지 옵션은 동일한가요?
a. 참
b. 거짓
질문 3: ECS와 관련하여 클러스터는 무엇인가요?
a. 실행 중인 컨테이너의 인스턴스
b. 실행할 컨테이너의 정의
c. 애플리케이션 구성 요소에 관한 정의
d. 컴퓨팅 리소스의 논리적 그룹
답변: 1-a, 2-b, 3-d
결론
이 모듈에서는 먼저 컨테이너에 대해 알아봤는데요. 컨테이너와 가상 머신의 차이점은 물론, Docker Linux 컨테이너와 Windows 컨테이너의 차이점에 대해서도 알아보았습니다. 컨테이너는 가볍고 표준화되어 있으며 휴대가 가능하고 이동이 간편하며 배포 시간을 단축하고 비용을 절감할 수 있습니다. AWS의 컨테이너는 안전하고 안정적이며 다양한 컨테이너 서비스를 통해 지원되며 AWS와 긴밀하게 통합됩니다.
그 다음으로는 서버에 대해 고민할 필요 없이 애플리케이션을 구축할 수 있는 서버리스 기술에 대해 배웠습니다. 제반 이점으로는 운영 오버헤드 제거, 자동 조정, 비용 절감, 다른 AWS 서비스와의 기본적인 통합을 통한 애플리케이션 구축 용이 등이 있습니다. 사용 사례로는 웹 애플리케이션, 데이터 처리, 배치 처리, 이벤트 수집이 있습니다.
컨테이너용 AWS 컴퓨팅 서비스와 컴퓨팅 서비스 선택 방법에 대해 알아보았습니다. AWS App Runner는 컨테이너 호스팅을 위한 완전 관리형 서버리스 서비스라는 것을 알게 되었습니다.