bitfield / terraform-provider-checkly

A Terraform provider for the Checkly monitoring service

Checkly Terraform provider

This Terraform provider enables users to manage Checkly resources like checks.

You can read a detailed tutorial and explanation of the Checkly Terraform provider here:

• Managing Checkly checks with Terraform

Using the provider

1. Download the binary applicable for your platform from the latest tagged release. Then copy the binary to your Terraform plugin folder, unzip it and rename it to just terraform-provider-checkly. Lastly, set the correct access rights.

I you're on MacOS, just run the script install.sh script

curl https://raw.githubusercontent.com/bitfield/terraform-provider-checkly/master/install.sh | sh

2. Run terraform init and then terraform providers. The Checkly plugin should be listed.

terraform init

Initializing provider plugins...
Terraform has been successfully initialized!

terraform providers
.
└── provider.checkly

If you're having issues, please check the Hashicorp docs on installing third party plugins.

Authentication

To use the provider with your Checkly account, you will need an API Key for the account. Go to the Account Settings: API Keys page and click 'Create API Key'.

Now expose the API key as an environment variable in your shell:

export TF_VAR_checkly_api_key=<my_api_key>

Usage examples

Add a checkly_check resource to your resource file.

This first example is a very minimal API check.

variable "checkly_api_key" {}

provider "checkly" {
  api_key = "${var.checkly_api_key}"
}

resource "checkly_check" "example-check" {
  name                      = "Example check"
  type                      = "API"
  activated                 = true
  should_fail               = false
  frequency                 = 1
  double_check              = true
  ssl_check                 = true
  ssl_check_domain          = "api.example.com"
  use_global_alert_settings = true

  locations = [
    "us-west-1"
  ]

  request {
    url              = "https://api.example.com/"
    follow_redirects = true
    assertion {
      source     = "STATUS_CODE"
      comparison = "EQUALS"
      target     = "200"
    }
  }
}

Here's something a little more complicated, to show what you can do:

resource "checkly_check" "example-check2" {
  name                   = "Example check 2"
  type                   = "API"
  activated              = true
  should_fail            = true
  frequency              = 1
  ssl_check_domain       = "api.example.com"
  double_check           = true
  degraded_response_time = 5000
  max_response_time      = 10000

  locations = [
    "us-west-1",
    "ap-northeast-1",
    "ap-south-1",
  ]

  alert_settings {
    escalation_type = "RUN_BASED"

    run_based_escalation {
      failed_run_threshold = 1
    }

    time_based_escalation {
      minutes_failing_threshold = 5
    }

    ssl_certificates {
      enabled         = true
      alert_threshold = 30
    }

    reminders {
      amount = 1
    }
  }

  request {
    follow_redirects = true
    url              = "http://api.example.com/"

    query_parameters = {
      search = "foo"
    }

    headers = {
      X-Bogus = "bogus"
    }

    assertion {
      source     = "JSON_BODY"
      property   = "code"
      comparison = "HAS_VALUE"
      target     = "authentication.failed"
    }

    assertion {
      source     = "STATUS_CODE"
      property   = ""
      comparison = "EQUALS"
      target     = "401"
    }

    basic_auth {
      username = ""
      password = ""
    }
  }
}

Developing the provider

Clone the repo, build the project and add it to your Terraform plugins directory. You will need to have Go installed.

git clone [email protected]:bitfield/terraform-provider-checkly.git
cd terraform-provider-checkly
go test
go build && CHECKLY_API_KEY=XXX go test -tags=integration

terraform-provider-checkly's Issues

API error when applying terraform with not set sslCertificates.alertThreshold

Terraform version: 0.12.24
Provider version: 0.4.0
The problem: Applying plan that seems correct (no errors or warnings) fails with API error.

Steps to reproduce:
run terraform apply on file sam as in #8.

Result:
(manually formatted for clarity)

Error: API error: unexpected response status 400: 

{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "child \"AlertSettingsSchema\" fails because [child \"sslCertificates\" fails because [child \"alertThreshold\" fails because [\"alertThreshold\" must be one of [3, 7, 14, 30]]]]",
  "validation": {
    "source": "payload",
    "keys": [
      "alertSettings.sslCertificates.alertThreshold"
    ]
  }
}

New release tag

Any chance you to create a new release given the changes that have been merged in since the last release? v0.4.0...master

Switch to using Terraform plugin SDK

Currently the provider uses the (now) legacy Terraform Core SDK. The new way is to use the terraform-plugin-sdk library. I don't think there are any big code changes required (just import changes), but at some point the old SDK will go away, so we'll need to upgrade to keep the provider working.

Prep for Terraform Provider Development Program

This is the workflow for getting a provider officially 'approved' by Hashicorp and added to the standard providers repo: https://www.terraform.io/guides/terraform-provider-development-program.html

This issue is to track the additional work required to pass this program.

Terraform reports "method" is not allowed to be empty on request url change

tf version
Terraform v0.12.12

• provider.checkly v0.6.2

Apply the following:

provider "checkly" {
  api_key = ...
}

resource "checkly_check" "api-check" {
  name = "Name"
  type = "API"

  activated = true
  should_fail = false

  frequency = 1
  double_check = true

  use_global_alert_settings = false

  degraded_response_time = 10000
  max_response_time = 30000

  locations = [
    "us-west-1",
    "eu-west-1"
  ]

  alert_settings {
    escalation_type = "RUN_BASED"

    reminders {
      amount = 0
      interval = 15
    }

    run_based_escalation {
      failed_run_threshold = 3
    }

    ssl_certificates {
      enabled = false
    }
  }

  request {
    method = "GET"
    url = "https://service.url.com/first"

    follow_redirects = true
    headers = {}
    query_parameters = {}

    body_type = "NONE"

    assertion {
      source = "STATUS_CODE"
      comparison = "EQUALS"
      target = 200
    }

    basic_auth {
      username = ""
      password = ""
    }
  }
}

Than change request url, from https://service.url.com/first to https://service.url.com/second and apply. Terraform reports:

Error: API error: unexpected response status 400: "{\"statusCode\":400,\"error\":\"Bad Request\",\"message\":\"child \\\"request\\\" fails because [child \\\"method\\\" fails because [\\\"method\\\" is not allowed to be empty]]\",\"validation\":{\"source\":\"payload\",\"keys\":[\"request.method\"]}}"

Improve documentation

classic Terraform style documentation would be nice
—@tkowalcz

Yes, it would.

Provider shows no version on `terraform version`

After installing, there is no version displayed. This makes debugging harder.

$ terraform version
Terraform v0.12.24
+ provider.checkly (unversioned)

Terraform apply generates changes every time I run it

Hi,

I got info from Checkly support to create issue with my problem here.

Terraform version: 0.12.24.
Provider version: v0.4.0
The problem: Every time I run teraform apply it will produce some changes. I don't do any changes from the UI or anything. Just run the command in a loop. Also I would kill for any documentation e.g. what are valid values for assertion.source?

Thanks!

I use following main.tf. Note that following fields were redacted:
provider.checkly.api_key, checkly_check.example-check.request.url, checkly_check.example-check.request.assertion.target.

provider "checkly" {
  api_key = "..."
}

resource "checkly_check" "example-check" {
  name = "Example"
  type = "API"

  activated = true
  should_fail = false

  frequency = 1
  double_check = true

  use_global_alert_settings = true

  locations = [
    "us-west-1", "eu-west-1"
  ]

  request {
    url = "https://some-website"
    follow_redirects = true

    assertion {
      source = "TEXT_BODY"
      comparison = "NOT COTAINS"
      target = "some string I do not want to see"
    }
  }
}

Diff on basic_auth even when not using it

As part of #8 I mentioned I hoped to work around the "diff-even-without-changes" problem by just explicitly stating everything so it would stop show the properties as being removed in the diff.

Specifying all the alert settings seemed to work out somewhat ok, but then I wanted to do the same with the diff's shown in the request where we also had no desired changes even if the plugin showed changes.

It showed something like this (I don't have the exact output but hope this will do for now):

      + request {
          + body_type        = "NONE"
          + follow_redirects = true
          + method           = "GET"
          + url              = "https://some-website"

          + assertion {
              + comparison = "NOT COTAINS"
              + source     = "TEXT_BODY"
              + target     = "some string I do not want to see"
            }
        }

      - request {
          - body_type        = "NONE" -> null
          - follow_redirects = true -> null
          - headers          = {} -> null
          - method           = "GET" -> null
          - query_parameters = {} -> null
          - url              = "https://some-website" -> null

          - assertion {
              - comparison = "NOT COTAINS" -> null
              - source     = "TEXT_BODY" -> null
              - target     = "some string I do not want to see" -> null
            }

          - basic_auth {}
        }

Notice that the request block it wants to add is without headers, query_parameters and basic_auth (which is what I want), so I hoped I could just set them explicitly to be "empty"/"unset". This seems like it would work for headers and query_parameters, but it does not work for basic_auth because the provider requires you to define a username and password property on the basic_auth block, but in my case I don't even want to use basic_auth.

Manually deleting check breaks terraform

Terraform version: 0.12.24
Provider version: 0.4.0
The problem: Manually deleting terraform managed check breaks terraform.

Steps to reproduce:

1. Create check via terraform
2. Delete check via UI
3. run terraform apply or terraform plan

Result:

checkly_check.example-check: Refreshing state... [id=36152cfc-f65c-42a9-b922-7eadd23c5840]

Error: API error: unexpected response status 404: "{\"statusCode\":404,\"error\":\"Not Found\"}"