AWS Code Deploy를 수행하면서의 트러블슈팅

Github Action와 CodeDeploy를 적용한 배포과정을 만들면서 만난 이슈들을 정리한 목록이다.

이 글을 보는 미래의 나 또는 다른 사람들이 이 글을 보고 수고를 많이 덜었으면 좋겠다는 생각에 글을 정리하였다.

SSH Bad Permission

Ec2 생성 이후 로컬과의 SSH 연결시

Permissions 0644 for 'iDrop-Server-key.pem' are too open.
It is required that your private key files are NOT accessible by others.

에러가 발생한다.

이는 Key가 소유자외에 다른 사용자의 접근이 불가능해야 하기 때문이다.

sudo chmod 400 ./iDrop-Server-key.pem

이 명령어를 통해 권한을 소유자만 읽기가 가능하도록 권한을 축소시켜준다.

---

EC2 Region 이동시키기

현재 EC2의 Region이 시드니에 되어있다. 인스턴스 세팅은 이미 다 되어있었고, 이를 서울 Region으로 이동시키기 위해서는 인스턴스를 다시 세팅하는 것이 아니라 AMI를 통해 세팅된 인스턴스를 복제한 후 서울 Region에 인스턴스를 생성하도록 하였다.

아래의 글에 방법이 자세히 기술되어 있다.

 

https://hagenti0612.github.io/aws/aws-region-change/

AWS EC2 리전 변경

---

Gradle Not Found

현재 디렉토리의 위치는 BE에 위치해있다.

├── TeamName...
│   ├── BE
│   │   └── Project
│   │       ├── HELP.md
│   │       ├── build
│   │       │   ├── classes
│   │       │   │   └── java
│   │       │   │       ├── main

github Actions가 참조하려는 .yml파일은 최상위 폴더인 Team2-iFive에 위치하고있다.
따라서 빌드시 실행하려는 gradlew는 Be/iDrop에 위치하고 있기 때문에 Gradle를 인식하지 못한다.

workingDirectory를 iDrop의 위치로 옮겨주어 Gradle 빌드 명령을 수행할 수 있도록 하였다.

---

Application정보 배포하기

현재 application.yml의 정보는 다른 yml파일을 이용하여 분리시켜 놓았다. 따라서 application의 seceret정보는 ${} 문법을 통하여 볼 수 없도록 하였고, 분리된 mysql.yml파일은 ignore로 인하여 깃허브에 올라가지 않는다다.

따라서 mysql에 대한 정보를 깃허브 시크릿에 등록하여 ${{ secretes.내용 }}의 형식으로 웹훅 yml파일에 사용가능하도록 하였다.

    - name: properties 설정
      run: |
        cd BE/...
        mkdir -p ./src/main/resources/env
        echo touch ./src/main/resources/env/...
        echo "${{ secrets.MYSQL_INFO }}" > ./src/main/resources/env/...

    - name: gradlew 실행 권한 설정
      run: |
        cd BE/...
        chmod +x ./gradlew

    - name: 빌드
      run: |
        cd BE/iDrop
        ./gradlew clean build -x test

---

CodeDeployPlugin::CommandPoller: Missing credentials

EC2에 CodeDeploy 관련 IAM Role이 부여되기 전에 CodeDeploy Agent 가 실행되면서 IAM Role을 가져가지 못해서 생긴 오류이다.
EC2의 IAM Role이 변경되면 CodeDeploy Agent 를 재시작 해주어야 한다.

그러나 restart를 해도 동일한 오류가 발생하였다.

따라서 기존 설정한 IAM권한을 다시 설정해주었다.

EC2에 설정할 IAM 권한은 AmazonEC2RoleforAWSCodeDeploy 권한으로 수정하고 적용시켰고,

CodeDeploy의 application에서는 AWSCodeDeployRole 권한을 주어 오류를 해결할 수 있었다.

---

bucket name must not contain a forward-slash (/)

현재 버킷의 구조는 bucketName 안쪽에 빌드 파일을 저장할 /build 와 이미지를 저장할 /image 두가지의 폴더로 이루어져있다.
따라서 현재 CD를 하기 위하한 빌드 파일은 /build 에 위치해야 한다.

현재 githubAction에 명시되어있는 S3 배포 업로드 경로는 다음과 같다.

- name: S3 업로드
  run: aws deploy push --application-name ${{ secrets.CODE_DEPLOY_APP_NAME }} --ignore-hidden-files --s3-location s3://${{ secrets.BUCKET_NAME }}/$GITHUB_SHA.zip --source ./BE/iDrop

깃허브 시크릿에 등록된 secrets.BUCKET_NAME에서 Bucket안의 폴더 이름을 명시하였다.

즉, bucketName/folder/build 의 경로가 되는 것이다. 시크릿의 Bucket이름을 제거하고 이를 run명령어에 수동으로 기입해주는 방법으로 문제를 해결할 수 있었다.

- name: S3 업로드
  run: aws deploy push --application-name ${{ secrets.CODE_DEPLOY_APP_NAME }} --ignore-hidden-files --s3-location s3://${{ secrets.BUCKET_NAME }}/build/$GITHUB_SHA.zip --source ./BE/iDrop

---

CodeDeploy agent was not able to receive the lifecycle event. Check the CodeDeploy agent logs on your host and make sure the agent is running and can connect to the CodeDeploy server.

해당 오류는 S3에서 EC2로 파일을 옮기지 못하는 오류이다.

인스턴스에 기존 AWS자격 증명파일이 저장되어 있어 IAM정보를 제대로 못 가져오기 때문이다.

현재 새로 사용하고있는 인스턴스는 AMI 이미지를 통해 복제하여 사용하고 있었다.

따라서 이전 credentials 정보를 가지고 있어서 이에대한 문제가 발생할 수 있다.

# AWS 자격증명 파일 삭제
$ sudo rm -rf /root/.aws/credentials

# codedeploy-agent 재시작
$ sudo systemctl restart codedeploy-agent

해당 자격증명 정보를 삭제하고 다시 실행해주도록 한다.

---

HttpS NameServer Missmatch

구매한 도메인에서 SSL인증서를 받기 위해서 도메인 인증을 거쳐야한다.

이때 도메인 검증이 되지않고 무한정 대기가 발생하는 문제가 발생하였다.

도메인을 구입한 곳에서 네임서버를 Rout53에서 지정한 레코드의 라우팅 대상과 맞춰주어야 한다.