jser.dev 블로그의 Initial Mount 챕터를 보며 번역하고 이해한것을 정리하였습니다. 해당 내용에 틀린점이나 뇌피셜이 포함되어있을 수 있습니다.

이전 Overview에서 React가 내부적으로 Fiber Tree를 사용하여 최소한의 DOM 업데이트를 계산하고 커밋 단계에서 실제 업데이트를 진행한다고 간략하게만 이야기했다. 이번에는 React가 초기 마운트(초기 렌더링)시에 정확히 어떤 동작을 하는지 알아보자.

1. Fiber Architecture에 대한 간략한 소개

(이미지 출처: jser.dev - Initial Mount)

Fiber는 간단하게는 React가 내부적으로 앱 상태를 어떻게 관리하는지에 대한 아키텍처이다. FiberRootNode와 FiberNodes로 구성된 트리형 구조이다. Fiber Tree에서 FiberRootNode를 제외한 모든 Node는 FiberNode이다. FiberRootNode와 FiberNode에 대해 더 자세히 살펴보자.

1.1 FiberRootNode

FiberRootNode는 React Root 역할을 하는 특수한 Node로, 전체 앱에 대한 필수 메타 정보를 보유한다. FiberRootNode의 current는 실제 Fiber Tree를 가리키며 새로운 Fiber Tree가 구성될 때마다 current는 새로운 HostRoot를 다시 가리키게 된다.

1.2 FiberNode

위에서 말했듯 FiberNode는 FiberRootNode 이외의 모든 Node를 의미한다. 이제 FiberNode의 중요한 프로퍼티들을 알아보자.

• tag: FiberNode에는 tag로 구분되는 많은 하위 유형들이 있다. 예를 들면 FunctionComponent, HostRoot, ContextConsumer, MemoComponent, SUspenseComponent 등이 있다.
• stateNode: stateNode는 다른 백업 데이터를 가리킨다. HostComponent의 경우를 살펴보자면 HostComponent의 stateNode는 실제 백업 DOM Node를 가리킨다.
• child, sibling, return: 해당 요소들은 함께 트리 구조를 형성한다. (이 부분은 정확히 이해하지 못함)
• elementType: 우리가 작성하는 함수 컴포넌트 또는 HTML tag이다. (이해하기로는 함수 컴포넌트명 또는 JSX에서 작성한 기본 HTML tag명)
• flags: 커밋 단계에서 적용 할 업데이트를 나타낸다. subtreeFlags는 해당 Node의 하위 트리를 위한것이다.
• lanes: 보류중인 업데이트의 우선순위를 나타낸다. childLanes이다는 해당 Node의 하위 트리를 위한것이다.
• memoizedState: 추상적이지만 중요한 데이터를 가리키고 있다. 함수 컴포넌트에서는 hooks를 의미한다. (정확히 어떤 역할을 하는지는 정확히 이해하지 못했다. 추후 업데이트 해보자)

2. Trigger 단계의 Initial mount

우리가 잘 알고있는 React의 createRoot()함수는 더미 HostRoot FiberNode가 있는 React Root를 생성한다. 이 더미 HostRoot는 createRoot()가 생성한 root의 current로 참조할 수 있다.

자세한건 아래 ReactDOMRoot.js에서 주요 로직만을 골라낸 코드를 직접 살펴보자. 함수의 선언부와 호출 구문이 순서대로 되어있지는 않으나 주요한 내용은 모두 있으니 주석을 활용하며 꼼꼼히 살펴보자.

export function createRoot(
  container: Element | Document | DocumentFragment,
  options?: CreateRootOptions,
): RootType {
  let isStrictMode = false;
  let concurrentUpdatesByDefaultOverride = false;
  let identifierPrefix = '';
  let onRecoverableError = defaultOnRecoverableError;
  let transitionCallbacks = null;

  // 여기서 root 변수에는 FiberRootNode의 참조값이 담긴다.
  const root = createContainer(
    container,
    ConcurrentRoot,
    null,
    isStrictMode,
    concurrentUpdatesByDefaultOverride,
    identifierPrefix,
    onRecoverableError,
    transitionCallbacks,
  );
  markContainerAsRoot(root.current, container);
  Dispatcher.current = ReactDOMClientDispatcher;

  const rootContainerElement: Document | Element | DocumentFragment =
    container.nodeType === COMMENT_NODE
      ? (container.parentNode: any)
      : container;
  listenToAllSupportedEvents(rootContainerElement);
  return new ReactDOMRoot(root);
}

export function createContainer(
  containerInfo: Container,
  tag: RootTag,
  hydrationCallbacks: null | SuspenseHydrationCallbacks,
  isStrictMode: boolean,
  concurrentUpdatesByDefaultOverride: null | boolean,
  identifierPrefix: string,
  onRecoverableError: (error: mixed) => void,
  transitionCallbacks: null | TransitionTracingCallbacks,
): OpaqueRoot {
  const hydrate = false;
  const initialChildren = null;
  // 위 코드에서 createContainer함수를 호출할때 createFiberRoot 함수의 return값이 반환된다.
  return createFiberRoot(
    containerInfo,
    tag,
    hydrate,
    initialChildren,
    hydrationCallbacks,
    isStrictMode,
    concurrentUpdatesByDefaultOverride,
    identifierPrefix,
    onRecoverableError,
    transitionCallbacks,
  );
}

export function createFiberRoot(
  containerInfo: Container,
  tag: RootTag,
  hydrate: boolean,
  initialChildren: ReactNodeList,
  hydrationCallbacks: null | SuspenseHydrationCallbacks,
  isStrictMode: boolean,
  concurrentUpdatesByDefaultOverride: null | boolean,
  identifierPrefix: string,
  onRecoverableError: null | ((error: mixed) => void),
  transitionCallbacks: null | TransitionTracingCallbacks,
): FiberRoot {
  // 실제로 FiberRootNode의 인스턴스가 생성되는 부분이다.
  const root: FiberRoot = (new FiberRootNode(
    containerInfo,
    tag,
    hydrate,
    identifierPrefix,
    onRecoverableError,
  ): any);
  const uninitializedFiber = createHostRootFiber(
    tag,
    isStrictMode,
    concurrentUpdatesByDefaultOverride,
  );

  // HostRoot의 FiberNode가 생성되어 FiberRootNode의 current에 할당된다.
  root.current = uninitializedFiber;

  uninitializedFiber.stateNode = root;
  ...
  initializeUpdateQueue(uninitializedFiber);
  return root;
}

root.render() 동작은 HostRoot에서 업데이트를 예약한다. 아래 코드는 render 함수의 동작이다.

function ReactDOMRoot(internalRoot: FiberRoot) {
  this._internalRoot = internalRoot;
}
ReactDOMHydrationRoot.prototype.render = ReactDOMRoot.prototype.render =
  function (children: ReactNodeList): void {
    const root = this._internalRoot;
    if (root === null) {
      throw new Error('Cannot update an unmounted root.');
    }
    updateContainer(children, root, null, null);
  };

root 함수의 동작에서 updateContainer 함수를 호출하고 있는데 아래 코드는 updateContainer 함수의 동작이다. 자세히 살펴보면 update라는 변수에 createUpdate 함수의 반환값을 담고 있는데 해당 반환값에 있는 payload라는 프로퍼티에 element 파라미터 값을 저장하고있다. 이때 element파라미터에 전달되는 인자는 render함수를 호출할때 전달되는 첫번째 인자값이다.

export function updateContainer(
  element: ReactNodeList,
  container: OpaqueRoot,
  parentComponent: ?React$Component<any, any>,
  callback: ?Function,
): Lane {
  const current = container.current;
  const lane = requestUpdateLane(current);
  if (enableSchedulingProfiler) {
    markRenderScheduled(lane);
  }
  const context = getContextForSubtree(parentComponent);
  if (container.context === null) {
    container.context = context;
  } else {
    container.pendingContext = context;
  }
  const update = createUpdate(lane);
  // Caution: React DevTools currently depends on this property
  // being called "element".

  // render() 함수를 호출할때 전달하는 첫번째 인자가 update객체의 payload 프로퍼티에 저장된다.
  update.payload = {element};

  // 이후 업데이트가 대기열에 추가되게 된다. 이게 어떻게 동작하는지는 해당 챕터에서 다루진 않는다. 다만 우선순위에 따라 업데이트가 처리되길 기다리고 있다는것만 알면된다.
  const root = enqueueUpdate(current, update, lane);

  if (root !== null) {
    scheduleUpdateOnFiber(root, current, lane);
    entangleTransitions(root, current, lane);
  }
  return lane;
}

3. Render 단계의 Initial mount

3.1 performConcurrentWorkOnRoot()

이전 Overview에서 다뤘듯이 PerformConcurrentWorkOnRoot()는 Initial Mount 및 Re-Render에 대한 렌더링을 시작하는 진입점이다.

한가지 주의해야 할 점은 동시성으로 이름이 지정되더라도 필요한 경우 내부적으로 여전히 동기적 모드로 돌아간다는것이다. Initial Mount는 DefaultLane이 Lane을 차단하고 있기 때문에 발생하는 경우 중 하나이다.

다음 코드를 살펴보자. 일부 코드가 생략되어 있지만 sudo 코드라고 생각하고 함수명과 변수명을 글을 읽듯이 해석한다고만 생각해보자.

shouldTimeSlice 변수는 boolean type인데 어떨때 true값이 담기는지 살펴보면 root에 blockingLane이 포함되지 않으면서 ExpiredLane이 포함되지 않고 workLoop의 스케줄러 타임아웃이 비활성화 되거나 titmeOut이 되지 않았을때이다. 말로 풀어쓰는게 사실 더 복잡하니 코드 자체를 보는걸 추천한다.

이후 shouldTimeSlice값에 따라 동시성 렌더를 할것인지 동기적 렌더링을 할것인지 결정하게 된다.

function performConcurrentWorkOnRoot(root, didTimeout) {
  ...
  // 저장된 필드를 사용하여 작업 할 다음 Lane을 결정한다.
  let lanes = getNextLanes(
    root,
    root === workInProgressRoot ? workInProgressRootRenderLanes : NoLanes,
  );
  ...
  // 어떤 경우에는 time-slicing을 비활성화한다. 작업이 너무 오랫동안 CPU에 바인딩 되어 있거나 기본적으로 동기화 업데이트 모드에 있는 경우이다.
  const shouldTimeSlice =
    !includesBlockingLane(root, lanes) &&
    !includesExpiredLane(root, lanes) &&
    (disableSchedulerTimeoutInWorkLoop || !didTimeout);
  let exitStatus = shouldTimeSlice
    ? renderRootConcurrent(root, lanes)
    : renderRootSync(root, lanes);
  ...
}

// Blocking means it is important, should not be interrupted.
export function includesBlockingLane(root: FiberRoot, lanes: Lanes) {
  //DefaultLane is blocking lane
  const SyncDefaultLanes =
    InputContinuousHydrationLane |
    InputContinuousLane |
    DefaultHydrationLane |
    DefaultLane;


  return (lanes & SyncDefaultLanes) !== NoLanes;
}

지속적으로 언급되는 lane에 대해 자세히 알아보고 싶다면 jser.dev블로그의 lanes-in-react포스트를 참고하세요.

위 코드에서 보이듯 Initial Mount시에는 DefaultLane이 사용되고 있기 때문에 동시 모드가 실제로는 사용되지 않음을 알 수 있다. 이는 Initial Mount시에는 최대한 빨리 UI를 렌더링 해야하는데 동시 모드를 사용하며 렌더링을 지연시키는게 이에 맞지 않기 때문이다.

3.2 renderRootSync()

renderRootSync는 내부적으로 그저 while loop를 돌고있는 함수이다.

function renderRootSync(root: FiberRoot, lanes: Lanes) {
  const prevExecutionContext = executionContext;
  executionContext |= RenderContext;
  const prevDispatcher = pushDispatcher();
  // If the root or lanes have changed, throw out the existing stack
  // and prepare a fresh one. Otherwise we'll continue where we left off.
  if (workInProgressRoot !== root || workInProgressRootRenderLanes !== lanes) {
    if (enableUpdaterTracking) {
      if (isDevToolsPresent) {
        const memoizedUpdaters = root.memoizedUpdaters;
        if (memoizedUpdaters.size > 0) {
          restorePendingUpdaters(root, workInProgressRootRenderLanes);
          memoizedUpdaters.clear();
        }
        // At this point, move Fibers that scheduled the upcoming work from the Map to the Set.
        // If we bailout on this work, we'll move them back (like above).
        // It's important to move them now in case the work spawns more work at the same priority with different updaters.
        // That way we can keep the current update and future updates separate.
        movePendingFibersToMemoized(root, lanes);
      }
    }
    workInProgressTransitions = getTransitionsForLanes(root, lanes);
    // Root또는 Lane이 변경됐을 경우 새로운 Stack을 준비
    prepareFreshStack(root, lanes);
  }
  do {
    try {
      workLoopSync();
      break;
    } catch (thrownValue) {
      handleError(root, thrownValue);
    }
  } while (true);
  resetContextDependencies();
  executionContext = prevExecutionContext;
  popDispatcher(prevDispatcher);
  // Set this to null to indicate there's no in-progress render.
  workInProgressRoot = null;
  workInProgressRootRenderLanes = NoLanes;
  return workInProgressRootExitStatus;
}
// The work loop is an extremely hot path. Tell Closure not to inline it.
/** @noinline */
function workLoopSync() {
  // Already timed out, so perform work without checking if we need to yield.
  // 해당 while문의 조건은 workInProgress가 존재하는지에 대한 여부이다.
  while (workInProgress !== null) {
    // 함수명처럼 하나의 Fiber Node 단위로 작동한다. 해당 함수는 3.3에서 더 자세히 알아보자.
    performUnitOfWork(workInProgress);
  }
}

3.2에서 중요한건 WorkInprogress가 무엇을 의미하는지 알아야한다. React코드를 살펴보다보면 current와 workInprogress prefix는 어디에나 있는데, React는 Fiber Tree를 사용하여 내부적으로 현재 상태를 나타내기 때문에 업데이트가 있을 때마다 React는 새로운 Tree를 구성하고 이전 Tree와 비교해야한다. 따라서 current는 UI에 그려지는 현재 버전을 의미하고 workInprogress는 빌드중인 다음 current 버전을 의미한다.

3.3 performUnitOfWork()

해당 함수는 React가 단일 Fiber Node에서 작동하여 수행할 작업이 있는지 확인한다.

function performUnitOfWork(unitOfWork: Fiber): void {
  // The current, flushed, state of this fiber is the alternate. Ideally
  // nothing should rely on this, but relying on it here means that we don't
  // need an additional field on the work in progress.
  const current = unitOfWork.alternate;
  let next;
  if (enableProfilerTimer && (unitOfWork.mode & ProfileMode) !== NoMode) {
    startProfilerTimer(unitOfWork);
    next = beginWork(current, unitOfWork, subtreeRenderLanes);
    stopProfilerTimerIfRunningAndRecordDelta(unitOfWork, true);
  } else {
    next = beginWork(current, unitOfWork, subtreeRenderLanes);
  }
  resetCurrentDebugFiberInDEV();
  unitOfWork.memoizedProps = unitOfWork.pendingProps;
  if (next === null) {
    // If this doesn't spawn new work, complete the current work.
    completeUnitOfWork(unitOfWork);
  } else {
    workInProgress = next;
as mentioned, workLoopSync() is just a while loop

that keeps running completeUnitOfWork() on workInProgress

So assigning workInProgress here means setting next Fiber Node to work on

  }
  ReactCurrentOwner.current = null;
}

beginWork() 는 실제 렌더링이 일어나는 곳이다.

리액트의 내부 동작을 알아보기 위해 JSer.dev님의 React Internals Deep Dive 블로그를 기반으로 Deep Dive를 시작해보려고한다.

해당 시리즈에서는 블로그 원문을 단순 번역하는게 아니라 내가 학습한것들을 기반으로 배운것과 시도해본것들을 기록 할 것이다. 혼자만 알아보는 막글을 쓰고싶지는 않아서 공개된 장소에 글을 작성하지만 혹여나 이 글을 읽게된다면 글에서 제공되는 정보가 틀릴 수 있으니 검증은 따로 충분히 해주셨으면 좋겠다. (물론 나 자신도 정보에 대한 검증을 위해 자료도 같이 첨부하며 정리 할 예정이다)

React 디버깅

리액트의 내부 동작을 알아보기 위해 실제 리액트의 사용자(개발자)가 break point를 설정하고 디버깅을 할 수 있는 방법에 대해 알아보자.

break point 지정하기

break point를 지정하는 방법은 크게 2가지가 있다.

코드단에서 지정하기

Javascript의 키워드(예약어)인 debugger 사용

function App() {
  debugger;

  const [count, setCount] = useState(0);

  useEffect(() => {
    debugger;

    setCount(prevCount => prevCount + 1);
  }, []);

  return <div>currentCount: {count}</div>;
}

브라우저 개발자 도구로 지정하기

브라우저의 개발자 도구(Chrome 기준)에서 특정 DOM 요소의 하위 트리가 변경되었을때 break point를 만들 수 있다. 아래 사진처럼 특정 요소의 하위 트리가 변경되었을때 브레이크 포인트를 만든다면 하위에 어떠한 요소 하나라도 업데이트 된다면 브레이크 포인트로 작동해야한다.

디버깅 해보기

일단 위에서 살펴본 방법으로 디버깅을 해보자. 개념적으로 먼저 살펴보기 위해 원문 블로그에서 제공하고 있는 데모 페이지를 활용 할 것이다.

1. break point 설정

a. 데모 페이지에 기본적으로 아래와 같은 break point가 debugger 키워드를 사용하여 지정되어 있다.

function App() {
  const [count, setCount] = useState(1);
  debugger;

  useEffect(() => {
    debugger;

    setCount((count) => count + 1);
  }, []);
  return <button>{count}</button>;
}
ReactDOM.createRoot(document.getElementById("container")).render(<App />);

b. 개발자 도구를 연 후 id가 container인 노드에 break point를 걸어준다.

컴포넌트 렌더링시 첫번째 break point

break point를 설정한 후 개발자 도구를 열고 새로고침을 하게되면 break point마다 코드의 실행이 멈추며 디버깅을 할 수 있다.

이때 콜스택을 첫번째 break point인 App function의 debugger 구문에서 코드 실행이 중단된다. 이때 콜스택이 어떻게 쌓였는지 살펴보자. 콜 스택이기 때문에 아래에 있는 요소가 더 먼저 실행된 함수라고 생각하면 된다.

위 콜스택에서 React가 렌더링을 어떻게 수행하는지에 대해 중요 몇가지 기능을 위주로 살펴보자. 지금은 단순히 용어를 보는것만으로는 이해가 되지 않으니 이정도의 흐름을 가지고 있구나 정도로 읽고 넘어가보자.

1. ReactDOMRoot.render: 보통의 경우 React를 실행할때의 entry point인 index 파일에서 실행하는 render 함수이다. 여기까지는 개발자가 직접 코드단으로 수정할 수 있는 레벨이다.
2. scheduleUpdateOnFiber: React에게 렌더링 할 위치를 알려주는 함수이다. 초기 렌더링시에는 루트에서 호출된다.
3. ensureRootIsScheduled: 예약되어 있는 performConcurrentWorkOnRoot가 있는지 확인하는 함수이다. 해당 동작은 중요한 역할을 한다고 하는데 React Scheduler 섹션에서 좀 더 자세히 알아보자.
4. scheduleCallback: React Scheduler의 일부이고 postMessage에 의해 호출되는 비동기 함수라고 한다. 지금으로썬 이해하기 쉽지 않아보이니 이 또한 React Scheduler에서 자세히 알아보자.
5. workLoop: 브라우저의 event loop처럼 React의 반응성 요소들을 지속적으로 처리하기 위한 동작이다. 이 개념도 React Scheduler에서 자세히 알아보자.
6. performConcurrentWorkOnRoot: 예약되어있는 작업이 실행되는 구분이며 이때 구성 요소가 실제로 렌더링 된다.

두번째 break point

Deploy.yml

# workflow의 이름을 설정해준다.
name: CI/CD

# workflow가 작동되는 이벤트를 정의한다.
# 해당 workflow같은 경우는 main branch에 push 될 경우 작동된다.
on:
  push:
    branches:
      - main

# 아래 S3와 CodeDeploy에서 사용 될 env값을 정의한다.
# 이 값은 2편과 3편에서 설정해준 S3의 버킷명과
# CodeDeploy의 applicationName, groupName과 일치해야한다.
env:
  S3_BUCKET_NAME: dev-recruit.mash-up.kr
  CODE_DEPLOY_APPLICATION_NAME: dev-recruit-code-deploy
  CODE_DEPLOY_DEPLOYMENT_GROUP_NAME: dev-recruit

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 16

      # pacakge.json에 명시된 의존성을 설치한다.
      - name: Install dependencies
        run: yarn install

      # 프로젝트를 빌드한다.
      - name: Build next app
        run: yarn build

      # S3에 올리기 전 빌드파일을 압축해준다.
      # 여기서 $GITHUB_SHA라는 값을 사용하는데 이 값은 Github에서 기본적으로 제공하는 환경변수다.
      # $GITHUB_SHA는 해당 워크플로우를 트리거 한 커밋의 고유값이 할당되어있다.
      - name: Make zip file
        run: zip -qq -r ./$GITHUB_SHA.zip . -x "node_modules/*"
        shell: bash

      # 2편에서 만든 IAM사용자를 이용해 AWS 서비스에 접근하는데 필요한 권한을 얻어오는 단계이다.
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2

      # Make zip file 단계에서 압축된 빌드 파일을 S3 버킷에 업로드하는 단계이다.
      - name: Upload to S3
        run: aws s3 cp --region ap-northeast-2 ./$GITHUB_SHA.zip s3://$S3_BUCKET_NAME/$GITHUB_SHA.zip

      # S3에 업로드 된 빌드 파일을 이용해 CodeDeploy가 정의된 동작을 하도록 트리거해주는 단계이다.
      # CodeDeploy의 동작에 대한 정의는 다음편에서 다뤄볼것이다.
      - name: Code Deploy
        run: |
          aws deploy create-deployment \
          --deployment-config-name CodeDeployDefault.AllAtOnce \
          --application-name ${{ env.CODE_DEPLOY_APPLICATION_NAME }} \
          --deployment-group-name ${{ env.CODE_DEPLOY_DEPLOYMENT_GROUP_NAME }} \
          --s3-location bucket=$S3_BUCKET_NAME,bundleType=zip,key=$GITHUB_SHA.zip

주석이 제거된 Deploy.yml

name: CI/CD

on:
  push:
    branches:
      - main

env:
  S3_BUCKET_NAME: dev-recruit.mash-up.kr
  CODE_DEPLOY_APPLICATION_NAME: dev-recruit-code-deploy
  CODE_DEPLOY_DEPLOYMENT_GROUP_NAME: dev-recruit

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 16

      - name: Install dependencies
        run: yarn install

      - name: Build next app
        run: yarn build

      - name: Make zip file
        run: zip -qq -r ./$GITHUB_SHA.zip . -x "node_modules/*"
        shell: bash

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2

      - name: Upload to S3
        run: aws s3 cp --region ap-northeast-2 ./$GITHUB_SHA.zip s3://$S3_BUCKET_NAME/$GITHUB_SHA.zip

      - name: Code Deploy
        run: |
          aws deploy create-deployment \
          --deployment-config-name CodeDeployDefault.AllAtOnce \
          --application-name ${{ env.CODE_DEPLOY_APPLICATION_NAME }} \
          --deployment-group-name ${{ env.CODE_DEPLOY_DEPLOYMENT_GROUP_NAME }} \
          --s3-location bucket=$S3_BUCKET_NAME,bundleType=zip,key=$GITHUB_SHA.zip

이로써 Github Actions의 workflow를 모두 작성했다! 다음편에서 CodeDeploy의 동작에 대한 정의를 하는 appspec.yml파일을 작성해보자

CodeDeploy 설정

Step1

일단 IAM 서비스에 접근하여 새로운 역할을 생성해주어야 한다. IAM -> 역할 -> 역할 만들기

Step2

엔터티 유형은 AWS 서비스를 선택한다. 사용 사례는 CodeDeploy를 검색하여 선택한다. 그리고 다음 단계로 넘어간다.

Step3

Step2에서 CodeDeploy를 선택했기 때문에 자동으로 정책이 추가 되어있을것이다. AWSCodeDeployRole이라는 권한이 정상적으로 추가되어있다면 다음 단계로 넘어간다.

Step4

역할 이름에 원하는 값을 입력해준다. 그리고 페이지 최하단으로 가서 역할 생성 버튼을 눌러준다. 이제 CodeDeploy를 생성 할 준비가 끝났다.

Step5

CodeDeploy 서비스에 접근한다. 사이드바의 애플리케이션 메뉴를 선택한 후 애플리케이션 생성 버튼을 눌러준다.

Step6

애플리케이션 이름에는 원하는 값을 입력해준다. 컴퓨팅 플랫폼은 EC2/온프레미스를 선택해준다. 그리고 애플리케이션 생성 버튼을 눌러준다.

Step7

애플리케이션 생성이 정상적으로 되었다면 배포 그룹 생성 페이지를 볼 수 있을것이다. 해당 페이지에서 배포 그룹 생성 버튼을 눌러준다.

Step8

배포 그룹 이름에는 원하는 값을 입력해준다. 서비스 역할은 Step1 ~ Step4에서 만들어준 역할을 선택해준다.

Step9

배포 방법은 현재 위치를 선택해준다. 환경 구성은 Amazon EC2 인스턴스를 선택한다. 그러면 태그를 선택할 수 있는데 CodeDeploy-Instance를 선택해준다. 이 태그는 1편 Step4에서 EC2 인스턴스에 지정해준 태그이고 이 태그를 이용하여 EC2와 CodeDeploy를 맵핑 시켜준다.

Step10

다른 설정은 건들지 않고 스크롤을 맨 아래로 내리면 로드 밸런싱 활성화라는 체크박스가 기본적으로 체크되어있을것이다. 로드 밸런싱 활성화 체크박스를 체크해제 해준다. 만약 따로 로드 밸런싱 설정을 해주었다면 알아서 활성화 해주어도 당연 무방하다. 이제 배포 그룹 생성 버튼을 눌러주면 CodeDeploy 설정은 끝나게 된다!

다음으로는 Github Actions workflow를 작성하러 가보자.

S3 생성

Step1

S3서비스에 접근하여 버킷 만들기 버튼을 눌러준다.

Step2

버킷 이름과 리전을 선택해준다. 그리고 본인이 필요한 설정이 특별히 있는 경우가 아니면 기본 설정값으로 버킷을 만들어준다.

Step3

S3용 IAM 생성을 위해 IAM 서비스로 접근한다. 사이드바에서 사용자 메뉴로 접근하여 사용자 추가 버튼을 눌러준다.

Step4

원하는 사용자 이름을 입력한다. 자격 증명 유형은 액세스 키 - 프로그래밍 방식 액세스를 선택해준다. 그리고 다음 단계로 넘어간다.

Step5

기존 정책 직접 연결 메뉴를 클릭한다. 그리고 정책 필터에서 S3FullAccess와 CodeDeployFullAccess를 검색하여 선택해준다. 2개를 선택하였다면 다음 단계로 넘어간다. 다음 단계는 태그 추가 단계인데 태그는 건너뛰고 또 다음 단계로 넘어간다.

Step6

검토 단계이다. Step4, 5에서 설정했던 값과 정책을 확인한다. 이상이 없다면 다음 단계로 넘어간다.

Step7

생성이 완료되었다면 보안 자격 증명에 대한 정보를 알려줄것이다. 설명에도 나와있듯이 지금이 아니면 이 자격 증명에 대한 값을 알 수가 없다. .csv파일을 다운로드하여 보관하거나 따로 메모장에 기록해두자.

Step8

방금 만든 IAM User의 accessKeyId와 Key를 Gitgub Actions를 사용 할 Github 레포지토리에 등록한다. 레포지토리의 설정 -> Secrets -> Actions탭에서 우측 상당 New repository secret 버튼을 클릭하여 Key: Value 형식으로 추가해주면 된다.

이로써 EC2 인스턴스로 배포 파일을 서빙 하기 전 저장소로 쓰일 S3 생성 및 설정이 끝났다.

다음으로는 S3에서 EC2 인스턴스로 서빙해주는 역할을 하는 CodeDeploy 설정을 해볼것이다.

EC2 인스턴스 생성

Step1

인스턴스 생성 전 우측 상단에서 사용 할 지역을 설정해준다.
해당글은 서울 리전(ap-northeast-2)으로 설정 후 진행 할 것이다.

지역을 설정해주었다면 EC2 대시보드에 접근한 후 인스턴스 시작 버튼을 클릭한다.

Step2

원하는 OS에서 선택 버튼을 눌러 다음 단계로 넘어간다.

프리티어를 사용할것이기 떄문에 t2.micro 유형을 선택 후 검토 및 시작을 누른다.

이 글에서는 프리티어 기준으로 설명하지만. 혹시 프리티어를 사용하는게 아니라면 가성비가 더 좋은 t3a나 t4g인스턴스를 선택해도 상관없다.

Step3

인스턴스에 Next App을 배포 후 Http 또는 Https로 접근해야하기 때문에 보안그룹 편집으로 접근해 80포트와 443포트에 대해 퍼블릭하게 접근 가능하게끔 설정해준다.

그 후 검토 및 시작 버튼을 눌러 다시 인스턴스 시작 검토 단계로 돌아간다.

만약 도메인을 구매해 https까지 붙이지 않을거라면 80포트만 허용해줘도 상관없다.

Step4

태그 편집 버튼을 누룬다.

키 항목에 원하는 값을 넣어준다. 이 글에서는 CodeDeploy-Instance로 사용하겠다.

이 키 항목은 추후 배포 자동화를 위해 CodeDeploy에서 tag group을 지정하는데 이때 방금 설정한 EC2인스턴스의 tag의 키 항목과 매칭시켜 줄 것이다. CodeDeploy에 정의한 동작이 tag로 매칭된 EC2인스턴스에 실행되는것이다.

키 항목에 원하는 값을 채워넣었다면 검토 및 시작 버튼을 누른다.

키 항목 우측의 값 항목은 따로 추가해주지 않아도 된다.

Step5

시작하기 버튼을 누른다.

Step6

해당 인스턴스에 SSH로 접근하기 위한 .pem 키를 발급받는다.

기존에 사용하던 키페어가 있다면 기존 키 페어를 사용해도 좋다.

키 페어는 분실하게 되면 아주 곤란하니 다운로드 받아 잘 보관하도록 하자

Step7

(선택사항) EC2인스턴스를 그냥 사용하게 되면 IP가 동적으로 변경되게 된다. 만약 도메인을 할당해 사용한다면 필수적으로 탄력적 IP를 할당받아 인스턴스에 적용 시켜줘야한다. 일단 네트워크 및 보안 > 탄력적 IP 메뉴에 진입하여 탄력적 IP를 할당받자.

Step8

위에서 할당받은 IP를 생성한 EC2 인스턴스에 연결시켜주자.

이렇게 되면 EC2 인스턴스에 고정 IP 할당이 완료된것이다.

주의할 점은 인스턴스를 중지 혹은 종료한 후에 탄력적 IP를 릴리즈해주지 않으면 비용이 청구되니 사용하지 않는다고 판단이 되면 꼭 릴리즈를 시켜주자.

Step9

인스턴스를 만들때 발급받은 .pem키를 이용해 SSH로 터미널을 통해 인스턴스에 접근해보자.

필자는 보통 pem키를 ~/.ssh폴더에 모아놓고 관리하기 때문에 일단 ssh폴더로 다운받은 pem키를 이동시키겠다.

mv  ~/Downloads/ap2-key-pair.pem ~/.ssh

그리고 pem키를 소유자만 Read 할 수 있게끔 권한설정을 해주자.

chmod 400 ~/.ssh/ap2-key-pair.pem

그 후 pem키를 이용하여 EC2 인스턴스에 접근해보자.

ssh -i ~/.ssh/ap2-key-pair.pem ubuntu@3.39.127.148

ubuntu@ 뒤의 IP 주소는 아까 할당받아 EC2 인스턴스에 연결한 탄력적 IP주소를 적어준다.

잘 접속이 되었다면 위와 같은 화면을 만날 수 있을것이다.

Step10

아직 자세히 설명하진 않았지만 조금 이따 사용 될 CodeDeploy 에이전트를 설치 해야한다. 아래 명령어를 접속한 인스턴스의 터미널에 입력해보자.

아래 명령어는 ubuntu 20.24버전 기준으로 작성되었으니 만약 버전이 다를 경우엔 Ubuntu Server용 CodeDeploy 에이전트 설치 공식문서를 참고하자.

sudo apt update && sudo apt upgrade
sudo apt install ruby-full
sudo apt install wget
cd /home/ubuntu
wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto > /tmp/logfile

sudo service codedeploy-agent status

해당 명령어를 입력했을때 위 사진같이 active(running) 상태가 나온다면 EC2 인스턴스에 CodeDeploy 에이전트 설치는 끝난것이다.

Step11

이제 다시 AWS로 돌아가 EC2 인스턴스에 IAM 설정을 해야 한다.

상단 검색바를 이용해 IAM 서비스에 접근 후 역할 메뉴에서 역할 만들기 버튼을 누른다. 그리고 신뢰할 수 있는 엔터티 유형에서 AWS 서비스를 선택 후 사용 사례를 EC2를 선택해준다. 그리고 다음 버튼을 눌러준다.

그 후 권한 추가를 해줄것이다.

검색을 이용하여 AWSCodeDeployFullAccess, AmazonS3FullAccess 권한을 추가해준 후 다음 버튼을 눌러준다.

마지막으로 역할의 이름을 지정해주고 설정한 서비스와 권한을 확인해준 후 역할 생성 버튼을 눌러준다.

Step12

이제 생성된 IAM role을 EC2인스턴스에 적용시켜주자.

혹시 EC2에 접근했는데 인스턴스가 보이지 않는다면 우측 상단의 지역 설정이 제대로 되어있는지 확인해보자.

생성한 인스턴스의 IAM역할 수정 메뉴에 접근하여 방금 만든 ec2-iam role을 선택해준 후 저장 버튼을 눌러준다.

이로써 Next App을 배포 할 EC2 생성 및 설정이 끝났다.

다음으로는 Github Actions에서 Build된 파일을 EC2로 보내주기 전 해당 파일을 저장해줄 AWS S3 설정을 해볼것이다.