각 단어에 대한 상세설명은 1. 간략 개요 글을 읽어주기 바랍니다.
각 단계에서 일어나는 일들을 위 도식도 순서에 맞게 설명을 덧붙여 보겠습니다.
PROVISIONING
내부적으로 준비하는 상태( 간략개요글 참고 )
PENDING
ECR에서 Docker 이미지를 가져와 실행
이때 ECR이미지는 이미 빌드가 완료된 Docker image를 저장하고 있어야 한다.
특별한 설정을 하지 않았다면, 빌드가 잘못되었다고해서 run이 안되진 않는다.
ACTIVATING
TargetGroup에 Task를 등록하는 상태
이때 Task Definition에는 서버 리소스 사용, 환경변수, 여러 상태를 미리
정의시켜놓고 늘 그 상태로 배포될수있는 외적인 요소들이라고 생각하면 된다.
이때 제일 많이 나는 오류
- ECR의 주소를 못찾아서
RUNNING
이때는 배포한다는 흐름상
Old_Service가 New_Service로 교체되는 상황이 생긴다.
위에서 TargetGroup이 Old_Service와 New_Service의 HealtyCheck를 하여서
서비스 교체의 여부를 결정짓는다.
이때는 여러 오류가 생겨서 Old_Service와 New_Service의 교체가 이루어 지지 않는다.
다음과 같은 오류들이 생긴다.
- DB Connection 오류 ( 인프라상 접근이 불가하면 Connection Time out )
- 로드밸런서의 상태확인의 실패 ( TargetGroup 에서 healty Check Path 확인 )
- 로드밸런서의 상태확인 코드 설정 범위 ( 기본 200 → 200-404 까지 범위 허용 )
- 로드밸런서의 상태체크 횟수 확장 ( 기본 2 → 5 )
- Service 설정시 설정 값.
healthCheckGracePeriod :
정의된 기간동안 ALB의 상태확인은 무시된다.
=> 애플리케이션이 로드되는 시간을 넉넉잡아 해두어야 한다.
이 밖에도 여러 오류가 생긴다.
해당 오류를 디버깅하기 위해서는 두가지만 유의깊게 보면 된다.
- Running으로 돌아서지만 계속 STOPPED되는 경우 ⇒ Task Definition에서 CloudWatch 로그 경로를 꼭 설정하고 로그를 확인.
- Running이 보이기도 전에 STOPPED되는 경우 ⇒ 이때는 꼭 STOPPED된 Task를 들어가 상세한 정보를 확인하여야한다. 보통 ECR Pull Fail 이런 오류가 많이 날텐데 ECR url을 올바르게 수정해본다.
DEACTIVATING
TargetGroup에서 Task가 등록 취소 된다.
Old_Service와 New_Service의 교체가 이루어지는 과정에서 성공이든 실패든 해당 과정으로 오게되어있다.
재시도를 할 수 있고 정상 처리가 될 수도있다.
해당 상태로 성공적인 배포라 판단하면 안된다.
STOPPING
실행중인 컨테이너를 정상적으로 종료하는 프로세싱 단계
이미 중지되었다면 처리되지 않지만 정상적으로 설정되었다면 StopTimeout 설정값 까지 대기하고 컨테이너를 강제 종료. (기본값 30초)
DEPROVISIONING
생성된 리소스, 네트워크에서 정리 및 분리
STOPPED
최종적으로 정리된 상태
참고 :
'Cloud > AWS-ECS' 카테고리의 다른 글
| [AWS] TaskLifeCycle 단어 정의 (0) | 2020.12.12 |
|---|---|
| [AWS] Schduled task(EC2/Fargate) (0) | 2020.12.12 |
