AWS Code Pipeline, Code Build를 사용하여 새 Docker 컨테이너를 생성하고 ECR로 푸시합니다.
내 응용 프로그램은 간단한 간단한 단일 컨테이너 기반입니다. 현재 실행중인 컨테이너를 풀다운하고 ECS 레지스트리 (코드 파이프 라인을 통한 코드 빌드 출력)에서 새 컨테이너를 다시 시작하는 마찰이 적은 방법입니다.
EC2 사용자 데이터로 CloudFormation을, 한쪽에서 사용자 지정 스크립트를, 다른 쪽에서 작업을 정의하여 ECS를 사용하여 CloudFormation을 시도했습니다 (아직 성공하지 못함). 더 분명하고 간단한 접근 방식이 필요하다고 강하게 느낍니다.
답변:
ECS 컨테이너 인스턴스 ( Docker 호스트 에 대해 이야기하고 있습니다. 여기서는 AWS 용어가 마음에 들지 않습니다)와 배포를 두 가지로 유지하겠습니다.
ECS 스택을 가동하십시오. CloudFormation 및 Auto-Scaling 그룹을 통해이를 관리 할 수 있습니다. 그냥 배포하는 플랫폼으로 클러스터의 생각 에 , 당신이 필요하지 뭔가 재배포 .
그런 다음 CD의 경우 가장 쉬운 방법은 서비스 정의를 업데이트하여 새 작업 정의를 사용하고 ECS 롤링이 컨테이너를 업데이트하도록하는 것입니다.
작업을 시작할 때마다 ECS는 로컬에 이미지가있는 경우에도 docker pull image : tag를 실행하여 해당 이미지의 최신 버전이 있는지 확인합니다. 따라서 사용하는 이미지 태그는 중요하지 않습니다 (모든 빌드에서 태그를 변경할 필요는 없습니다).
즉, 쉽게 배포하기 위해 myimage : latest를 반복해서 구축 할 수 있습니다.
필요한 것은 이미지 = myimage : latest 인 작업 정의입니다. 해당 작업 정의를 사용하여 서비스를 생성하고 ECS가 작업 (서비스 인스턴스)을 시작할 때마다 가장 최근에 구축 한 "myimage : latest"가됩니다.
거기에서 CodeDeploy에서 퍼즐에 하나의 조각 만 누락되어 람다 함수를 호출하여 작업 정의의 새 개정을 작성하고 서비스를 업데이트하면 ECS가 해당 개정에 대한 새 작업을 자동으로 작성합니다. 이전 작업을 제거하십시오.
예를 들면 :
MyService라는 서비스를 만들었다 고 가정 해 봅시다. 작업 정의 MyTaskDefinition : 1 (개정 1)에 대해 2 개의 작업을 실행하도록 해당 서비스를 구성했습니다. 해당 작업 정의에는 이미지가 "myimage : latest"로 설정된 하나의 컨테이너 정의가 있습니다.
참고 : 실제로 새 작업 정의를 만들 필요는 없습니다. 원하는 경우 대신 서비스 작업 목록을 검색하여 하나씩 수동으로 중지 할 수 있습니다. 새 작업을 중지하기 전에 ECS가 작업을 다시 시작할 때까지 기다려야합니다 (즉, 첫 번째 컨테이너를 중지하고 ECS가 교체 할 때까지 기다렸다가 두 번째 컨테이너를 중지합니다). ECS가 컨테이너를 다시 시작하면 앞에서 설명한대로 최신 myimage : latest built을 가져옵니다. 새 작업 정의를 작성하는 것이 쉽고 오류가 덜 발생한다고 생각합니다 (기다리고 확인하는 데 필요한 논리가 없으며 ECS는 새 작업 정의가있는 경우 롤링 업데이트를 처리합니다).
간단한 사용 사례에서는 Docker 용 Elastic Beanstalk를 확인하는 것이 좋습니다. 베어 ECS 사용과 같은 최소 솔루션은 아니지만 ELB, EC2 AutoScale, 상태 모니터링 등과 같은 자동 관리 및 구성된 서비스의 이점을 누릴 수 있습니다.
고급 요약 :
이 방법은 동일한 태그를 재사용하는 대체 접근 방식으로 빌드 ID가있는 태그를 생성합니다 (예 : myimage : tested-42). 새로운 태그로 매번 Elastic Beanstalk를 업데이트해야하지만 배포 된 개정판을보다 세밀하게 제어 할 수 있습니다.