This post will go over how incorporating your Next-Gen WAF Edge deployment can work with your existing Fastly VCL service.
We are going to have a very basic VCL service with http-me.glitch.me as our origin.
That’s it. It does not take much Terraform configuration to get up and running with VCL
Let’s talk about Terraform state. I am going to quote the fantastic documentation from the folks over at Hashicorp. State | Terraform | HashiCorp Developer
Terraform must store state about your managed infrastructure and configuration. This state is used by Terraform to map real world resources to your configuration, keep track of metadata, and to improve performance for large infrastructures.
This state is critical to determine which resources need to be added, changed, deleted, or left alone. The state file can exist locally or can be utilized in a cloud provider such as Terraform cloud. If Terraform is the thing that is maintaining the absolute true state of then the Terraform state file should always consistently match the remote state. However, if something other than Terraform is modifying the remote configuration, then there will be drift in the local and remote state. The most straightforward example of this is with Fastly Dictionaries, reapplying-original-items-with-managed_items-if-the-state-of-the-items-drifts. Most of our customers would expect the values of the dictionaries to be dynamic and configurable either by 3rd party API calls or via configuration in the UI, which is why the default behavior is for Terraform to not manage the values in dictionaries after the initial creation of a dictionary.
For other resources like dynamic snippets, if those values change within Terraform, then customers typically expect Terraform to change those values when applying a configuration change. However, the behavior with dynamic snippets may be modified based on our docs, reapplying-original-snippets-with-manage_snippets-if-the-state-of-the-snippets-drifts. Here is a quote from our docs.
By default, the user is opted out from reapplying the original changes if the snippets are managed externally. The following example demonstrates how the manage_snippets field can be used to reapply the changes defined in the HCL if the state of the snippets drifts. When the value is explicitly set to ‘true’, Terraform will keep the original changes and discard any other changes made under this resource outside of Terraform.
This distinction is important since the NGWAF edge deployment (as of the time of this writing) uses dynamic snippets and dictionaries for the integration into customers’ services.
We have a version one configuration. We are going to stage the dictionary and dynamic snippets as a placeholder configuration for the edge deployment API requests (Edge deployment) that will be handled via the NGWAF Terraform provider. Here is that configuration.
The dynamic snippets are simply commented VCL and act as a placeholder for the modifications that will occur via the NGWAF edge deployment. It is worth noting that both the dictionary and dynamic snippets are versionless. This means when modifications are made (even in subsequent service versions), those modifications will persist.
We can now run the following terraform configuration.
After running this version the dynamic snippets and edge dictionary are updated via the NGWAF Terraform provider. And here is where understanding Terraform state matters. Because the SigSci Terraform provider is making modifications to the VCL service instead of those modifications coming from the Fastly Terraform provider, the local Terraform state is unaware of those values for the dynamic snippets. However, by setting the manage_snippets field to “false”, we are telling Terraform to ignore any modifications to those specific snippets.