0

SAM を使用して API の v1 をデプロイしました。スタックは、API Gateway、Lambda、および DynamoDB テーブルです。

Lambda 関数は、AutoPublishAliasプロパティを介してバージョン管理されます。別名は「ライブ」。v1 の新しいリリースをデプロイするたびに、新しい Lambda バージョンを取得し、「Live」エイリアスが新しいリリースを指すように変更されます。次に例を示します。

発売前：

Lambda version:
              3 <--- Alias: Live <--- v1 API
              2
              1

リリース後:

Lambda version:
              4 <--- Alias: Live <--- v1 API
              3
              2
              1

ここで、v2 をデプロイしたいのですが、v1 はデプロイしたままにします。

/v1 および /v2 ベース パスを使用してパスを作成するように、swagger を変更する方法を検討しました。また、v1 の最後のリリースを指す「v1」エイリアスを作成し、そのエイリアスを /v1 API に使用します。次に例を示します。

Lambda version:
              5 <--- Alias: Live <--- v2 API
              4 <--- Alias: v1   <--- v1 API
              3
              2
              1

次にAutoPublishAlias、新しいリリースごとに「ライブ」エイリアスを引き続き移動しますが、「v1」エイリアスは元の場所に保持されます。たとえば、次のようになります。

新しい v2 リリース

Lambda version:
              6 <--- Alias: Live <--- v2 API
              5
              4 <--- Alias: v1   <--- v1 API
              3
              2
              1

これは、v1 にバグを修正するのが難しいという例外を除いて、理論的根拠のように思えます。SAM を使用した API のバージョン管理 (Lambda のバージョン管理ではない) に関する議論がインターネット上で見つからないことに驚いています。これを処理するための規則はありますか?

4

1 に答える 1

1

慣習はないと思います。誰もが自分のニーズに合った独自のことをしています。

できることの 1 つは、Lambda Aliasリソースを SAM テンプレートに追加し、v1 を関数のバージョン 4 に手動で固定することです。

MyLambdaV1Version:
  Type: AWS::Lambda::Alias
  Properties:
    FunctionName: !Ref MyLambda
    FunctionVersion: 4
    Name: v1

ただし、バグ修正リリースを v1 にプッシュすることには問題があることを正しく指摘しています。v1 と v2 を独立した Cloudformation スタックに分割することをお勧めします。あなたの関数は API ゲートウェイの背後にあり、言及されたバグ修正リリースに加えて、v1 のさらなる開発は凍結されていると思います。

于 2019-01-16T13:40:00.807 に答える