5. github Action 적용 응용 (BackEnd)
5-1. 방법 1 : BackEnd
1. 용도
개인 프로젝트에서 사용
2. 흐름
→ github 에 push → githubAction 이 이벤트 감지 → git pull EC2
3. 장점
- git pull 을 활용해서 변경된 부분의 프로젝트 코드에만 업데이트를 하기 때문에 CI/CD의 속도가 빠르다
- ⇒ 대부분의 CI/CD 방식은 전체 프로젝트를 갈아 끼우는 방식
- github Action 만 사용하기 때문에 인프라 구조가 복잡하지 않고 간단하다
4. 단점
- 빌드 작업을 EC2에서 직접 진행하기 때문에 운영하고 있는 서버의 성능에 영향이 있을 수 있다
- github 게정 정보다 EC2에 저장되기 때문에 믿을만할 사람들과 같이 진행하는 토이 프로젝트에서만 사용해야 한다
5. 사용 상황
- 주로 개인 프로젝트에서 CI/CD 를 간단하고 빠르게 적용하고 싶을 때 사용
5-2. 방법 2: BackEnd (github Action, SCP)
1. 용도
일반 프로젝트에서 많이 사용하는 방법
2. 흐름
→ github 에 push → githubAction 이 이벤트 감지 → 빌드 파일 전송 → EC2
3. 장점
- 빌드 작업을 github Action에서 하기 때문에 운영하고 있는 서버의 성능에 영향을 거의 주지 않는다
- CI/CD 툴로 github Action 만 사용하기 때문에 인프라 구조가 복잡하지 않고 간단하다
4. 단점
- 무중단 배포를 구현하거나 여러 EC2 인스턴스에 배포를 해야하는 상황이라면, 직접 github Action script를 작정해서 구성해야 한다
- 직접 구현을 할 때 생각보다 복잡하다
- 나중에 인프라 고도화 시 인프라 구조를 변경해야 하는 상황에서 시간이 많이 걸린다
5. 사용 상황
- 현업에서 초기 서비스 구축 시 사용
- 처음 서비스를 구현할 때는 대규모 서비스에 적합한 구조로 구현하지 않는다복잡한 인프라 구조를 갖추고 관리하는 것은 생각보다 여러 측면에서 신경 쓸 것이 많아지게 된다
- 즉, 오버엔지니어링을 하지 않기 위해 사용하고, 확장의 필요성이 느껴질 때 인프라를 고도화 하기 시작한다
인프라 고도화의 단점
- 에러가 발생할 때 트러블 슈팅이 어려움
- 팀원이 인프라 구조를 이해하기 어려움
- 기능 추가, 수정 시 많은 시간이 소비
- 금전적인 비용이 더 많이 발생할 수 있다
5-3. 방법3 : BackEnd(github Action, S3, Code Deploy)
1. 용도
확장성을 고려한 프로젝트에서 많이 사용되는 방법
2. 흐름
→ github 에 push → githubAction 이 이벤트 감지 → 빌드 파일 전송 → S3 (AWS CodeDeploy)→ EC2
- AWS CodeDeploy :
- EC2에게 S3로부터 빌드 파일을 다운 받은 뒤 배포 하도록 명령
AWS CodeDeploy, AWS CodeDeploy Ageng(Ec2)
→ GithubActoin 은 s3에 접근할 수 있어야 한다 (외부에서 AWS 사용)
→ GithubAction은 CodeDeploy에 접근 할 수 있어야 한다 (외부에서 AWS 사용)
→ Ec2는 S3에 접근 가능해야 한다 (AWS 내부에서 AWS 서비스 사용)
→ CodeDeploy는EC2에 접근 가능해야 한다 (AWS 내부에서 AWS 서비스 사용)
EC2에게 S3 접속을 해서 build 된 파일을 다운로드 한 뒤 배포를 진행하도록 명령하기 위해 사용
이 명령은 CodeDeploy Agent가 처리
위의 접속 관계를 이해하고 IAM 설정이 필요
3. 사용하는 이유 (오버엔지니어링이 아닌 경우)
3. 장점
4. 단점
- CodeDeploy 를 사용하여 인프라 구조가 복잡
- 구조가 복잡하여 관리할 포인트가 자동적으로 증가 ( 관리, 유지보수 비용, 난이도, 트러블 슈팅 어려움, 복잡도 증가)
5. 사용 상황
서버를 여러대 이상 구동해야 하거나 무중단 배포가 필요한 서비스 일 때 주로 사용
5-4. 방법4 : BackEnd (github Actions, Docker)
1. 용도
컨테이너 기반( 도커)의 프로젝트에서 사용하기 위해
2. 흐름
→ github 에 push → githubAction 이 이벤트 감지 →빌드 파일 전송 (AWS EC2)→ AWS/ECR
- 빌드 파일 : Docker Image 생성 및 Docker Image를 ECR로 전달
- 이벤트 감지 → AWS EC2 :
- ECR로부터 Deocker Image를 다운 받아서 배포
3. 장점
Doker 기반으로 서비스를 운영할 때, 가장 간단하게 구성할 수 있는 인프라 구조
4. 단점
- 무중단 배포를 구현하거나 여러 EC2 인스턴스에 배포를 해야 하는 상황일 때 직접 github Action에 스크립트를 작성해서 구현해야 한다
- 구현 시 많이 복잡하다
5. 사용 상황
- 컨테이너 기반 인프라 구성 시 이 방법을 많이 사용한다
- 서버를 여러 대 운영하고 있지 않는 소규모 프로젝트 일 때 주로 활용
5-5. 방법5 (github Actions, Docker, CodeDeploy)
1. 용도
컨테이너 기반에서 많이 사용되는 방법
2. 흐름
→ github 에 push → githubAction 이 이벤트 감지 →빌드 파일 전송 (AWS S3, AWS CodeDeploy)→ AWS ECR
- 빌드 파일 : Docker Image 생성 및 Docker Image를 ECR로 전달
- 이벤트 감지 → AWS CodeDeploy ⇒ AWS EC2 :ECR로부터 Deocker Image를 다운 받아서 배포
- EC2 에게 S3로부터 CodeDeploy 관련 파일을 다운 받은 뒤
3. 장점
- 컨테이너 기반 서버가 여러 대이더라도 쉽게 자동 배포를 구축 가능
- 쉽게 구축한
4. 단점
- CodeDeploy 를 사용하여 인프라 구조가 복잡
- 구조가 복잡하여 관리할 포인트가 자동적으로 증가 ( 관리, 유지보수 비용, 난이도, 트러블 슈팅 어려움, 복잡도 증가)