All Projects → Yelp → terraform-provider-cloudhealth

Yelp / terraform-provider-cloudhealth

Licence: Apache-2.0 license
Terraform provider for Cloudhealth

Programming Languages

go
31211 projects - #10 most used programming language
python
139335 projects - #7 most used programming language
Makefile
30231 projects
shell
77523 projects
Dockerfile
14818 projects

Projects that are alternatives of or similar to terraform-provider-cloudhealth

terraform-provider-logicmonitor
Terraform LogicMonitor provider.
Stars: ✭ 19 (+35.71%)
Mutual labels:  terraform-provider
terraform-provider-azurerm
Terraform provider for Azure Resource Manager
Stars: ✭ 3,829 (+27250%)
Mutual labels:  terraform-provider
terraform-provider-mcbroken
Base the count of your infrastucture resources on the current number of broken mcdonald's ice cream machines nationally or by a city of your choosing. Powered by https://mcbroken.com/
Stars: ✭ 29 (+107.14%)
Mutual labels:  terraform-provider
terraform-provider-commercetools
Terraform provider for commercetools
Stars: ✭ 58 (+314.29%)
Mutual labels:  terraform-provider
terraform-provider-argocd
Terraform provider for ArgoCD
Stars: ✭ 245 (+1650%)
Mutual labels:  terraform-provider
terraform-provider-fusionauth
registry.terraform.io/providers/gpsinsight/fusionauth/latest
Stars: ✭ 23 (+64.29%)
Mutual labels:  terraform-provider
terraform-provider-hcp
Terraform provider for HashiCorp Cloud Platform.
Stars: ✭ 36 (+157.14%)
Mutual labels:  terraform-provider
terraform-provider-civo
Terraform Civo provider
Stars: ✭ 54 (+285.71%)
Mutual labels:  terraform-provider
terraform-provider-cisco-aci
Terraform provider for automating Cisco ACI enabled networks
Stars: ✭ 14 (+0%)
Mutual labels:  terraform-provider
terraform-provider-sysdig
Sysdig Terraform provider. Allow to handle Sysdig Secure policies as code.
Stars: ✭ 41 (+192.86%)
Mutual labels:  terraform-provider
terraform-provider-rancher
Terraform Rancher provider
Stars: ✭ 35 (+150%)
Mutual labels:  terraform-provider
terraform-provider-circleci
Terraform provider for CircleCI
Stars: ✭ 94 (+571.43%)
Mutual labels:  terraform-provider
terraform-provider-redfish
Terraform provider for Redfish REST APIs
Stars: ✭ 54 (+285.71%)
Mutual labels:  terraform-provider
terraform-provider-twitter
No description or website provided.
Stars: ✭ 24 (+71.43%)
Mutual labels:  terraform-provider
terraform-provider-env0
Terraform Provider for env0
Stars: ✭ 28 (+100%)
Mutual labels:  terraform-provider
terraform-provider-oneview
Automates the provisioning of physical infrastructure from a private cloud using templates from HPE OneView with Terraform
Stars: ✭ 46 (+228.57%)
Mutual labels:  terraform-provider
terraform-provider-artifactory
Terraform provider for managing Artifactory
Stars: ✭ 17 (+21.43%)
Mutual labels:  terraform-provider
terraform-provider-graylog
Terraform Provider for Graylog
Stars: ✭ 21 (+50%)
Mutual labels:  terraform-provider
terraform-provider-vra
Terraform VMware vRealize Automation provider
Stars: ✭ 82 (+485.71%)
Mutual labels:  terraform-provider
terraform-provider-upcloud
Terraform provider for UpCloud
Stars: ✭ 52 (+271.43%)
Mutual labels:  terraform-provider

Terraform provider plugin for Cloudhealth

Supports Cloudhealth perspectives as a Terraform resource

Install

$ go get github.com/Yelp/terraform-provider-cloudhealth
$ make

Then update ~/.terraformrc:

providers {
  cloudhealth = "/path/to/terraform-provider-cloudhealth/terraform-provider-cloudhealth"
}

Provider Configuration

The plugin requires a Cloudhealth API key. There are two ways you can set it:

Via the environment:

export CHT_API_KEY=<api_key>

Or via provider.tf:

provider "cloudhealth" {
    key = "<api_key>"
}

Simple Perspective Example

The below example defines two groups. The first is called "My Team" who matches against any AwsAsset with tag team=my_team or [email protected]. The second is a dynamic group that categorizes based on Redshift cluster name.

resource "cloudhealth_perspective" "my_perspective" {
    name = "My Perspective"
    include_in_reports = false

    group {
        name = "My Team"
        type = "filter"

        rule {
            asset = "AwsAsset"
            condition {
                tag_field = ["team"]
                val = "my_team"
            }
        }

        rule {
            asset = "AwsAsset"
            condition {
                tag_field = ["team"]
                val = "[email protected]"
            }
        }
    }

    group {
        name = "redshift"
        type = "categorize"

        rule {
            asset = "AwsRedshiftCluster"
            field = ["Cluster Identifier"]
        }
    }

Rules and Groups

Rules have the following structure.

rule {
    asset = <asset>
    [field = ["field1", "field2" ...]]
    [tag_field = ["tagfield1", "tagfield2" ...]

    combine_with = <[OR]|AND>
    condition {
        [field = ["field1", "field2" ...]]
        [tag_field = ["tagfield1", "tagfield2" ...]
        op = <[=]|!=|Contains|Does Not Contain,...]
        val = <val>
    }
}

There are only two permissible values for group type. Static groups have type=filter. This is the default. Dynamic groups have type=categorize. In this case you must also define field or tag_field on the rule.

Important note about rule ordering

There is one main difference between the schema used in Terraform and the actual Cloudhealth Perspective API.

The official API organizes a perspective by the ordering of rules, not the order of groups. It is permissible to interleave the rules for different groups. For example, the first rule send assets to group 1, the second rule to send assets to group 2, then the third rule sends assets to group 1 again. This is quite confusing and not reflected in the Perspective UI.

By comparison, the schema in Terraform groups all rules for a single group together. All rules are ordered by the order of appearance of their groups in the list.

If doing a terraform import of an existing perspective you may encounter ordering differences in how your rules are processed. While this may require you to make some fixes, it is my opinion that this is much more more maintainable. It also will match the UI's presentation of the perspective configuration.

Not supported

Merges are not supported. Nor are dynamic groups that include additional "filter" rules. You may get errors if you attemp to import a perspective that has either of these things.

Tests

To run the tests, use

go test

To run acceptance tests, you must follow the instructions in provider configuration to set the CHT_API_KEY env variable. You must then run

TF_ACC=1 go test -v

Its probably also useful to enable logging by setting the TF_LOG env variable

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].