AWS SAM と Go を使用した API の構築

AWS SAM は、Infrastructure as Code (IAC) 経由で Web アプリケーションをデプロイする優れた方法です。最近、仕事のプロジェクトでそれを使おうとしたところ、厳しい現実に遭遇しました...

Go は 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)

これは、ラムダが実行されるオペレーティング システムを指します。 al2023 はより新しく、低価格で優れたパフォーマンスを提供する AWS Graviton プロセッサと互換性があるため、使用することをお勧めします。

とにかく、これらのランタイムでは、各ラムダ関数内で実行される実行可能ファイル (通常はブートストラップという名前) を提供する必要があります。 したがって、コードをラムダに配信する代わりに、以前に 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>

Lambda の定義を見ると、次のことが分かります:

1. BuildMethod: go1.x AWS の組み込み Go ビルダーを使用して実行可能ファイルをビルドします
2. CodeUri: hello-world/ ラムダ コードはこのディレクトリにのみ保存されます。
3. ハンドラー: bootstrap 実行可能ファイルの名前は bootstrap になります
4. ランタイム: provided.al2023 これがランタイムになります。

問題がわかりますか?現在、2 番目のラムダが必要です。独自の go.mod、go.sum、および依存関係を含む新しいディレクトリを作成する必要があります。2 つのラムダ間でユーティリティ関数を共有したい場合はどうすればよいでしょうか?残念な？！同じファイルを新しい lambda フォルダーにコピーする必要があります。これにより、次のようなファイル構造が残ります:

これはとても悪いことですか？

<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. すべての公開コードをinternal/ フォルダーに分割しました。
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 と Go を使用した API の構築の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。