Integrating functions with cloud databases
1. Integrating functions with cloud databases
In this module, we discuss how you can integrate your functions with cloud databases. You learn how to securely connect your functions to read and write data from and to Firestore and Memorystore databases in Google Cloud. In this module, we first discuss how to connect Cloud Run functions to Memorystore, Google Cloud’s cache service, and discuss how you can use environment variables with Cloud Run functions. We’ll then discuss how you can connect Cloud Run functions to Firestore, and how you can use secrets with Cloud Run functions. You’ll then complete a lab on integrating Cloud Run functions with Firestore. Finally, we review what was discussed in this module. Let’s begin. You can integrate Cloud Run functions with: Firestore, Cloud SQL, Spanner, Bigtable, BigQuery, and with Memorystore, Google Cloud’s in-memory cache service. In this module, we discuss how you can connect your Cloud Run functions to Memorystore and Firestore. For information about connecting to other Cloud databases, refer to the documentation. Memorystore is a Google Cloud service that provides a highly available, scalable, and secure in-memory cache solution for Redis and Memcached. It’s a fully managed service that automates provisioning, replication, failover, and patching. It’s also integrated with IAM for secure access, and with Cloud Monitoring for service monitoring and alerting. For a complete list of features, see the Memorystore documentation. Redis is an open source in-memory data structure store used as a database, cache, message broker, and streaming engine. Memcached is an open source distributed memory object caching system. You can connect to a Redis instance from Cloud Run functions by using Serverless VPC Access. Once you’ve determined your Redis instance’s authorized VPC network, you create a Serverless VPC Access connector in the same region as your function. Then, attach the connector to the Redis instance’s authorized VPC network. Specify the network, region, and IP address range when the VPC connector is created. Ensure that the connector is in a Ready state before using it. Deploy the function specifying the path and name of the connector, and environment variables for the Redis host IP address and port. Your function code can then use these environment variables to instantiate a client that connects to the Redis service. To invoke the function, send an HTTP GET request to the functions URL endpoint. The source code for this function can be found on GitHub. Cloud Run functions supports the use of environment variables. Environment variables are key-value pairs that can be set for Cloud Run functions at deployment time. The variables are accessed by your function code at runtime, or as configuration information for the buildpack system. They are stored in the Cloud Run functions backend, are bound to a single function, and exist within the same function lifecycle. You can provide the environment variable key-value pairs when you deploy your function with the gcloud CLI or in the Google Cloud console. You can store them in a YAML file in source control and provide the name of the file during function deployment. For more information on using environment variables with Cloud Run functions, see the documentation. To access runtime environment variables in your function written in Python, use the os module. To access environment variables in other language runtimes, view the samples in the documentation on the Cloud Run functions website. Let’s now discuss how you can connect Cloud Run functions to Firestore. Firestore is a Google Cloud service that provides a fully managed serverless NoSQL document database. It provides high availability, scalability with no maintenance windows or downtime required, and multi-region replication. You store a set of key-value pairs known as a document in Firestore and all documents are stored in collections. For a complete list of features, see the Firestore documentation. You can extend Firestore’s capabilities with Cloud Run functions by handling events that are triggered by changes in your Firestore database. By implementing function code to handle these events, you can easily add server-side functionality to your application without running your own servers. You can implement your function code to handle Firestore events that occur when a document is created, updated, deleted, or when any of these events occur. These events are exposed by the Cloud Run functions for Firebase SDK that you use in your function source code. Firestore triggers for Cloud Run functions are available only for Firestore in Native mode. It is not available for Firestore in Datastore mode. Functions that are triggered on Firestore events must specify a document path, and an event type. The document path can reference a specific document or a wildcard pattern, and must not contain a trailing slash. When a function is triggered, a snapshot of the data related to the event is available to the function. You can use this snapshot to read from or write to the document that triggered the event. The document snapshot data before and after the update is available to the function. Each function invocation is associated with a specific document in your Firestore database. You can access that document as a DocumentReference in the ref property of the snapshot returned to your function. This DocumentReference comes from the Firestore Node.js SDK and includes methods that enable you to modify the document that triggered the function. You can also read and write data of documents other than the one that triggered the function using the Firebase Admin SDK. Cloud Run functions supports the use of secrets. Let’s review how you can use secrets with Cloud Run functions. When your function code needs to access certain databases or APIs, it will need to provide credentials like a database username/password or API key. This kind of sensitive information should be securely stored and accessed by the function when it executes. You can use secrets and Google Cloud’s Secret Manager to store this information. A secret is an object that contains a collection of metadata like replication locations, labels, permissions, and other information; and the secret versions. A secret version stores the actual secret data such as an API key or password as a text string or binary blob. To create and manage secrets, you must enable the Secret Manager API. To access a secret, your function must first be granted access to the secret. This is achieved by granting the appropriate role (roles/secretmanager.secretAccessor) to the function’s runtime service account on the secret. To make the secret available to your function, you can: Mount the secret as a volume so that the function can access it from a file. Mounting the secret as a volume allows your function to reference the latest version of the secret each time the file is read. You can also pass the secret to the function as an environment variable. Because environment variables are resolved at function instance startup time, with this method, your function would have access to a specific version of the secret. To provide your function access to a secret that is in a different project than your function: Grant your function’s runtime service account access to the secret as previously described. Make the secret available to the function by specifying the secret’s resource path that includes the project ID and secret name. A sample use case of using a secret is when your function must access an external service or API, that requires an API key to identify the calling application. The key is considered a sensitive piece of information so it is stored as a secret using Secrets Manager. Write your function code to access the secret by reading the contents of a file or environment variable. The file path is provided when the function is deployed. When deploying the function, provide the secret name and the method to access the secret. The method can be a mounted file path or environment variable. To access the secret, the function’s runtime service account must be granted the Secret Manager Secret Accessor role on the secret. Call the API from the function with the secret value which is the API key.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.