'task 정의'에 해당하는 글 2건

ECS 배포

Server/AWS 2018. 8. 20. 23:32

드디어 ECS 마지막 단계인 배포다. ㅋㅋ 지금까지 Docker Image 를 만들었고, Docker Image 를 ECR 에 푸시했고, 해당 이미지를 Task 정의에 할당했고, Task 정의를 Cluster 의 인스턴스에서 실행해 보았다. 제목의 ECS 배포란 말은 Cluster 의 인스턴스에서 Task 정의를 실행한 것을 말한다. 정확한 표현으로는 단지 Task 실행이다. ^^ 이미 Task 정의를 Cluster 에서 직접 시켜봤으니 사실상 배포를 해 본 셈이다. 실제 웹서버 운영이라면 Auto scaling 이나 Load Balancing 을 붙이게 되는데 이것은 Cluster 의 Service 를 생성하여 설정할 수 있다.


* Service 가 해주는 일

- Auto scaling 이나 Load Balancing 설정.

- Service 스케줄러 전략으로부터 Task 정의 인스턴스를 제어.



1. Service 생성



Cluster - Services - [Create] 를 클릭하고 항목을 작성한다. Service 이름, Task 정의 선택, Task 수, 로드 밸런싱, Auto scaling 등을 설정하고 나머지는 다 default 로 둔다. (로드 밸런싱, Auto scaling 생성/설정은 알아서 ㅜ). Service 생성을 마치고 나면 Task 수 만큼의 인스턴스가 생성되어 바로 구동된다. 즉 바로 배포.


Service 에서는 Task 실행이 실패하거나 중단되어도 Task 수를 유지할 수 있도록 계속해서 Task 실행을 시도하게 된다. 이것 역시 Task 를 직접 실행하는 것과이 차이점이다. Service 에서 Task 수를 유지하려는 것은 Service 생성시 default 설정으로 둔 Replica 전략 때문이다. 이 Replica 는 최소 상태 백분율 및 최대 백분율 파라미터 등의 설정 대로 실행할 Task 정의를 어느 인스턴스에 배포할지를 판단한다.


즉, ECS 배포는 Task 의 실행, 곧 Service 를 생성하거나 업데이트 하는 순간 Task 정의가 실행되며 배포된다고 볼 수 있다. 추후 이미지를 수정하여 변경되거나 했을 때 최신 버전으로 인스턴스에 올리기 위해서는 Service 를 업데이트만 해주면 된다. Service 생성도 배포이고, Service 업데이트도 배포인 것이다.



2. Service 업데이트


Service 를 다른 용도로 업데이트 할 일은 별로 없을 것이다. 주로 인스턴스 수를 조정하거나 최신 이미지를 재배포 할 때 업데이트를 하게 될텐데, 업데이트는 매우 간단하다. Service 리스트에서 업데이트할 Service 에 체크하고 Update 를 클릭하면 기존 세팅이 나타나는데 [Force new deployment] 항목에 체크하고 나머지 항목은 모두 그대로 두면 latest 이미지를 가져와 업데이트 할 것이다.




이렇게 배포를 마쳤다. 여기까지는 ECS Document 만 보고 쉽게 따라할 수 있지만, Free Tier 사용자의 경우 EC2 를 두 개 이상 테스트 해보기는 쉬운 결정이 아닐 수도 있다. Fargate 도 마찬가지. 표면상 배포는 잘 돌아가겠지만, 관리 측면에서 보면 앞으로 고민해야 할 일이 더 많을 수도 있다. Image 업데이트부터 배포까지의 매우 번거로운 단계를 최대한 자동화 시키는 것에 대한 고민과, 인스턴스에 늘어나는 Image 에 대한 용량이나 롤백에 대한 고민, task 실행 실패시 알람 및 전략, ECS/Docker/EC2 로그 수집 방법 등등 필요로 하는 더 많은 기능들에 대해 고민해 봐야 한다. 운영면에서는 관련 문서가 그리 많지 않으니 그냥 열심히들 삽질해 보자.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

ECS Task

Server/AWS 2018. 8. 17. 22:16

Image 를 푸시하고 Cluster 를 생성하면 Image 를 구동할 수 있는 것처럼 얘기했지만, 해야 할 것이 하나 더 있다.


Docker 저장소의 Image 는 ECS 에서 사용하기 위해 Task 라는 작업에 정의해야 한다. 이 task 정의에는 실행할 이미지, 컨테이너 사양, 포트 등을 설정할 수 있으며, 이러한 Task 정의로부터 특정 ECS Cluster 를 선택하여 실행시킬 수 있다. Image 는 여러 Task 정의에서 가져다 쓸 수 있으며 Task 정의 역시 여러 Cluster 에서 실행시킬 수 있다.


이번에는 Task 정의를 생성하여 사용할 Image 를 설정해 보겠다.



1. 아키텍처 설계


컨테이너 서비스인 ECS 를 사용하여 어플리케이션을 운영한다는 것은 아키텍처 면에서 기존 방식과 조금씩 차이가 있을 수 있다. (이건 각자 알아서 ㅜ) 하나의 이미지를 여러 인스턴스에서 실행할 것인지 하나의 인스턴스에 여러 이미지를 실행할 것인지 등을 생각해 보아야 한다. 일단 하나의 Docker 이미지로 웹 서버 2대를 사용한다고 했을 때 필요한 것은,


web Image:1 -> web Task 정의:1 -> web Cluster (EC2:2)


이렇게 구성하면 될 것이다. 2 대의 인스턴스를 로드 밸런서에 묶기 위해 Cluster 에 Service 라는 것도 추가해야 하지만 일단 생략했다. 공통 모듈을이나 구성 요소에 따라, 하나의 task 정의에 여러 컨테이너(Image) 를 정의할 수도 있을 것이고... 일단 가장 심플하게 가보자.



2. Task 정의 생성


먼저 콘솔의 ECS - Task Definitions - [Create new Task Definition] 을 선택한다. ECR 에서도 잠시 거론했지만, Task 정의도 가장 먼저 선택하는 것이 시작 유형이다. Fargate / EC2 인스턴스 시작 유형 중 하나를 가장 먼저 선택하게 되고, 선택한 시작유형에 따라 미세하게 설정에 차이는 있다. Network 모드나 Port 설정 등... ECS Document 에 보면 Task 정의를 Dockerfile 처럼 json 파일로 정의할 수 있게 만들어놨는데, 그걸 먼저 보면 토나온다. 설정하는 것은 몇개 안되는데 모든 항목들이 다 나와 있어서 매우 복잡해 보이지만, 콘솔 대신 json 파일로 작업해야 한다면 콘솔에서 제공하는 json 형태의 스크립트에서 설정할 항목만 뽑아서 가져다 쓰면 된다. EC2 인스턴스 시작 유형을 선택했다면 이것저것 설정할 항목이 많아 보이는데, 대부분 Default 로 두면 되고 설정할 것은 몇 개 안된다.


- Task 정의 이름

- Add container : 사용할 Image 의 Repository URI, 이 컨테이너에 할당할 메모리/CPU, Port 매핑


메모리와 CPU 는 사용할 인스턴스 사양과 추가할 컨테이너들을 고려하여 설정한다. 이게 끝이다. ㅋㅋ 컨테이너 Image 나 메모리/CPU, 포트 매핑 등을 수정하기 위해 task 를 업데이트 하면 새로운 리비전이 추가된다. 아마도 운영중에는 크게 수정할 일이 없을 것이다.



3. Task 실행


구동을 확인해 보고 싶다면, Task 정의 리스트에서 Task 정의를 선택하고 [Run Task] 를 클릭하여 실행할 Cluster 를 선택하고 Number of tasks 수를 입력하면 끝. 혹은 Cluster - Tasks 에서 [Run new Task] 를 선택해도 결과는 동일하다. Number of tasks 수를 2 로 지정하면 두 개의 인스턴스에서 Task 가 독립적으로 실행될 것이다. Cluster 에 지정된 인스턴스 수가 한 개라면 한 개의 Task 만 실행된다. Task 가 실행되고 나면 PENDING 상태에 돌입하고 수초내에 정상적인 인스턴스에서 실행되고 있다는 뜻의 RUNNING 상태가 된다. Cluster 에 등록된 인스턴스에서 Task 정의의 Image 를 실행시킬 것이고, Public DNS 를 통해 Image 구동을 확인할 수 있다. Task 를 Stop 시키면 인스턴스에의 task 도 곧 중지된다. 개발 중에는 이렇게 로드 밸런서를 통하지 않고 Task 정의를 클러스터에 다이렉트로 실행시켜서 바로 Image 를 확인할 수 있다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,