[스킬업] Docker 기반 CI/CD 파이프라인 구축하기 3주차

GitLab으로 AWS Cloud로의 지속적인 배포

 

 

 

 

AWS에 배포하는 것이 목표 (AWS Elastic Container Service 를 이용하여 배포 준비)

> GitLab에서 aws cli를 이용해 ecs에 접근하고, gitlab-runner를 통해 도커 이미지를 빌드하여 ecr에 업로드.

> ecs는 ecr에 저장된 도커 이미지를 가져와 컨테이너로 실행

> 이를 통해 사용자는 ecs에서 실행중인 애플리케이션에 접근할 수 있음.

 

 

 

ECS란?

 

ECS (AWS Elastic Container Service)는 애플리케이션을 쉽게 배포하고 운영할 수 있도록 지원하는 완전 관리형 Container Orchestration 서비스이다.

 

• Kubernetes같은 Container Orchestration 서비스
• Kubernetes에 비해 저렴하고 사용하기가 쉽다.
• Serverless로 구성하면 인스턴스를 구성 및 관리할 필요가 없다. (Fargate?)
• AWS의 다른 서비스와 쉽게 연동
• 운영, 모니터링, 스케일링의 완전 자동화

 

• 컨테이너의 클러스터를 가짐 - 하나 이상의 여러 Service로 구성되고, 각 Service 안에는 여러 컨테이너를 가짐
• 한 서비스는 하나의 이미지에서 생성된 컨테이너들이 실행됨 (container = task)
• 자동 스케일러 기능 탑재
• 로드 밸런스 서비스인(?) AWS의 ELB와 연동하여 사용자가 쉽게 서비스에 접근할 수 있도록 함
• AWS의 CloudWatch라는 모니터링 솔루션도 함께 사용 가능
• ECS는 Task definition파일의 내용을 읽어서 ECR, ELB, Service 및 컨테이너를 실행하고 동작하도록 한다.
  (Dockerfile과 유사한듯?)
• Task Definition
  • 이미지를 실행할 ECR URL
  • 몇개의 task를 실행할 것인지에 대한 정보
  • 로드밸런서(ELB) 설정을 위한 정보

 

 

 

 

 

 

 

로드 밸런싱(ELB)과 타겟그룹

 

 

AWS 가상클라우드(VPC)에 ECS Cluster를 만든다. 이건 각 app을 의미하기도 함(?).

각 클러스터에는 여러 Service로 구성할 수 있고, 각 서비스에는 여러 Container(혹은 task)로 구성되어 있다.

위 그림에서는 두개의 컨테이너를 하나의 target group으로 묶었다. 그 이유는
Client(사용자)요청이 80번 포트로 들어왔을 때, Listener가 연결된 타겟그룹으로 사용자의 요청을 로드밸런싱(부하분산?)하기 위해서 이다.

다시 정리하면, 사용자가 요청했을때 ELB(Elastic Load Balancing)가 그 요청을 80번 포트로 받고, Listener에 연결된 타겟그룹으로 요청을 보낸다. 그림은 두개의 task가 있으니 이 중 하나의 task로 요청을 보내게 된다. 그럼 만약 하나의 task에 문제가 생겼을 때, 다른 task에서 동작할 수 있으므로 고가용성 구성이 가능하다는 점이 특징이다.

 

 

 

 

 

Review

 

 

1. 개발자가 코딩
2. 코딩 결과를 GitLab에 push하여 저장소에 저장
3. push한 결과의 변경사항을 gitlab-runner가 확인하여 pipeline 동작 시작
4. pipeline 내의 build, test, deploy 등의 과정을 차례대로 실행
5. build단계에서는 도커 이미지를 build하고 ecr에 push
6. deploy 단계에서는 aws cli를 이용하여 ecs에 서비스를 업데이트
7. ecs는 ecr에 있는 도커이미지를 가져와서 새로 서비스를 실행

> GitLab을 이용하여 전체 과정을 자동화 함 = CI/CD