Git Hub Action_CodeDeploy 배포 기록

김동영·2022년 2월 9일
0

OurMemory 프로젝트

목록 보기
3/6
post-thumbnail

Code Deploy 설치

GitHub 선 작업

전체 작업

  1. https://ms3864.tistory.com/381?category=1003779
  2. https://ms3864.tistory.com/382?category=1003779
  3. https://ms3864.tistory.com/383?category=1003779

참고

  1. codeDeploy 로그 위치

    • /var/log/aws/codedeploy-agent
  2. codeDeploy 에이전트 로그에서 아래 에러가 발생하는 경우, 서버를 재기동하면 된다.

  3. appspec.yml 문서 작성 및 이벤트 설명

  4. 배포 완료 후 codeDeploy 에서 EC2 서버에 작업 중 아래와 같은 오류가 발생한다.

The CodeDeploy agent did not find an AppSpec file within 
the unpacked revision directory at revision-relative path "appspec.yml".

The revision was unpacked to directory 
"/opt/codedeploy-agent/deployment-root/2338ec72-676d-462a-b299-bbb4fb725b33/d-71FQJK70F/deployment-archive",
and the AppSpec file was expected but not found at path 
"/opt/codedeploy-agent/deployment-root/2338ec72-676d-462a-b299-bbb4fb725b33/d-71FQJK70F/deployment-archive/appspec.yml". 

Consult the AWS CodeDeploy Appspec documentation for more information at 
http://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html
  1. 원인 분석 및 해결(22.03.06 ~ 22.03.07)
    • appspec.yml 파일이 같은 경로에 없어서 발생한 문제였다.
      appspec.yml 못 찾는 이슈 해결방안 공식 문서
    • 이를 해결하기 위해 아래 파일들을 tgz 로 묶어 S3 에 배포하여 성공함.
      • appspec.yml => 배포 서버에서 작업할 스크립트
      • OurMemory.jar => 배포 대상 파일
      • start.sh => 배포 후 실행할 스크립트 코드
    • 코드디플로이에서 아래 경로에 tgz 파일을 압축해제한 뒤, appspec.yml 스크립트에 따라 파일 배포 및 스크립트를 실행한다.
      /opt/codedeploy-agent/deployment-root/deployment-instructions
    • 성공 케이스를 찾았으니, deploy.yml 를 통해 위 작업이 이루어질 수 있도록 전체적인 수정이 필요하다.
    • 온전히 성공할 경우, develop 레포지토리에 대해 Pull Request 명령어로 머지된 커밋에 대해 액션이 수행되도록 세밀한 조정도 해야함.
    • 그 후 그룹 이슈에 따라 ReadMe.md 에 CI/CD(CD 는 맞으나 CI도 포함인지 개념확인 필요) 내용을 작성하자.
    • 22.03.07
      메인 레포 develop 에 풀리퀘스트 후 머지를 통해 푸시할 때, 배포되도록 적용 완료.
      CI/CD 순서도 및 설명 ReadMe.md 에 추가 완료.
      => GitHub Action 에서 빌드 오류가 발생하여 우선 보류함.
      => 빌드 온전히 구현된 후, 각 브랜치 별 푸시할 때마다 빌드를 통해 코드 검증하도록 액션 스크립트 작성하자.
      => 또한 머지 이후 develop 브랜치 기준 배포 과정에 빌드를 추가하여 머지 후 빌드가 온전할 때만 서버에 배포되도록 수정하자.

  1. GitHub Action 환경에서 빌드하기(22.03.14 ~)
    • GitHub Action 환경에 맞춰 확인해보니, 테스트용 프로파일에 설정이 없어 발생한 오류였다.
    • 추가해야 하는 설정 값은 보안 설정(AWS IAM 시크릿 키, FCM 서비스키) 값이었기 때문에 코드에 직접 업로드할 수 없음.
    • 이를 해결하기 위해 프로파일 및 FCM 서비스키 값을 GitHub Action 전용 Secrets 에 등록한 뒤 빌드 전 application-test.yml, fcmServiceKey.json 파일을 생성하여 해당 문제를 해결하였다.
    • 현재 FriendServiceTest.java:840 에서 결과값 검증이 실패하여 빌드가 되지 않고 있다.(그 외 테스트 케이스 전부 성공함.)
      로컬 환경에서는 재현이 되지 않기 때문에 확인이 필요함.(22.03.14)
      FriendServiceTest > 사용자 목록 조회 FAILED
       org.opentest4j.AssertionFailedError at FriendServiceTest.java:840
      22.03.16
    • 원인을 찾지 못해 임시 주석 처리함.
    • workflow_dispatch 를 통해 deploy 전 build 실행되도록 수정
      (convictional/trigger-workflow-and-wait Actions 사용)
    • 풀리퀘스트받은 레포에서 빌드되지 않아 확인 필요 -> 위 오류와 동일하지만 똑같이 설정했음에도 실패하고 있음. application-test.yml 설정에 문제가 있는지 확인이 필요함.
      22.03.26
    • ./gradlew build -debug 옵션으로 빌드 과정 디버그 진행
    • 아래 오류로 인해 진행되지 않음.
      2022-03-25T16:08:32.2269558Z 2022-03-25T16:08:32.129+0000 [DEBUG] [TestEventLogger]     [ERROR] [22-03-25 16:08:32][Test worker][SpringApplication:843] Application run failed
      2022-03-25T16:08:32.2271925Z 2022-03-25T16:08:32.129+0000 [DEBUG] [TestEventLogger]     org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'messageSource' defined in class path resource [com/kds/ourmemory/v1/config/MessageConfig.class]: Unexpected exception during bean creation; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'spring.message.basename' in value "${spring.message.basename}"
      주의1 build -debug 로 실행 시, 디버그 로그가 너무 많아 웹사이트가 거의 정지되는 수준이기 때문에 왠만하면 info 레벨 정도로 줄여서 확인하도록 하자
      주의2 build stacktrace 의 경우, 콘솔에 로그가 기록되는 방식이라 그런지 디버그 로그에는 기록이 남지 않아 확인할 수 없으니 조심하자.
    • secrets 내용을 echo 로 확인한 결과, 빈 문자열만 출력되기 때문에 secrets 내용을 가져오지 못한다.
    • 포크된 레포지토리로부터 풀리퀘스트/머지 진행하는 경우, 해당 레포지토리의 시크릿을 조회한다.
      이 경우, 보안 상의 문제로 GITHUB_TOKEN 밖에 조회할 수 없기 때문에 빌드 과정에서 오류가 발생할 수 밖에 없다.
      풀 리퀘스트 시, Secrets 값이 없는 현상 관련 질문글
    • pull_request_target 이벤트를 통해 풀리퀘스트요청한 레포지토리의 시크릿을 사용할 수 있다고 한다.
      하지만 이렇게 할 경우, 임의의 사용자가 작성한 악의적인 액션이 실행될 우려가 있기 때문에 앞으로 포크받지 말고 원본 레포지토리에 권한을 부여받아 작업하는 방식으로 변경하도록 한다.
      pull_request_target 공식 가이드
profile
프레임워크와 함께하는 백엔드 개발자입니다.

0개의 댓글