CoCo APM Dynatrace Terraform BackUp Exporter

The main purpose of the coco_apm_dynatrace_terraform_backup_exporter is to pull all the available configuration files from Dynatrace to back them up.

Environment Variables

To run this project, you will need to add an .env file with the following environment variables:

EUPROD_TOKEN_VAR EUPREPROD_TOKEN_VAR NAPROD_TOKEN_VAR NAPREPROD_TOKEN_VAR CNROD_TOKEN_VAR CNPREPROD_TOKEN_VAR

Installation

In order to run the program on the local machine, it is necessary to install the packages that are listed within the requirements.txt file by:

pip3 install --user -r requirements.txt

Terraform Provider for Dynatrace

It is also required to install the Terraform Provider for Dynatrace. Once you download and extract a selected version of the provider, please make sure to add the directory of the extracted executable as well as the filename of it in tf-provider-config.yaml.

Additional configurations

Note: Additionally you must configure the environment url env-url and output directory output-dir within the env-config.yaml file in the future if your environment url changes or if you prefer a different output directory.

Run Locally

In order to make a backup of all the available enviornments that are configured within the configuration.yaml file you can execute the script with the following command:

python3 .\export

Documentation

The Documentation briefly describes the currently set up backup process and a scenario for restoration.

BackUp Process

The export script is executed every day at 5 AM by Jenkins. Jenkins pushes the backup to the coco_apm_dynatrace_terraform_backup by creating a branch with a timestamp. Each branch contains the dashboards and all other configurations stored both separately. The reason for this is due to the Terraform Dynatrace Provider - in the GitHub documentation it is stated that dashboards need to be exported separately.

Additonally, Jenkins downloads the Terraform Dynatrace Provider version 1.30.1, however you can configure this within the Jenkinsfile by adjusting the global parameters bin, fileand link.

Note: It might be possible that you could encounter issues when upgrading to a higher version due to compability issues. Here is an example:

Warning: Provider source not supported in Terraform v0.12

  on ___providers___.tf line 3, in terraform:
   3: 		dynatrace = {
   4: 		source = "dynatrace-oss/dynatrace"
   5: 		version = "1.30.2"
   6: 		}

A source was declared for provider dynatrace. Terraform v0.12 does not support
the provider source attribute. It will be ignored.


Error: no provider exists with the given name

Explanation:

• (A) The error indicates that Terraform v0.12 does not support the downloaded Terraform Dynatrace Provider version 1.30.2. Therefore it was necessary to downgrade to 1.30.1!
• (B) It could also mean a misconfiguration of the environment within env-conig.yaml. Example: Wrong token or environment url, therefore the environment cannot be found and the warning alongside the error are thrown. As a result no configuration files as well as dashboards could be fetched, resulting in an empty backup directory.

Restore Process

If you are planning to restore the backed up configuration files or dashboards, then you will need to install Terraform on your local machine. Do not forget to add the binary file to your system environment path.

Usage/Examples for Restoration

Scenario: A dashboard tile has been changed or accidently deleted. How can this be solved?

First you will need to know when the incident happened. After downloading the backup repository you will need to checkout the branch with the day before the accident happened. Then, you will need to configure the ___providers___.tf file which resides is in the same direcory as the main.tf file:

terraform {
  required_providers {
    dynatrace = {
      source  = "dynatrace-oss/dynatrace"
      version = "1.30.1"
    }
  }
}

provider "dynatrace" {
    dt_env_url    = "<tenant-url>"
    dt_api_token  = "<your-token>"
}

You need to add the url of the tenant and also the associated token! After that has been done you need to initialize it by the following command:

terraform init

Once the backend has been initalized, all you need to do now is to first import the state of the affected dashboard as in the following example:

terraform import module.dashboard.dynatrace_dashboard.CD_VDLM_XXXXX 1123jk2-1234ud

Basically the above expression indicates that the current state of the affected dashboard will be genearted (state file) within the following syntax:

terraform import module.<module_name>.<resource_type>.<resource_name> ADDRESS_ID

More about the Syntax can be read here Resource Addressing and here Command: import.

Once the state is imported you will have to apply the changes of the backed up file by using the following command:

terraform apply -target module.dashboard.dynatrace_dashboard.CD_VDLM_XXXXX

The above command indicates that the backed up configuration will be applied. With that the changes of the affected dashboard will be reverted back to a state before the accident.

Note in the above syntax that apply is used with the option -target in order to specifiy the resource name. Hence the ADDRESS_ID is omitted since the backup process fetches the ids and adds them as a comment in the first line of each configuration file! Also after the command is executed it will prompt you to type "yes" in order to execute the command. In Resource Targeting you can read more about it.