aws SAM init & deploy 해보기

https://travis.media/developing-aws-lambda-functions-locally-vscode/ 의 내용을 수행하며 정리한 내용이다.

1. sam 설치

2. docker 설치 - 윈도우는, wsl 2 버전으로의 업데이트를 msi로 꼭 해주어야 도커가 잘 실행된다.

3. index 파일 및 yml 작성

   • runtime이 노드일 경우 아래와 같이 기입
     

4. sam build 해보기.

   • 실행하게 되면 .aws-sam 아래에 build된 파일들이 생기게 됨. 코드 변경 후 항상 빌드를 해주어야 한다고 함

5. 로컬에서 lambda 함수 호출해보기

   • 루트아래 events/events.json 파일을 만들어 index 코드에서 작성된 변수를 생성함
     
   • sam local invoke HelloNameFunction(아마 여긴 명시한 function 이름) -e events/events.json 실행
     - 혹시나 해서 yml 의 HelloNameFunction을 TestFunc로 바꾼 후 build 없이 실행해보았지만, 역시 오류를 뱉었다.
     

aws typescript 버전 sample로 다시 실행

https://aws.amazon.com/ko/blogs/compute/building-typescript-projects-with-aws-sam-cli/

1. sam init으로 typescript를 지정하여 폴더 생성

에러발생, 자꾸만 폴더에 권한이 없다고 함.

window에서 temlplate 파일의 위치를 설치중 잘못 잡는다고 함. https://github.com/aws/aws-sam-cli/issues/1891 location 파라미터와 함께 재실행


위와 같이 보이는 typescript-nodejs 폴더까지의 경로를 명시해 줘야함. 알고보니, 중간에 AWS SAM이라는 폴더 명이 윈도우에서 말썽을 일으키는 것 같았음.

2. sam build & deploy 하기

빌드 과정에서 esbuild를 사용한다. esbuild는 type checking을 하지 않기 때문에 tsc를 써야할 수도 있다.

3. template.yml 의 esbuild 프로퍼티 metadata를 커스텀한다.

현재로써 마땅히 건드릴/건드려야 할 것이 없다.

4. credential 추가

deploy를 위해 credential을 추가해주어야 한다.
위와 같은 파일을 만들기 위해 로그인 한 계정의 계정 증명 섹션으로 가보면 다음과 같은 화면이 활성화 되어 있다.
액세스 키를 새로 만들어서 aws 액세스 키와 비밀 액세스 키를 가져와 cli 환경에서 configure 명령어로 등록한다
aws에 profile을 두개 설정하려고 aws configure list-profiles를 해서 확인해 보았다. aws cli 버전이 2가 아닌 1이라서 해당 커맨드가 존재하지 않았다. 2를 냅다 설치하고 다시 확인해보자.
정상적으로 등록되었다~

5. deploy 해보기

sam deploy --guided 로 실행하고자 하였으나..

위 에러는 MFA(모바일 디바이스 인증) 을 사용할 때 생기는 오류라고 한다. 이를 위해서...는 여러가지 과정을 거쳐 MFA를 사용하여(?) cli 로그인 세션을 생성하여 토큰을 명시 하고 사용하면 된다는데, 이게.. 최장 시간이 3시간이다.
개발 환경을 구성하고 싶은 입장에서 이는 원하지 않은 상황이었고 admin 계정에 대한 역할로 수행되면 충분할 일이었다. 그래서, 내 이름으로 된 백엔드 전용 아이디로 작업하는 상황을 가정하고 credential을 바꾸었다.

다음 상황은, cloudforamtion 에 대한 kwangho 계정의 권한이 없다는 내용이다. cloudforamtion 에 대한 권한을 갖는 작업 목록을 확인하여 계정의 권한에 추가하면 될 듯 하다. https://docs.aws.amazon.com/ko_kr/service-authorization/latest/reference/list_awscloudformation.html
하지만, 권한이라는 것은 상황에 맞게끔 설정되는 것이 좋다고 생각되고 필요한 상황에 추가해 나가는 것이 익숙해지는 데 도움될 것 같아 찾아서 설정해주기로 했다. (번거롭지만.)
cloudformation:CreateChangeSet 을 포함하는 작업 중 적당한 것을 확인해 보았다.

아.. 딱 하나 밖에 없는 걸 보니 이걸 추가하는게 cloudformation 을 사용하기 위한 기본 조건인가보다. 권한은 관리자 급의 역할을 하는 계정으로 접속하여 맴버에 대한 권한을 부여하면 된다.
권한 부여 화면에서 기존 정책 직접 연결이 있다. 이쪽에 위에서 찾은 '작업' 의 권한이 바로 있을 줄 알았지만, 그것이 아닌 정해진 어느 정도의 정책은 여러가지의 '작업' 권한을 포함하는 세트인 듯 싶었다. 이해관계가 바로 된 상황에서 내 정책을 생성한다는 것은 여러 '작업' 권한을 포함한 정책을 일컫는 것인가보다.
아무튼, cloudforamtion에 대한 full access가 정책으로 있는 것을 선택해서 kwangho 계정에 부여하였다. 다시 deploy를 하려 하는데...

매번 저걸 다시 해야하는 것은 싫다.. toml 파일을 생성해주자. aws 공식 문서를 참고하여 일반 deploy가 요구하는 arg를 다 명시하면 이제 더는 안물어보겠지

위의 deploy 영역에서 요구되는 parameter를 모두 써주자. 위 작업에서 명시되지 않는 명령어는 일단 모두 삭제한다.

이 정도로 배포를 수행해본다.

y/n은 계속 물어봤다. 하지만 명시되어 있겠지 하며 엔터를 누르다보면 위 에러가 나는데... y/n 을 명시해주면 정상 작동된다.

아무튼의 에러가 난다. 헬스체크가 제대로 되어 있지 않기 때문이라고 한다... 이를 위해 검색해보니, cloudformation에서 기존 스택을 정상화하라고 한다. 근데 난 만든적이 없는데..??

근데 진짜 있다. 아마 과정 중에 생성되었다가 중간에 무언가 명시되지 않아 에러가 생기고 그대로 상태가 고장난 것을 계속 쓰려고 해서 이상이 생겼나보다. 스택을 삭제하고 다시 deploy 해본다.
Error: Failed to create managed resources: Waiter StackCreateComplete failed: Waiter encountered a terminal failure state: For expression "Stacks[].StackStatus" we matched expected path: "ROLLBACK_COMPLETE" at least once
오늘 안에 할 수 있는건가
-
아무튼, 검색을 조금 해보니 git issue 들에 많은 사람들이 s3 를 연동하면서 생기는 문제라고 하는 것 같다. 디버그 상에서도 s3 부분에서 에러가 생겼고. 그렇다면.. s3에 대한 모든 권한을 설정해주어야 할까?
s3에 대한 fullaccess를 kwangho 에게 설정하였다. 그렇게 하니 stack 까지는 생성하게 되는 듯 하다.
다음 스테이지. deploy 중간에 스택의 각 리소스에 접근할 역할들을 생성하는 권한이 kwangho 에게 없기 때문에 여기서 y를 한 것은 실수였나보다. n으로 다시 deploy한다. 위 옵션의 여부랑 다르게 IAM의 역할 생성은 필요한 듯 싶어 (에러가 계속 발생했다) IAM fullaccess를 부여했다.
쉽게 가야겠다. 해당 작업에 필요한 모든 권한을 부여할 것이다. debug 옵션 덕분인지, deploy에 필요한 모든 작업을 간략하게 띄워주는 것을 확인할 수 있었다. api point에 대한 관리자 권한도 부여했다.
드디어 성공했다. 젠장.