provider/fastly: V1 of the Fastly Provider

[catsby]

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 and Backends are supported, with things like Healthchecks, Directors, and custom VCL 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:

/service/<service_id>/version/<version_number>/domain

Once a Service is created, that version of the service becomes locked and immutable. POST or PUT 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:

• Fastly service_v1 implementation
• Fastly service_v1 tests
• Vendor sethvargo/go-fastly

For reference, here's a link to relevant Fastly docs:

• https://docs.fastly.com/guides/about-fastly-services/
• https://docs.fastly.com/api/

[phinze]

Ye olde Cloud Sleep. ☁️ 💤 😄

We can probably ping Fastly Support to ask about if there's a better heuristic for us to use here. In the meantime, might be good to debug log that we're going to sleep. 👍

[phinze]

Alrighty! Made a pass, but this is looking really nice so far!

[phinze]

Alright with the changes this looks solid 🐍

Nice work on this - LGTM for merge! 👏

[ghost]

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.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.