이번에는 3편에서 만든 CodePipeline을 실행하면 발생하는 오류를 해결해보도록 하자
1. 빌드 오류사항 파악
1-1. 오류 발생
- 잘 만들어서 동작시켰더니 빌드에서 오류가 발생했다. 이를 파악하기 위해 실행 실패 하단의 "CodeBuild에서 보기"를 클릭했다.
1-2. 오류 파악하기
- "빌드 상태" 하단에 있는 “단계 세부 정보” 목록을 클릭해서 오류를 확인했다.
- DOWNLOAD_SOURCE단계에서 아래와 같은 오류가 발생했다.
CLIENT_ERROR: RequestError: send request failed caused by: Get "https://codepipeline-ap-northeast-2-555139989952.s3.ap-northeast-2.amazonaws.com/Recipia-member-git/SourceArti/87tmyth": dial tcp 3.5.143.181:443: i/o timeout for primary source and source version arn:aws:s3:::codepipeline-ap-northeast-2-555139989952/Recipia-member-git/SourceArti/87tmyth
1-3. 에러코드 분석하기
- request failed caused by: Get하고 "s3.ap-northeast-2.amazonaws.com" 라는 내용이 있는것으로 보아 S3 관련 문제라고 생각했다. 그리고 "i/o timeout" 라고 적혀있는것도 있어서 네트워크 문제가 아닐까? 라는 생각이 들었다.
- GPT는 이렇게 대답했다.
- S3 접근: dial tcp 3.5.143.181:443: i/o timeout 부분은 S3에 연결할 수 없음을 나타내므로, S3 버킷에 접근할 수 있는지도 확인해 보세요.
2. 빌드 오류 해결하기 (S3 액세스 오류 해결하기)
2-1. S3 액세스 확인하기
- 내가 봐도 S3의 접근 문제인것 같아서 Amazon S3 버킷으로 들어와서 확인했다. 액세스에 "버킷 및 객체가 퍼블릭이 아님" 이라고 되어있었다.
2-2. S3 액세스 직접 체크하기
- S3에서 내가 연결시킨 버킷(codepipeline)에 파일을 업로드해서 접근 가능성을 확인했다.
- 버킷에 들어가서 우측 상단의 "업로드" 버튼을 클릭한다.
- 업로드화면은 아래와 같다. 여기서 우측의 “파일 추가” 버튼을 눌러서 파일을 추가한다.
- 아래 화면처럼 추가한 파일이 나올텐데 여기서 추가한 파일을 선택하고 하단의 “업로드” 버튼을 누른다.
- 아래와 같은 업로드에 실패했다는 메시지창이 나온다.
- 아래 사진처럼 “파일 및 폴더”의 리스트에 있는 오류사항을 확인해 보면 “오류 : 엑세스가 거부됨”이라고 나와있다.
- 지금처럼 S3 버킷에 파일 업로드가 안 되는 경우, 주로 IAM (Identity and Access Management) 정책 또는 S3 버킷 정책, 또는 둘 다에 문제가 있을 가능성이 높다고 한다.
2-3. S3 버킷 액세스 퍼블릭으로 만들기
- 액세스를 변경하고자 하는 버킷을 클릭해서 들어간다. (여기서는 codepipeline 버킷)
2-4. 들어왔다면 상단 메뉴바를 보면 3번째에 있는 "권한"을 클릭해서 들어간다.
- "권한"을 누른 후 하단의 내용을 보면 퍼블릭 액세스 차단(버킷 설정) 메뉴가 존재한다. 여기서 “편집”버튼을 클릭한다.
2-5. 퍼블릭 액세스 차단 편집하기
- 아래와 같은 화면이 나오는데 여기서 체크된 버튼을 없애준다.
- 아래와 같이 체크박스를 해제하면 된다. (여기서 주의할 점은 퍼블릭 액세스는 보안을 고려해서 진행해라)
- 이후 하단의 "변경 사항 저장" 버튼을 클릭한다.
- 아래와 같이 편집이 완료되었다고 나올것이다.
2-6. ACL 열어주기
- 이제 ACL을 열어줄 차례다. S3버킷에서 위와 똑같이 권한을 선택해서 하단의 리스트를 확인한다. 그럼 하단에 아래와 같이 객체 소유권이 있을것이다. 여기서 우측의 "편집" 버튼을 클릭한다.
- 객체 소유권에서 처음에는 ACL 비활성화가 되어있을텐데데 ACL활성화를 해주자.
- 설정을 완료하면 아래와 같이 나온다.
2-7. 다음으로 S3버킷의 정책을 설정한다.
- 객체 소유권을 설정한 후 위로 스크롤을 해보면 "버킷 정책"이 있는데 여기서 우측에 있는 "편집" 버튼을 누른다.
- 버킷 정책 편집으로 바뀌는데 여기서 우측의 "정책 생성기" 버튼을 클릭한다
- 아래의 페이지로 이동할텐데 Step1에는 Select Type of Policy에 "S3 Bucket Policy"를 선택해 준다.
- Step2에서 Principal에는 *를 적어주고 Actions에는 GetObject, PutObject를 선택해 준다. (2 Actions라는게 옆의 2개를 선택해서 저렇게 보이는 것이다.)
- Actions 다음에 적는 "ARN"에는 이전 작성하던 페이지인 "버킷 정책"에 있던 "버킷 ARN" 값을 복사해서 넣는다.
- 다시 정책 생성으로 돌아와서 Step2 하단의 “Add Statement” 버튼을 누르면 아래와 같이 Step3: Generate Policy가 생긴다.
- Step3 하단의 “Generate Policy” 버튼을 클릭한다.
- 아래와 같은 JSON값을 보여주는 팝업창이 나올텐데 이 JSON 값을 복사한다.
- 이제 정책 하단의 에디터에 기존에 적혀있던 Json값을 삭제하고 위에서 복사한 값을 붙여넣기 한다. 이후 하단의 "변경 사항 저장" 버튼을 클릭한다.
- 저장했더니 아래와 같은 오류가 발생했다. 읽어보니 "Actions does not apply to any resource(s) instatement" 였다.
- Resource에 문제가 있어서 아래와 같이 value의 맨 뒤에 "/*"를 추가해 줬다.
- 다시 "변경 사항 저장"을 시도하니 성공했다.
2-8. 액세스 권한 확인하기
- 이제 페이지를 새로고침하면 아래와 같이 나온다. 액세스가 퍼블릭으로 전환되어 있는것을 확인할 수 있다.
- 버킷 목록에서도 액세스가 "퍼블릭"으로 보였다.
2-9. ACL 편집하기
- 이제 ACL(액세스 제어 목록) 우측의 “편집”을 클릭한다.
- 여기서 객체의 "나열"과 "쓰기"를 모두 열어줬고 버킷 ACL도 "읽기", "쓰기"를 일단 모두 열어줬다.
여기까지가 S3의 액세스를 "퍼블릭"으로 열어주는 과정이었다. 이제 IAM 정책도 수정하자
3. CodeBuild의 IAM 서비스 역할에 S3 액세스 권한 부여하기
3-1. IAM 사용자 그룹에 S3 역할을 열어줘야 하는가?
- AWS CodeBuild 작업에서 S3 리소스에 액세스하려면 CodeBuild 프로젝트에 지정된 IAM 서비스 역할이 S3 액세스 권한을 가져야 한다. 개별 IAM 사용자 계정의 권한은 이 과정에 영향을 주지 않는다.
3-2. IAM 서비스 역할:
- CodeBuild 프로젝트를 생성할 때 지정한 IAM 서비스 역할에 AmazonS3FullAccess 정책이나 S3 액세스 권한을 부여하는 다른 정책을 연결해야 한다. 이렇게 하면 CodeBuild 작업이 S3 버킷에 액세스하여 소스 코드를 다운로드할 수 있다.
- CodeBuild프로젝트를 생성할 때 아래와 같은 이름으로 역할을 만들었었다.(역할을 새로 만든적이 여러번이라 이전 포스트와 역할 이름은 다를수도 있다.) 이 새로만든 역할에 S3 액세스 권한을 부여해야 한다.
- 바로 IAM > 역할로 들어가서 위에서 작성한 역할 이름을 검색해 봤다. 나오는 역할의 이름을 클릭해서 들어가자
- IAM 역할 요약에서 하단의 "권한 정책" 옆에있는 "권한 추가" 버튼을 눌러서 "정책 연결"을 클릭한다.
- 여기서 s3를 검색해서 "AmazonS3FullAccess"를 클릭한다. 이후 하단의 "권한 추가" 버튼을 누른다.
- 정책이 역할에 연결되었다고 나올것이다.
IAM 사용자 계정에 AmazonS3FullAccess 정책을 연결해도 CodeBuild 작업의 S3 액세스에는 영향을 주지 않는다. CodeBuild 작업의 S3 액세스를 제어하려면 CodeBuild 프로젝트에 지정된 IAM 서비스 역할을 업데이트해야 한다.
4. S3의 VPC - 엔드포인트 적용하기 (적용하지 않음)
4-1. S3에 접근하기 위해 VPC의 엔드포인트를 설정해야하는가?
AWS CodeBuild 프로젝트를 생성할 때 VPC를 선택하지 않았다면, CodeBuild는 AWS의 기본 네트워크 환경에서 실행된다.
이 경우, CodeBuild 인스턴스는 인터넷을 통해 AWS 서비스와 다른 온라인 리소스에 액세스할 수 있다.
S3 액세스:
- VPC를 선택하지 않고 기본 네트워크 환경에서 CodeBuild를 사용하면, CodeBuild는 자동으로 인터넷을 통해 S3와 같은 AWS 서비스에 액세스할 수 있다. 따라서 VPC 엔드포인트를 설정할 필요가 없다.
네트워크 구성:
- VPC 선택을 하지 않았다면, 네트워크 관련 구성은 기본적으로 관리되며, 사용자는 별도의 네트워크 구성을 설정할 필요가 없다.
보안:
- VPC 내에서 CodeBuild를 실행하려면, VPC와 관련된 보안 및 네트워크 구성을 관리해야 한다. 하지만 VPC를 선택하지 않았다면, 이러한 추가 구성은 필요하지 않다.
따라서, VPC를 선택하지 않고 CodeBuild 프로젝트를 생성했다면, 별도의 VPC 엔드포인트 설정 없이도 S3에 액세스할 수 있어야 한다.
4-2. 나의 CodeBuild구성 확인
- 아래와 같이 이전에 CodeBuild를 구성할때 나는 VPC를 선택하지 않았다.
즉, 나는 VPC를 선택하지 않았기 때문에 따로 엔드포인트를 설정하지는 않았다.
5. 빌드 시도하기
5-1. 다시 파이프라인으로 들어가서 우측의 "변경 사항 릴리스"를 클릭한다.
5-2. 다시 Build가 될텐데 여기서 하단의 "세부 정보"를 클릭해서 들어간다.
5-3. 세부 정보로 들어오면 "빌드 상태"가 보이는데 하단의 "단계 세부 정보" 메뉴를 체크한다.
5-4. 이번에는 S3의 접근관련된 오류는 사라졌다. 이전에 S3에 대한 엑세스 설정을 해준것들이 효과가 있었던것 같다.
5-5. 대신 이번에는 PRE_BUILD 단계에서 새로운 에러가 발생했다.
새롭게 발생한 PRE_BUILD 단계의 에러는 다음 포스트에서 해결해보도록 하자
2023.10.30 - [AWS] - AWS CI/CD: CodePipeline 두 번째 빌드 오류 해결 (5편)
AWS CI/CD: CodePipeline 두 번째 빌드 오류 해결 (5편)
이번에는 PRE_BUILD 단계에서 발생한 빌드오류를 해결해 보자 1. 빌드 오류 파악하기 1-1. 오류 파악 열심히 S3 관련 문제를 해결했더니 이번에는 아래와 같은 PRE_BUILD 단계에서 에러가 발생했다. COMMA
curiousjinan.tistory.com
2023.10.29 - [AWS] - AWS CI/CD: CodePipeline 배포 및 검토 (3편)
AWS CI/CD: CodePipeline 배포 및 검토 (3편)
이번에는 2편에 이어서 Step4 배포 스테이지와 Step5 검토를 작성한다. 1. Step4: 배포 스테이지 추가 1-1. 배포 스테이지 추가 Step3에서 다음을 누른다면 아래와 같은 배포 스테이지 추가 화면으로 이
curiousjinan.tistory.com
'AWS > CodePipeline, CICD' 카테고리의 다른 글
| AWS CI/CD: CodePipeline 세 번째 빌드 오류 해결 (6편) (1) | 2023.10.30 |
|---|---|
| AWS CI/CD: CodePipeline 두 번째 빌드 오류 해결 (5편) (1) | 2023.10.30 |
| AWS CI/CD: CodePipeline 배포 및 검토 (3편) (0) | 2023.10.29 |
| AWS CI/CD: CodePipeline 빌드 스테이지 추가 (2편) (2) | 2023.10.29 |
| AWS CI/CD: CodePipeline 기본 설정 (1편) (1) | 2023.10.29 |