Pocket

1ヶ月のブログとなります。皆さんお元気ですか!?最近、API GatewayをバシバシTerraform化しているのですが、rootのリソース / 配下にPOSTメソッドを設定する場合、どうしても以下のようになってしまい、見事にハマりました。

今回は下記のように設定したい場合、ブログしたいと思いますが、まずはNGだったコードを見てみましょう。


api_gateway.tf

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/api_gateway_resource
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/api_gateway_method

メソッドは上記のようにリソースを定義しないとTerraformの変数として取り出すことができません。ちなみに path_part = "/" にしていますが、これだと下記のように / は文字列として対応していないから直せと怒られてしまいます。なので、 POST でイケるかと思い上記のようにrootリソース配下にPOSTができてしまい、その配下にPOSTメソッドができちゃうわけですね。(そりゃそうだ)じゃあどうするのといったところで、ドキュメントにも見当たらず、stack overflowにて発見しました。

Error: Error creating API Gateway Resource: BadRequestException: Resource’s path part only allow a-zA-Z0-9._- or a valid greedy path variable and curly braces at the beginning and the end.


Terraform: How to create a api gateway POST method at root?

https://stackoverflow.com/questions/61072514/terraform-how-to-create-a-api-gateway-post-method-at-root

The “root resource” is created automatically as part of creating an API Gateway REST API. In Terraform, the id of that root resource is exposed as the root_resource_id attribute of the REST API resource instance.

Because that resource is implicitly created as part of the API, we don’t need a separate resource for it. Instead, we can just attach methods (and the other necessary downstream objects) directly to that existing root resource:

ルートリソースはAPI Gateway REST APIの作成の一部として自動的に作成されます。 TerraformではそのルートリソースのIDはREST APIリソースインスタンスのroot_resource_id属性として公開されます。 そのリソースはAPIの一部として暗黙的に作成されるため、個別のリソースは必要ありません。 代わりに、メソッド(およびその他の必要なダウンストリームオブジェクト)を既存のルートリソースに直接アタッチできます。

  • api_gateway.tf

aws_api_gateway_resource は指定する必要なく、既存の aws_api_gateway_method から aws_api_gateway_rest_apiresource_id に指定すればOKとのことでした。そりゃ論理的に考えるとそうだわと言う感じですな。


まとめ

盲点過ぎる!!しかし、ちゃんと考えればできていたような気がする…
ドキュメントの例外として書いてもらえるとありがたき!

Pocket

カテゴリー: AWSTerraform

adachin

1989年生まれのSRE。ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、オブザーバビリティ、緊急対応、AWS/Azureでのインフラ構築、Docker開発環境の提供、Kubernetes保守、インフラコード化、新技術の検証、リファクタリング、セキュリティ強化などを担当している。個人事業主では数社サーバー保守とベンチャー企業のSREインフラコンサルティングやMENTAで未経験者にインフラのコーチング/コミュニティの運用を実施している。また、「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。

0件のコメント

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください