목차
1. CI/CD 개념
2. OverView
3. VPC 생성 및 연결
4. Github Actions 설정
5. AWS IAM 생성
6. AWS Elastic Beanstalk 설정
7. 프로젝트 파일 생성 및 수정
8. HTTPS 적용
https://aeeazip.tistory.com/50
[CI/CD] Github Actions + Elastic Beanstalk를 활용한 Node.js CI/CD 구축 (1)
목차 1. CI/CD 개념 2. OverView 3. VPC 생성 및 연결 4. Github Actions 설정 5. AWS IAM 생성 6. AWS Elastic Beanstalk 설정 7. 프로젝트 파일 생성 및 수정 8. HTTPS 적용 1. CI/CD 개념 CI 빌드/테스트 자동화 과정 CI는 개
aeeazip.tistory.com
1편에서 1번 CI/CD 개념부터 4번 Github Actions 설정까지 다뤘다. 전체적인 OverView가 궁금하다면 1편을 참고하길 바란다.
5. AWS IAM 생성
IAM으로 만들 수 있는 것은 총 3가지이다.
- 사용자 (계정)
- 역할
- 정책
내가 IAM으로 만들어준 것은 역할이다!
AWS Elastic Beanstalk이 동작하려면 몇 가지 권한이 필요하다.
- Elastic Beanstalk 자체의 권한 (배포하기 위한 이미지가 필요 → S3에 올림)
- EC2 권한
먼저 IAM > 역할 > 역할 생성을 클릭한다.
역할 생성을 선택하고 신뢰할 수 있는 엔터티 유형으로 AWS 서비스를 골라준다.
사용 사례로는 EC2를 선택하고
(아무것도 안붙어 있는 그냥 순수 EC2)
다음으로 권한 정책 추가에서 두가지를 선택한다.
- AWSElasticBeanstalkEnhancedHealth
- AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy
다음은 역할 이름 지정이다.
이름은 뚜렷한 역할을 이해하기 쉽도록 직관적으로 작성해주는 것이 좋다. (ex) aws-elasticbeanstalk-service-role)
역할 이름 지정이 끝났다면 신뢰 정책을 설정해주어야 한다.
이 역할을 부여했을 때 믿을 수 있는지를 넣어주는 부분이고 여기서 편집을 눌러도 잘 안되기 때문에 (대기업에서 이런 버그가..?) 일단 만들고 수정하는 쪽이 좋다.
아래 사진은 편집 전의 사진으로 현재는 EC2를 위한 권한만 존재한다.
따라서 신뢰 정책 편집을 선택하고 다음과 같은 내용으로 수정해주어야 한다.
위와 같은 방식으로 EC2에 대한 권한을 하나 더 생성해준다.
권한 이름은 역할이 잘 드러날 수 있도록 aws-elasticbeanstalk-ec2-role2이라고 설정해주었고 다음과 같은 권한을 부여해주어야 한다.
- AWSElasticBeanstalkMulticontainerDocker
- AWSElasticBeanstalkWebTier
- AWSElasticBeanstalkWorkerTier
방금까지는 IAM으로 권한을 생성해주었다면 이번엔 사용자 생성이다.
IAM > 사용자 > 사용자 생성을 선택하고 이름을 설정해준다.
이때 권한 옵션은 직접 정책 연결을 선택하고
권한 정책은 AdministratorAccess-AWSElasticBeanstalk을 선택하여 생성해준다.
그리고 액세스 키를 만들어주어야 한다.
이때 발급바은 액세스 키와, 비밀 액세스 키를 잘 간직하고 있어야 한다!!!!
나는 프로젝트에서 환경변수로 액세스 키와, 비밀 액세스 키 값을 주입받기 때문에 Github Secret에 값을 등록해주었다.
- 액세스 키 : AWS_ACTION_ACCESS_KEY_ID
- 비밀 액세스 키 : AWS_ACTION_SECRET_ACCESS_KEY
6. Elastic Beanstalk 설정
먼저 Elastic Beanstalk에서 애플리케이션 생성을 선택한다.
이제 애플리케이션 환경 구성 단계다.
- 환경 티어 : 웹 서버 환경을 선택
- 애플리케이션 이름은 정보를 명확하게 작성 (ex. project명-dev / project명-prod)
- 환경 정보는 따로 설정해주지 않아도 괜찮다!
- 플랫폼 : Node.js 선택 (만약 Java 프로젝트라면 Java 선택)
- 애플리케이션 코드 : 샘플 애플리케이션
- 이때 더 이상 수정할 계획 없는 완성된 코드라면 코드 업로드를 해도 괜찮지만
- 지속적인 수정 및 배포 자동화를 구축해놓는다면 샘플 애플리케이션을 선택하는 편이 좋다!
- 사전 설정 : 사용자 지정 구성 선택
- 이때 단일 인스턴스를 선택하면 무중단이 불가능하기 때문에 사용자 지정 구성을 선택해주었다! (하나의 인스턴스에 블루-그린 배포를 했다면 단일 인스턴스도 괜찮을 것 같다..)
다음은 서비스 액세스 구성 단계이다.
- 서비스 역할 : 기존 서비스 역할 사용 선택
- 기존 서비스 역할은 IAM으로 만든 ELB 역할을 선택
- EC2 키페어 : ELB가 EC2를 만드는데 원격접속 시 사용할 키를 지정해주는 부분이며, 아직 생성 전이라면 EC2에서 키 생성을 통해 발급
- EC2 인스턴스 프로파일 : IAM으로 만든 EC2 역할
다음은 네트워킹, 데이터베이스 및 태그 설정 단계이다.
이때 VPC는 1편에서 만든 ELB를 위한 VPC를 사용한다.
인스턴스 설정에서 퍼블릭 IP 주소 활성화를 반드시 선택해주어야 한다.
amazon에서 EC2가 잘 만들어졌는지에 대한 가용성을 확인하고, EC2가 ELB에게 알려줘야 한다.
Q. 이때 EC2가 ELB에게 어떻게 알려줄까?
당연히 네트워크를 통해 알려주기 때문에, 통신을 위한 주소를 찾기 위해 퍼블릭 IP가 반드시 필요하다!!
다음은 인스턴스 트래픽 및 크기 조정 구성 단계이다.
EC2 보안 그룹 설정은 1편에서 인바운드 및 아웃바운드 규칙을 생성해준 보안 그룹을 선택해준다.
용량을 결정하기 전 먼저 오토 스케일링 개념에 대해 짚고 가자.
오토 스케일링은 자동적으로 인프라의 크기를 조정하는 것을 의미한다.
오토 스케일링은 크게 스케일업(Scale-Up), 스케일아웃(Scale-Out) 방식이 있다.
스케일업은 인스턴스의 크기 자체를 키우는 것을 의미한다.
(ex. 크기가 1인 인스턴스를 크기를 30으로 키운다.)
스케일아웃은 인스턴스의 규모를 늘리는 것을 의미한다.
(ex. 인스턴스 1개를 인스턴스 30개로 늘린다.)
오토 스케일링에 대해서는 아래 블로그에 잘 정리되어 있으니 참고하길 바란다!
[AWS] 📚 Auto Scaling 개념 원리 & 사용 세팅 💯 정리
오토 스케일링 (Auto Scaling) 클라우드 컴퓨팅의 대표적인 장점으로는 필요에 따라 서비스를 빠르게 확장하거나 축소할 수 있는 유연성을 들 수 있다. 그중, 오토스케일링(Auto Scaling)은 클라우드의
inpa.tistory.com
아무튼~
ELB가 배포하면서 자동으로 CloudFormation을 이용해 EC2를 생성 및 삭제한다. 그런데 이때 인스턴스가 최대 1개라면 블루-그린 배포가 아닌 이상 무중단 배포가 불가능하다.
따라서 인스턴스를 최소 1개 최대 2개로 설정해주어 무중단 배포를 진행한다.
즉, 오토 스케일링 중 스케일 아웃을 활용한 방법이다!
- 인스턴스 유형에서 t3.micro 삭제
- 프리티어를 사용하는 경우 과금 발생 가능하므로 삭제해준다..
그리고 ELB안에 기본적으로 WAS가 잘 돌고 있는지 확인하기 위해 지속적으로 health check를 진행한다.
get 요청을 보내 응답이 돌아오는지를 확인하며 이 부분을 담당하는게 프로세스라고 할 수 있다.
나는 프로젝트에 health check를 위한 uri가 /health인 get 요청의 API를 생성해주었고
편집 선택 > 상태 확인 경로를 /health로 변경해주었다.
마지막으로 업데이트, 모니터링 및 로깅 구성 단계이다.
먼저 롤링 업데이트 및 배포 단계에서
- 배포 정책 : 추가 배치를 사용한 롤링
- 배포 정책으로 한번에 모두를 선택 시 중단 배포가 된다!
두 번째로 플랫폼 소프트웨어 > 환경 속성을 선택하고 프로젝트 .env에서 적어준 환경 변수들을 작성해준다.
프로젝트 환경 변수 주입은 이를 통해 주입받으면 된다!!!!
'Server > CI&CD' 카테고리의 다른 글
[CI/CD] Github Actions + Elastic Beanstalk를 활용한 Node.js CI/CD 구축 (3) - 完 (3) | 2024.03.14 |
---|---|
[CI/CD] Github Actions + Elastic Beanstalk를 활용한 Node.js CI/CD 구축 (1) (2) | 2024.02.18 |
[CI/CD] GitLab + Jenkins를 활용한 SpringBoot CI/CD 구축 (3) - 完 (2) | 2024.02.13 |
[CI/CD] GitLab + Jenkins를 활용한 SpringBoot CI/CD 구축 (2) (0) | 2023.10.20 |
[CI/CD] GitLab + Jenkins를 활용한 SpringBoot CI/CD 구축 (1) (0) | 2023.08.18 |