풀소유

웹 애플리케이션을 개발할 때, 로컬 환경에서 개발하다가, 서버에 배포할 때, 서버 환경에서 운영하게 됩니다. 이때, 로컬 환경과 서버 환경이 달라서 발생하는 문제를 해결하기 위해서는 환경 변수를 설정할 필요가 있습니다. 저는 사이드 프로젝트를 준비하면서 로컬에서 사용할 환경 변수를 지정하기 위해 @nestjs/config 라이브러리를 사용하였습니다. @nestjs/config NodeJS에는 대표적으로 환경 변수를 설정하는 라이브러리 dotenv가 존재하며 NestJS에서는 dotenv를 내부적으로 사용하는 @nestjs/config 라이브러리가 존재합니다. npm i --save @nestjs/config . env 파일 먼저 Root 디렉터리에 .dev.env 파일을 생성합니다. Root 디렉토리란 ..

인프라 구성도 저번 시간에 이어 Github Actions를 설정하고 workflow 파일을 작성하겠습니다. Github Actions에 Secret 설정하기 Github 레포지토리의 Settings > Secrets and variables > Actions 탭을 선택하고 New repository secret을 선택합니다. 이전에 S3에 접근하기 위해 생성한 사용자 정보와 데이터베이스 정보와 OAuth 정보를 등록합니다. Workflow 파일 작성하기 프로젝트 디렉토리에 .github/workflows/workflow.yml 파일을 생성합니다. 파일명은 사실 아무거나 괜찮다고 합니다. name: Deploy NestJs Application on: push: branches: [ release ] p..

NestJS의 Provider 란? 프로바이더는 Nest의 기본 개념입니다. 대부분의 기본 Nest 클래스는 서비스, 리포지토리, 팩토리, 헬퍼 등 Provider로 취급될 수 있습니다. 프로바이더의 주요 아이디어는 종속성으로 주입할 수 있다는 것입니다. 즉, 객체는 서로 다양한 관계를 만들 수 있으며 객체의 인스턴스를 연결하는 기능은 대부분 Nest 런타임 시스템에 위임될 수 있습니다. 위에 글은 NestJS 에서 설명하는 Provider를 번역한 글입니다. 저는 이글을 보고 Provider를 스프링의 Bean이라고 이해했습니다. 애플리케이션에서 사용되는 객체를 정의하고, 의존성 주입 시스템에 등록하며 인스턴스를 필요한 곳에 제공한다는 점이 Bean과의 공통점이지만 Bean은 기본적으로 Singleto..

인프라 구성도 이번 시간에는 저번 시간에 이어 프라이빗 서브넷에 RDS를 구축합니다 데이터베이스 서브넷 그룹 생성 RDS를 이용하기 위해서는 서브넷 그룹을 생성해야 합니다. 서브넷 그룹은 두 개 이상의 가용영역에 생성된 프라이빗 서브넷으로 구성합니다. 이전에 새성했던 프라이빗 서브넷 두개를 선택후 생성합니다. 보안 그룹 생성하기 RDS에 연결될 보안 그룹을 생성합니다. 저는 MariaDB를 사용하기에 인바운드 규칙에 MYSQL/Aurora을 선택했고 소스로 EC2-SG를 선택했습니다. EC2에 연결되어 있는 보안 그룹의 아웃바운드를 수정합니다. 대상으로 RDS에 연결되어있는 보안그룹을 선택합니다. RDS 생성하기 사용하고 싶은 데이터베이스 엔진을 선택합니다. db 인스턴스 식별자와 마스터 사용자 이름, ..

인프라 구성도 이전에 구성한 서브넷에 NestJS와 NextJS를 위한 오토스케일링 그룹과 ALB를 배포 후 HTTPS를 적용할 계획입니다. Route53에 도메인이 있어야 진행할 수 있습니다. 생성하는 리소스는 모두 EC2 서비스에서 생성 및 편집할 수 있습니다. 보안 그룹 생성하기 보안 그룹(Security Group)은 EC2 인스턴스와 RDS, Load Balancer 등 AWS 리소스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다. 보안 그룹은 인스턴스 또는 서비스마다 적용되며, 각 보안 그룹은 특정 포트, 프로토콜, IP 주소 범위에 대한 규칙을 설정하여 허용되는 트래픽을 제한할 수 있습니다. 로드 밸런서용 보안 그룹 인터넷으로부터 오는 HTTP와 HTTPS를 허용..

인프라 구성도 이번 시간에 생성하게 될 인프라 구성도입니다. VPC와 퍼블릭 서브넷, 프라이빗 서브넷, 그리고 서브넷에서 사용하게 될 라우팅 테이블과 NACL에 대해서 다룹니다. AWS 콘솔을 이용하면 생성하기 쉽고 또한 많은 블로그들이 있기 때문에 개념적인 내용과 설정에 대해서만 집중하겠습니다. VPC 생성하기 IPv4로 CIDR로 10.0.0.0/16를 입력하고 생성해 줍니다. (10.0.0.0 ~ 10.0.255.255입니다) VPC 설정 옵션 중에 DNS라는 단어가 나와서 헷갈리는 몇 가지 옵션이 있습니다. DNS 호스트 이름 활성화 옵션은 EC2 인스턴스의 호스트 이름을 DNS에 등록하는 옵션이며, DNS 확인 활성화 옵션은 DNS 서버가 호스트 이름의 소유자가 DNS 레코드를 변경할 수 있는 ..

사이드 프로젝트를 AWS에 배포하는 과정을 기술합니다. 인프라 구성도 저희 사이드 프로젝트는 5월부터 약 한 달간 운영되는 서비스로 트래픽을 전혀 예상할 수 없고 비용을 최대한 아끼는 쪽으로 인프라를 구성할 계획입니다. 이번 시간에는 간단히 설명을 진행하고 이후 시리즈로 각 단계별로 자세히 다뤄보겠습니다. 배포 배포는 GithubAction과 CodeDeploy를 통해 이루어집니다. release 브랜치에 코드가 merge 혹은 push 되면 Github Action에 의해 빌드되고 S3로 ZIP파일이 업로드됩니다. 이후 EC2에 CodeDeploy Agent가 S3에 접근하여 각각에 EC2에 배포를 진행합니다. EC2에는 Nginx가 리버스 프록시로 사용하고 뒤에 각각의 애플리케이션이 배포됩니다. 무중..

인프라 구성도 이번 시간에는 이미지 상에서 빨간 네모 속, 코드를 빌드하고 배포에 필요한 리소스들을 생성 및 설정하겠습니다. IAM 사용자 생성하기 Github Action에서 S3에 접근하기 위해서 IAM 사용자를 생성해야 하니다. IAM 역할은 AWS 리소스나 사용자에 부여할 수 있기 때문에 IAM 사용자를 생성해 주어야 합니다. AmazoneS3FullAccess와 AWSCodeDeployFullAccess 권한을 부여합니다. 사용자 상세 화면에서 액세스 키 만들기를 선택합니다. 액세스 키 모범 사례 및 대안은 아무거나 선택해 줍니다. 액세스 키는 웬만하면 csv 파일로 다운로드하는 걸 추천드립니다. IAM 역할 생성하기 CodeDeploy에서 EC2에 접근하기 위한 역할 AWSCodeDeployR..

Pipe 클라이언트가 보내는 HTTP 요청으로부터 데이터를 Parsing 하고 Validation 하여 컨트롤러 메서드의 파라미터로 전달하는 중간 레이어이다. 스프링 MVC의 ArgumentResolver와 Bean Validation이라고 생각하면 된다. 스프링의 BeanValidator와 비슷한 구조를 하고 있지만 예외처리를 각각의 Pipe에서 하기 때문에 오히려 코드가 깔끔해질것 같다는 생각이 든다. NestJS 기본 내장 파이프 ValidationPipe: DTO에 대한 유효성 검사를 수행합니다. ParseArrayPipe: 문자열을 배열로 변환합니다. ParseBoolPipe: 문자열을 부울 값으로 변환합니다. ParseEnumPipe: 문자열을 enum 값으로 변환합니다. ParseIntPip..

요청 유효성 검사 UserUpdateDto export class UserUpdateDto { @IsNotIn([' ']) @Length(1, 7) nickname: string; @MaxDate(new Date()) birthdate: Date; } @IsNotIn()는 리스트를 파라미터로 받아 리스트 안에 객체와 같으면 BadRequest를 응답한다. ParseUserUpdateDtoPipe 요청으로 넘어오는 birthdate는 String이다. 때문에 Date 타입으로 변경해야 한다. CustomException은 HttpException을 상속한 커스텀 예외이다. export class ParseUserUpdateDtoPipe implements PipeTransform { transform(va..