편집자 주: 함께 보면 좋아요!
애플리케이션 개발부터 배포까지, AWS CodeStar
CodeStar + Lambda + SAM으로 테스트 환경 구축하기
AWS Lambda + API Gateway로 API 만들어보자
목차
1. CodeStar 프로젝트 생성
2. 템플릿 선택
3. 프로젝트 정보 입력
4. 프로젝트 생성 및 자동 배포 확인
5. CodeCommit 접속
6. staging 브랜치 생성
7. index.py 수정 및 Commit
8. 람다 실행 권한 변경
9. 스택 생성 및 템플릿 소스 복사
10. 템플릿 소스 붙여넣기 및 S3 버킷 URL 생성
11. staging 브랜치용 CloudFormation 스택 생성(1)
12. staging 브랜치용 CloudFormation 스택 생성(2)
13. 파이프라인 설정
14. AWS CodeCommit 연결
15. CodeBuild
16. CodeDeploy
17. staging 브랜치용 파이프라인 생성 및 자동 릴리즈
18. 작업 그룹 추가
19. 파이프라인 실행 및 배포
20. API Gateway 접속 및 엔드포인트 확인
21. index.py 배포 확인
Overview
AWS는 유용한 서비스를 많이 제공하지만, 이것들을 조합하고 사용하는 건 꽤나 번거롭습니다. CodeStar는 이런 고충을 해결해주고자 등장한 서비스입니다. 버전 관리(CodeCommit)부터 빌드(CodeBuild)와 배포(CodeDeploy), 모니터링(CloudWatch)까지 한 번에 프로젝트를 구성해줍니다. 여기서 한 발 더 나아가 브랜치(master, staging)마다 자동으로 빌드, 배포되도록 구성했습니다. 이 포스팅에서는 AWS CodeCommit과 AWS Lambda(Python)을 사용했습니다. 물론 다른 스택을 사용해도 괜찮습니다.
Practice
1.CodeStar 프로젝트를 생성하겠습니다. CodeStar로 접속해 프로젝트를 생성합니다. CodeStar를 처음 사용한다면 서비스 역할을 생성하라는 창부터 나옵니다. 역할을 생성하고 진행합니다.
2.왼쪽 필터에서 웹 서비스, Python, AWS Lambda를 클릭하고 프로젝트 템플릿을 선택합니다.
3.프로젝트 정보를 입력하고 AWS CodeCommit을 선택, 프로젝트를 생성합니다. 코드편집 도구설정은 건너뜁니다. 나중에 다시 설정할 수 있습니다.
4.조금 기다리면 프로젝트가 생성됩니다. 오른쪽 아래의 엔드포인트로 접속하면 자동으로 생성되는 예제 프로젝트가 잘 배포된 것을 볼 수 있습니다. 클릭 몇 번으로 자동 빌드, 배포에 모니터링까지 가능한 프로젝트가 구성되었으니 이제 staging 브랜치를 생성하여 똑같이 구성하겠습니다.
5.먼저 브랜치를 생성하겠습니다. CodeCommit에 접속해 왼쪽의 브랜치 메뉴를 클릭하면 아래와 같이 master 브랜치가 생성된 것을 볼 수 있습니다.
6.브랜치 생성을 클릭해 브랜치 이름은 staging, 다음으로부터의 브랜치는 master를 선택합니다.
7.생성된 staging 브랜치를 클릭하면 파일 리스트가 보입니다. master 브랜치와 결과 페이지를 구별하기 위해 index.py 파일을 임의로 수정하겠습니다. index.py > 편집을 클릭해 output 문자열을 수정하고 Commit합니다.
8.CodeStar는 CloudFormation 서비스로 인프라 리소스를 관리합니다. CloudFormation은 ‘스택’이라는 개념을 사용해 설정을 구성하고 있습니다. 지금은 master 브랜치의 template.yml 파일을 사용해 master 브랜치용 스택이 생성되어 있는 상태입니다.
문제는 여기에 기본적으로 람다(lambda) 실행 역할이 구성되어 있는데, 이 역할의 리소스 접근 권한은 master 브랜치 람다로 한정되어 있다는 것입니다.1)
이 글에서는 staging용 람다 실행 권한을 별도로 생성하는 방법으로 문제를 해결했습니다. staging 브랜치의 template.yml 파일을 열어 Resources: LambdaExecutionRole: Properties: RoleName을 임의의 값으로 수정합니다. 저는 뒤에 ‘-staging’을 붙였습니다.
9.CloudFormation 스택도 따로 생성합니다. AWS CloudFormation에 접속하면 기본적으로 생성된 스택을 볼 수 있습니다. 기존의 스택 템플릿에서 조금만 수정해 스택을 생성하면 되니 템플릿을 복사해오겠습니다.
awscodestar-testproject-lambda를 클릭해 오른쪽의 ‘Designer에서 템플릿 보기/편집’을 클릭하면 템플릿 소스를 볼 수 있습니다. 가장 아래의 템플릿 탭이 클릭되어 있는지 확인하고 그대로 복사합니다.
10.다시 CloudFormation으로 돌아와 템플릿 디자인 버튼을 클릭하고 복사한 소스를 붙여 넣습니다. 여기서 마찬가지로 Resources: LambdaExecutionRole: Properties: RoleName을 조금 전의 이름과 같게 수정하고 저장합니다. 템플릿 언어를 YAML로 바꾸고 수정하면 보기 편합니다.
Amazon S3 버킷에 저장하면 템플릿 파일이 S3 버킷에 저장되며 S3 버킷 URL이 생성됩니다. 잘 복사해둡니다. 템플릿 디자이너는 이제 닫아도 됩니다
11.CloudFormation 창에서 스택 생성을 클릭해 Amazon S3 템플릿 URL에 복사한 URL을 입력합니다. 이후의 내용은 스택 이름만 다르게 하고, 나머지는 기본적으로 생성된 스택 정보와 동일하게 입력합니다. 기존에 생성한 스택 정보는 스택 상세 페이지 오른쪽의 스택 업데이트를 클릭하면 볼 수 있습니다.
생성 페이지 마지막의 ‘AWS CloudFormation에서 사용자 지정 이름을 갖는 IAM 리소스를 생성할 수 있음을 승인합니다’를 체크하고 생성을 클릭합니다.
12.staging 브랜치용 CloudFormation 스택이 생성되었습니다. 이 스택을 사용해 staging 브랜치용 파이프라인을 생성하겠습니다.
13.CodePipeline으로 접속해 파이프라인 생성을 클릭하면 설정창으로 이동하는데, 아래 이미지와 같이 입력합니다.
CodeStar프로젝트가 생성되며 IAM 역할과 S3 버킷이 자동 생성되는데, 동일한 역할과 버킷으로 설정하면 됩니다. 파이프라인 이름만 임의로 다르게 넣어줍니다.
14.AWS CodeCommit을 연결해야 합니다. 아래와 같이 자동 생성된 리포지토리를 선택하고 미리 생성한 staging 브랜치를 연결합니다.
15.CodeBuild를 알아보겠습니다. 기본 파이프라인에서 자동 생성된 프로젝트를 선택하고 다음을 클릭합니다.
16.새 창을 열어 기존에 생성된 파이프라인 상세 페이지로 접속합니다. 편집을 클릭하고 Deploy 스테이지 편집을 클릭, GenerateChangeSet 편집 버튼을 클릭하면 설정값이 보입니다. 이 값을 참고해 다음 스텝을 아래와 같이 진행하면 됩니다.
앞서 생성했던 staging 브랜치 파이프라인용 스택을 연결하고, 세트 이름을 임의로 다르게 넣습니다. ‘템플릿’과 ‘템플릿 구성 - 선택 사항’ 설정값도 다르니 주의합니다.
17.다음으로 진행하면 staging 브랜치용 파이프라인이 생성되어 자동으로 릴리즈되고 있는 것을 볼 수 있습니다.
18.여기서 master 파이프라인과 동일하게 Deploy 스테이지의 GenerateChangeSet 아래에 작업 그룹을 하나 추가해야 합니다. 마찬가지로 master 파이프라인을 참고해 작성힙니다. 작업이름, 새로 생성한 스택, staging용으로 임의 작성했던 세트 이름을 넣습니다.
19.저장 후, 변경사항 릴리스를 클릭하면 파이프라인이 실행됩니다. 잠시 기다리면 완료와 함께 배포작업까지 이뤄집니다.
20.모든 작업이 끝났습니다! 제대로 구성되었는지 엔드포인트로 접속해 확인해보겠습니다. AWS API Gateway로 접속해 staging 브랜치용 API Gateway를 클릭합니다.
21.왼쪽의 스테이지 메뉴를 클릭하면 엔드포인트 URL을 볼 수 있습니다. 이 URL로 접속하면 위에서 편집한 staging 브랜치의 index.py가 배포된 것을 볼 수 있습니다. master 브랜치의 엔드포인트로도 접속해서 비교해보세요.
Conclusion
AWS의 서비스들은 강력하고 다양합니다. 그 수가 많아져 이제는 전부 다루기는커녕 나열하기도 어려울 정도입니다. 아마존에서도 이런 고충을 알기 때문에 여러 서비스를 묶어 간편하게 세팅하는 CodeStar를 제공하는 게 아닌가 싶습니다. 수가 많은 만큼 각각의 서비스를 정확히 이해하고 적절히 이용해 오버엔지니어링을 피하는 게 중요하겠습니다.
참고
1) IAM - 역할 - Permission boundary에서 확인 가능합니다
양정훈 사원 | R&D 개발3팀
yangjh@brandi.co.kr
