While the examples and code listings in this book can be used directly without any supporting material, a companion Git repository is also provided to help you with the setup process and the automation of test environments so that you can follow along easily.

In this section, we're going to explore how that repository is organized, explain some choices that are made in terms of the automation of the test environments, and give some pointers on how to customize them:

.
├── Makefile
├── README.md
├── cache/
├── chapter03/
├── ...
├── chapter14/
└── utils/

The root structure of the repository shown here should be fairly easy to understand:

• One directory per chapter that needs its own test environment (aptly named chapter, followed by the chapter number)
• A cache directory, which will hold downloaded packages so that rebuilding test environments becomes as fast as possible
• A utils directory, where default versions and parameters of the test environments can be found (and changed if wanted), along with some helper functions

Next, we are going to drill down and have a closer look at each of these, like so:

.
├── ...
└── utils/
    ├── defaults.sh
    ├── helpers.sh
    └── vagrant_defaults.rb

In the utils directory, the following files can be found:

• defaults.sh: Here, the versions of each component in the Prometheus stack (such as Prometheus itself, along with exporters and Alertmanager, among others) that will be used in the test environments can be found.
• vagrant_defaults.rb: This file controls a couple of tunable parameters for the virtual machines that are used to run the test environments, like the amount of RAM each virtual machine will have, which base image to use, and what the environment's internal network will look like.
• helpers.sh: This is a shell library that's used by the provisioning scripts with some helper functions to manage the downloading and caching of archives:

.
├── ...
├── chapter03/
│   ├── Vagrantfile
│   ├── configs/
│   └── provision/
└── ...

While each test environment will differ in some ways between chapters, the basic structure will remain the same:

• A Vagrantfile to describe how many virtual machines are needed for the test environment, along with how to configure and provision them
• A configs directory to house configuration files that will be used in the provision step
• A provision directory with scripts to download, install, and configure each of the Prometheus components that are required for the current test environment

We can see an example of this by looking at the tree structure for this chapter:

.
├── ...
├── chapter03/
│   ├── Vagrantfile
│   ├── configs/
│   │   ├── alertmanager/
│   │   ├── grafana/
│   │   ├── node_exporter/
│   │   └── prometheus/
│   └── provision/
│       ├── alertmanager.sh*
│       ├── grafana.sh*
│       ├── hosts.sh*
│       ├── node_exporter.sh*
│       └── prometheus.sh*
└── ...

The configs directory has sub-directories for each of the components that's used in this chapter. The provision directory follows the same model, with an added hosts.sh shell script to automate the management of /etc/hosts file on the guests.

By now, the question of Why not just use configuration management? might have risen in the minds of some. All the provisioning automation was done in a shell for a couple of reasons:

• This was a conscious effort to expose every detail, not abstract them away.
• Shell scripting is the lowest common denominator of automation in Unix-like systems.
• The purpose of this book is to focus on the inner workings of Prometheus, not the specific implementation of a given configuration management tool.