Express Mode 외부에서 리소스 업데이트 - Amazon Elastic Container Service
공동 책임 모델 이해Express Mode 서비스에서 Amazon ECS 기능을 활용하기 전에 작업을 수행해야 하나요?Express Mode 외부 업데이트 예제

Express Mode 외부에서 리소스 업데이트

Express Mode는 사용자를 대신해 AWS 리소스를 자동으로 프로비저닝하고 관리하여 배포를 단순화하지만, 책임 모델을 이해하는 것이 중요합니다. Express Mode는 Amazon ECS 서비스, 로드 밸런서 및 오토 스케일링 정책과 같은 리소스를 생성하고 구성하는 동안 모든 리소스는 AWS 계정에 남아 있으며 직접 관리를 위해 해당 리소스에 완전히 액세스할 수 있습니다. AWS 콘솔, AWS CLI 또는 API를 사용하여 Express Mode 외부에서 이러한 리소스를 수정할 수 있지만 수정 시 Express Mode의 서비스 관리 기능에 영향을 미칠 수 있습니다. 이 섹션에서는 Express Mode가 관리하는 리소스, Express Mode 외부에서 안전하게 변경하는 방법, 작업을 수행할 때 상황에 대해 설명합니다.

공동 책임 모델 이해

Express Mode의 책임 경계는 API 사용량에 의해 정의됩니다. Express Mode API는 여러 AWS 서비스에서 조정된 업데이트를 통해 사용자를 대신하여 리소스를 관리합니다. 표준 AWS 서비스 API를 사용하면 개별 리소스를 직접 제어할 수 있습니다. 그러면 Express Mode가 구성을 위해 제공하는 파라미터 세트를 넘어 모든 리소스의 모든 파라미터를 제어할 수 있습니다. 두 API 세트 모두 계정의 동일한 기본 인프라에서 작동하며, 두 세트 모두 사용자가 요청한 작업을 실행합니다. AWS는 사용자가 요청한 작업을 수행할 책임이 있습니다. Express Mode는 직접 API를 사용하는 리소스 수정이 Express Mode 구성과 충돌하는지 여부를 검증하지 않으며 서비스 기능을 방해할 수 있는 변경을 방지하지 않습니다. 또한 사용자가 리소스를 변경할 수 있으며 이러한 변경 사항은 유지됩니다. Express Mode 업데이트의 일부로 요청되지 않는 한 Express Mode는 변경 사항을 덮어쓰지 않습니다. 직접 API를 사용하는 수정이 Express Mode의 구성과 상호 작용하는 방식을 이해하고 발생할 수 있는 충돌이나 서비스 문제를 해결해야 합니다.

Express Mode가 설정하는 기본값과 해당 기본 모드가 오케스트레이션하는 리소스에 대한 자세한 내용은 Resources created by Amazon ECS Express Mode services를 참조하세요.

Express Mode 서비스에서 Amazon ECS 기능을 활용하기 전에 작업을 수행해야 하나요?

아니요. Express Mode에는 졸업 경로나 긴급 조치가 없습니다. Express Mode 서비스에서는 전체 Amazon ECS 기능 세트를 항상 사용할 수 있습니다. 서비스에서 더 이상 Express Mode 업데이트를 수행하지 않으려면 몇 가지 옵션이 있습니다. 리소스에서 관리형 태그를 제거하면 Amazon ECS는 더 이상 해당 리소스를 Express Mode 서비스로 식별하고 운영할 수 없습니다. 또는 IAM을 사용하여 사용자 권한을 Express Mode API로 제한할 수 있습니다.

Express Mode 외부 업데이트 예제

Express Mode 서비스에 사이드카 추가

서비스에 사이드카 컨테이너를 추가할 수 있습니다. 이 예제에서는 Fluent Bit 로깅 사이드카를 추가하는 방법을 보여줍니다.

  1. https://console.aws.amazon.com/ecs/v2에서 콘솔을 엽니다.

  2. 탐색 창에서 클러스터를 선택합니다.

  3. Express Mode 서비스가 있는 클러스터를 선택하고 서비스 패널에서 선택하세요.

  4. 리소스 탭으로 이동하고 태스크 정의를 선택하세요.

  5. JSON 탭을 선택한 다음 새 개정 생성이라는 상단 버튼에서 아래쪽 화살표를 선택하세요. 여기에서 JSON을 사용하여 새 개정 생성이라는 작업을 찾을 수 있습니다.

  6. 기본 컨테이너 정의 전후에 사이드카 컨테이너를 추가하세요. 자세한 내용은 Amazon ECS 태스크 정의 예제: FireLens로 로그 라우팅을 참조하세요.

  7. 이 예제와 같이 로깅 사이드카가 있는 경우 기본 컨테이너에서 logDriver를 변경해야 합니다.

    
"logConfiguration": {
    "logDriver": "awsfirelens"
}

  8. Express Mode 서비스의 기본 설정을 가정하여 기본 컨테이너 memoryReservation을 1,998, Fluent Bit 컨테이너 memoryReservation을 50으로 설정하세요. 그러면 두 컨테이너의 총 메모리 예약이 Fargate 태스크(기본 Express Mode 서비스의 경우 2,048)에서 실행한 양을 초과하지 않습니다.

  9. 새 개정을 생성하세요.

  10. 배포라는 드롭다운을 클릭하고 서비스 업데이트를 선택하세요.

  11. 업데이트하려는 클러스터 및 서비스를 선택한 다음 새 배포 강제 적용을 선택하세요. 방금 생성한 태스크 정의 개정이 자동으로 선택됩니다. 업데이트를 선택합니다.

  12. 배포가 수행되는지 확인하세요. 이제 이 서비스의 태스크에는 두 개의 컨테이너가 있습니다. Express Mode 콘솔 또는 API를 통한 추가 업데이트는 태스크 정의에 대한 변경 사항을 덮어쓰지 않습니다. 예를 들어 이 경우 Express Mode에 새 로그 그룹 및 로그 스트림 이름을 부여하면 logDriver가 다시 awslogs로 업데이트됩니다.

서비스에 사용자 지정 도메인 추가

사전 조건: 이 가이드에서는 도메인이 ACM 인증서를 통해 Route 53에서 관리하는 호스팅 영역이라고 가정합니다. 도메인이 다른 곳에서 호스팅되는 경우 Application Load Balancer DNS 레코드를 가리키려면 CNAME이 필요합니다.

  1. https://console.aws.amazon.com/ecs/v2에서 콘솔을 엽니다.

  2. 탐색 창에서 클러스터를 선택합니다.

  3. Express Mode 서비스가 있는 클러스터를 선택하고 서비스 패널에서 선택하세요.

  4. 리소스 탭으로 이동하고 리스너 규칙을 선택하세요.

  5. 작업 및 규칙 편집을 선택하세요.

  6. 현재 호스트 헤더 값(애플리케이션 URL)을 복사한 다음 규칙을 제거하세요. 각 유형에 대해 하나만 있을 수 있기 때문입니다.

  7. 호스트 헤더 유형의 조건을 추가하고 애플리케이션 URL을 호스트 헤더 조건 값으로 다시 붙여 넣으세요.

  8. OR 조건 값 추가를 클릭하세요.

  9. 사용자 지정 도메인 이름을 입력하세요.

  10. 다음을 클릭하고 변경 내용 저장을 클릭하세요.

  11. 이제 Application Load Balancer 리스너의 인증서 탭을 선택하세요.

  12. 인증서 추가를 클릭하세요. 여기서 인증서를 리스너로 가져올 수 있습니다.

  13. Route 53 호스팅 영역에서 레코드 생성을 클릭하여 서비스에 대한 라우팅 레코드를 생성하세요.

  14. 단순 라우팅 레코드를 선택하세요.

  15. 레코드 이름을 추가하세요.

  16. 레코드 유형을 선택하세요.

  17. 트래픽을 Application 및 Classic Load Balancer에 대한 별칭으로 라우팅하세요.

  18. 리전을 선택합니다.

  19. Express Mode 서비스가 사용하는 로드 밸런서를 선택하세요.

전파를 위해 몇 분 후에 서비스가 사용자 지정 도메인에서 트래픽을 수신하기 시작합니다. Application Load Balancer에 많은 인증서를 추가하거나 Application Load Balancer에서 많은 Express Mode 서비스를 지원하는 경우 Application Load Balancer에서 인증서에 대한 서비스 제한을 높이는 방법을 고려할 수도 있습니다.