제수기 > AWS / Elastic Beanstalk 애플리케이션 생성하기 / 과금 여부 확인 / CICD 환경구

Eunbi Jo·2025년 2월 11일
0

제수기

목록 보기
87/90
post-thumbnail
제수기 - 제발 수업내용을 기억해라 / 단순 수업정리 시리즈

Elastic Beanstalk 애플리케이션 생성하기

elastic beanstalk란?

Load Balancer, ec2, s3, db 등이 각각 있는데, 이걸 묶어서 제공하는 게 elastic beanstalk다.

모두 aws에서 제공하고 있고, 각자 하는 역할이 다르다.

  • Load Balancer는 실제 사용자 접속이 늘어나서 traffic 규모가 커졌을 때 ec2 개수를 늘리고, trafic이 줄면 다시 줄여주는 등 제어하는 기능을 한다.

  • db는 db만 따로 제공하는 rds라는 서비스가 있다. 그런데 이게 리눅스 머신에다가 ec2 인스턴스 빌려가지고 db 설치하면 훨씬 저렴하기 때문에, 굳이 사람들이 잘 안 쓴다.

  • 실질적으로 오늘 제공받을 건 ec2. 그 전에는 우리가 django 앱만 돌리는 구조였는데, 이제는 ec2 안에서 django 앞에 서버 하나를 둔다. 이 서버는 ngix. proxy server라고도 한다. 사용자 요청이 들어왔을 때 ngix를 통해서 django. 실질적으로 우리가 이번에 사용할 docker. 에 연결해준다. 얘의 역할은 앞에서 먼저 받는 거다.

  • 간단하게 말하면 eginx는 정적 파일을 서빙한다. load balancing 역할도 일부 한다.

  • 동적인 부분은 docker에서 담당을 하게 된다. 그런데 우리는 따로 eginx에서 스테틱으로 시작하는 걸 경로로 이동될 수 있게 하는 걸 하지 않아도 된다. docker 안에서 블랙노이즈 패키지가 대신 해주고 있기 때문.

과금 여부에 대해 추가로 적자면, 앨라스틱 빈즈토크 자체는 과금이 없고 그 안에 있는 서비스들은 과금이 있는데 프리티어에서 ec2, s3, rds는 일부 구간 무료.
로드 밸런스에서 스케일 아웃(인스턴스를 늘리는 거)을 하면 과금. 로드밸런스는 아예 프리티어에서 사용을 못한다.

docker 이미지는 별도의 s3(파일 저장소)에 배포한 저장소를 다 저장해둔다. 이걸 저장해두면 어떤 게 수월해지냐.

혹시라도 버전을 배포했는데 올려보니까 문제가 생기는 경우가 분명히 있다. 그럴 때 잘못하면 서비스가 끊어지니까 방금 올렸던 애를 폐기하고 이전 버전으로 복구하는 게 수월해진다.

앨라스틱 빈즈토크는 통합적인 서비스라고 보면 된다.
로드 밸런스 ec2, s3, db 묶어서.

구성

application이 있고, application-env가 있다.

allication은 묶어주는 용도고 application-env 하위에 ec2, 등 여러 권한들이 있다. 이걸 role이라고 하는데, service-role, ec2-role 이렇게 두 가지가 있다. 그 외에 네트워크 설정 subnet

엘리스틱 빈즈토크를 쓸 거면 이걸 다 묶어서 쓰는 거다.

  • 스케일 아웃: 똑같은 사양의 컴퓨터를 여러대 놓는 것. 인스턴스 확장.
  • 스케일 업 : 실제 하드웨어의 사향을 높인다. 웹의 크기를 높이고 하는 등. 이거는 그런 식.

클라우드 와치는 엘라스틱 빈즈 토크가 제대로 되는지 감시하는 애다.


이제 배포를 위해 가보자.

먼저 iam 으로 접속


aws 서비스 , ec2 2개가 필요한데, service role은 자동으로 만들어주지만 ec2 role은 아니므로, 먼저 ec2 role을 만들어줘야 한다.

ec2 role 만들기

  • 권한에 아래 3개 추가

이제 elasticbeanstalk 어플리케이션 생성하기

플랫폼 Docker
플랫폼 브ㅐㄴ치 Docker running on 64bit Amazon Linux 2023 (linux 배포판. 우분투 같은 거. 이름을 ec2-user로 자동생성)

역할 부여. s3, ec2, , , 다 제어할 수 있게. 역할 이름은 자동으로 만들어준다.

  • Virtual Private Cloud(VPC)
    내 계정으로 나만 쓸 수 있는 작은 네트워크에 대한 설정. 이미 만들어져 있어서 뜰 거다.

인스턴스 서브넷 하나 선택 / 퍼블릭 IP 주소 활성화.
퍼블릭 ip를 확보하지 않으면 바뀌지 않는 ip 주소 하나를 확보하게 된다. 이걸 확보 안 하면 ec2를 껐다 키거나 할 때 내부적으로 바뀔 수 있는 데 그거를 하나 지정하겠다는 거.

4단계 - 인스턴스 건들 거 없고, 용량 쪽.
인스턴스 유형
프리티어인 t2micro 로 설정.

ec2 인스턴스에서 퍼블릭ipv4주소나 퍼블릭ipv4 dns 중에 하나 복사

ssh remote host에 가져다 넣고, 키 넣고 ec2 user 이름 넣어주고

cat nginx.conf 입력해서 확인 가능


루트 계정으로 과금 체크

루트로 접속해서 aws 앱이 있는데, 루트 계정으로 들어가서 요금 상황 살펴봐야 함. 계정 왔다갔다 하는 거 귀찮으면 루트계정은 폰 앱으로 봐도 된다.

ctrl + shift + n 시크릿 모드(이건 그냥 기존 로그인 끊길까봐 시크릿 모드로 들어간 거) - aws 검색 - 로그인 - 루트 계정으로 로그인

오른쪽 위에 아이디 선택 - 결제 및 과금 메뉴 선택 - 청구서 확인

1달러 나오면 알림 오게 하는 거
홈 - 비용모니터링 - 설정 필요


https://h-susu.tistory.com/10#google_vignette
참고 링크


CICD 환경구성

Elastic Beanstalk - MobaXterm 확인

aws eb 안에 ec2 놓고 그 안에 ngix, docker가 돌고 있다. 요청이 들어오면 ngix 통해서 docker로 간다.

CICD는 지속적인 통합 Continuous Integration 지속적인 배포 Continous Delivery

Github Action 이라는 CICD 툴을 써보자.

소스코드를 하나로 만들어내는 빌드 작업. 하나의 이미지로 뜨는 docker bulid가 통합.
docker hub 저장소에 push. 얘를 실행하려면 ec2에 pull 이미지 떙기고 run 하면 배포.

cicd는 이 작업을 자동화해준다.

시작점은 github 저장소. master 브랜치에 push나 pullreqeust가 일어나면 github action이 한방에 해준다.

branch strategy - gitflow
를 사용해보자.

우리는 지금 dev를 쓰고 있는데, master brench는 배포용으로 따로 빼려고 그렇게 한거다.

develop 브랜치에서 개발을 하다가, 스프린트 기준으로 master 통해서 배포하는 식.

내 github 저장소 -> 소스코드 Create(github 경로)

파이참 열기 - gitignore 파일 생성 - 원격(저장소 url / 디폴트 원격)

브랜치 - develop 새 브런치 만들기 - commit

  • 수업에서는 에러가 자꾸 나서 일단 master로 진행했음

혹시 에러 나면 터미널 - del /s /a:h desktop.ini
하위 디렉토리의 모든 ini 삭제

이제 push

  • 브랜치는 소스코드에서 만들어도 되고, github에서 만들어도 된다.

기본브랜치 설정

  • settings

  • 소스코드에서 브랜치 - develop 새로 생성 -> pull

  • 실수로 master에서 작업하지 않도록 로컬에서 삭제

개발과 운영 환경 분리하기

장고 settings_py의 ALLOWED_HOST 비우기 (개발 localhost, 배포 IP 이렇게 써있었음)

  • 여기에 settings_dev.py
  • settings_prod.py
    만들기

settings_dev는 로컬 개발환경
settings_prod는 EB 하위의 EC2 운영환경

  • settings_dev에는 나중에 database도 가져와야 함
  • settings_prod의 ALLOWED_HOSTS = [ 'eb 도메인주소. 앞의 http://, 뒤의/ 지우고 붙여넣기.' ]

환경변수에 가보면, value가 있는데, 모듈이다. django-app 하위의 settings.py 모듈이 있어서 지금까지 읽혔던 거다.

이걸 더블클릭해서 뒤에를 _dev로 하면 개발환경이 되는거고, _prod로 써주면 운영환경이 되는 거다.

Github Action

  • action - docker image 선택

  • yml 문서 구성
    docker image build를 할 건데, develop 브랜치에서 pull_request를 하는 event가 발생할 때 jobs를 실행시켜줘.
    jobs는 여러 steps로 구성돼 있어.

강의 자료 2025-02-12 11-01-05 12-14분 내용에서 자세한 내용 확인

  • commit

디렉토리 안에 .github/workflows 안에 docker.images.yml에서 언제든지 수정이 가능하다.

소스코드에서 원격 dev 내용 땡겨오면 확인할 수 있다.

루트에 Dockerrun_aws_json 파일을 만들고 docker run -d -p 8000:8000 이런 명령어 등을 써놓을 수 있다. dockerrun 할 때 쓰이는 옵션을 적어둔다.

시크릿값 채워주기

시크릿 값을 채우기 위해 .github/workflows 안에 docker.images.yml를 열어보자.
이런 걸 채워야 한다.

  1. dockerhub에 가서 비밀번호 대신해서 쓰는 토큰을 받아보자.


이제 이 토큰을 github setting > security > Secrets and variables > Action

docker.images.yml 여기에 써놓은 dockerhub username 변수값을 name에 그대로 붙여넣고 secret에 토큰을 포함한 값을 적어주면 된다. 실제 유저이름 등.

  1. eb도 마찬가지로 해준다.
    어플리케이션 이름, 환경이름 등을 aws 콘솔에 가서 확인하고 action에 적어준다.

  2. aws IAM
    사용자 > 사용자 만들기 > 권한 옵션 직접 연결 > 권한 정책

보안자격증명 > 액세스키 만들기 > 기타 > 다음 > 액세스키 만들기
키 / 비밀 액세스키 가 나온다. .csv로 다운로드 한다.

이제 action에 이름과 시크릿값을 적어주면 된다.

실행

  • 이제 지정해둔 조건을 만족시키면, action workflow에서 진행 log를 실시간으로 볼 수 있다.

eb 환경변수 업데이트

  • 구성 편집

환경속성 이름 장고 새팅즈 모듈 값에 디렉토리 이름 + 모듈 이름 적어주고 (환경변수에 있는 거)

이제 S3에 가보면 우리의 앱이 압축된 상태로 있다. 나중에 원복하기 위한 용도.

0개의 댓글