API Gateway | New config change forces replacement of the Gateway #8532
Comments
ghost
added
the
|
|
|
reopening this topic after reversion. In practice adapting this required too many prerequisites to change the underlying api_config. Namely the |
|
@ScottSuarez is the suggestion not to use Terraform at all for managing the APIGW then? At least for the time being until a zero-downtime update model can be figured out. |
|
@ScottSuarez -- is there any way to do an update to a config in-place right now, or a plan to add in this feature later? |
|
This is possibly outside of the hands of the Terraform team. As mentioned, the API config is immutable and it creates a problem for how Terraform manages state. An API specification can't be updated in-place, a new one must be created, but terraform will opt for a create/destroy cycle, taking the associated gateway with it. I was planning to explore the option of adding API config resources using terraform and issuing a gcloud command using the terraform gcloud provider module. Haven't had time to fully explore this but it might be a viable solution. Either way, configuring the api_config resource to use a for_each block so that you can incrementally create new specs without going through a create/destroy cycle is probably a prerequisite for all of the other approaches. We have something like this. The local spec names are constructed using a fileset command. resource "google_api_gateway_api_config" "external" {
for_each = local.spec_names
provider = google-beta
api = google_api_gateway_api.external.api_id
api_config_id = each.value
openapi_documents {
document {
path = "specs/${each.value}.yaml"
contents = base64encode(templatefile("${path.module}/specs/${each.value}.yaml",
{
services = var.services
environment = var.workspaceName
security_definitions = local.env.security_definitions
}))
}
}
gateway_config {
backend_config {
google_service_account = var.apigw_svc_account.id
}
}
lifecycle {
create_before_destroy = true
}
}Another approach could be to suffix the api config name with the current timestamp/date and treat it as a new resource, but still trying to come up with a way to maintain that state throughout applies. I'll post ideas as we find approaches. The one we have working today is by continuously maintaining two gateways and doing a blue/green deployment at the load balancer level. The fact that this many hoops need to be jumped through to achieve something this straightforward is truly maddening though. We've spent an unreasonable amount of time trying to shape this into a usable service. Google really dropped the ball here in a surprisingly obvious way. |
|
Since this topic continues to generate significant interest I'll take another stab at considering working with this. Ultimately you would need to set a lifecycle rule for creation before destroy on the new |
|
@kostacasa @ScottSuarez -- thank you so much for your comments and help! |
|
FYI, you can use There are a few other immutable resources that have the prefix field but the underlying Google APIs work properly in the sense that the returned operation for the creation is done once it is ready to be used(eg, certificates, instance templates) and you can safely delete the old one. API Gateway transition should be seamless like it is for GCE APIs. |
|
Unfortunately, even using prefixes, a gateway destroy/create cycle is performed when the config is updated. This will cause downtime while the gateway is being re-created. |
|
Changing the gateway lifecycle to create before destroy results in: |
|
I've checked in a potential change. Going to monitor our test pipeline. If everything is green and pending no revert you should see this change in 3.69.0 |
|
Thank you @ScottSuarez ! What will the new behavior be? |
|
You will be able to update |
|
Hey @ScottSuarez just tried this out and it worked perfectly! |
|
nice ! happy to see it's working well for you :) |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
github-actions
bot
added
service/apigateway
forward/review
Community Note
modular-magicianuser, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned tohashibot, a community member has claimed the issue already.Terraform Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
Panic Output
Expected Behavior
Run an update in place.
Actual Behavior
Forces replacement of the Gateway to new one.
Steps to Reproduce
terraform planterraform applyImportant Factoids
References
The text was updated successfully, but these errors were encountered: