태스크 정의에 따라 태스크 또는 서비스를 실행할 수있는 것으로 보입니다. 태스크와 서비스의 차이점과 유사점은 무엇입니까? Task를 생성 할 때 “Task Group”을 지정할 수 있지만 Service는 지정할 수 없다는 단서가 있습니까? 태스크와 서비스는 태스크 정의의 계층 적으로 동일한 인스턴스입니까, 아니면 서비스가 태스크로 구성됩니까?
답변
작업 정의 1 개 이상의 모음입니다 컨테이너 구성 . 일부 작업에는 컨테이너가 하나만 필요할 수 있지만 다른 작업에는 동시에 실행되는 잠재적으로 연결된 컨테이너가 2 개 이상 필요할 수 있습니다. 작업 정의를 사용하면 사용할 Docker 이미지, 노출 할 포트, 할당 할 CPU 및 메모리 양, 로그 수집 방법, 환경 변수 정의를 지정할 수 있습니다.
작업은 당신이 직접 작업을 실행할 때 생성 그들이하는 그들이 포인트, 스스로 중지 또는 종료 될 때까지 (작업 정의에 정의 된) 어떤 출시 용기 (들)을 자동으로 대체되지 않습니다 . 작업을 직접 실행하는 것은 CRON을 통해 수행 한 작업의 예로서 단기 실행 작업에 이상적입니다.
서비스는 항상 작업의 일부 수있는 것을 보장하는 데 사용됩니다 항상 실행을 . 오류로 인해 작업의 컨테이너가 종료되거나 기본 EC2 인스턴스가 실패하여 교체되면 ECS 서비스가 실패한 작업을 대체합니다. 이것이 서비스가 사용할 CPU, 메모리 및 네트워크 포트 측면에서 많은 리소스를 갖도록 클러스터 를 만드는 이유 입니다. 우리에게는 태스크가 실행되는 한 어떤 인스턴스 태스크가 실행되는지는 실제로 중요하지 않습니다. 서비스 구성 은 작업 정의를 참조 합니다. 서비스는 태스크 생성을 담당합니다 .
서비스는 일반적으로 웹 서버와 같은 장기 실행 애플리케이션에 사용됩니다. 예를 들어, 오레곤 (us-west-2)에 Node.JS로 구동되는 웹 사이트를 배포 한 경우 고 가용성을 위해 3 개의 가용 영역 (AZ)에서 실행되는 작업이 3 개 이상이라고 말하고 싶습니다. 하나가 실패하면 다른 두 개가 있고 실패한 것은 교체됩니다 ( 자가 치유 로 읽으십시오 !). 서비스를 만드는 것이이를 수행하는 방법입니다. 클러스터에 6 개의 EC2 인스턴스 (AZ 당 2 개)가있는 경우 서비스는 CPU, 메모리 및 네트워크 리소스를 고려하면서 가능한 한 최대한 영역간에 작업의 균형을 자동으로 조정합니다.
최신 정보:
이러한 것들을 계층 적으로 생각하는 것이 도움이 될지 모르겠습니다.
또 다른 매우 중요한 점은로드 밸런서를 사용하도록 서비스를 구성 할 수 있다는 것입니다. 따라서 작업을 생성 할 때 서비스가 작업 정의에 정의 된 컨테이너를 시작할 때 서비스가 자동으로 컨테이너의 EC2 인스턴스를로드 밸런서에 등록합니다. 로드 밸런서를 사용하도록 작업을 구성 할 수 없으며 서비스 만 가능합니다.
답변
@talentedmrjones가 말로 아름답게 설명했습니다. 아래 그림을 통해 쉽게 시각화 할 수 있습니다. 🙂
답변
작업 정의 :
이것은 실행할 Docker 컨테이너를 설명하고 애플리케이션을 나타내는 청사진입니다. 여기에는 여러 작업이 포함됩니다.
서비스:
작업 정의의 인스턴스입니다. 또한 지정된 시간에 실행되는 하나의 작업 정의, 자동 확장 및 부하 분산에서 최소 및 최대 작업을 정의합니다.
ECS 컨테이너 인스턴스 :
Docker와 ECS Container Agent가 실행중인 EC2 인스턴스입니다. 에이전트는 ECS와 인스턴스 간의 통신을 처리하여 실행중인 컨테이너의 상태를 제공하고 실행중인 새 컨테이너를 관리합니다.
관계:
