나는 위 아키텍쳐에 따라 배포 자동화를 목표로 프로젝트를 진행 중이었다. 만들어진 애플리케이션을 GitHub Action을 통해 Docker 이미지로 빌드하고 ECR의 프라이빗 레포지토리에 푸시하는 과정 자동화는 성공했다.
이제 ECR의 최신 latest이미지를 가져와서 CodePipeline을 사용하여 자동으로 ECS에 올려 Fargate Task로 배포할 수 있게 작업 중이었다. CodePipeline 과정을 설정하는 것에서 가장 중요한 것은 source 단계(ECR)에서 imageDetail.json으로 출력된 아티팩트를 imageDefinition.json으로 변환하는 것이었다. 아마도 ECS를 잘 실행하기 위해서는 작업 정의가 필요한데, 원하는 형태가 있는 모양이다. 그래서 나는 아래와 같이 build단계의 프로젝트 이름을 Transform-to-imageDefinition으로 지정하고 입력 아티팩트를 ECR에서 받아온 SourceArtifact로 지정하고 출력 아티팩트 이름을 Transformed-Artifact로 지정하였다. 그 후 ECS의 입력 아티팩트를 Transformed-Artifact로 지정하여 위 아키텍쳐에 부합하는 파이프라인을 구성했다 생각했다..
그런데 문제가 생겼다.
Deploy과정이 실패한 것이다. 에러코드를 보니 다음과 같았다.
Unable to access the artifact with Amazon S3 object key 'p2-teama-pipe/Transforme/Hs2pFYA' located in the Amazon S3 artifact bucket 'codepipeline-ap-northeast-2-307317292352'.
The provided role does not have sufficient permissions.
아주 무서운 권한 문제이다..
내가 시도했던 행동들은 다음과 같다.
- s3 버킷정책 확인
- sufficient permissions가 없다 했으므로, s3의 최대 권한인 퍼블릭 액세스도 가능하게 해 보았다.
- IAM role에서 사용자에게 s3 full access 허용하기
설정된 버킷 정책은 다음과 같았다.
{
"Version": "2012-10-17",
"Id": "SSEAndSSLPolicy",
"Statement": [
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::codepipeline-ap-northeast-2-307317292352/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "DenyInsecureConnections",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::codepipeline-ap-northeast-2-307317292352/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
음.. 특정한 경우에만 Deny 하는 정책이 있으므로, 웬만하면 s3 권한 문제가 될 건 없어 보였다.
그러나 계속 deploy에서 같은 에러가 발생했고, stack overflow에서 해결의 실마리를 찾을 수 있었다.
첫 번째 댓글을 통해,
artifact:
files: imagedefinitions.json
가 빠져있을 수도 있겠다 라는 생각을 했다. 왜냐하면 나는 AWS 공식문서를 통해 printf 명령을 통해 imagesdefinitions.json 파일을 생성만 했지, 아티팩트로 파일을 지정해주진 않았기 때문이다.
또한 두 번째 댓글을 통해 s3를 확인해보니, 리소스에 아무것도 없었다.. 리소스 파일이 s3에 올라가지 않았으니 deploy를 할 게 없었던 것이고 s3에 접근해도 뭐가 없으니 permission 에러가 뜬다고 말해주었다. 참 없으면 없다고 하지 괜히 권한을 많이 건드려보았었다.
이러한 생각을 하고 다시 보니, AWS 공식문서에 이미지 정의 파일을 buildspec에 포함시켜라라는 한 줄의 안내가 있었다. 사실 공식문서에 다 친절히 안내되어 있었지만, 성급한 내가 지나쳤었다.
결과는 성공적이었다!
이 경험을 통해 다음을 깨우쳤다.
- 처음 하는 작업일 경우 공식문서를 찬찬히, 꼼꼼히 읽어보자!
- 실질적인 문제는 성공이라고 떴었던 build 단계에서 있었다. 모든 작업은 순서가 있으므로, 에러가 뜬 부분만 집중하지 말고 꼭 전후 관계를 확인해보자!
'배포자동화' 카테고리의 다른 글
[AWS]no identity-based policy allows the ecs:RegisterTaskDefinition action 에러 (0) | 2022.04.03 |
---|---|
[배포자동화]배포의 종류와 차이점 (0) | 2022.03.29 |