웹 프로젝트 서버 배포 흐름도

 

배포 흐름도 

1. 코드 작성
   • 개발자가 로컬에서 애플리케이션 코드 작성 및 수정
2. 코드 푸시
   • 코드를 GitHub 리포지토리의 특정 브랜치에 푸시
3. GitHub Actions 트리거
   • 코드 푸시 시 GitHub Actions가 자동으로 트리거됨
4. CI/CD 파이프라인 실행 (GitHub Actions)
   • 빌드 단계
     • 애플리케이션 빌드
     • 자코코 테스트 커버리지 측정
       • 자코코를 사용하여 테스트 코드의 커버리지 측정
       • 커버리지 리포트를 생성하여 품질 확인
     • 테스트 실행
     • 빌드 아티팩트 생성
   • Docker 이미지 빌드
     • Dockerfile을 사용해 애플리케이션의 Docker 이미지 생성
5. ECR에 Docker 이미지 푸시 (도커 허브 개념)
   • 빌드된 Docker 이미지를 AWS Elastic Container Registry (ECR)로 푸시
6. ECS에 배포 - 컨테이너 관리, 쿠버네티스 역할
   • ECR에서 Docker 이미지를 가져와 AWS Elastic Container Service (ECS)에 배포
   • ECS 서비스 업데이트 (새로운 태스크 정의를 사용)
   • ECS 클러스터 - 커다란 아파트 단지
7. EC2 (가상 서버), 클라우드에서 빌려 쓰는 집 
   • EC2 인스턴스가 ECS의 클러스터로 사용될 수 있음
   • 즉, 아파트 단지 ECS의 한 개의 아파트 EC2
     • 만약 한 개의 ECR만 EC2에 올릴 경우 ECS는 생략해도 됨
   • EC2 인스턴스에서 애플리케이션 실행 (ECS에 의해 관리됨)
8. Webhook (선택적)
   • 배포 완료 후 특정 URL로 웹훅 호출 (예: Slack 알림, 다른 서비스와 통신)
9. 모니터링 및 관리
   • AWS CloudWatch를 통해 애플리케이션 성능 모니터링
   • 필요시 스케일링, 로드 밸런싱 설정

 

정리하자면

`ECR` 도커 이미지를 저장하는 레지스트리

`ECS` 컨테이너화된 애플리케이션을 관리하고 실행하는 서비스

`EC2` ECS가 관리하는 컨테이너가 실제로 실행되는 가상 서버

 

결국, EC2는 ECS가 ECR로 만든 컨테이너를 실행하기 위해 사용하는 가상 인프라