provider/fastly: V1 of the Fastly Provider #5814
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a Terraform Provider for the Fastly CDN service. The implementation is based on the discovery/planning work by @apparentlymart in #3716 .
The goal here is to create a new Terraform provider for Fastly CDN service, enabling users to manage Fastly services alongside other parts of their configurable infrastructure. Given an origin server that serves content, and a configured DNS entry that points to the Fastly service, users should be able to create a Fastly resource that provides CDN services for the origin server via the domain name.
This is a minimal implementation for now, but provides a resource we can iterate on. Only
Domains
andBackends
are supported, with things likeHealthchecks
,Directors
, and customVCL
configuration that can come later.Background (explained in #3716 as well):
To design this provider, we have to make compromises to align how Fastly operates it’s services, and how Terraform traditionally models resources. Terraform manages resources via a dependency graph among them, allowing you to compose your infrastructure by ensuring dependent resources exist in order to build on to them. For example, at the top level AWS has a VPC resource, which can be considered the root, with several “child” resources objects referencing it’s ID, and a graph is built. Each of these resources can be managed individually, without going through the VPC (it’s ID is referenced, but the endpoint is not tied to it), thus each resource has it’s own CRUD operations.
Fastly models it’s offering at the top level with a “Service” resource. These services have an internally managed version, and each update increments this version. Child resources (Domains, Backends) are referenced through this service and it’s version, meaning the API endpoint to modify them is in this format:
Once a Service is created, that version of the service becomes locked and immutable.
POST
orPUT
calls to any locked version are rejected. You cannot unlock versions. To change a child resource is to duplicate the current version (which increments the version), and post changes to it. The entire topology is copied into the newer version. After a validation step, you can then “activate” the new version. As a result, we essentially only get CRUD for the top level object.As a result, this Fastly Service resource encompases all supported aspects of the Service. Domains, Backends, and other components are nested types in the schema. While this isn't ideal, it's a starting place for the provider that we can expand on, and in the future ideally we can add some core features that may allow us to branch out and have additional, separate resources, while still staying within Fastly's model.
Includes:
For reference, here's a link to relevant Fastly docs: