AWS SAM and Go를 사용하여 API 구축

AWS SAM은 IAC(Infrastructure as Code)를 통해 웹 애플리케이션을 배포하는 좋은 방법입니다. 최근 업무 프로젝트에 사용하려고 하다가 냉혹한 현실에 부딪혔는데...

가면 AWS의 미운 오리새끼인가요?

AWS SAM Go 전용 문서 섹션은 매우 짧고 모호하므로 소스 코드를 광범위하게 반복할 것을 권장합니다! 모든 람다 함수에는 go.mod, go.sum 및 유틸리티 함수가 있습니다?!

저처럼 혼란스러운 여러분을 위해 이 글을 씁니다.?‍?. 이 문제를 함께 해결해 봅시다!

2부작 시리즈로 구성됩니다.

1. 파일 구조(본 글)
2. SAM 구성

런타임 컨텍스트 이동

현재 Go 런타임에서는 람다가 지원되지 않습니다. 즉, AWS Lambda에는 코드가 Go로 작성되도록 지정하는 특정 옵션이 없습니다. 대신 AWS는 2가지 공통 런타임을 제공합니까?

• al2(Amazon Linux 2)
• al2023(Amazon Linux 2023)

람다가 실행될 운영 체제를 나타냅니다. 더 새로운 버전이고 저렴한 가격으로 더 나은 성능을 제공하는 AWS Graviton 프로세서와 호환되는 al2023을 사용하는 것이 좋습니다.

어쨌든 이러한 런타임에서는 각 람다 함수 내에서 실행될 실행 파일(일반적으로 부트스트랩이라는 이름)을 제공해야 합니다. 그래서 코드를 람다에 전달하는 대신 이전에 Go로 컴파일한 실행 파일 을 전달합니다. 아주 간단하죠?

또한 모든 공통 종속성이 컴파일된 실행 파일에 패키지되므로 JS와 같은 언어에 대한 람다 계층이 필요하지 않습니다.

질문

그럼 이 실행 파일을 어떻게 빌드하나요? AWS에서는 각 람다를 go.mod 및 go.sum과 함께 폴더에 저장할 것을 권장하며, 이들이 제공하는 템플릿은 다음과 같습니다.

<code>.
├── hello-world/
│   ├── go.mod
│   ├── go.sum
│   └── main.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>

template.yaml의 함수 정의입니다

<code>  HelloWorldFunction:
    Type: AWS::Serverless::Function 
    Metadata:
      BuildMethod: go1.x
    Properties:
      CodeUri: hello-world/
      Handler: bootstrap
      Runtime: provided.al2023
      Architectures:
        - x86_64
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: /hello
            Method: GET</code>

람다 정의를 살펴보면 다음과 같은 내용을 알 수 있습니다.

1. BuildMethod: go1.x AWS에 내장된 Go 빌더를 사용하여 실행 파일을 빌드합니다.
2. CodeUri: hello-world/ 람다 코드는 이 디렉터리에만 저장됩니다.
3. 핸들러: bootstrap 실행 파일 이름은 bootstrap입니다
4. 런타임: 제공된.al2023 이것이 런타임이 됩니다.

문제가 보이시나요? 현재 두 번째 람다가 필요합니다. 자체 go.mod, go.sum 및 종속성이 있는 새 디렉터리를 만들어야 합니다. 두 람다 간에 유틸리티 기능을 공유하려면 어떻게 해야 할까요? 너무 나쁘다?! 동일한 파일을 새 람다 폴더에 복사해야 합니다. 그러면 다음과 같은 파일 구조가 남습니다:

너무 심해요?!

<code>.
├── function1/
│   ├── go.mod
│   ├── go.sum
│   ├── main.go
│   └── SHAREDFUNC.go
├── function2/
│   ├── go.mod
│   ├── go.sum
│   ├── main.go
│   └── SHAREDFUNC.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>

중복된 ​​코드가 많아요!

그리고 더 많은 람다를 추가할수록 상황은 더욱 악화됩니다. 더 좋은 방법이 있을 겁니다!

솔루션

모든 람다를 통해 go.mod, go.sum 및 유틸리티 코드를 공유하고 싶기 때문에 다음과 같은 구조를 생각해냈습니다.

<code>.
├── hello-world/
│   ├── go.mod
│   ├── go.sum
│   └── main.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>

1. 공개 코드를 모두 내부/ 폴더로 분리했습니다.
2. go.mod 및 go.sum 파일을 루트 디렉터리에 넣습니다.
3. 모든 람다 진입점을 /cmd로 이동합니다(Go에는 프로젝트에서 여러 실행 파일을 생성할 때마다 진입점이 cmd 디렉터리에 배치된다는 규칙이 있습니다).

이제 AWS SAM에 이 새로운 구조를 알리기만 하면 되나요?! CodeUri와 Handler의 값을 조정하는 것만으로도 해결책을 찾았습니다.

비밀?

그러면

• go.mod 및 go.sum을 루트 폴더로 이동
• CodeUri를 함수 진입점이 있는 폴더로 설정합니다.

SAM은 이를 자동으로 감지하고 루트 종속성과 내부/코드를 사용하여 빌드합니다. ?

<code>  HelloWorldFunction:
    Type: AWS::Serverless::Function 
    Metadata:
      BuildMethod: go1.x
    Properties:
      CodeUri: hello-world/
      Handler: bootstrap
      Runtime: provided.al2023
      Architectures:
        - x86_64
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: /hello
            Method: GET</code>

더 좋아질 수 있을까요?

예✨, 다음 글에서 Go 컴파일을 사용자 정의하는 더 많은 방법에 대해 논의하겠습니다!

위 내용은 AWS SAM and Go를 사용하여 API 구축의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!