✅ TIL

---

서비스의 규모가 복잡해지고 커질수록, 서비스를 배포하는 과정이 복잡해지고 소요되는 시간이 늘어나게 된다.
또한 변경 사항이 생길 때마다 배포 과정을 매번 수동으로 진행한다면, 배포 과정에 많은 시간을 허비해야 할 것이다.

버튼 하나만 클릭하면 전체 배포 과정이 '자동'으로 진행되게 만들 수는 없을까?

이번 유닛에서는 배포 자동화 개념에 대해 학습하고, 실습을 통해 배포 자동화의 장점을 체험해보겠다.

CI/CD

---

CI/CD는 약어로, 몇 가지의 다른 의미를 가지고 있다.

CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다.
CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

CI/CD의 "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.

CI/CD의 단계

---

지속적 통합(Continuous Integration, CI)

---

개발자를 위한 자동화 프로세스라고 볼 수 있으며, Code - Build - Test 단계에서 꾀할 수 있다.

• Code : 개발자가 코드를 원격 코드 저장소 (Ex. github repository)에 push하는 단계이다.
• Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계이다.
• Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는지 확인하는 과정이다.

이 과정에서 개발자는 코드를 잦게 원격 코드 저장소에 push하고, 테스트 및 빌드를 하며 빌드 결과를 통해 빌드가 성공했는지 실패했는지 확인을 하고, 통합 테스트 결과를 통해 개선 방안을 찾는다. 이 지속적인 통합 과정을 통해 개발자는 버그를 일찍 발견할 수 있고, 테스트가 완료된 코드에 대해 빠른 전달이 가능해지며 지속적인 배포가 가능해진다.

지속적 통합은 모든 코드 변화를 하나의 리포지토리에서 관리하는 것부터 시작한다. 모든 개발팀이 코드의 변화를 확인할 수 있기 때문에, 투명하게 문제점을 파악할 수 있다. 그리고 잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합한다. 이때, 기본적인 테스트도 작동시킬 수 있다. 이렇게 지속적 통합을 통해 개발팀은 각자 개발한 코드를 이른 시점에 자주 합치고 자주 테스트 해볼 수 있다.

지속적 통합으로 보안 이슈, 에러 등을 쉽게 파악할 수 있어 해당 이슈를 빠르게 개선할 수 있다. 이전에는 각자 개발자가 작성한 코드를 합치고 난 후, 모두 모여서 빌드를 시작하고 나서야 문제점을 파악할 수 있었다. 지속적 통합이 적용된 개발팀은 코드를 머지하기 전, 이미 빌드 오류나 테스트 오류를 확인하여 훨씬 더 효율적인 개발을 할 수 있게 된다.

지속적 배포(Continuous Delivery/Deployment, CD)

---

지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미하며
이 두 용어는 상호 교환적으로 사용된다. 이 부분은 Release - Deploy - Operate 단계에서 꾀할 수 있다.

• Release : 배포 가능한 소프트웨어 패키지를 작성한다.
• Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출한다. 실질적인 배포 부분이다.
• Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지한다.

지속적 배포의 경우, 코드 변경 사항의 병합부터 프로덕션에 적합한 빌드 제공에
이르는 모든 단계로, 테스트 자동화와 코드 배포 자동화가 포함된다.

이 프로세스를 완료하면 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 배포할 수 있기
때문에 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 된다.

최근에는 클라우드 기술 발전과 맞물려 지속적 통합과 지속적 배포가 빠른 속도로 진행되면서 CI/CD를 하나로 묶어서 다루는 경우가 점차 증가하고 있다. 예를 들어, 이전에는 배포 자체가 상당히 오래 걸리고 힘든 일이어서 배포 이전 단계에서 많은 고민을 하곤 했다. 서버를 전부 재시작해야 한다거나, 일부 기능을 제공하지 못하는 경우도 많았기 때문이다. 요즘은 고객의 피드백을 빨리 받기 위해서라도, 서비스를 중단하지 않기 위해서라도 릴리스만 잘 기록해 두고 바로바로 배포하는 사례가 증가하고 있다.

CI/CD 파이프라인

---

배포 자동화

배포 자동화란 한 번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것을 뜻한다.
배포 자동화가 왜 필요할까?

• 먼저 수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약된다.
• 휴먼 에러(Human Error)를 방지할 수 있다.
  여기서 휴먼 에러란 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수들을 뜻한다. 그전에 했던 배포 과정과 비교하여 특정 과정을 생략하거나 다르게 진행하여 오류가 발생하는 것이 휴먼 에러의 예로 볼 수 있다.

배포 자동화를 통해 전체 배포 과정을 매번 일관되게 진행하는 구조를 설계하여 휴먼 에러 발생 가능성을 낮출 수 있다.

CI/CD 파이프라인

앞서 우리는 전통적인 개발 프로세스와 모던 개발 프로세스에 대해 배웠다.
그리고 SaaS가 모던 개발 프로세스로 개발하기 적합한 소프트웨어임도 확인했다.

그렇다면 이번에는 이렇게 생각해보자. 사용자 업데이트에 대한 걱정에서도 벗어났고, 하루에 여러 번의 배포도 가능해졌다. 그렇다면 어떻게 빠른 배포 속도를 보장받을 수 있을까? 개발자가 배포할 때마다 일일이 빌드하고 배포하는 이러한 과정이 수없이 진행된다면 일일이 이 과정을 수행하는 것이 번잡스럽고 지루할 것이다.

그래서 이 수없이 진행되는 배포 과정을 자동화시키는 방법을 구축하게 되는데, 그것을 CI/CD 파이프라인이라고 한다.

해당 그림은 배포 과정을 도식화한 것이다.

개발자가 코드를 원격 저장소에 올리면, 그 코드가 빌드 및 테스트와 릴리스를 거쳐 배포 서버로 전달된다.

배포 서버에 도달한 빌드된 코드는 애플리케이션 서버로 최종 배포가 완료되고,
그 결과물을 유저가 직접 확인하게 되는 것이다.

여기서 자동화를 꾀하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지이다.
이 부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현한다.

CI/CD 파이프라인을 구성하는 기본 단계와 수행 작업

배포에서 파이프라인(Pipeline)이란 용어는 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻한다.

파이프라인은 전체 배포 과정을 여러 단계(Stages)로 세 가지 단계로 분리한다.
각 단계는 파이프라인 안에서 순차적으로 실행되며, 각 단계마다 주어진 작업(Actions)들을 수행한다.

1. Source 단계: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우,
   이를 감지하고 다음 단계로 전달하는 작업을 수행한다.
2. Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다.
   또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행한다.
3. Deploy 단계: Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행한다.

파이프라인의 단계는 필요에 따라 더 세분화되거나 간소화될 수 있다
DevOps를 전문으로 학습하는 경우 아래와 같이 파이프라인의 단계를 세분화해서 나누기도 한다.
또한, 해당 툴을 소개하는 업체에 따라 용어를 미묘하게 다르게 사용하기도 한다.

CI/CD 파이프라인 구성 요소 및 장점

• 빌드 (소프트웨어 컴파일)
• 테스트 (호환성 및 오류 검사)
• 릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
• 배포 (개발에서 프로덕션 환경으로의 변환)
• 규정 준수 및 유효성 검사

로이루어져 있으며, 이 과정이 실무에서는 반복적인 프로세스이기 때문에
이 부분을 일련의 자동화 단계로 만든다고 볼 수 있다.

이렇게 구축된 파이프라인은 최신 버전의 소프트웨어 애플리케이션을 업데이트하고 제공하려는 일련의 처리 단계에 걸리는 시간을 수동으로 하는 것보다 더 빠르고 안정적이며 효과적으로 줄여주고 CI/CD 인프라와의 호환성과 효율성을 높여준다.

Github Action

---

GitHub Actions는 Github가 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼이다.

레포지토리에서 Pull Request나 push같은 이벤트를
트리거로 GitHub 작업 워크플로우(Workflow)를 구성할 수 있다.

워크플로우는 하나 이상의 작업이 실행되는 자동화 프로세스로,
각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행된다.

워크플로우는 .yml (혹은 .yaml ) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러 개의
워크플로우로도 만들 수 있다. 생성된 워크플로우는 .github/workflows 디렉토리 이하에 위치한다.

비공개 레포지토리의 경우 Github Actions가 작동할 때의 용량과 시간이
제한되어 있으며 공개 레포지토리는 무료로 사용 가능하다.

튜토리얼

---

이번 튜토리얼에서는 나만의 아고라 스테이츠 서버 레퍼런스와 Github Action을 이용하여 진행한다.

먼저, 자신의 깃허브 계정에 새로운 리포지토리를 만든다.
💡 public으로 만들어야 Github Action을 무료로 이용할 수 있다.

새로운 리포지토리에 나만의 아고라 스테이츠 서버 레퍼런스 코드를 push한다.

drag & drop을 할 수도 있겠지만, 가능하면 기존 나만의 아고라 스테이츠 서버 레퍼런스를
클론받아서, 새로운 리포지토리를 원격 리포지토리로 등록하고, 코드를 push한다.

# 기존 나만의 아고라 스테이츠 서버 레퍼런스 클론
git clone git@github.com:codestates-seb/fe-sprint-my-agora-states-server-reference.git
# 디렉터리 이동
cd fe-sprint-my-agora-states-server-reference
# 새로운 리포지토리를 원격 리포지토리로 등록
git remote add myRepo git@github.com:{여러분의 아이디}/{새로운 리포지토리 이름}.git
# 기존 레퍼런스 코드를 새로운 리포지토리로 push
git push myRepo reference

아래와 같이 코드가 모두 push가 된 모습을 확인한다. 커밋 기록을 보시면, 주황색 원을 확인할 수 있다.

주황색 원이 무엇인지 좀 더 자세히 파악하기 위해 Actions 탭으로 이동한다.
Github Action을 코드를 설정해 두면 이렇게 서버 테스트가 자동으로 작동하는 것을 확인할 수 있다.

Github Action은 Github의 특정 이벤트에 맞게 다양한 작업을 시킬 수 있는 CI/CD 플랫폼이다. EC2와 같은 하나의 가상 인스턴스를 실행시켜서 원하는 작업을 시킬 수 있다. 그런데, 리포지토리를 push하기만 했는데, 왜 작동했을까? ./.github/workflows/pullRequest.yml 파일을 읽어보면, 언제 어떤 job을 할지 명시되어 있다.

• npm install은 빌드를 위한 준비과정으로 볼 수 있다. Node.js로 만든 서버 애플리케이션은
  npm으로 관련 오픈소스를 모두 깔끔하게 설치해야 작동하기 때문이다.
• npm test는 유닛 테스트 과정이다. 작성한 코드가 요구사항
  충족을 위한 최소한의 조건을 만족했는지 확인하고 있다.
  
  

name: Bare Minimum Requirements

# 언제 job을 작동시킬지
on: [push, pull_request]

# 어떤 job을 할지
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Bare Minimum Requirements
        uses: actions/setup-node@v1
        with:
          node-version: '16'
      - run: npm install
      - run: npm test

YAML

---

Yet Another Markup Language의 약자로, 사람이 읽을 수 있는 데이터 직렬화 언어를 의미한다.
파일로 작성 시 확장자는 .yaml 혹은 .yml 확장자를 가진다.

YAML은 사람이 읽을 수 있고 이해하기 쉬워 프로그래밍 언어 중에서도 인기가 높다. 또한 다른 프로그래밍 언어와
함께 사용할 수도 있다. YAML은 그 유연성과 접근성으로 인해 자동화 프로세스를 생성하는 데에도 사용된다.

JSON vs YAML

---

// YAML 파일

name: Bare Minimum Requirements
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Bare Minimum Requirements
        uses: actions/setup-node@v1
        with:
          node-version: '16'
      - run: npm install
      - run: npm test

// JSON 파일

{
  "squadName": "Super hero squad",
  "homeTown": "Metro City",
  "formed": 2016,
  "secretBase": "Super tower",
  "active": true,
  "members": [
    {
      "name": "Molecule Man",
      "age": 29,
      "secretIdentity": "Dan Jukes",
      "powers": [
        "Radiation resistance",
        "Turning tiny",
        "Radiation blast"
      ]
    }
  ]
}

JSON 파일과 YAML 파일은 key-value 형태로 작성된 파일이며, 계층 구조를 가지는 것에는 동일하다.

그러나 YAML 파일은 "" (큰따옴표, double quotation marks) 없이 문자열 작성이 가능해, 설정을 위한 스펙이나 프로퍼티 값 등이 JSON 파일에 비해 한눈에 들어온다는 점이다. 또한 JSON 파일처럼 {} 형태로 감싸줄 필요도 없기 때문에 스코프의 압박(잘못 쓰면 일일이 어디가 처음이고 끝인지 찾아야 하는 등)에서 벗어날 수도 있다.

게다가 YAML 파일은 JSON 파일과 다르게 주석을 작성할 수 있다는 점도 굉장한 이점으로 작용한다.
JSON 파일은 주석을 작성할 수 없기 때문에 해당 파일 하나만 두고 커뮤니케이션하기가 까다롭지만,
YAML 파일은 애초에 파일 내에 주석을 작성할 수 있기 때문에 커뮤니케이션하기가 훨씬 수월하다.

그리고 YAML은 JSON의 상위 호환 격이므로, 기존 json문서를 그대로 yaml파일로 사용하거나 원하는
부분만 손볼 수 있다. 반대로 yaml을 json으로 변환해 사용할 수도 있다는 점이 장점으로 작용한다.

YAML 문법

---

YAML도 일종의 프로그래밍 언어이기 때문에 문법이 있다.
해당 문법을 지켜 작성하지 않으면 YAML 파일로 읽지 못하기 때문에, 문법을 잘 지켜줘야 한다.

💬 주석, 문서의 시작과 끝
---------------------------------------------

`#`  : 주석
`---`  : 문서의 시작 (선택사항)
`...`  : 문서의 끝 (선택사항)


💬 기본 표현
---------------------------------------------

key: value이며, : 다음에는 무조건 공백 문자가 와야 한다.


💬 자료형
---------------------------------------------

`int`, `string`, `boolean`, 리스트, 매핑을 지원한다.

여기서 int와 string 타입은 스칼라(Scalar)라 부르고, 배열 혹은 리스트는 시퀀스(Sequence)라 부른다.
매핑에는 기본 표현인 key-value 쌍 및 hash, dictionary가 포함된다.

#int(숫자)
int_type: 1

#string(문자열)
string_type: "1"

#blooean(참/거짓)
boolean_true_type: true
boolean_false_type: false

#이외에 yes, no로 작성하기도 한다.
yaml_easy: yes
yaml_difficult: no

#리스트(배열 형태)
person:
  name: Chungsub Kim
  job: Developer
  skills: 
    - docker
    - kubernetes
  # JSON 형식의 "skill" : [docker, kubernetes]와 같다.


💬 객체
---------------------------------------------

객체 표현은 `key` 작성 후 두 칸을 들여써서 key-value 형태로 작성을 해주거나,
`key`를 작성 후 중괄호(`{}`)로 한 번 묶고 key-value 형태로 작성한다.

key: 
  key: value
  key: value

# 또는 이렇게도 가독성을 위해 작성한다.
key: {
  key: value,
  key: value
}


💬 Text
---------------------------------------------

줄바꿈 표현(`|`)과 줄바꿈 무시 표현(`>`)이 있다.

# |는 줄바꿈 표현이다.
# JSON 형식의 "comment_line_break": "Hello codestates.\nIm kimcoding.\n"과 같다.
comment_line_break: |
  Hello codestates.
  Im kimcoding.

# >는 줄바꿈 무시 표현이다.
# JSON 형식의 "comment_single_line": "Hello world my first coding."과 같다.
comment_single_line: >
  Hello world
  my first coding.
  
  
💬 문자열 따옴표
---------------------------------------------

key-value 쌍에서 value에 `:`가 들어간 경우는 반드시 따옴표가 필요하다.

# error가 난다.
windows_drive: c:

# 이렇게 써야 한다.
windows_drive: "c:"
windows_drive: 'c:'

🔥 과제1. Github Action 실습

---

나만의 아고라 스테이츠 서버의 클라이언트 부분을 S3로 배포합니다.
튜토리얼에 이어서 해당 실습을 진행합니다. 기존에 가지고 있었던 레포지토리를 이용해 봅시다.

Github Actions를 통한 배포 Flow (클라이언트)

이번 클라이언트 배포는 간단하게 3가지 단계로 나뉩니다.

• Source: Github reference 브랜치에 코드가 커밋되면
• Build: github acitons의 YAML 파일에 적힌 명령어를 토대로 Webpack을 이용해 빌드를 하고
• Deploy: github acitons의 YAML 파일에 적힌 명령어를 토대로 s3로 빌드 결과를 업로드합니다.

이미 여러분의 S3는 배포를 위해 충분히 준비되어 있음으로, s3로 파일만 잘 전달하면 충분히 배포를 할 수 있습니다. 차근차근 고민하면서 아래 코드의 <?> 을 채워보시기 바랍니다.

# .github/workflows/client.yml
name: client
on:
  push:
    branches:
      - <?>
jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout source code.
        uses: actions/checkout@v2
      - name: Install dependencies
        run: <?>
        working-directory: ./my-agora-states-client-react
      - name: Build
        run: <?>
        working-directory: ./my-agora-states-client-react
      - name: SHOW AWS CLI VERSION
        run: |
          <?>
      - name: Sync Bucket
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws s3 <?> \
            --region ap-northeast-2 \
            build s3://<?> \
            --delete
        working-directory: <?>

💬 Sprint Review

---

과제를 진행하면서, 과정이나 추가 설명을 덧붙이겠다.

1. 원격 레포지토리 Clone & Push 세팅

---

터미널에서 다음과 같이 원본 레퍼지토리를 클론한 후,
미리 만든 원격 레퍼지토리로 푸시해준다.

그럼 바로 Github에서 확인 가능하다.

바로 Actions 탭에서 기존에 만들어져있던, yml 파일이 push를 감지해서 Action이 작동하는 것을 볼 수 있다.

2. Actions secrets key 설정

---

이제 yml 파일을 작성하기 전에, 현재 레퍼지토리에 Action에 대한 key를 설정해야 한다.

secrets 명은 과제 yml 코드를 보면 알겠지만, 환경 변수 값으로 전달받기 위해서 정확하게 같도록 설정했다.

AWS 접근 키와 같은 민감한 정보를 안전하게 저장하기 위해 환경 변수로 설정하는 것이 일반적이다.

당연히 이렇게 환경 변수로 설정하는 이유는 보안을 위함이며,
GitHub Secrets를 사용하여 GitHub 저장소의 설정에서 안전하게 관리될 것이다.

만약, AWS 접근 키를 설정해주지 않는다면 Action build 과정에서 이렇게 에러를 볼 수 있다.

3. yml 파일 작성 (GitHub Actions workflow)

---

이제 바로 yml 파일을 작성한다.

GitHub Actions workflow로 클라이언트 애플리케이션을 빌드하고 AWS S3 버킷에 배포하는 설정을 하는 것이다.

name: Fronted Client Deploy

on:
  push:
    branches: [reference]

jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout source code.
        uses: actions/checkout@v2
      - name: Install dependencies
        run: npm install
        working-directory: ./my-agora-states-client-react
      - name: Build
        run: npm run build
        working-directory: ./my-agora-states-client-react
      - name: SHOW AWS CLI VERSION
        run: |
          aws --version
      - name: Sync Bucket
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws s3 sync \
            --region ap-northeast-2 \
            build s3://fe-2-widrns15-s3 \
            --delete
        working-directory: ./my-agora-states-client-react

branches는 현재 배포할 브랜치인 reference로 설정했고,
각각 npm install, npm run build를 상황에 맞게 넣어줬다.

환경 변수로 지정될 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY 값은
secrets에서 불러와서 할당되도록 알맞게 지정해준다.

위에서 key 명을 저렇게 지은 이유는 위 코드와 같게 해주기 위함이었다.

이제 설정은 다 마쳤다.

커밋 메세지도 알맞게 작성해주면 완전히 끝이다. 이제 Actions 초기 탭으로 돌아가서 확인해보자.

정상적으로 build가 돌아가는 것을 확인할 수 있었고

조금 기다리면 정상적으로 처리된 것을 볼 수 있었다.

4. AWS S3 배포 확인

---

링크를 확인하기 전까지는 의문이 하나 있었다.

저번 유닛에서 S3 버킷에 업로드했던 파일도 그대로 있고, 링크도 그대로라 어떻게 처리될지가 의문이었다.

결과적으로 걱정과 다르게, 방금 배포한 클라이언트 파일이 정상적으로 덮어씌워져 있는 것을 볼 수 있었다.
후에 다시 업로드했던 파일을 삭제하고 재업로드했더니, 다시 저번 유닛 로그인 페이지를 볼 수 있었다.

Proxy

---

CORS 정책이 필요한 이유

브라우저에서 기본적으로 API를 요청할 때에, 브라우저의 현재 주소와
API의 주소의 도메인이 일치해야만 데이터를 접근할 수 있게 되어 있다.

만약 다른 도메인에서 API를 요청해서 사용하려면, CORS 설정이 필요하다는 것을 이전 섹션에서 다뤘었다.

• 💡 CORS

  • 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여,
    한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.

• 💡 출처

  • 웹 콘텐츠의 출처(origin)는 접근할 때 사용하는 URL의 스킴(프로토콜), 호스트(도메인), 포트로 정의된다.
    두 객체의 스킴, 호스트, 포트가 모두 일치하는 경우 같은 출처를 가졌다고 말한다.
    일부 작업은 동일 출처 콘텐츠로 제한되나, CORS를 통해 제한을 해제할 수 있다.
    
    

로컬 환경에서 개발한 앱은 기본적으로 localhost:3000으로 시작한다.

그러나 나중에 로컬 환경에서 개발한 실제 서비스 및 프로젝트의 클라이언트에서
서버의 API로 요청하게 되면, 이 포트로 요청하는 것이 차단될 것이다.

만일 실제 서비스가 되는 상용 앱을 운영 중이라면, 구축한 클라이언트 뒤의
서버와 연결되어 있는 DB에는 라이브 데이터(live data)가 쌓일 것이다.

• 💡 라이브 데이터(live data)
  • 실제 서비스되고 있는 앱의 데이터베이스(Data Base, DB)에 적재되고 있는 데이터를 의미한다.
    유저 및 상품, 결제 등 다양한 정보들을 예로 들 수 있다.
    
    

이런 라이브 데이터는 민감성이 높은 데이터들이 위주이기 때문에 보안이 무엇보다 중요하다.

그러나 서비스 및 프로젝트가 모든 출처의 접근을 허락한다면 이러한
보안성이 현저히 낮아지고, 해킹의 위험에 그대로 노출되게 된다.

따라서 모든 도메인을 허용해서는 안 되고, 특정 도메인을 허용하도록 구현해야 한다.

프론트엔드 개발자가 백엔드 개발자에게 프론트엔드 개발 서버 도메인을 허용해 달라고
요청을 해야 하고,백엔드 개발자는 응답 헤더에 필요한 값들을 담아서 전달을 해줘야 한다.

서버에서 적절한 응답 헤더를 받지 못하면 브라우저에서 에러가 발생하기 때문이다.

Proxy

그러나 위의 과정 없이 React 라이브러리, 혹은 Webpack Dev Server에서
제공하는 proxy 기능을 사용하면 CORS 정책을 우회할 수 있다.

이는 별도의 응답 헤더를 받을 필요 없이 브라우저는 React 앱으로
데이터를 요청하고, 해당 요청을 백엔드로 전달하게 된다.

여기서 React 앱이 서버로부터 받은 응답 데이터를 다시 브라우저로 전달하는 방법을 쓰기 때문에
브라우저는 CORS 정책을 위반했는지 모르게 된다. 브라우저를 proxy 기능을 통해 속이는 것이다.

위의 그림은 proxy를 적용해 브라우저를 속이기 전 흐름이다. 프론트엔드가 개발한 React 앱에서 브라우저 쪽으로 요청을 보낸다. 그러면 브라우저는 백엔드, 즉 서버 쪽으로 리소스를 요청하게 된다. 이때 접근 권한이 있는지, 즉 출처가 같은지 확인하는데 이때 백엔드 서버는 정상적으로 200 OK 응답을 브라우저에게 보낸다. 마지막으로 브라우저는 받은 리소스 및 응답과 함께 출처가 같은지 아닌지 확인하게 되는데, 이때 출처가 다르다면 응답을 파기(CORS Error) 하고, 출처가 같다면 응답을 파기하지 않고 다시 프론트엔드 쪽으로 응답을 보내주는 것이다.

위의 그림은 proxy를 적용해 브라우저를 속인 후 흐름이다. React 앱에서 브라우저를 통해 API를 요청할 때, proxy를 통해 백엔드 서버로 요청을 우회하여 보내게 된다. 그러면 백엔드 서버는 응답을 React 앱으로 보내고, React 앱은 받은 응답을 백엔드 서버 대신 브라우저에게 전달한다. 이렇게 되면 출처가 같아지기 때문에 브라우저는 이 사실을 눈치채지 못하고 허용하게 된다.

Proxy 사용법

---

오늘은 두 가지 방법으로 Proxy를 다뤄볼 것이다.

• webpack dev server proxy
• http-proxy-middleware 라이브러리

webpack dev server proxy

---

먼저 webpack dev server에서 제공하는 proxy 기능을 사용하는 방법이 있다.

webpack dev server의 proxy를 사용하게 되면, 브라우저 API를 요청할 때
백엔드 서버에 직접적으로 요청을 하지 않고, 현재 개발서버의 주소로 우회 요청을 하게 된다.

그러면 웹팩 개발 서버에서 해당 요청을 받아 그대로 백엔드 서버로 전달하고,
백엔드 서버에서 응답한 내용을 다시 브라우저 쪽으로 반환한다.

웹팩 개발서버의 proxy 설정은 원래 웹팩 설정을 통해서 적용을 하지만, CRA를 통해 만든 리액트
프로젝트에서는 package.json 에서 "proxy" 값을 설정하여 쉽게 적용할 수 있도록 구성이 되어 있다.

...

"browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
	"proxy" : "우회할 API 주소"
}

그리고 기존의 fetch, 혹은 axios를 통해 요청하던 부분에서 도메인 부분을 제거한다.

// 변경 전
export async function getAllfetch() {

    const response = await fetch('우회할 api주소/params');
    .then(() => {
			...
		})
}

// 변경 후
export async function getAllfetch() {

    const response = await fetch('/params');
    .then(() => {
			...
		})
}

React Proxy 사용법

---

webpack dev server에서 제공하는 proxy는 전역적인 설정이기 때문에,
종종 해당 방법이 충분히 적용되지 않는 경우가 생기기도 한다.

그래서 수동으로 proxy를 적용해줘야 하는 경우가 있는데,
이때는 http-proxy-middleware 라이브러리를 사용해야 한다.

http-proxy-middleware 라이브러리 설치

npm install http-proxy-middleware --save

그리고 React App의 src 파일 안에서 setupProxy.js 파일을 생성하고,
안에서 설치한 라이브러리 파일을 불러온 다음, 아래와 같이 작성을 한다.

const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = function(app) {
  app.use(
    '/api', // proxy가 필요한 path prameter를 입력한다.
    createProxyMiddleware({
      target: 'http://localhost:5000', // 타겟이 되는 api url를 입력한다.
      changeOrigin: true, // 대상 서버 구성에 따라 호스트 헤더가 변경되도록 설정하는 부분이다.
    })
  );
};

그리고 기존의 fetch, 혹은 axios를 통해 요청하던 부분에서 도메인 부분을 제거한다.
밑의 부분은 webpack dev server에서 제공하는 proxy 기능을 사용할 때와 동일하다.

// 변경 전
export async function getAllfetch() {

    const response = await fetch('우회할 api주소/params');
    .then(() => {
			...
		})
}

// 변경 후
export async function getAllfetch() {

    const response = await fetch('/params');
    .then(() => {
			...
		})
}

🔥 과제2. Proxy를 설정해 HTTP 통신하기

---

앞서 proxy에 대해 배워보았습니다.
proxy를 잘 설정하면 CORS 정책을 우회하여 개발 단계에서도 http 통신이 가능합니다.

🔥 Bare Minimum Requirement

여기 레포지토리로 들어가 git clone 한 뒤, 과제를 진행합니다.

백엔드의 개발 서버 역할을 해줄 api와, 프론트엔드의 개발
서버 역할을 해줄 my-app에 각각 접근하여 npm install을 합니다.

cd api
npm install

cd my-app
npm install

이어 api에 접근한 터미널에서는 npm run dev를,
my-app에 접근한 터미널에서는 npm start를 통해 각기 개발 서버를 엽니다.

//api terminal
npm run dev

//my-app terminal
npm start

그러면 터미널이 각기 이런 화면으로 여러분을 맞이할 것입니다.

그다음 http://localhost:3000/으로 이동해봅시다.

이 상태에서 클라이언트 Get all Books라고 쓰여 있는 버튼을 눌러봅시다.

CORS 에러가 뜨며 응답을 제대로 받아오지 못하는 것을 확인할 수 있습니다.
이 단계에서부터 proxy 기능을 사용해 페어와 함께 CORS 에러를 해결해 나갈 것입니다.

과제1

페어와 함께 webpack dev server의 proxy 기능을 사용해 우회하여 응답을 받아옵니다.

과제2

레포지토리로 받아온 과제를 살펴보면 api2라는 폴더가 존재하고 있습니다. 실제로 프로젝트 및 실무를 할 때, 하나의 도메인이 아닌 여러 개의 도메인에서 응답을 받아와야 하는 경우가 종종 있습니다. 이럴 때는 유연하게 proxy를 설정할 필요가 있습니다.

• 페어와 함께 webpack dev server의 proxy 기능 대신 http-proxy-middleware의
  proxy 기능을 사용하여 proxy를 유연히 설정해 2개의 도메인에서 모두 응답을 받아옵니다.
• 페어와 함께 api2에 관련된 fetch 함수를 만들고, 컴포넌트를 하나 이상 만들어
  2개의 도메인에서 모두 응답을 받아오는지 테스트해봅니다.

💬 Sprint Review

---

과제는 총 2개로 위 과제와 마찬가지로 과정과 추가 설명을 덧붙이겠다.

먼저 결과 전체 코드를 CodeSandbox로 첨부해두겠다.

과제 1

---

webpack dev server는 package.json에 proxy를 설정해주고,
src 폴더 안에 있는 BookService에서 도메인 부분을 제거해서 간편하게 구현했다.

후에 터미널에서 api는 npm run dev로 my-app(client)는 npm start로 각각 서버와 클라이언트 포트를 열었다.

Get all Books 버튼을 눌러도 에러가 생기지 않으며, 정상적으로 추가까지 되는 것을 확인할 수 있었다.

과제 2

---

과제 2는 추가적으로 api2까지 다루므로, ToDo라는 컴포넌트를 따로 만들어서
api2 도메인을 fetch 해오는지 육안으로 확인할 수 있게 했다.

그리고 http-proxy-middleware 라이브러리를 설치해주었으며,
package.json에서 설정해주었던 proxy를 지워주었다.

이제 이 역할은 새로운 컴포넌트 setupProxy가 할 것이다.

// setupProxy.js

const { createProxyMiddleware } = require("http-proxy-middleware");

module.exports = function (app) {
  app.use(
    ["/api", "/api2"],
    createProxyMiddleware({
      target: process.env.REACT_APP_API_URL,
      changeOrigin: true,
      router: {
        "/api2": process.env.REACT_APP_API_URL2,
      },
    })
  );
};

도메인은 환경 변수로 만들어주었으며, 두 도메인을 하나처럼 묶어주었다.

이후 package.json에서 기존 webpack dev server proxy를 지워주었는데도
api, api2, client port를 전체 켜고 테스트해보니 정상적으로 진행되었다.

클라이언트에서는 추가적으로 구현한 ToDo 컴포넌트가 기존과 합쳐 정상적으로 나타났고,
서버에서 정상적으로 데이터를 가져와 뿌려줬다. 추가로 터미널에서 실시간으로 이 상황을 볼 수 있었다.

정상적으로 http-proxy-middleware 구현을 마친 것이다 !

💡 Error Note.

---

💡 http-proxy-middleware를 쓰는 이유_#Remind

• api는 기존에 **webpack dev server proxy**로 CORS 정책을 피해서 사용하고 있었다.
• ✨ 하지만 다른 도메인을 가진 api2를 동시에 다루려면 또 다시 CORS 정책에 걸리게 된다.
• ✨ 따라서 http-proxy-middleware를 사용해서 api, api2가
  같은 도메인에서 요청하는 것처럼 보이도록 할 수 있어 CORS 정책을 피할 수 있다.
  
  

👉 http-proxy-middleware는 웹 개발 시, 클라이언트에서 서버로 요청을 보낼 때
프록시(proxy) 설정을 쉽게 할 수 있도록 도와주는 Node.js 라이브러리이다.

웹팩 개발 서버나 다른 서버 사이에 있는 API 서버 또는 다른 호스트에 대한 요청을 프록시하는데 사용된다.

• 주요한 상황과 이유는 다음과 같다:
  
  

1. CORS(Cross-Origin Resource Sharing) 이슈 해결: 웹 개발 중에, 보안 상의 이유로 브라우저에서는 다른 도메인에 대한 AJAX 요청이 기본적으로 차단된다. 따라서 개발 환경에서 개발 서버와 백엔드 서버가 다른 도메인에 위치해 있다면, 브라우저에서 AJAX 요청을 보낼 때 CORS 이슈가 발생할 수 있다. 이 때 http-proxy-middleware를 사용하여 프론트엔드 개발 서버에서 백엔드 서버로 요청을 프록시하면, 같은 도메인에서 요청하는 것처럼 보이도록 설정할 수 있다.
2. 서버 리소스 접근: 개발 중에는 프론트엔드에서 특정 경로에 대한 요청을 프록시하여 백엔드 서버의 리소스에 접근할 수 있다. 이는 개발 시 백엔드 API를 사용하지만, 프론트엔드에서 직접 호출하지 않아도 되기 때문에 개발 효율성을 높여준다.
3. 로컬 개발 서버와의 연동: 일부 개발 환경에서는 웹팩 개발 서버와 API 서버 또는 다른 서버를 동시에 실행하는 경우가 있다. 이 때 프록시 설정을 통해 개발 서버에서 API 서버로 요청을 전달하면, 별도의 도메인 또는 포트를 사용하는 것에 대한 불편함을 해소할 수 있다.