15. 도커 배포 프로세스: AWS ECS 활용1

EC2를 활용한 배포의 단점

 

앞서 해본 EC2를 활용한 도커 배포는 여러가지 단점이 있다. 먼저 서비스에 수정사항이 있다고 생각해보자. 먼저 로컬에서 소스를 수정하고 새로 이미지를 빌드한다. 그리고 새로운 이미지를 도커 허브에 업로드 한다. 이제 EC2 인스턴스로 이동하여 업로드된 이미지를 다시 가져오고, 컨테이너를 재시작 하면 서비스 수정이 완료된다. 이처럼 로컬과 EC2 인스턴스를 이동하며 작업을 진행해야하는 번거로움이 있다. 그리고 컨테이너가 EC2 인스턴스에서 실행되기 때문에, 해당 EC2 인스턴스를 생성하고 설정 및 관리하는 역할까지 수행해야한다.

 

 

---

AWS ECS

 

AWS ECS란 AWS에서 제공하는 완전관리형 컨테이너 배포 및 관리 서비스이다. EC2를 사용할 때는 컨테이너 및 서버를 관리하는 것은 우리의 책임이었다. 하지만 ECS는 완전관리형 서비스이기 때문에 AWS에서 컨테이너와 서버의 배포 및 유지관리 업무를 대신 수행해준다. ECS를 사용하면 컨테이너로 실행될 어플리케이션과 이미지 개발에만 집중할 수 있는 것이다. 이러한 서비스는 AWS 뿐 아니라 Azure 및 GCP에도 유사 서비스가 존재한다.

 

 

---

ECS 생성 및 접속

 

ECS 생성 페이지에 들어가면 위와같은 그림을 볼 수 있다. 여기서 Container는 우리가 지금까지 봐왔던 컨테이너와 동일한 개념이다. 이미지를 기반으로 하여 어플리케이션이 실행되는 곳이 컨테이너이다. Task는 컨테이너가 실행되는 서버이다. 이전에 EC2에서 컨테이너를 실행했을때 EC2가 여기서 태스크라고 볼 수 있다. 서비스는 태스크들을 바탕으로 오토 스케일링, 오토 밸런싱을 설정할 수 있는 상위 개념이다. Cluster는 서비스들을 클러스터 단위로 묶어주는 개념이다.

 

Custom 컨테이너 설정을 보면 여러가지 항목들이 있는데, 이중 다수는 docker run 명령어 실행시 들어가는 옵션들이다. 컨테이너 이름은 --name 이름 옵션, 대상 이미지, -p 포트 옵션 등 여러가지 항목이 docker run의 옵션과 같다. 이렇게 docker run 처럼 컨테이너를 설정해주고 컨테이너 생성을 완료하면 Task의 IP를 통해 NodeJS App에 접속 할 수 있다.