Good day all,
Scenario: We have multiple teams working on the DMZ API for a project. The current terraform configuration compiles multiple OpenAPI YAML files for each team into a single file, and instantiates the aws_api_gateway_rest_api
from this single OpenAPI spec.
Issues: Deployments and ownership of deployments get messy and causes deployments to take a lot longer than they should. This also causes issues in the different environments as one team’s deployment may overwrite anothers.
Proposed solution: Declare the main DMZ API with default {+proxy}
route in the DMZ API repository. Split out the resources into separate repositories.
Problems: There is no Terraform resource that will update an existing aws_api_gateway_rest_api
by “appending” additional OpenAPI specifications. There is no separate Terraform resource that will setup the aws_api_gateway_resource
, aws_api_gateway_method
, aws_api_gateway_integration
and all the rest from an OpenAPI specification.
Requirements: Each team should be able to deploy their resources independently of another repo/deployment i.e. don’t concatenate the OpenAPI specs from different repos.
What I’ve tried:
-
Using the same terraform state and “updating” the
aws_api_gateway_rest_api
withput_rest_api_mode = "merge"
This ended up just deleting the default routes and adding the new routes.
-
Importing the
aws_api_gateway_rest_api
Id and adding the resources by looping through the OpenAPI yaml.This is very tedious and difficult as the OpenAPI yaml is extremely nested
Any suggestions on how I can achieve this? Perhaps there is a code generate that can generate Terraform resources from an OpenAPI spec?
I’ve also considered storing each team’s OpenAPI specs in git submodules but that will still reside in a single repository and be deployed with a single deployment which doesn’t fix anything.