[MUSIC PLAYING]
LINGKAI SHEN: Hi, I'm Lingkai.
I'm a Software Engineer at Firebase.
Today, I'm going to share how you
can manage multiple Firebase projects with confidence
using Terraform.
Let's meet Sally.
Sally is a software engineer working on a fast-growing app.
So far, Sally has been building apps in a single Firebase
project that she also uses for testing.
She enjoys the convenience she gets
from testing the real environment
but is worried about accidentally
breaking prod, or production.
For her next app though, Sally wants
to adopt best practices by setting up a staging
environment to preview changes before they go into prod.
This new app is going to be available on Android devices,
Apple devices, and the web.
The app will use authentication for user management
and Firestore to store data.
Sally is quite familiar with the Firebase Console.
She opens up the Firebase Console in two separate windows
side by side so that she can work through setting up
two identical Firebase projects, one for staging,
and one for prod.
After the two projects are created,
she adds an Android app to each project, and then
the Apple App to each project, and then an web
app to each project.
Next, she sets up authentication to each project
and enables the identity providers.
Finally, she sets up the Firestore databases
for each project, including their security rules.
Phew.
Although Sally is quite proud of her fluency in the Firebase
Console, she can't help but wonder,
is there a better way to do this?
Introducing Firebase integration with Terraform.
Terraform is an open source tool from HashiCorp for managing
infrastructure as code.
This means Sally can describe her prod project in code
and reuse the code as often as she'd like to set up
similarly structured projects.
Let's see how Sally's prod project
might look like in a Terraform configuration.
The Terraform block contains Terraform settings, including
the required providers Terraform will
use to provision the infrastructure.
In this case, most of the Firebase resources
are supported in a Google beta provider.
The google-beta provider has an attribute
named user_project_override to determine
how the operations from Terraform
will be quota checked.
For provisioning most resources, Sally
should use user_project_override equals true,
which means to check quota against her own Firebase
project.
However, to set up her new project
so that it can accept quota checks,
Sally will first need to use user_project_override
equals false.
The Terraform "alias" syntax allows
Sally to distinguish between the two provider setups.
Sally needs to create a Firebase project.
Recall that each Firebase project is actually
a Google Cloud project, just with Firebase services enabled
for it.
So Sally creates a Google Cloud project
first using the provider with no_user_project_override.
Since Sally will be using Firebase authentication
with identity platform, the billing account
is needed on the Google Cloud project.
Next, Sally enables the Service Usage API and the Firebase
Management API.
This API development is usually handled behind the scenes
when you use the Firebase Console,
but Terraform needs to be explicitly told
to do this enablement.
By enabling the Service Usage API,
her new project can accept quota checks.
So, for all future resource provisioning,
she should use the provider with user project override.
And the very last thing Sally needs to do
is to create a Firebase project is to enable the Firebase
services on the project.
And note how she's using the provider with user project
override, no alias needed.
You might notice the depends_on class here,
which tells Terraform to wait for the APIs to be enabled.
Otherwise, Terraform doesn't know about the dependency
and may run into errors when providing resources
in parallel.
What Sally has so far represents an empty Firebase project.
Next, let's look at how Sally can
add Firebase resources such as the platform variant server
app and the Firebase products that she plans to use,
authentication and Firestore.
Sally's project resources can be described as a collection
of resource blocks.
Terraform creates those resources
if they don't exist and updates them
if the configuration changes.
Let's look at each one.
To add each platform variant of her app,
Sally makes three resource blocks for Android, Apple,
and web.
Later, after she's done with Terraform,
she still needs to set up her app's code base
to connect to and use Firebase.
Let's now look at how Sally can add authentication
and Firestore to her project.
Some Firebase products require underlying APIs to be enabled.
In Sally's case, this includes some common APIs, as well as
Firestore and Firebase rules and identity toolkit
used by authentication.
You might be wondering, where do you find which APIs
you need for Firebase products?
Great question.
It isn't always easy to tell.
Cloud Firestore uses the Firestore API,
but the case with authentication and identity toolkit
may be less obvious.
But don't worry.
If Terraform tries to operate on a resource
with APIs not enabled, Terraform will show an error message
containing the name of the API.
Once Sally figures out which APIs to enable,
Sally continues to provision the Firestore database.
Sally then configures her Firestore security rules
as her ruleset, which represents a version of security rules,
and releases the ruleset to apply those rules to the Cloud
Firestore database.
To set up authentication, Sally first
configures general settings such as auto-deletion
of anonymous users.
So you can then configure sign in methods
such as anonymous signing, email password, and phone
authentication.
Federated identity providers are also supported.
More information is available from the links
in the description below.
[MUSIC PLAYING]
Now that Sally has a Terraform configuration file,
she can use the Terraform CLI to provision everything
that she's defined in the configuration file.
You can use Terraform before, the next bit will be familiar.
There are three commonly used Terraform commands-- terraform
init, terraform plan, and terraform apply.
terraform init will download and initialize
the providers specified in the Terraform
block of the configuration.
terraform plan will compare the Terraform configuration
with real infrastructure and provide
a preview of the operations without performing them.
terraform apply will perform those operations
to create the resources.
terraform apply actually includes the Terraform plan,
where it prompts you to approve that plan
and takes the planned actions.
Since this will be the first time Sally uses Terraform
in the directory, she runs terraform init first,
which will install the google-beta provider.
And then, she runs terraform apply,
which gives a preview for Sally to approve.
Once Sally approves, Terraform will start running.
Behind the scenes, Terraform is performing similar operations
that Sally would have done in the Firebase Console herself.
Once terraform apply is complete,
Sally can check out the new project in the Firebase
Console, where she will find the platform apps,
a Firestore database with published security rules,
and authentication setup with her selected identity
providers.
Or, without leaving the terminal,
Sally can also find the same information using the terraform
show command, such as finding the app ID of the Android app
that was just created.
Now that Sally has the prod project,
how can she use Terraform to create the staging project?
Recall that Sally has a collection of resource
blocks for the prod project.
She can just make a copy of the blocks
and tweak them for staging.
Copying a Terraform configuration
may not be for everyone.
What if you like to make your staging project infrastructure
aligned with your prod project?
Can you just reuse your configuration without copying?
Yes, there are features in the Terraform language,
similar to for loops, that allow this level of reuse
without making a copy.
This way, your staging project can stay in sync
with the prod project.
On the other hand, though, making
a copy of the configuration gives you the flexibility
to make the staging project slightly
different from the prod project.
For Sally's staging project, the project
should have staging in the display name
and probably in the project ID.
The platform apps should have a more applicable display name
too.
Regardless, since Terraform configuration
is checked into source control, just like code,
changes to infrastructure will not
go unnoticed, because they are reviewed and tracked.
Sally has control on how much the staging project can
drift from the prod project.
[MUSIC PLAYING]
To make changes to infrastructure,
Sally can just modify the Terraform configuration file.
For example, a few weeks later, Sally
has improved the security rules to Firestore
and would like to test them out in staging first.
She updates only the staging Terraform configuration
to use the new rules and runs terraform apply.
After sufficient testing, she updates the prod Terraform
configuration to use the new rules and run
terraform apply too.
That's it.
Sally is quite amazed at how she can create and maintain
two similar Firebase projects for prod and staging
with confidence.
She can't wait to explore more about how Terraform can help
her manage Firebase projects.
Welcome to Terraform land, Sally.
There are many more ways Terraform can help
manage your Firebase resources.
For example, you can set up daily environments
or even spin up disposable Firebase projects
for each meaningful code change.
To see a list of currently available Firebase resources
with Terraform support, visit the Firebase Terraform
documentation from the link in the description below.
If you have any questions or feature requests,
raise an issue in a GitHub repository
for Google's Terraform provider, also linked below.
Thank you, and enjoy the rest of I/O.
[MUSIC PLAYING]