DataDog/workbench-recipes

Name: workbench-recipes

Owner: Datadog, Inc.

Description: Recipes for the Integration Workbench project

Created: 2017-06-22 09:40:26.0

Updated: 2018-03-14 18:18:01.0

Pushed: 2018-05-18 20:13:41.0

Homepage: https://github.com/DataDog/workbench-tooling

Size: 67

Language: Shell

GitHub Committers

User	Most Recent Commit	# Commits

Other Committers

User	Email	Most Recent Commit	# Commits

README

Datadog Integration Workbench recipes

This repository holds the recipes for the Integration Workbench project. Please refer to this repository's documentation to learn about the scope of the project and the usage of the workbench tool.

As these are generic docker-compose files that can be reused for other uses (eg. continuous integration), we are hosting them in a separate repository.

Repository structure

• For every target software, a recipe is created in a dedicated folder, with a manifest.yaml file describing it
• Each recipe provides one or several docker-compose files, called flavors
• Each flavor can accept one or several options, passed as environment variables to docker-compose
• When relevant, flavors include a provision stage that injects test data in the data stores

Flavors can either use public docker images, or provide their own Dockerfiles that will be built on demand by docker-compose. For better readability, flavors can be moved into separate sub-folders.

Recipes can provide auto_conf templates to be used by the agent for autodiscovery. They are to be in the auto_conf folder, and will be automatically copied by workbench update command

| Filename | Format | Contents | Required? | |———-|——–|————-|———–| | README.md | Markdown | usage instructions / tips for the recipe | Optional | | manifest.yaml | See below | recipe metadata, to be used by workbench | Required | | .compose | docker-compose | flavor description as a valid docker-compose v2 or v2.1 file | Required | | auto_conf/.yaml | yaml | autodiscovery templates for dd-agent. Required if not provided by the defaul dd-agent distribution | Required |

Manifest format

Recipe manifest files are yaml files with the following structure:

Toplevel elements

| Name | Type | Description | Required? | |——|——|————-|———–| | name | string | recipe name to display | Required | | flavors | dict | available flavors | Required not empty

Flavor properties

| Name | Type | Description | Required? | |——|——|————-|———–| | description | string | flavor description to display | Required | | compose_file | string | relative path to the docker-compose file | Required | | options | dict | options to pass as environment variables to docker-compose | Optional |

Option properties

| Name | Type | Description | Required? | |——|——|————-|———–| | description | string | option description to display | Required | | values | array of strings | possible values an option can take | Optional | | default | string | default value to use if not specified | Optional |

Tips and tricks

Manifests

• You can use YAML anchors to share common properties between flavors. See the redis manifest for example.

Compose files

• To allow dd-agent to monitor the containers, they must be connected into the workbench network. Please look at existing flavors
• To run provisionning scripts (inserting test data, setting up clusters), flavors can run an additional container that will start after the server containers and run a script. You can have a look at the mongodb and rabbitmq recipes for examples.
• To allow for finer-grained matching of auto_conf templates, you can use the com.datadoghq.sd.check.id container label, and set that in the docker_images field of the auto_conf template