지난 편에서 CI/CD 파이프라인 구축을 완료했습니다. 이번 편에서는 실제 배포 과정에서 발생한 다양한 문제들과 해결 과정을 다뤄보겠습니다.
트러블슈팅 과정
하지만 현실은 그렇게 호락호락하지 않았습니다. 실제 배포 과정에서 여러 문제들이 발생했고, 이를 해결하는 과정을 기록해보겠습니다.
이슈발생 1: JAR 파일 찾기 실패
'Zip deployment package' 단계에서 cp build/libs/*.jar ... 명령어가 실패
이를 위해 일단 내부에 어떤 .jar이 생기는지 확인하자.
Build with Gradle 다음 단계에 디버깅용 코드를 추가하고 push 하여, github actions의 콘솔을 확인한다.
# 5. Spring Boot 애플리케이션 빌드
- name: Build with Gradle
run: ./gradlew build
# --- [추가] 디버깅용 단계 ---
- name: Check for JAR file
run: |
echo "--- Checking the contents of build/libs directory ---"
ls -l build/libs
# --- 여기까지 추가 ---
# 6. AWS 자격 증명 설정
- name: Configure AWS credentials
# ... 이하 생략 ...
actions 실행 결과
원인 : 기대한 SNAPSHOT.jar가 아닌 SNAPSHOT-plain.jar와 같이 두개의 파일이 존재
core-0.0.1-SNAPSHOT-plain.jar (라이브러리만 담긴 작은 파일)core-0.0.1-SNAPSHOT.jar (실행 가능한 모든 것이 포함된 큰 파일)
actions의 deploy.yml을 보면 run에서 *.jar으로 모든 파일을 집어오게하여, 우리가 원하는 파일이 아닌 것 까지 가져와서 실패한 것이다.
# 7. 배포 패키지 압축
- name: Zip deployment package
run: |
mkdir -p deploy
cp build/libs/*.jar deploy/application.jar
cp appspec.yml deploy/appspec.yml
cp -r scripts deploy/scripts
cd deploy && zip -r deploy.zip .
해결 : run 스크립트를 변경하여, 정확한 파일만 가져오도록 변경
- 기존:
cp build/libs/*.jar deploy/application.jar - 변경:
cp $(find build/libs -name "*.jar" ! -name "*-plain.jar") deploy/application.jar
build/libs폴더에서 .jar로 끝나지만, -plain.jar는 아닌 파일만 찾아내는 명령어이다.
이제 수정해서 다시 실행해보자.
이슈 발생 2: 배포 그룹을 찾을 수 없음
원인 : 배포 그룹 이름 불일치
deploy.yml의 배포 그룹이 일치하지 않거나, 다른 리전일 경우가 될 수 있다.
CodeDeploy 애플리케이션 > TIO-Shop-Application > 배포 그룹을 보면
TIO-Spring-CodeDeploy-Group이라고 되어있다. 코드를 보면.
# 9. AWS CodeDeploy 배포 실행
- name: Deploy to AWS CodeDeploy
run: |
aws deploy create-deployment \
--application-name TIO-Shop-Application \
--deployment-group-name TIO-Spring-Deployment-Group \
--s3-location bucket=${{ secrets.AWS_S3_BUCKET_NAME }},bundleType=zip,key=spring-app/deploy.zip
맞다.. 내가 틀렸다 😭 그냥 yaml을 CodeDeploy 애플리케이션의 배포 그룹명으로 맞춰주면 끝난다.
이슈 3 : 접근 거부 (권한 문제?)
제미나이를 통해 도움받아서 작성한 IAM 정책이 부족한 부분이 있었나보다.
원인 : 권한 부족
CodeDeploy의 create-deployment 명령어는 내부적으로 여러 개의 세부적인 권한(예: 개정판 등록, 배포 그룹 정보 가져오기 등)을 필요.
또한, CodeDeploy 서비스가 우리의 EC2에 배포 작업을 수행할 수 있도록 역할을 넘겨주는 iam:PassRole 권한도 필수적임
해결: 정책 수정
actions 전용으로 만들어준 IAM 유저인 github-actions-deployer의 정책을 수정해준다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3ArtifactAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::your-artifact-bucket-name/*"
},
{
"Sid": "CodeDeployActions",
"Effect": "Allow",
"Action": [
"codedeploy:CreateDeployment",
"codedeploy:GetDeployment",
"codedeploy:GetDeploymentConfig",
"codedeploy:GetApplicationRevision",
"codedeploy:RegisterApplicationRevision",
"codedeploy:GetDeploymentGroup"
],
"Resource": "*"
},
{
"Sid": "CodeDeployRolePassing",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/TIO-CodeDeploy-Role"
}
]
}
수정할 부분:
your-artifact-bucket-name: 이전에 GitHub Secret에 저장했던 S3 버킷 이름으로 변경. (예: tio-cicd-artifacts)YOUR_AWS_ACCOUNT_ID: 본인의 12자리 AWS 계정 ID로 변경. (콘솔 오른쪽 상단에서 확인 가능,-는 빼고 숫자만)- 왜 내 AWS 계정 id를 넣어줘야하나? : 관리자의 권한 위임을 해준다는 개념으로 이해하면됨
정책을 수정해주면, 아래와 같이 IAM 권한이 하나 더 생겼다.
진짜 끝
github actions가 다 정상적으로 돌아갔고, 배포에 성공했다! 🎉
(아마도?)
성공 확인하기
1. CodeDeploy 배포 콘솔 확인
이상없다 😭
2. EC2 서버 직접 확인 (애플리케이션 실행 여부)
CodeDeploy가 성공했더라도, Spring Boot 애플리케이션 자체가 실행 중에 오류를 일으켜 바로 종료되었을 수도 있다고 한다. (예: DB 접속 정보 오류, 설정 파일 누락 등)
SSH 포트를 닫았으므로, SSM 세션 관리자를 통해 서버에 안전하게 접속하여 직접 확인 해야한다.
- EC2 콘솔 > 인스턴스로 이동
TIO-Spring-Server중 하나를 선택하고, 상단의 [연결(Connect)] 버튼을 클릭
- '세션 관리자(Session Manager)' 탭을 선택하고, [연결] 버튼 클릭 (브라우저에 검은색 터미널 창이 나타난다)
- 터미널에 아래 명령어들을 입력하여 확인
- 프로세스 확인:
java프로세스가 실행 중인지 확인
- 명령어를 실행했을 때,
... application.jar와 같은 내용이 보인다면 성공적으로 실행 중인 것, 아무것도 나타나지 않는다면 실행에 실패한 것... ps -ef | grep java- 배포 로그 확인: 저희가
start_server.sh에 설정한 로그 파일을 확인하여 배포 과정에 문제가 없었는지 본다
728x90'Jungle' 카테고리의 다른 글
트러블슈팅) spring CI/CD 빌드 실패 (0) 2025.07.10 파이썬 인스턴스 스펙(인스턴스 유형, 스토리지) 변경하기 (0) 2025.07.10 SSM을 활용한 개발환경(로컬 - mySQL workbench) 에서 RDS(AWS DB) 사용하기 (0) 2025.07.09 pre-signed URL 기법 (front → s3) (0) 2025.07.09 AWS CLI 및 SSM 플러그인 설정 (0) 2025.07.09
- 프로세스 확인: