[TroubleShooting] P2 배달앱 만들기 Day1

Son_Doobu96·2023년 1월 27일

Project2 TroubleSooting

목록 보기

1/4

Day1

# Day1의 목표
### Fastify 프레임워크를 사용해 WAS와 DB를 컨테이너화 하는 것!

◎ Milestone 1

마일스톤 1단계에서는 프레임워크를 사용해 만든 WAS 서버를 도커 이미지로 빌드하고
이를 ECR에 푸쉬하는 과정을 진행했습니다.

■ 처음으로 마주한 문제

Dockerfile 작성 레퍼런스 공식 문서
레퍼런스를 활용해 Dockerfile을 작성했다.

FROM node:16-alpine
ENV NODE_ENV=test

WORKDIR /app

COPY ["package.json", "package-lock.json*", "./"]

RUN npm install

COPY . .

EXPOSE 3000

CMD [ "node", "app.js" ]

Dockerfile을 작성 후 빌드 명령어를 통해 WAS를 이미지화 시키고 컨테이너를 실행해봤더니

분명 명령어를 잘 입력했지만 계속해서 실행한 컨테이너가 곧 바로 종료되는 현상이 발생했다.

Exited (0) 5 seconds ago

라는 문제로 구글링을 해본 결과 Docker의 기본 개념에 관련한
문제를 설명하는 글들이 많았다. VM과 다르게 Container는 서버 환경이 아니기 때문에
CMD의 명령을 이행시켜 줄 뿐이라는 것이었다.

처음에는 이 말을 잘 이해하지 못했는데. 엔지니어님께 한번 더 질문 후 확실하게 이해할 수 있었다.
엔지니어님께서는 Package.json 파일의 Script 부분에 주목해 보라고 하셨는데
Package.json에서는 npm start에 대해 아래와 같이 기술하고 있었다.

"start": "fastify start -l info app.js --address 0.0.0.0”

fastify 프레임워크를 사용했기에 node명령어를 통해 실행되지 않아 문제가 발생했던 것이다.
그래서 Dockerfile의 CMD를 아래와 같이 변경해 줌으로써 문제를 해결 할 수 있었다.

CMD [ “npm", "run", “start” ]

■ 두번째로 마주한 문제

ECR에 도커 이미지를 푸쉬하는 AWS 공식문서
위의 레퍼런스를 통해 이미지로 만든 WAS서버를 ECR에 푸쉬하려 했다.
aws에서 사용자를 따로 생성 후 ECR 푸쉬에 필요한 권한을 찾아 추가해준 다음
AWS CLI를 이용해 도커 이미지를 푸쉬하려했는데 아래의 오류 메세지를 확인했다.

Unable to locate credentials. You can configure credentials by running "aws configure".

해당 에러를 구글링을 통해 검색해 본 결과 aws configure를 설정해줘야 해당 문제를 해결 할 수 있다는 점을 발견했고 aws configure를 설정한 후 해당 문제를 해결 할 수 있었다.

▶ Milestone1에서 배운 점

1. Docker에 대한 개념 정립

Docker에서 Image가 컨테이너의 시작 템플릿이라는 개념을 이전에는 글로만 알고 있었다.
하지만 이번 프로젝트를 진행하면서 Image를 계속 빌드하고 이를 컨테이너화 하는 작업을
반복하면서 알게 되었다.

Image란 컨테이너의 작업 명세서다!

그렇기에 소스코드가 변경되면 컨테이너의 내용이 달라져야 하기에 새로운 작업 명세서가 필요해지는 것이었다.

그리고 그동안은 docker build 명령어에 대해 Image를 만드는 명령어라고만 생각했었지만
이번 프로젝트를 통해 이 명령어가 사실은 Dockerfile에 있는 명령을 수행하는 명령어의 역할이라는 것을 확실하게 깨닫게 되어 Dockerfile에 대한 개념도 확실하게 정립할 수 있었다.

2. AWS에서의 권한

이 내용은 Milestone1을 반복 진행 해보면서 깨닫게 되었다.
ECR에 도커 이미지를 푸쉬하는 레퍼런스를 보면서 AWS CLI를 사용하려면 굉장히 복잡한 과정이 많네? 라고 느끼면서 처음에는 프로젝트를 진행했었다.

하지만 두번째 반복 진행을 하면서 공식문서에 나와있는 아래의 명령어가
ECR에 로그인하기 위한 명령어라는 점을 깨닫게 되었다.
그리고 ECR의 Permission을 통해 해당 리포지토리에 필요한 최소의 권한만을 주어
작업을 진행해야 한다는 그 중요성을 깨닫게 되었다.

aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com

처음 프로젝트를 진행할 땐 사용자에 이 권한 저 권한을 다 매칭하며 진행했었는데.
두번째 반복진행에서는 IAM 사용자를 통해 내가 ECR에 푸쉬할 수 있는 정도의
적절한 권한만을 주면서 Milestone1을 진행할 수 있었고 이 과정을 겪으면서

AWS의 최소권한 원칙의 개념을 몸소 체험하고 사용자를 통해 권한을 관리하는 방법 또한 배우게 되었다.

◎ Milestone 3

마일스톤 3단계는 프레임워크를 사용해 만든 WAS서버를 GitHub Action을 통해
소스코드가 변경되면 자동으로 이미지를 빌드하고 ECR에 푸쉬하는 워크플로우를 형성하는 것입니다.

※ Milestone3에 들어가기 전의 생각
Workflow를 생성하는 과정은 이전에 다른 과정을 통해
충분히 학습을 해봤기 때문에 ~~크게 어려울거라고 생각하지는 않았다.~~

인간이기에 할 수 있는 오만이었다고 생각한다..;;

■ 처음으로 마주한 문제

Workflow를 위한 yml파일 작성 레퍼런스1
Workflow를 위한 yml파일 작성 레퍼런스2

workflow를 생성하기 위해 yml파일을 작성하는 레퍼런스를 참고하며 yml파일을 작성했다.

name: Deploy to Amazon ECR

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
env:
  AWS_REGION: ap-northeaest-2
  ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
  ECR_REPOSITORY: devops03-teamf
  IMAGE_TAG: ${{ github.sha }}

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - 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: ${{ env.AWS_REGION }}

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

    - name: Build, tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

레퍼런스를 여기저기 짬뽕하면서 작성하다보니 처음에는 Workflow가 작동하지도 않았다..
그래서 다시 yml파일을 주의깊게 살피면서 중복된 곳을 제거하고 다시 커밋을 하였다.
그때 아래와 같은 에러를 만나게 되었다.

Credentials could not be loaded, please check your action inputs: Could not load credentials from any providers

해당 문제가 인증에 관련한 문제라는 것은 빠르게 파악할 수 있었다.
하지만 처음 프로젝트를 진행할때는 IAM인증과 관련한 개념이 확실하게 정립되지 않아
어떻게 인증을 해결해야 할지에 대해 꽤 많은 삽질을 했다.

Github Secret에 사용자 Arn을 넣기도 하고 하면서 정말 많은 삽질을 했었다.
하지만 결국 사용자의 Access key를 Secret에 지정하면서 해당 문제를 해결할 수 있었는데.

지금 돌아보면 프로젝트를 진행하면서 ECR에 푸쉬하는 전체적인 과정을 다시 한번 생각해봤다면

    - 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: ${{ env.AWS_REGION }}

이 과정 자체가 필요하지 않다는 것을 알 수 있었을텐데... 라는 생각이 든다.

■ 두 번째로 마주한 문제

사실 문제에 대한 핵심은 Error: 코드 위 줄에서 쉽게 발견할 수 있다. 지금은 말이다....ㅋㅋㅋ

unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/runner/work/devops-03-P2-TeamF/devops-03-P2-TeamF/Dockerfile: no such file or directory

당시에는 팀원들과 함께 꽤나 이 문제를 가지고 오래 고민을 했었다.
문제의 핵심은 바로 Dockerfile의 경로를 찾을 수 없다는 말이었는데 말이다...

      run: |
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

Dockerfile의 경로는 TeamF-WAS 디렉토리 안에 있었지만

/home/hi8294/devops-03-P2-TeamF/TeamF-WAS

Workflow의 yml파일은 그 상위 폴더에 위치했으니 문제가 일어나는 것은 당연했다.

/home/hi8294/devops-03-P2-TeamF

      run: |                                                        
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG ./TeamF-WAS/ 
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG        
        echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

위와 같이 도커파일의 경로를 제대로 설정해 주니 문제를 해결 할 수 있었다.

▶ Milestone3에서 배운 점

1. 자동화를 원하는 DevOps라면 Workflow에 필요한 과정을 반드시 숙지해야 한다.

무작정 Workflow를 위해 yml파일을 작성하여 자동화를 돌리는 것이 아니라 적절한 리소스를 활용하여 최소의 시간 및 비용을 들여 자동화 Workflow를 형성하는 것이 매우 중요하다는 점을 깨달았다.

2. 오타를 주의하자!

마일스톤 3번의 과정을 반복 수행하는 과정에서도 에러를 만날 수 있었다.

에러코드 1번에 EOF라고 적힌 에러를 발견하자 가장 처음으로 떠올랐던 생각은
내가 Local에서 ECR에 푸쉬할때 EOF문제가 발생하면 대부분 ECR권한과 관련된 문제였어서
ECR에 권한을 싹 뒤져보며 문제를 찾기 시작했다.