Azure portal ... 가만두지 않을테다.

 

inbound IP 는 대상에 집어넣으면 안된다.

 

소스에다가 카테고리 IP address 로 바꾸고 해당 IP 넣어줘야한다.

 

대상에다가 넣고 삽질하다가 원래 안되는줄알고 집어 던질 뻔했다. nginx 로 가서 detour way 찾았고, allow IP list 작성 후 deny ALL other ip address 해버렸다. nginx 문구 나오면서 403 나오는게 너무 분해서 계속 찾기 시작했다. 한참 돌아본 후 대상이 아닌 소스 카테고리에 변경해줘야 하는 것을 알았다. 

 

번역에 문제가 참 많다. UI / UX 는 바라지도 않으니 제발 번역이라도 잘 해놨으면.. 하는 생각이 들었다.

덕분에 mongoDB / backend 사이에 proxy 잡아줘야 하는 작업을 못했다... 한글 버전을 쓰고 있는 나의 잘못이다.

 

빨리 스테이징 셋업이 필요하다.

결국 오늘 한 일 FE / BE port IP inbound 걸고 DB 용 vm 에 inbound 걸어둔거 끝..

 

유럽 클라 서버 아이피도 뚫어놔야한다 까먹지 말자. 

 

Docker 걷어내고 ACI 집에 넣는 작업 먼저 하려고한다. 따로 Azure pipeline이라는 기능이 있어 애플리케이션 레벨 빌드 테스트부터 전부 셋업해두려고 한다. 

 

사실 ACI 같은 경우, 개발 풀 자체가 전무후무 해보이기도 해서 왜 쓰는지 잘 모르겠지만.. 같은 Azure Platform에서 관리할 수 있다는 점 때문에 되도록 깊이 들여다보려 한다.

 

오늘 다 하고 잘거다.

죽어도 마무리 하고 잔다.

 

proxy setup 끝 

Backend Source 수정 필요 -> proxy 서버로 Request 날아가도록.. 프록시는 안전상 설정해두긴 했지만 포탈 credential이 통째로 날아가지 않는 이상 굳이 필요한 작업인가 싶기도 하다. 앞으로의 기능도 Load balancing 정도 일 듯 해서. 

 

Azure Pipeline 필요성이 크지 않다면 jenkins로 파이프라인 잡으려 한다.

 

'Configuration' 카테고리의 다른 글

실무 개발 환경 / 배포 시 환경 설정  (0) 2022.12.11

react, next 개발 시, 개발 환경과 배포 환경에 대한 기본 설정에 대한 정리.

 

node.js 에서 개발을 시작. 

 

첫번째, package.json 파일에 기본 설정을 하게 된다.

이때 package.json이란 현재 프로젝트에 관한 정보와 패키지 매니저 (npm, yarn)을 통해 설치한 모듈들의 의존성을 관리하는 파일을 말한다. Json 포멧으로 관리한다.

 

의존성 모듈을 설치하게 되면 dependencies 라는 배열 내에 해당 모듈과 이름이 추가된다. 내가 추가하지 않아도 패키지 매니저를 통해 모듈을 설치하면 자동으로 package.json을 수정해주니 딱히 건드릴 일은 없다.

 

두번째, 개발을 진행하다보면 개발환경과 배포환경을 다르게 해야 하는 경우가 생긴다.

예를 들면, DB를 mysql로 진행한다고 하였을때, 현재 운영하는 DB와 개발 시 동작이 가능한지를 판단하는 DB는 다르게 만들어야 하기 때문에 DB의 id/pw가 다르게 설정을 하여 시작 시 필요한 DB를 사용할 수 있게 만드는 것이 좋다. 정리하면 개발환경과 운영 환경에서의 변수 값을 다르게 설정해야 할 경우 아래의 방식을 이용하면된다.

 

개발 환경과 배포 환경을 따로 설정

환경변수 선언(.env)을 통해 한다. .env의 종류는 여러가지가 있는데, .env.local, .env.development, .env.test, .env.production이 있다. 

 

0. 기본 개념 ( 환경 변수) 

결론만 정리하면 개발용, 테스트용, 릴리즈용 환경변수를 위한 env 파일을 각각 따로 생성하여 관리하여야 하며, env 파일은 말그대로 환경변수를 저장하고, package.json 에서 npm 또는 yarn명령어를 다루게 된다.

 

기본적으로 node.js 는 production와 Development, Test로 구분하여 사용한다. Build시 또는 run시에 실행 명령어에 따라 자동으로 NODE_ENV값이 정해진다.

 

// production 배포 env실행
npm run build

// development 개발 env 실행
npm start

// test 개발 env실행
npm run test

실행 OS에 따라 환경변수를 설정하는 방법이 다르기 때문에, 환경 변수 설정 시 undefined가 나오는 경우가 있다. 따라서 아래의 명령어를 실행하여 cross-env 모듈을 사용하여 환경변수를 설정하는 것이 좋다.

 

npm i cross-env

설치 후에 아래와 같이 package.json 에서 사용이 가능하다. 

이후에 package.json 에서 scripts 내에 명령어를 지정해줌으로써 사용이 가능하다.

// 사용법 'cross-env 환경변수1=값 환경변수=2값 실행 명령어

"scripts" : {
	"local":"cross-env REACT_APP_API_URL=localhost react-scripts-start",
    "build":"cross-env REACT_APP_API_URL=999.99.99.99 react-scripts start"
}

0.1 .env.local (로컬 개발 시)

.env.local 파일은 .env를 덮어쓰는 파일로, test 환경외의 모든 환경에서 로딩된다.

 

02. .env.development

.env.development 파일은 개발환경 시 아래의 명령어를 치면 사용된다. 만약, .env.development.local이 있다면, .env.development을 덮어쓴다.

 

npm start 시 env 파일도 실행되는 우선순위가 있다. 우선 순위는 아래와 같다. 

.env.development.local > .env.development > .env.local > .env

 

0.3 .env.production (서버 배포 시)

.env.production 파일은 배포 환경 시 사용되며, 아래의 명령어를 치면 자동으로 사용된다. 만약, env.production.local 이 있다면, .env.production을 덮어쓴다.

 

npm run build 시 env 파일도 실행되는 우선순위가 있다. 우선 순위는 아래와 같으며 오른쪽을 먼저 실행한다.

.env.production .local > .env.production > .env.local > .env

 

0.4 .env.test

.env.test 파일은 테스트 환경 시 사용한다. 만약, .env.test.local 이 있다면, .env.test을 덮어쓴다.

npm run test $ yarn test

 

npm run test시 .env 파일도 실행되는 우선순위가 있다. 우선순위는 아래와 같다.

.env.test.local > .env.test> .env.local > .env

오른쪽이 우선실행된다.

 

'Configuration' 카테고리의 다른 글

Memo - 막 적는 메모.  (0) 2023.11.05

+ Recent posts