Github Action + ECS + Fargate를 통한 CI/CD 구현 3

1 ~ 2번에서의 요약은 다음과 같다.

 

일단 AWS 계정은 필수

 

1. Github에 Repository 만들기

2. Docker로 이미지 만들어 보기

3. AWS IAM으로 ECR 업로드 가능한 권한 생성

4. Github Action으로 ECR에 Push까지 하기

 

이제 AWS에서 몇 가지 세팅과 도메인 세팅을 추가 해야 한다.

먼저 ECS 차례다.

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/Welcome.html

Amazon Elastic Container Service란 무엇입니까? - Amazon Elastic Container Service

 

1.ECS Cluster 생성

여기서 클러스터 이름과 인프라에서 어떤 방식으로 구성할지 정의할 수 있다.

서버리스와 EC2 인스턴스 간에는 각기 장단점이 존재하므로 각자 상황에 맞춰서 선택하는 것이 좋을 것이다.

여기선 ECS Anywhere는 건너 뛰고 가장 많이 쓰는 두가지중에서 고르는 것 중 하나를 해보자.

 

장점

EC2

  - EC2 기반에서 동작하는 Task들이며 필요시 서버로 접근하여 ecs task의 로그등을 직접 접근이 가능하다는 장점이 있다.

  - 멀티스레드를 기반으로 한 언어의 경우에도 CPU 카운트 등의 리소스에 대한 소모가 적다.

  - 리소스에 따라 다르지만, 배포 속도 자체는 Fargate보단 속도가 소폭 빠름 (단, EC2 자체가 늘어나야 하는 경우엔 Fargate보다 느리다.

  - Fargate 대비해선 저렴하다.

Fargate

  - 싱글스레드로 구동되는 언어들에 대해서 각 단일 Task로 구성되므로 CPU 제약등에 대한 리소스 관련 이슈 문제가 적다.

  - ECS Task가 얼마나 늘어나던 큰 문제가 없다.

 

단점

EC2

  - 싱글 스레드를 이용하는 언어들의 경우, 코어수 부족에 따라 EC2가 자주 늘어나거나 줄어들 수 있고 EC2 자체가 조정되는 중에는 Fargate보다 업데이트가 느리기 때문에 대기 시간 증가

  - EC2의 Service Quota를 넘어서는 경우, EC2 증가가 멈추고 배포가 무한 대기 상태로 전환된다. (Support Case를 통해 해제 필요)

Fargate

  - EC2 대비 좀 더 비싸다.

  - Log를 직접 들어가서 보는 부분이 어려우므로 cloudwatch 등으로 이용해서 로그를 별도로 전송해야 한다.

 

 

사실 나의 경우엔, Fargate를 선택했다.

EC2를 이용하면 로그도 직접 필요시 들어갈 수 있고 여러가지 장점이 있지만, 그만큼 EC2 관리를 위한 관리 코스트가 증가한다. Fargate는 ㄹㅇ 도커 이미지 그 이하도 그 이상도 아니기에 삭제되면 그만이지만, EC2의 경우엔 EC2 서버에 대한 직접적 관리가 더 늘어나기 때문에 처음 시작은 Fargate로 해보고 EC2 관리나 기존에 EC2를 많이 쓰고 있었다면 EC2로 해보는 것도 방법이다.

 

일단은 예제는 Fargate로 하기로 한다.

 

클러스터가 만들어졌다.

활성과 실행중이 1인 이유는 이미 만들어서 사용중인 것에 대한 스샷을 떳기 때문이다. 만일 방금 만든거면 활성, 실행중 모두 0이어야 한다.

 

이제 태스크 정의를 만들어볼 차례다.

이것은 ECS Service가 기동될때 이미지를 어디서 사용할건지, CPU/RAM 크기는 어떻게 할건지, IAM Profile은 어떻게 쓸건지, 포트를 어떻게 열건지 등 docker를 구성하기 위한 모든 네트웍등에 대한 설정을 다룬다.

쓰고 싶은 이름으로 작성

 

 

필수

- CPU

- 메모리

- 태스크 실행 역할은 Task 구동을 위한 역할 (이건 필수, 없으면 새로 생성할것)

 

컨테이너 세부 정보

- 이름 : container용 name

- 이미지 URL : ECR의 주소:tag

필수 컨테이너 : 예

 

포트 매핑

- 컨테이너 포트 : 컨테이너에서 열릴 포트 지정

- 포트 이름 : 포트를 정의할 이름

 

 

 

로그는 필수다. 하지만 스토리지는 별일 없으면 쓸일이 많이 없으니 일단 이렇게 그대로 가보자.

 

일단 이대로 ECS Service를 만들어 보는 것이다.

 

패밀리가 보일 것이다. 이 곳이 방금 만든 태스크 정의가 들어갈 곳이고, 개정은 몇번째 생성된 것인지 넣어주면 된다.

서비스 이름은 원하는대로 넣으면 된다.

 

정말 중요한 곳은 여기다.

선택사항이라곤 써 있지만 이게 없으면 웹에서 접근이 불가능 하다.

리스너는 아직 만들지 않았으니 새 리스너 생성을 고른다. 당연히 대상 그룹도 없으니 연결 해야 한다.

그리고 포트가 연결되고 웹이 실행되면, ALB에선 health check 라는 활성 상태 체크를 하게 되는데, 정상적으로 호출되는 주소를 한개 적는다.

그리고 맨 아래의 생성 버튼을 누른다.

무엇인가 생성이 되었다. 지금은 생성되어 정상적으로 동작하는 클러스터의 상태를 보여지는 것이지만, docker image의 크기에 따라 생각보다 시간이 좀 걸릴 수 있다.

생각보단 빨리 끝나니 물 한잔 마시고 화장실 한번 갔다오면 끝나서 저런 녹색의 바를 볼 수 있을 것이다.

 

이제 연결이 될지 확인해볼 차례이다.

ALB를 열어볼 차례다.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/introduction.html

Application Load Balancer란 무엇입니까? - Elastic Load Balancing

 

아마 처음 들어왔을땐 이렇게 되어 있지 않을 것이다.

 

AWS에서 보통 제안하는 방식은 이러하다.

80 -> 443 -> ACM -> Target Group -> Task

 

80용 리스너를 이렇게 바꾸어보자.

이렇게 하면 http로 들어오면 https로 URL값을 바꾸어 넘겨버린다.

 

ACM은 외부에서 구매하는 SSL 인증서를 내부에서 거의 무료로 쓸수 있게 해주는 서비스다.

https://docs.aws.amazon.com/ko_kr/acm/latest/userguide/acm-overview.html 

AWS Certificate Manager이란 무엇입니까? - AWS Certificate Manager

 

설정은 이렇게 한다.

도메인 이름은 보통 root domain, wild card domain 두개를 넣는다. 예를 들어 이렇게 넣으면 된다.

1. test.com

2. *.test.com

 

이렇게 하면 리스트에 다시 가보면 새로운 인증서가 인증 대기 상태가 되어 있을 것이다.

거기에 들어가서 아래 레코드를 확인하고 네임서버 레코드를 수정한다. (Route 53을 쓰는 방법도 있겠지만, 기존 도메인을 다른 네임서버에서 사용한다는 가정이다)

도메인에 보면 cname 이름과 cname값을 name server 제공하는 곳에서 dns를 교체해주어야 한다.

교체가 완료되고 AWS에서 인증이 완료되면 상태 : 발급됨, 도메인 상태 : 성공 이 표시된다.

 

이게 완료되면 https 인증서를 쓸 수 있다.

다시 ALB로 돌아가서 443 리스너를 만들어본다.

 

대상그룹으로 연결에서 아까 ECS 서비스를 만들면서 만든 대상그룹이 보일 것이다.

그걸 넣어준다.

 

보안 리스너 설정 섹션에 ACM에서 옆에 아까 만든 ACM이 보일 것이다.

저장을 누르면 나는 어플리케이션에서 보안 인증 작업을 하지 않았음에도 AWS가 해준것이다.

 

이게 저장을 한다고 바로 적용되는 것은 아니니, 안전하게 3~5분을 기다린 뒤 도메인으로 들어가보자.

내가 원하는 홈페이지가 나온다면 성공이다.

 

4편에 계속...

(업데이트, 배포 확인, Logging)