Like the title suggests, this is a request for a Terraform provider.
Motivation
Terraform provides a unified way to write declarative configuration files, collaborate and share configurations, evolve and version you infrastructure, automate provisioning, and define infrastructure as code to manage the full life-cycle – create new resources, manage existing ones, and destroy those no longer needed.
Use case
Terraform is cloud-agnostic and allows a single configuration to be used to manage multiple providers, and even handle cross-cloud/cross-provider dependencies. This simplifies management and orchestration, helping operators to build complex multi-cloud/multi-provider infrastructures.
An example of this could be
storing FaunaDB credentials some sort of vault supported by terraform-provider-a
fetching those credentials to bootstrap terraform-provider-fauna
set up a FaunaDB database
configure an Auth0 access provider for the above database
set up an api, with terraform-provider-auth0, using relevant output from step 4.
Which features would you want to see from a provider plugin to start using it? I imagine there’s a line where you’d use the Terraform for infra setup and then switch to FQL or GraphQL for data, but where?
Hello! Just popping in to +1 this. I really want to have a list of resources as I do with fauna-schema-migrate, but instead of a bunch of migrations, just one terraform script that makes the cloud functions/indexes/collections/roles match my resources. I don’t have a whole lot of need for data migration.
@rob In my opinion it would be useful to be able to do things like provision databases, nested databases, and roles. Essentially the things you might expect to be more static and not dynamically controlled by the application itself would be good first candidates. I don’t know if Indexes fall into this category but those might be included as well.
That’s in line with our current thinking. I expect nested databases might not make the first version because each nested database would need its own Terraform provider.
On the plus side, I expect we would include indexes in the first version.
Yeah I’d love something like this. At the time I have resorted to creating a repo with the Javascript driver and create scripts that create the functions/indexes/collections/roles but I need to be very careful when an update is done to pretty much delete the resource so I can run it again. But this will be awesome. Specially for having a development / Preview / Production version of the database in fauna
Thanks all for your suggestions here. We are currently designing our schema management system, which will likely include a declarative syntax, designed to integrate with Terraform (in addition to other IaC tooling). Please stay tuned.
Hi folks, Is the request for Terraform Provider really more about fulfilling a need for automated schema management? We understand users would like to manage schema as they do their code, and automate the configuration of their schema. However, Terraform is suited for management of long lasting infrastructure and database instances themselves. Database schemas are not suited to Terraform as they change as the application evolves. To my knowledge, there are no database providers which support schema directly in a Terraform config.
In the context of a service like Fauna, a provider would enable you to manage two main resource types: databases and backups. Schema, As I mentioned earlier, would be managed with our new, declarative language called FSL.
Soon you will be able to upload/download FSL files via new Schema API to manage your database configuration much the way that @Rachael_McQuater and @Oscar_Esquivel describe above. In fact, we envision users managing their FSL files in code repositories, right alongside the application code that depends on it. You can automate the deploy of a schema to a database with use of Github actions which push the schema to the API when a new version of the schema is committed to the repository.
Work in these features are currently in progress. FSL will also be supported by the Fauna Shell CLI, effectively replacing Fauna Schema Migrate.
I’m eager to get your input. So, please let me know if FSL as I’ve described it would meet your needs. Would having a Terraform Provider that manages database and backup resources, but not schema still be valuable to you?
As far as I can tell, so far FSL doesn’t support managing child databases. If the plan is to have the dichotomy where FSL is about managing the schema documents for a given database, and then Terraform is about managing the hierarchy of databases (parent and child databases), I think that would work.