UMC 11주차 CI/CD

그린·2024년 1월 21일

UMC 5기

목록 보기

6/6

VPC에서 172.31.0.0은 default VPC 이다.

VPC를 선택하고 리소스 맵 탭을 클릭하면 전체적인 구조도를 볼 수 있다.
-> Default VPC는 다 public 상태임을 알 수 있다.

EC2를 만들 때 VPC를 만들지 않고도 통신이 될까? -> default vpc에서 인터넷게이트웨이가 연결되어 있어서 가능하다.
이 위에서 라우팅테이블도 보면 0.0.0.0/0으로 인터넷게이트웨이가 연결되어 있어서 이렇게 나올 수 있다.

이번에는 private 서브넷을 이용할 예정
NAT 게이트웨이는 비싸서 사용 안 하는 것을 추천

EB는
퍼블릭 VPC 2개, 프라이빗 VPC 2개가 필요하다.

EB는 CI/CD 중 쉬워서 이걸 이용하고자 한다.
로드밸런서가 들어있어서 관리하기 쉬움.

ECS + ECR까지 하려면 Docker를 잘 알아야 한다.

EB는

도커 빈스톡 (조금 더 어렵긴 함)
단일 빈스톡 (사용은 더 귀찮은데 더 쉬워서 이걸로 이번에 이용할 예정)
이 있다.

서브넷을 만들자.
bean-stalk VPC에 총 4개의 서브넷을 만들 것이다.

서브넷은 가용영역을 a와 c를 이용하는 게 좋다.
b는 피하는 게 좋다고 한다.
인스턴스 유형에 따라 올라갈 수 있는 가용영역이 다른데 b 가용영역에는 잘 안 올라가서, a, c를 해주는 게 좋다.

서브넷1 (public)

서브넷2 (public)

서브넷1 (private)

서브넷2 (private)

이렇게 세팅하고 서브넷을 생성한다.

이제 인터넷게이트웨이를 만들어야 public 서브넷을 만들 수 있다.

bean-stalk VPC의 리소스맵을 보면 아래와 같이 서브넷들이 아직 네트워크 연결이 안 된 모습을 볼 수 있다.(다 private 상태)

인터넷 게이트웨이를 생성한다.

VPC에 할당해준다.

이렇게 한 후 라우팅 테이블을 만들어준다. -> 내가 만든 VPC로 설정

지금 라우팅테이블에는 안으로 들어오는 인바운드 패킷에 대한 것만 되어 있는 상태이다.

라우팅 편집 버튼을 누르고 아웃바운드에 대해 설정해주어야 한다.
0.0.0.0/0 에 대해 아까 만든 인터넷 게이트웨이로 연결!

이제 이 라우팅테이블에 대해 서브넷 연결 - 서브넷 연결 편집으로 들어간다.

퍼블릭 서브넷 2개에 대해서만 연결해준다.

보안그룹을 생성한다.

인바운드 규칙을 설정한다.(나중에 수정 가능)

ssh : ssh 연결해야 하니까 설정
http, https : 웹서버니까 설정
사용자 지정 TCP 8080 : 스프링부트에서 8080포트를 많이 사용해서 이렇게 지정함
MySQL/Aurora : DB 연결용
사용자 지정 TCP 6379 : redis를 사용하기 위해 추가
보안그룹 생성!

Github Action에 대해

CI/CD란 자동화 -> 트리거가 발동해서 이벤트가 발생하면 그것 기반으로 작동함

CI <- 깃허브 액션
CD <- ELB (bean-stalk) (ECS를 더 많이 사용하긴 하지만 초보는 ELB로 시작하면 좋음)

Github Action : pull, push 등에 대해 내가 지정한 이벤트가 돌아가도록 하는 것

Github Action을 쓰려면 Github Repository가 있어야 한다.

스프링부트 프로젝트 쓸 때 지금은 2.7 버전이랑 java 버전은 17을 쓰면 좋다. (11버전보다 17버전이 더 편리한 게 많다고 함)

CI/CD를 하려면 git flow(브랜치를 어떻게 관리할 것인가)를 알아야 함

개발 인프라
릴리즈 인프라(나중에 구축해도 됨)
를 구분하게 됨.

개발 인프라는 주로 dev / develop 브랜치에서 뻗어나가게 됨

dev 브랜치에 머지가 되면 CI/CD가 돌아가게 하자!
main
release 브랜치에 머지가 되면 CI/CD가 돌아가게 하자!
prod

Github Action 만들기(CLI 기반으로 만들 예정)

리포지토리 들어왔을 때 아래와 같이 구조가 바로 보이는 상태이면 된다.

가장 최상단 루트 디렉토리(아래 사진에서는 BE)에서 .github 라는 이름의 디렉토리를 생성해준다! -> 이 디렉토리를 토대로 깃허브 액션이 작동하게 됨.

.github 밑에 workflows 폴더를 추가하고 그 안에 dev_deploy.yml 파일을 추가한다.

name: Solution-friend Dev CI/CD

on:
  pull_request:
    types: [closed]
  workflow_dispatch: # (2).수동 실행도 가능하도록

jobs:
  build:
    runs-on: ubuntu-latest # (3).OS환경
    if: github.event.pull_request.merged == true && github.event.pull_request.base.ref == 'develop'
    
    
(후략)

아래는 이 코드 자세하게 설명!

pull_request가 닫혔으면 -> merge가 되었으면 돌아라는 뜻

merge가 되는 대상이 develop 브랜치면 돌아가도록 설정했다.

step 설명

Checkout : 코드를 가져오는 것
actions/checkout@v2에 있는 대로 수행한다는 뜻
checkout 기준은, 이 리포지토리 최상단 기준! (.gradle, src 등등이 다 포함된다)

자바 버전 설정해줌

이 아래는 리눅스 내용인데, 빌드된 대상이 ec2 안에 들어가게 되는데, 특정 디렉토리에 대해 권한이 있어야 함. 그런 것들을 주는 것이다.
gradlew가 무엇인지 찾아보기

시간 관련 내용

중요한 내용은 Generate deployment package! (제대로 빌드하는 과정)
리눅스 명령어들이다.

      - name: Generate deployment package
        run: |
            mkdir -p deploy # 이 디렉토리 만든다.
            cp build/libs/*.jar deploy/application.jar # gradle을 통해 빌드하면 build/libs/*.jar에 넣게 되는데, 깃허브가 임시적으로 돌려보고 나서 실제 디플로이할 대상(deploy/application.jar)으로 복사하는 과정
            cp Procfile deploy/Procfile # Makefile 같은 것
            cp -r .ebextensions-dev deploy/.ebextensions # Elastic Beanstalk에 올릴 때 이런 것들을 해주면 좋겠다고 알려주는 것
            cp -r .platform deploy/.platform # 추가적인 플랫폼(NGINX 등) 관련 설정
            cd deploy && zip -r deploy.zip . # 압축하는 코드

새로운 이슈 파서 브랜치(feat#5 로 만들었음) 만들고 새로운 브랜치로 들어온다!

아까 생성한 yml 파일에 대해 새로운 커밋을 날려주고 push한다.

아 이런 오류가 떠서 구글링해보니까 내가 workflow 수정 권한이 없어서 그랬다.

!	refs/heads/feat#5:refs/heads/feat#5	[remote rejected] (refusing to allow a Personal Access Token to create or update workflow `.github/workflows/dev_deploy.yml` without `workflow` scope)
Done

https://tigris-data-science.tistory.com/entry/workflow-scope-%EC%98%A4%EB%A5%98-%ED%95%B4%EA%B2%B0%ED%95%98%EA%B8%B0
이 분의 글을 참고해서 workflow까지 추가하고 아래에 update token 버튼을 클릭해주어야 한다!!

feat#5 브랜치에 날린 것을 develop브랜치로 합치는데, 이 과정에서는 Generate deployment pacakge 단계에서 당연히 오류가 발생해야 한다고 한다.

그런데 나는 Build with Gradle 단계에서 오류가 발생했는데, 자세히 보니 왠지 내가 application.yml 파일에 중요한 정보들이 있어서 깃허브에 올리지 않아서 발생한 문제 같다.
이 부분은,, 변수처리 한 후에 다시 올리고, 일단은 마저 강의를 따라해보겠습니다.

이 부분을 aws 에서 설정해주어야 한다.

aws Elastic Beanstalk에 들어와서 애플리케이션 생성 버튼을 클릭한다.

이름은 프로젝트이름 뒤에 개발용/릴리즈용을 구분해주어야 해서 dev를 붙였다.

플랫폼을 선택해주는데 여기에서 docker를 선택할 수도 있다.
여기에서는 java를 선택해주겠다.

우리는 "무중단" CI/CD를 할 것이다.
배포될 때 기존에 있던 것을 날리고 새로 빌드되는 동안 서버가 죽게 되는데, 이걸 막고자 한다.

사전설정에서 사용자 지정 구성으로 한다.

이런 인프라에서는 가용성/기밀성/무결성 -> 보안이 중요한데 IAM으로 관리가 가능함.
IAM은 사용자(계정)/역할/정책 관리 가능. -> 루트 계정으로 로그인해서 IAM 계정을 생성할 수 있는데, 이때 최소한의 권한만 줄 수 있음.

AWS ELB에서는 EC2를 직접 만들어서 내부적으로 cloud formation을 가지고 EC2를 만들 수 있다. 하지만 IAM을 이용하면 마음대로 할 수 없다.

ELB는 정상적으로 동작하려면 2가지 역할이 필요하다.
1. ELB 자체의 권한 - S3에 올리는 등 전반적인 내용
2. ELB가 만들 EC2 자체의 권한

AWS에서 IAM 메뉴로 들어가서, 역할 생성을 진행한다.

EC2 선택

AWSElasticBeanstalkEnhancedHealth 를 검색하고 선택!

AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy 를 검색하고 선택

이름 지정

1단계 - 신뢰할 수 있는 엔터티 선택
에서 신뢰관계에 ec2밖에 안 뜸 -> 이대로 ELB 만들면 터지게 된다.
(편집 눌러도 안 됨)

일단 이대로 생성하고, 편집하러 가보자.
역할 탭으로 와서 아까 만든 role을 클릭하고

신뢰 관계 - 신뢰 정책 편집 클릭

"Service": "elasticbeanstalk.amazonaws.com"으로 수정하고 정책 업데이트! -> 이 역할은 ELB에 대한 역할이다.

이제 EC2에 대한 역할 생성을 해보겠다.

AWSElasticBeanstalkMulticontainerDocker 권한 추가

AWSElasticBeanstalkWebTier 권한 추가

AWSElasticBeanstalkWorkerTier 권한 추가

이렇게 한 후 다음 버튼 클릭!

aws-elasticbeanstalk-ec2-role 이름으로 지어주었다.

여기서는 EC2를 위한 것이기 때문에 ec2에 대한 신뢰 정책이 알맞은 상태이다.

이제 다시 ELB 생성하러 가보자!
아까에서 이어서 진행...

기존 서비스 역할 : service-role 선택
EC2 키페어 : EC2 만들면서 발급받은 키페어
EC2 인스턴스 프로파일 : ec2-role 선택

VPC에 bean-stalk VPC 선택

퍼블릭 IP 주소 꼭 선택해주기!
elb ec2를 생성하는데, ec2가 잘 만들어졌는지 파악하게 됨
ec2가 elb에게 네트워크로 통신한다고 알려줘야 함 -> 퍼블릭 IP 주소가 필요함!
public 서브넷들로 설정해주자. 최소 2개 이상을 요구하기 때문에 2개씩 만들어두었던 것임!

다음으로 진행!
왜 데이터베이스 안 하냐? -> ELB가 다 사라지게 만들어서 기존 데이터를 넘기는데, 이 부분은 조금 위험하다고 생각하셔서 지정하지 않으심.

보안그룹 중요!

용량
-> 밸런싱된 로드 로, 최대 2개의 인스턴스로 진행하겠다.

t3.small 없애기!(돈 나감)

프로세스
health check -> EC2 안에 있는 웹서버(was)가 잘 동작하는가를 체크 -> get 요청을 보내서 응답이 오는지를 판단!
default 선택하고 편집 누르기

상태확인 경로(GET 요청)를 /health로 지정함
<- /health API 구현해야 함!!

모니터링은 강화됨이 좋다.
cloudWatch는 더 공부해보고 사용하기

관리형 플랫폼 업데이트는 활성화 빼주기
정해진 시간에 업데이트하는 것인데 딱히 안 필요함

롤링 업데이트 및 배포
배포 정책을 -> 추가 배치를 사용한 롤링 으로 지정해주어야 한다! -> 무중단 배포
'한번에 모두'는 중단 배포다.

환경 속성
5000 포트를 열면

로드밸런싱을 할 때 외부 요청이 오면 뒤에 있는 여러 서버 중에서 누구에게 갈지를 매핑해줌.
ELB 로드밸런서가 ELB의 WAS가 5000번 포트에 있을 것이다 를 디폴트로 해버리면, 8080이나 3000번 포트에 있기 떄문에 포트를 8080으로 고정해줄 것이다.

여기에 있는 이런 파일들은 무조건 프로젝트 최상단에 위치해야 한다.

최상단 위치에 Procfile 파일을 만들어준다.
web: appstart 한 줄 입력!

dev_deploy.yml 파일에 있는 대로,
.ebextensions-dev 디렉토리를 만들어주는데 최상단에 만들어준다.
둘이 이름 일치하게 해야 함!

.ebextensions-dev 디렉토리 밑에 00-makefiles.config 파일을 생성한다.
00, 01 이런 순으로 보기 때문에 이렇게 이름을 작성해줬다.

추가한다.
빨간색 떠도 됨!! 정상이다.

files:
    "/sbin/appstart":
        mode: "000755"
        owner: webapp
        group: webapp
        content: |
            #!/usr/bin/env bash
            JAR_PATH=/var/app/current/application.jar

            # run app
            killalljava
            java -Dfile.encoding=UTF-8 -jar $JAR_PATH

그리고 01-set-timezone.config 파일을 생성해서 추가해준다.

commands:
    set_time_zone:
        command: ln -f -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

.platform 디렉토리를 생성하고, nginx.conf 파일을 생성해준다.

user                    nginx;
error_log               /var/log/nginx/error.log warn;
pid                     /var/run/nginx.pid;
worker_processes        auto;
worker_rlimit_nofile    33282;

events {
    use epoll;
    worker_connections  1024;
    multi_accept on;
}

http {
  include       /etc/nginx/mime.types;
  default_type  application/octet-stream;


  log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

  include       conf.d/*.conf;

  map $http_upgrade $connection_upgrade {
      default     "upgrade";
  }

  upstream springboot {
    server 127.0.0.1:8080;
    keepalive 1024;
  }

  server {
      listen        80 default_server;
      listen        [::]:80 default_server;

      location / {
          proxy_pass          http://springboot;
                  # CORS 관련 헤더 추가
          add_header 'Access-Control-Allow-Origin' '*';
          add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
          add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
          proxy_http_version  1.1;
          proxy_set_header    Connection          $connection_upgrade;
          proxy_set_header    Upgrade             $http_upgrade;

          proxy_set_header    Host                $host;
          proxy_set_header    X-Real-IP           $remote_addr;
          proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
      }

      access_log    /var/log/nginx/access.log main;

      client_header_timeout 60;
      client_body_timeout   60;
      keepalive_timeout     60;
      gzip                  off;
      gzip_comp_level       4;

      # Include the Elastic Beanstalk generated locations
      include conf.d/elasticbeanstalk/healthd.conf;
  }
}

중요한 내용!
나한테 요청오면 http://springboot; 로 보낸다는 것인데, 이것은

조금 위에 있는 server 127.0.0.1:8080; 을 의미한다!

프로젝트 진행할 때 NGINX가 S3로 파일을 업로드할 때 크기 제한을 1MB로 하게 되는데,
프론트엔드에서 압축을 해달라고 해야 한다.
압축을 못한다고 하면 백엔드쪽에서 늘려야 할텐데 그러면 좀 많이 느리게 될 것이다.
백엔드에서 업로드할 때 1MB가 안 되면 늘려주어야 하는데,
이런 크기를 설정할 수 있는 코드이다.

.platform
  ㄴ nginx
     ㄴ conf.d
         ㄴ client_max_body_size.conf

이런 구조로 파일을 생성하고, 아래 코드를 넣어준다.
client_max_body_size 200M;

그리고 application.yml 파일에서도 아래와 같은 코드 부분에서 maxFileSize를 똑같이 조정해주어야 한다고 한다.
스프링부트도, NGINX도 둘 다 조정해주어야 반영된다!

Github Action을 통해 빌드를 해야 하니까, build.gradle에 추가해 주어야 할 것이 있다. (도커 빈스톡은 필요 없음)

jar {
	enabled = false
}

이 코드를 넣어주어야 한다. 이를 통해 깃허브 액션을 통해 빌드가 가능해진다.

우리가 만든 CI/CD는 develop 브랜치에 merge 되었을 때! 돌아간다!

AWS에서 Elastic Beanstalk - 내가 만든 것으로 들어가기

이 이름 복사하기

dev_deploy.yml 파일에 environment_name 값으로 넣어준다!

그리고 아래쪽에 나와있는 애플리케이션 이름을 복사해서,

dev_deploy.yml 파일에 application_name 값으로 넣어준다!

이 부분은 ELB에게 나 이제 배포할 것이라고 요청하는 내용이다.

이 깃허브는 AWS 밖에 있는 것이어서 무슨 권한을 가지고 있냐고 물어보게 된다.
이를 위해 사용자를 만들 것이다.

IAM 메뉴로 와서 사용자 생성을 클릭한다.

이름 설정

권한 옵션은 직접 정책 연결로 선택!

AdministratorAccess-AWSElasticBeanstalk 정책을 선택한다.
-> 이 사용자는 ELB에 100% 모든 행위를 다 할 수 있다는 뜻!
이제 사용자를 생성한다.

만든 사용자 상세보기로 접속한다.

여기에 뜨는 콘솔 로그인 링크가 무엇이냐면,

링크로 접속하게 되면 IAM 로그인 창으로 뜨게 된다.
-> 이 IAM 계정으로는 ELB밖에 못 만든다.

이렇게 되면 깃허브가 어떻게 사용할 수 있냐? -> 액세스 키를 만들어야 한다!
액세스 키 - 액세스 키 만들기로 접속한다.

깃허브 액션은 AWS 외부에서 실행되는 애플리케이션이기 때문에 이 옵션을 선택한다.

설명 태그 아무 값이나 꼭 넣기.

생성한 후에 뜨는 이 액세스 키! 는 복사해서, 깃허브 액션에 넣어주어야 한다.

깃허브 리포지토리 - settings - Secrets and variables - Actions 접속하기

여기에서 Repository secrets에다가 키를 넣어주면 된다. 생성 클릭!

아까 복사한 액세스 키 값을 Secret에다가 넣어주는데,

Name에다가는 dev_deploy.yml에 있는 aws_access_key의 값 중 AWS_ACTION_ACCESS_KEY_ID 이름과 일치하게 넣어준다.
이때 앞에 있는 secrets.는 방금 깃허브에서 설정한 secret을 의미한다.

이제는 비밀 액세스 키 값을 표시한 후 이 값을 복사한다.

secret 생성을 한번 더 하는데, secret 값으로는 방금 복사한 비밀 액세스 키 값을 넣어준다.

Name에다가는 dev_deploy.yml에 있는 aws_secret_key의 값 중 AWS_ACTION_SECRET_ACCESS_KEY 이름과 일치하게 넣어준다.

총 2개의 시크릿이 잘 생성된 것을 알 수 있다.

dev_deploy.yml에서 version_label은 타임스탬프 버전 관련이다.

wait_for_deployment의 의미?
깃허브 액션이 CI가 된 후 CD 과정까지 되는지 기다린 후 OK 한다는 뜻인데 이 과정에서 버전이 조금 꼬이게 된다.
깃허브액션의 버전보다, ELB에 들어간 버전이 더 중요하다.
이런 부분에서 안 되는 경우가 있어서 이 부분을 아예 false로 진행하고자 한다.

무중단 배포는 한 5분 정도 걸린다고 한다.

지금까지 만든 이 과정들을 push한다.

pull request에서 내가 push한 브랜치 -> develop 브랜치로 합쳐지도록 설정한다.

health check API를 만들어주어야 한다.
RootController를 생성하고,

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class RootController {
    @GetMapping("/health")
    public String healthCheck() {
        return "I'm healthy!";
    }
}

위 코드를 입력한다.

로컬에서 실행하면, 잘 뜨는 것을 확인할 수 있다.

이걸 다시 push하면 된다.
그리고 pull request 날려서 develop 브랜치로 합치기!

이 부분은 실은 아직 application.yml에서 중요한 부분을 환경변수를 처리를 안 해서,, 아직 깃허브에 못 올리고 있는데 이 부분 때문에 나는 아직 오류가 나긴 한다!

ELB에 값들을 넣어주고 환경변수 처리해서 진행할 수 있다고 한다.

이게 정상적으로 작동하면 ELB가 작동해서 인스턴스를 생성해서, 2개로 늘어난다고 한다.
이 인스턴스의 퍼블릭 IPv4 주소로 연결하게 되면 조금 기다리다보면 잘 뜨게 된다고 한다.

502가 뜨면 아직 스프링부트가 없는 상태이고, 조금 기다리다보면

이런 페이지가 뜰건데

health 체크를 위해 /health url로 이동하면 잘 뜨게 된다고 한다.

8080 번 포트로 가면? 접속이 안 된다.

+) 도메인을 가비아에서 구매해서 사야 한다.

로드밸런서 - NGINX - 스프링부트 이렇게 3중 구조를 가지는데, 로드밸런서를 뚫어주어야 한다.

Elastic Beanstalk - 구성 - 인스턴스 트래픽 및 크기 조정 - 편집 들어가기

리스너 - 리스너 추가

8080을 입력하고 저장한다

+)
https를 쉽게 적용하는 방법?
DNS주소를 가비아에서 구매해서 사용해야 한다.
UMC 11주차 강의 1:48:50
route 53 - 호스팅 영역

서브도메인을 쓰면 돈을 아낄 수 있다.

www.google.com에서 제일 최상단은?
www.google.com. 생략된 마지막 . 이다.

mail.google.com -> 구글에서 돌아가는 메일 관련 도메인
api.google.com -> 구글 내부 프론트엔드에서 요청하는 것

api.google.com = IP주소

서브도메인을 써서 돈을 아낄 수 있다.
가비아에서 .shop 을 사면 저렴한데,
웹 배포할 때에는 www.project.shop 이런 식으로 진행하고
개발 전용으로는 dev.project.shop,
최종적인 릴리즈는 api.project.shop 으로 서브도메인을 나눠서 작업이 가능하다.

아래 사진에서
별칭을 넣어야 한다.
IP주소를 넣으면 안 된다! 빈스톡이 배포할 때마다 EC2가 매번 없애지기 때문에 탄력적IP 등등 사용이 불가능하다.

레코드에 대한 것은 따로 공부해보기

도메인을 붙여놓고 https를 붙일 수 있다.

가비아에서 도메인 산 후 2시간 정도 기다려야 함

https로 만들어주려면, certificate manager를 쓸 수 있음.

정규표현식 써서 모든 서브도메인 들에 대해 진행

DNS 검증이 좋다고 한다.

이런 식으로 두면 영원히 검증이 안 되기 때문에 route53에서 레코드를 생성해주어야 한다.

인증서가 되고 나면 Elastic beanstalk 리스너에게 넣어주면 된다.

Elastic beanstalk - 해당하는 것 상세보기 - 구성 - 인스턴스 트래픽 및 크기 조정 - 편집

리스너 추가 버튼 클릭

리스너에 443 (https도 넣어준다)

이렇게 https를 진행할 수 있다고 한다.

이런 식으로 CI/CD가 끝난다.

릴리즈 인프라

강의 1:58:40
릴리즈를 제대로 만드는 순간 달에 10만원 정도가 나온다..
쿠버네티스 등등을 쓰면 더 돈이 많이 들어간다..

RDS를 만들어주어야 한다.
RDS 만들 때 서브넷 그룹을 만들어주어야 한다.

가용영역에 a,c로 넣고
서브넷은 1,2로 선택(public)

VPC에서

bean-stalk에 대해 DNS 호스트 이름 활성화를 체크한다.

이렇게 하고 난 후 https가 잘 연결된다. -> 강의 1:59:50

릴리즈 할 때 이 부분 따라해서 진행하기! 강의 2:00:00
private 서브넷을 만들어주겠다. -> release

dev 전용 데이터베이스를 생성해주겠다.

스토리지 자동 저장은 돈 나가니까 끄기

연결에 beanstalk 전용 VPC 선택!
서브넷 그룹도!

퍼블릭 액세스 - 예 체크

보안그룹에는 bean-stalk 보안그룹 추가

가용영역은 설정 안 하면 둘 중 하나로 알아서 들어가게 된다.

추가 구성에서 자동 백업 끄기 -> 돈 나감!

이제 데이터베이스를 생성한다.

release 전용 DB는 나중에 구현 거의 다 되면 진행하겠다,, -> 강의 2:03:00

도커 빈스톡

지금까지 배운 빈스톡으로는 EC2에 서버 스프링 하나만 올릴 수 있다.
도커를 쓰게 되면, 여러 장고, 노드, 스프링 등등을 쓸 수 있게 된다.
도커 빈스톡을 쓰면 dockerfile과 docker compose가 필요하다.

도커허브에서 도커 이미지를 가져오는데
AWS에서 나만의 도커 허브를 제공해주는데, 이게 ECR이다.
ECR에 도커 이미지를 올리고, 빈스톡에 배포할 때 끌어와서 환경을 만든다.
도커허브에서 바로 가져와도 됨.

릴리즈 인프라 구축

릴리즈에서는 데이터베이스를 private에 숨긴다.
bastion host와 ssh tunneling을 통해 접근이 가능하다.

프리티어는 리전 당 750시간 -> 서울리전에 ec2 프리티어가 2대면 24 * 60 = x
x - 750 만큼 돈이 나간다...

따라서 돈을 아끼기 위해
dev -> 도쿄,
릴리즈 -> 서울
이렇게 진행한다.

강의 2:14:00 bastion host 만들기 진행

yml 파일에서 환경변수로 설정하고 이 환경변수를 beanstalk에 넣을 수 있다.

Elastic beanstalk - 내 env 선택 - 구성 탭 접속 - 업데이트,모니터링 및 로깅
에서 키와 값을 관리할 수 있다!

여기에 환경변수로 넣고 관리 가능!

로컬에서 실행할 때에는
Edit configuration 에 들어와서

환경변수를 넣어주면 된다.

강의 2:19:30
릴리즈 관련해서,
아까 만든 bastion-host에 대한 퍼블릭 ipv4주소를
ssh로 연결해서 진행할 수 있다. -> ssh 터널링을 이용한 것!
안전해지는 방법이다...

가비아에서 도메인주소 구입해서 연결하기!

https://jie0025.tistory.com/504
이 글을 참고해서 구매를 진행했다.

gomin-chingu.site 로 만들 계획이다.

구매한 후, 도메인을 연결해주겠다.
AWS에서 Route 53 - 호스팅 영역 생성 - 구입한 도메인 이름 입력

호스팅 영역을 생성한 후 NS 유형에 값/트래픽 라우팅 대상을 확인한다.

위 상태에서 레코드 생성 버튼을 클릭한다.
개발 전용으로 만들기 위해 dev 로 만들어주었다.
그리고 별칭을 활성화시켜주어야 한다. ELB가 EC2를 지웠다 만들었다 하기 때문에, 별칭으로 지정해주면 된다.
트래픽 라우팅 대상을 Elastic Beanstalk 환경에 대한 별칭 - 서울 - beanstalk 선택!