군붕이의 메모장

여러명이서 프로젝트를 진행하다보면 환경변수 관리가 불편해진다. 이 때 도입할수 있는 방식이 AWS에서 제공하는 Parameter Store 이다. Parameter Store를 사용하면 환경변수를 관리를 중앙화 할 수 있다. ● AWS Parameter Store 우선 AWS 공식문서에 따르면 아래와 같은 서비스로 소개하고있다. AWS Systems Manager의 기능인 Parameter Store는 구성 데이터 관리 및 암호 관리를 위한 안전한 계층적 스토리지를 제공합니다. 이러한 서비스를 통해서 중요한 데이터를 중앙화하여 관리가 가능하다. https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/systems-manager-paramet..

● Nest.js의 body-parser Nest.js의 경우 기본적으로 bodyparser 라이브러리를 사용해서 json 데이터를 변환한다. nest new [name]을 통해서 nestjs 프로젝트를 생성하면 아래 사진처럼 node_modules 내부에 bodyparser가 설치되어있다. 자바스크립트는 기본적으로 UTF 인코딩을 지원하기때문에 실제 bodyparser 내부를 들여다보면 UTF를 제외한 인코딩 방식은 에러로 처리하는것을 확인할 수 있다. body-parser/lib/types/json.js // assert charset per RFC 7159 sec 8.1 var charset = getCharset(req) || 'utf-8' if (charset.slice(0, 4) !== 'ut..

실제 배포된 프로덕션 환경에서는 일반 유저가 API 문서에 접근하면 보안적인 문제가 발생할수 있다. API 문서에 접근하는것을 차단하기위해서 로그인, 토큰인증 등 다양한 방법이 존재한다. 그 중에서도 아주 간단하게 express-basic-auth를 활용한 로그인된 유저에게만 API 문서에 접근권한 부여가 가능하다. 해당 라이브러리 이외에 요구사항에 따라 미들웨어를 제작해서 /api 요청에 대한 접근 컨트롤이 가능할것이다. ● express-basic-auth 설치 npm i express-basic-auth ● express-basic-auth 활성화 import * as expressBasicAuth from 'express-basic-auth'; async function bootstrap() { ..

● this 키워드? this 키워드는 자신이 속한 객체또는 생성자 함수를 통해 생성할 인스턴스 를 가르킨다. 예를 들어 메소드에서 this 키워드를 사용하면 어떤 객체에서 호출이 되었는지 확인이 가능하고 생성자 함수를 통해 생성될 인스턴스 또한 참조가 가능하다. ● 객체에서 재귀호출로 참조하기 const obj = { data: 10, getData() { return obj.data; } }; console.log(obj.getData()); 하지만 위 코드는 일반적이지 않고 바람직하지 않다고 한다. 객체에서는 재귀호출로 참조가 가능하지만 생성자 함수에서는 위 방법이 불가능하다. 그 이유는 생성자 함수의 경우 new 키워드로 인스턴스가 생성되어야 참조가 가능하기 때문이다. ● 메소드에서의 this 바..

● 자바스크립트 변수 우선 자바스크립트에는 변수를 선언하는 3가지의 방식이 존재한다. 1. var ES5 까지의 버전에서 변수를 선언할때 사용하는 키워드로 주요 특징으로는 아래와 같다. 변수의 중복 선언을 허용 var a = 1; var a = 2; console.log(a); // 2 이러한 특성은 중복된 이름의 변수를 또 선언하게 될 경우 의도치않은 값이 할당되는 부작용이 발생한다. 함수 레벨의 스코프를 가진다 var a = 1; if (a === 1) var a = 10; console.log(a); // 10 var b = 1; for (var b = 1; b < 10; b++) {} console.log(b); // 10 if문, for문 등 과 같이 함수 외부에서 선언한 변수는 코드블록 내에서..

우선 현재 서버의 경우 인프라가 아래처럼 구성되어 있다. 만약 서버에서 코드를 몇줄만 수정해도 아래 과정을 거쳐서 다시 배포해야 한다. 1. 코드 수정 후 도커 이미지 빌드 2. 도커 이미지를 ECR에 업로드 3. EC2 SSH 접속하여 업로드된 도커 이미지 다운로드 4. 도커 이미지 실행 변경 작업은 유지보수를 하면서 계속해서 일어나게 되는데 매우 비효율적으로 생각됬다. 그래서 repository에 push될 경우 github actions를 사용하여 위 과정을 자동화해서 배포가 되도록 구성했다. 우선 Github Actions의 경우 이전 클라이언트에서 CI/CD를 구축하면서 적어둔게 있어 URL로 대체했다. https://iamiet.tistory.com/entry/S3%EB%A1%9C-%EB%B0..

지난번 CloudFront를 사용하면서 클라이언트를 배포하면서 HTTPS를 적용했다. https://iamiet.tistory.com/entry/AWS%EC%97%90-React-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0-3-CloudFront-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0 AWS에 React 배포하기 - 3, CloudFront 배포하기 이전글 : https://iamiet.tistory.com/entry/AWS%EC%97%90-React-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0-2-Route53-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0-%EB%B0%8F-SSL-%EC%9D%B..

우선 현재 클라이언트의 경우 인프라가 아래처럼 구성되어 있다. 만약 클라이언트에서 코드를 몇줄만 수정해도 아래 과정을 거쳐서 다시 배포해야 한다. 1. 리액트 프로젝트 빌드 2. S3에 업로드 3. CloudFront 캐시 무력화 변경 작업은 유지보수를 하면서 계속해서 일어나게 되는데 매우 비효율적으로 생각됬다. 그래서 repository에 push될 경우 github actions를 사용하여 위 과정을 자동화해서 배포가 되도록 구성했다. ● Github Actions Github Actions의 경우 가장 최상위 개념인 Workflow가 존재한다. Workflow는 특정 로직을 자동화해둔 파일(과정)이라고 생각하면 된다. 프로젝트 루트폴더 안에 ./github/workflows/main.yaml 형식으..

● Docker 빌드환경 설정하기 프로젝트의 루트폴더에 2개의 파일을 생성해야 한다. - Dockerfile 도커 이미지를 위한 설정파일, 즉 이미지가 어떻게 구성되어있는지 확인할 수 있는 파일이다. 도커 이미지를 빌드하면 해당 파일에 적어둔 커맨드를 통해서 이미지가 빌드된다. # docker의 이미지를 정의, 해당 프로젝트에서 node 16 버전을 사용 FROM node:16 # /app 이라는 폴더에서 프로젝트를 실행할 예정이므로 mkdir 명령어로 폴더를 생성 RUN mkdir -p /app # /app 이라는 폴더에서 프로젝트를 실행 WORKDIR /app # Dockerfile이 위치한 폴더의 모든 내용을 /app으로 복사 COPY . . # 프로젝트에서 사용한 패키지를 package.json ..

이전글 : https://iamiet.tistory.com/entry/AWS%EC%97%90-React-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0-3-CloudFront-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0 AWS에 React 배포하기 - 3, CloudFront 배포하기 이전글 : https://iamiet.tistory.com/entry/AWS%EC%97%90-React-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0-2-Route53-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0-%EB%B0%8F-SSL-%EC%9D%B8%EC%A6%9D%EC%84%9C-%EB%B0%9C%EA%B8%89 AWS..