Terraform Provider
With the CloudCasa Terraform Provider, you can use Terraform to configure cluster, backup job, policy, and storage resources in CloudCasa. You can also automatically deploy the CloudCasa agent to Kubernetes clusters. The provider interacts with the CloudCasa service using CloudCasa’s published REST APIs.
Getting Started
The CloudCasa Terraform Provider can be obtained from HashiCorp’s Terraform Registry.
Typically, the provider might be used to automatically add a new Kubernetes cluster to CloudCasa and configure backups for it as part of the cluster provisioning process. But there are other use cases for it as well. Below is an example of how to initialize the provider and use it to install the CloudCasa agent and take a snapshot backup.
See also
Full documentation for the Terraform Provider is available on the Terraform Registry page.
Note that you will need to obtain a CloudCasa API key in order to make use of the provider. Log in to CloudCasa and go to Configuration/API Keys to create a key.
See also
The provider is opensource software, licensed under the Apache 2.0 license. It is maintained and supported by Catalogic Software, but involvement from the user community is encouraged! The GitHub repository for the provider is: https://github.com/catalogicsoftware/terraform-provider-cloudcasa.
Initializing the Provider
In your Terraform manifest, create and configure the provider:
Creating CloudCasa Resources
Kubecluster
A cloudcasa_kubecluster resource represents a Kubernetes cluster. You can import an existing CloudCasa cluster using terraform import or define a new cluster.
To automatically install the CloudCasa agent on a cluster set auto_install to true. The provider will apply the agent spec using the environment variable KUBECONFIG to find the cluster context.
Objectstore
The cloudcasa_objectstore resource defines storage locations for CloudCasa backups. CloudCasa supports both AWS S3 and Azure Blob Storage as backend storage providers.
An objectstore can be associated with a kubecluster for all backups, or with specific kubebackup resources for copy backups.
Kubebackup
The cloudcasa_kubebackup resource refers to both snapshots and copy backups. Cluster ID of a valid CloudCasa kubecluster is required.
If run_on_apply is True, the backup will be considered Adhoc and does not require a policy ID. With this setting the backup will run any time we run terraform apply, even if the backup has already been created. Terraform will wait up to 5 minutes for the job to complete.
For example, here is a simple ad hoc snapshot job:
Policy
Policies are required for backups that do not have run_on_apply set. They are created by defining a Cron schedule for the job:
Importing Resources
You can import existing CloudCasa resources to manage them in Terraform using terraform import. For example, assume we have created a policy named “test_manual_policy” in CloudCasa UI. First create an empty resource for this policy:
Get the ID from the CloudCasa UI (or casa) and use terraform import <resource_state_path> <CC ID>:
After importing, Terraform will try to apply any local changes to the CloudCasa resource the next time you apply. Check the resource in Terraform using terraform state show <resource_state_path> and update the configuration values to match, and make any desired changes. Changes in Terraform will always supercede changes in CloudCasa!
For Terraform v1.4+, you can add an import block directly to the Terraform config to avoid using terraform import manually each time: