Terraform from HashiCorp is a development environment for programmatically provisioning the infrastructure and resources that relate to a particular service or application. Terraform is often referred to as "infrastructure as code," because it uses scripts to provision resources such as compute resources, RBAC controls, and application-specific resources using the provided APIs of those products. Terraform commands can then create, operate, and tear down that scripted infrastructure, easing the process to create, maintain, and rebuild when needed the same infrastructure using manual steps in user interfaces or APIs to perform those tasks.

A Terraform provider is a plugin usually provided by application vendors or other groups that can be installed within Terraform to define interactions to services. The ChaosSearch provider calls the ChaosSearch APIs to perform the tasks defined as resources within the Terraform workspace.

A resource is a defined entity that can be managed by a Terraform provider. The ChaosSearch Terraform provider includes support for managing the indexing, object groups, views, subaccounts, user groups, and alerts.

Resources are defined with a "create-or-replace" behavior; that is, the resource is created in the target ChaosSearch cluster if it does not already exist. If there is a matching resource of the same name already in the configuration, its definition is updated with the Terraform resource settings. In some cases an update might be blocked by a setting, or in cases where only a subset of settings might be modifiable after an object is created. When you run the terraform destroy operation, any resources that were created or updated in the terraform configuration *.tf file are removed from the ChaosSearch cluster configuration.

🚧

Only indexed data can be exempted from the delete operation.

All other resources—such as views, object groups, subaccounts, and RBAC groups that you might have added or modified—will be removed. An object group will be blocked from removal if the index data for that object group is retained. For example, if you used the Terraform configuration to change an existing view from case-insensitive to case-sensitive, that view will be deleted during the terraform destroy operation. As a best practice, the Terraform scripts should not update resources that were created by other means, such as the user interface.

The ChaosSearch provider does not include resources for the setup and configuration of the ChaosSearch computing and storage infrastructure. There are other official providers for services such as AWS that can manage the configuration of S3 storage, EC2 compute, and policy controls. Customers who wish to use Terraform to control and manage their cloud-compute resources or other aspects like SSO providers should work with those vendors and their Terraform providers.

Develop Terraform Workspace Guidelines

If you are an experienced Terraform user, you can skip this section. If you are new to using Terraform, or you are testing the provider as an alternative way to manage ChaosSearch resources versus the user interface or REST endpoints, be sure to carefully plan how you will use the Terraform provider and workspaces to manage your resources.

For example, if you have a test environment, you might be the only user and you can run the Terraform workspace to manage those ChaosSearch resources. One workspace-one environment is the general rule to follow to avoid accidental interactions and collisions in any environment. You can configure, manage, and destroy the resources when you no longer need them, usually with no impact to other users.

If multiple users share a dev cluster, they could set up their own Terraform configuration/workspace and manage resources that they will use. However, they should establish some "boundaries" for their resources that they manage. Without some careful rules about which resources are managed by each user, it is possible for them to "clobber" each other's work as they add, change, and then destroy their Terraform configuration. Some clear practices, like using well-defined prefixes for resources that belong to each user, can help to avoid accidental collisions.

In a production environment, the boundary rules and guidelines must be very clear and are usually enforced by tools such as source control. Organizations typically define ownership for specific, discrete tasks. Users create Terraform configurations and workspaces in source controlled locations so that there is one true and current copy of the target cluster. Users who need to manage the environment can be granted access to make changes to the files that are tracked and preserved. There should be only one set of Terraform configuration files (and one workspace) to manage one ChaosSearch cluster to avoid collisions or unintended configuration changes. There could be several discrete areas or responsibilities for the ChaosSearch configuration, but each area should not have active Terraform workspaces with overlapping resource management.

If you plan to use Terraform to manage ChaosSearch production resources, make sure that you have defined roles and responsibilities and source control practices to ensure that there is only one workspace and state for the set of resources that it manages.