Engineering_S/W & H/W

  해당 서버에 Nginx가 설치 되어 있어야 한다. 아래글 참고 Nginx 설치 - Ubuntu 네트워크 구성 IpTime 공유기 1대 (모델 : T5008SE) 리버스 프록시 서버 1대 -01서버 (모델 : JECS-N5095B, OS : Ubuntu 22.04, Nginx설치) 서버 1대 - 02서버 (모델 : JECS-8250B-i5, OS : Ubuntu 20.04) 1. 공유기 포트포워딩은 01서버로 지정 TCP 80 -> 01서버 : 80 TCP 443 -> 01서버 : 443 2. 도메인 DNS는 아래와 같이 진행 (저는 AWS의 Route53사용) example.com -> 01서버 IP. A레코드(www포함) 02서버는 3000포트가 서비스 포트이다. 따라서 Nginx가 프록시 요청을 받을시 02서버의 3000포트로 연결해 줘야 한다. 3-1. CertBot을 설치한다. apt 업데이트 $ sudo apt update copy snapd 설치 $ sudo apt install -y snapd copy 코어 설치 및 새로고침 $ sudo snap install core; sudo snap refresh core copy Snap를 이용해서 certbot 설치 $ sudo snap install --classic certbot copy "/usr/bin/certbot" -> "/snap/bin/certbot"으로 바로가기(심볼릭 링크) 설정 $ sudo ln -s /snap/bin/certbot /usr/bin/certbot copy certbot 버전 확인 (사용버전 : 5.2.2) $ certbot --version copy 4. 01서버를 통해서 SSL인증을 하기 위해서는 인증서가 필요하다. 먼저 인증을 받기위한 Nginx conf파일을 생성 - 도메인 증명을 위한 80 port 사용 파일경로 : /etc...

 Nginx 공식 사이트 :  https://nginx.org/ Nginx 공식 문서 :  https://nginx.org/en/docs/ 설치시 참고한 공식 문서 :  https://nginx.org/en/linux_packages.html 1. apt 업데이트 $ sudo apt update copy 2. 필요 apt install $ sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring copy 3. 공식 nginx 서명 키를 다운 $ curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null copy 4. 공식 nginx 서명 키를 검증 $ gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg copy 5. Nginx 패키지의 안정적 설치를 위하여 커멘드 실행 $ echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list 6. Nginx 설치 $ sudo apt install nginx copy 7. Nginx 동작확인 $ sudo systemctl status nginx copy 8. Nginx 버전확인 $ nginx -v copy nginx가 실행되는 웹사이트에 접속하면 위 사진...

 NextJS 또는 React를 배포할때 Build 또는 "npm run dev"를 이용해서 배포를 한다. 그런데 "npm run dev"시점에서 환경변수가 적용이 되지만 Build에서는 Build때 환경변수가 적용되어야 한다. 그래야 실제 배포때 env파일이 적용이 되기 때문이다. 아래 글은 Dockerfile에서 Build시 환경변수를 적용하는 방법이다. VITE를 이용해서 빌드를 할려고 하는데 필요한 환경변수는 아래 2개이다. VITE_API_URL VITE_FILE_UPLOAD_API_URL 먼저 Dockerfile에 해당 ENV파일이 저장될수 있도록 build전 단계에서 작성. 사진1) Dockerfile - ARG, ENV셋팅 GitHub의 Secreat를 사용하기 위해서는 ARG셋팅이 필요하다. Git Action의 yml파일에서 환경변수값을 Docker에 전달하기 위해서 해당 셋팅을 Dockerfile에 작성해야 합니다. ARG를 선언하지 않으면 build시 Dockerfile내부에 접근할수 없습니다. 이후 ENV로 해당 값을 지정 합니다. 이때 "$VITE_API_URL", "$VITE_FILE_UPLOAD_API_URL" 부분은 GitHub에서 갖고옵니다. 사진2) .yml파일의 build부분 수정 사진2의 84 ~ 86번째 줄이 build과정중에 ENV파일을 추가하기 위한 부분입니다.  사진3) Repository secrets 설정 옵션 사진4) Repository secrets 설정 옵션을 지정 마지막으로 사진3, 4와 같이 build시 저장할 Repository secrets를 설정한다. 위 설정이 다 된후에 CI/CD가 진행되는 branch에 푸시할시 build과정에서 Repository secrets를 이용해서 build를 진행한다.

 "Apache"와 "Let's Encrypt"와 PC를 이용해서 HTTPS웹사이트를 올릴수 있다. 1. 유저가 URL을 이용해서 서버(React)에 접속을 한다. 2. Route53에 대응되는 IP값을 클라이언트에 응답한다. 3. 해당 서버의 IP로 클라이언트가 접속한다. 4. 아파치 서버에서 해당 URL을 확인한다. 5. "Let's Encrypt"에 발급받은 SSL파일을 확인한다. 6. 아파치에서 "Let's Encrypt"에 발급받은 SSL을 적용한다. - 정해진 도메일을 이용해서 HTTPS접속 7. React에 접속 위 개념도에서 "Let's Encrypt"가 자동으로 SSL인증서를 갱신해 준다. 따라서 수동으로 기간이 다한 인증서를 교체할 필요가 없다.  다음 글에서는 실제 작업 방법에 대해서 터미널 화면과 함께 작성하겠다.

React Query란 무엇인가? React Query 는 서버에서 데이터를 가져오고, 캐싱하고, 갱신하고, 동기화하는 과정을 쉽게 만들어주는 비동기 상태 관리 라이브러리 입니다. 기존 방식의 문제점 React에서 데이터를 fetch할 때 보통 다음과 같은 패턴을 반복해야 했습니다: const [data, setData] = useState(null); const [loading, setLoading] = useState(true); const [error, setError] = useState(null); useEffect(() => { fetch('/api/data') .then((res) => res.json()) .then(setData) .catch(setError) .finally(() => setLoading(false)); }, []); → 중복되고 관리 포인트가 많아지는 문제를 React Query가 해결합니다. React Query의 핵심 기능 자동 캐싱: 동일 요청을 빠르게 응답 로딩/에러 상태 자동 제공: isLoading, isError 등 제공 백그라운드 리페치: 포커스 시 최신 데이터 재요청 자동 리트라이: 실패 시 자동 재시도 Query 무효화: mutate 후 관련 쿼리 리페치 Devtools: 쿼리 상태 시각화 기본 사용 예시 useQuery 예시 import { useQuery } from '@tanstack/react-query'; const fetchUsers = async () => { const res = await fetch('/api/users'); return res.json(); } export d...

React 애플리케이션을 개발할 때 상태(state)는 핵심 개념입니다. 이 상태는 크게 클라이언트 상태 와 서버 상태 로 나눌 수 있습니다. 각각의 상태는 성격과 관리 방법이 다르기 때문에 구분해서 이해하고 사용하는 것이 중요합니다. 클라이언트 상태 (Client State) 클라이언트 상태 는 브라우저 메모리 또는 React 내부에서 관리되는 상태로, 서버와의 직접적인 연동이 필요하지 않습니다. 사용자 인터페이스(UI)와 관련된 정보들이 주로 해당됩니다. 예시 모달의 열림/닫힘 상태 폼 입력값 (예: 이름, 이메일 등) 다크모드/라이트모드 토글 현재 탭이나 필터 선택 상태 특징 React의 useState , useReducer , Context API 또는 상태 관리 라이브러리(Zustand, Recoil 등)를 통해 관리됩니다. 빠르게 변하고 UI와 밀접하게 연관되어 있습니다. 새로고침 시 초기화됩니다. 비동기 처리가 필요하지 않습니다. 서버 상태 (Server State) 서버 상태 는 외부 시스템(API, 데이터베이스 등)에 존재하며, 데이터를 가져오기 위해 비동기 요청 이 필요합니다. 데이터의 소유권이 외부에 있기 때문에 이를 React 애플리케이션과 동기화 해야 합니다. 예시 사용자 목록 (GET /users) 게시글 목록 (GET /posts) 서버의 공지사항 정보 주문 내역, 결제 상태 특징 항상 최신 상태로 유지해야 하며, 서버의 데이터 변경을 반영해야 합니다. 요청 도중 로딩 상태와 에러 상태를 함께 관리해야 합니다. React Query, SWR, Apoll...

 "npx create-react-app ..."의 CRA의 개발이 중단됨에따라 다른 대안으로 React프로젝트를 생성해야 한다. 그중에 Vite가 있는데 CRA처럼 쉬고 간단하게 생성할수 있다. 1) 사전 준비 - 2025년 기준 Node.js 20+ 권장 (LTS). 버전 확인: $ node -v copy 2) 프로젝트 생성(이름: my-app ) 버전은 기본 최신(latest)으로 설정할 수 있으며 필요시 이전 버전으로 설정할 수 있다. (공식사이트의 Version참고 ) 대화형(템플릿 선택 프롬프트 표시): $ npm create vite@latest my-app copy 1) Window의 Git Bash로 생성 비대화형(바로 React + TS 템플릿): $ npm create vite@latest my-app -- --template react-ts copy pnpm / yarn 사용 시: $ pnpm create vite my-app --template react-ts copy $ yarn create vite my-app --template react-ts copy 3) 의존성 설치 & 실행 $ cd my-app copy $ npm install copy $ npm run dev copy 기본 개발 서버는 http://localhost:5173 에서 실행된다. 4) 생성 구조(요약) index.html : 진입 HTML src/main.tsx : React 엔트리 src/App.tsx : 샘플 컴포넌트 tsconfig.json : TypeScript 설정 vite.config.ts : Vite 설정 5) TypeScript 엄격 모드(선택) tsconfig.json 에서 "strict": true 권장. 6) 경로 별칭 설정(선택) vite.config.ts 예시: import { defineCo...

1. ssh key 생성 $ ssh-keygen -t ed25519 -C "이메일 주소" 사진1) ssh key 생성 기본 경로값은 "~/.ssh/id_ed25519"를 사용한다. 2. ssh 에이전트 실행 및 키 등록 $ eval "$(ssh-agent -s)" $ ssh-add ~/.ssh/id_ed25519 사진2) 공개키 조회 위 2개의 터미널을 "~/.bashrc" 또는 "~/.zshrc"에 추가해서 재부팅 후에도 키가 등록되게 할수 있다. 3. 공개키를 GitHub에 등록 $ cat ~/.ssh/id_ed25519.pub 사진3) public key GitHub에 들어가서 Setting을 클릭한다. 사진4) Access 설정에서 "SSH and GPG keys"을 클릭한다. 사진5) SSH and GPG keys 선택 "New SSH Key"를 선택해서 터미널에서 복사한(사진3) public key를 추가한다. 사진6) public key를 넣기 생성이 정상적으로 됬으면 아래와 같이 "Authentication keys"가 추가된 것을 확인할수 있다. 다만 한번도 사용이 안되어 있어서 "Never used - Read/write"로 되어있다. 사진7) Authentication key 추가 모습 4. ssh config 설정 .ssh 폴더안에 config파일을 생성해서 아래와 같은 내용을 추가한다. Host github.com   HostName github.com   User git   IdentityFile ~/.ssh/id_ed25519   IdentitiesOnly yes 사진8) config 저장모습 이후에 권한을 위해서 아래 터미널을 실행 $ chmod 600 ~/.ssh/config 제대로 설정됬는지 아래 터미널을 실행할수 있다. $ ssh ...

 기존의 github의 Repository를 새로운 Repository에 올려야 하는 경우가 있다. 위 사진에서 기존(Repository1) 레파지토리의 코드를 새로운(Repository2) 레파지토리에 옮길 것이다. 먼저 dev-test을 master로 변경 이제 새로만든 레파지토리(test_new)의 URL을 복사한다. 해당 레파지토리 URL에 해로운 remote를 생성한다. 새로운 리모트를 위 사진처럼(origin_new) 추가한다. 다음에 해당 리모트(origin_new)로 푸시 한다. 이제 다른 Repository에서 작업을 할수 있다.

  SSE(Server Side Event)란 서버에서 클라이언트로 실시간 데이터를 보내는 기술이다. HTTP 통신은 일회성 요청이기 때문에 이후의 서버에서 데이터를 클라이언트로부터 요청받기 전까지는 응답할수 없다.  하지만 SSE를 이용하면 서버에서 클라이언트로 데이터를 실시간으로 응답할수 있다. 해당 데이터 흐름은 서버에서 클라이언트로 이동하는 단방향 통신이며 역으로는 통신할수 없다.  장점 1. WebSocket, Poling, LongPoling를 이용하지 않고도 서버에서 클라이언트에 데이터를 전송할수 있다. 2. HTTP의 GET요청을 이용해서 보내기 때문에 기존의 HTTP 프로토콜을 이용하면 된다. 3. 네트워크가 종료 되어도 다시 자동으로 연결을 시도한다. 4. HTTP의 GET요청을 이용해서 지연시간을 조절할수 있다. 예로들어 SSE의 시간을 1시간으로 하면 1시간 후에 SSE가 해제된다. 단점 1. SSE로 응답하는 클라이언트가 많을경우 서버에 부하가 가해진다. 2. GET 메소드만 지원해서 전달 가능한 파라메타가 제한이 된다. 3. 클라이언트에서 페이지를 닫아도 서버에서 알수가 없다. 4. 한번 보낸 데이터는 취소가 불가능하다. 위와 같은 장단점을 갖고있다. 그래도 WebSocket, SocketIO를 이용해서 작성하는 것보다 SSE가 더 간단히 작성할수 있는 장점이 크다. Postman을 이용해서 테스트가 가능하다. 먼저 "localhost:3000/sse/1"로 GET요청을 한다. 여기서 숫자 1은 클아이언트에서 수신받을 ID이고 이 ID로 서버가 SSE응답을 한다. // /src/sse/sse.controller.ts import { Controller , Get , MessageEvent , Param , Sse } from '@nestjs/common' ; import { EventEmitter2 } from '@nestjs/event-emi...

 AWS의 S3에 정적 웹사이트(React)를 Build해서 올리는 방법입니다. 해당 블로그 글을 작성시 아래 글들을 참고하였습니다. https://s0ojin.tistory.com/48 참고링크 :  AWS S3에 CloudFront를 이용해서 HTTPS(SSL) 적용하기 GitAction을 이용해서 업로드 합니다. 해당 블로그 글에는 React를 이용해서 CI/CD작업을 작성하겠습니다. 1. yaml파일 작성 루트 경로에서 .github/workflows 폴더 안에 하나의 yaml(front-build.yaml)파일 하나를 생성한다. name : Front Deployment # trigger가 되길 바라는 action을 입력합니다. push / pull_request가 있습니다. # GitHub에서 직접 실행할려면 workflow_dispatch를 사용한다. # 저는 develop 브랜치에 push가 되면 actions을 실행하도록 설정했습니다. # S3에 배포하기 위해서 아래와 같은 Secreat이 설정되어야 합니다. # secrets.AWS_S3_ACCESS_KEY_ID : IAM AWS Access Key # secrets.AWS_S3_SECRET_ACCESS_KEY_ID : IAM AWS Secret ACCESS Key # secrets.AWS_S3_BUCKET_NAME : S3 Bucket Name on : workflow_dispatch # 위의 이벤트가 트리거되면 실행할 목록입니다. jobs : build : name : react build & deploy # runner가 실행될 환경을 지정합니다. runs-on : ubuntu-latest # name은 단계별로 실행되는 액션들의 설명을 담은 것으로, 나중에 github action에서 workflow에 표시됩니다. # uses 키워드로 Action을 불러올 수 있습니다. steps : # 레포지토리에 접근하...