Resources and Lifecycle

Maeztro makes a model of a system by scanning the entities from files in your project. A Maeztro entity can be any of the following:

• a Maeztro resource (e.g. maeztro.group)
• a Terraform resource (e.g. aws_instance.node_server)
• a Terraform module (e.g. module.my_module)
• a Cloudsoft AMP typed entity (e.g. workflow-process)

Maeztro allows you to describe how these entities should be managed and observed:

• names and descriptions
• relationships to other entities
• sensors, effectors, and policies

Resources

Defining Maeztro Resources

In the simplest case, you define new a new Maeztro resources in any *.mz file in your project, as in the following example:

resource maeztro "data_tier" {
  name = "Data Tier Maeztro Group"
}

As in Terraform, the general form of this is resource TYPE "ID": this example block defines a simple maeztro-type resource with ID data_tier. As in Terraform, it is referred to by its address TYPE.ID, or maeztro.data_tier here.

We can then optionally give a more human-readable name.

To place it in a group, specify a parent referring to a valid resource; for example:

resource maeztro "data_items" {
  name = "Data Items"
  parent = maeztro.data_tier
}

Importing and Extending Resources

Maeztro natively understands Terraform *.tf files and state, so all the Terraform resources in your project will be modeled automatically in Maeztro. These can then be extended in *.mz files that Maeztro processes.

For example, an aws_dynamodb_table Terraform resource might be declared as follows in your Terraform:

resource "aws_dynamodb_table" "data_table" {
  name = var.data_table_name
  billing_mode = "PAY_PER_REQUEST"
  hash_key = "HASH_KEY"

  attribute {
    name = "HASH_KEY"
    type = "S"
  }
}

This resource can be extended with Maeztro modelling information by using a maeztro extend, giving it a name as before and placing it in our “Data Tier” group:

maeztro extend resource "aws_dynamodb_table.data_table" {
  name   = "Data Table"
  parent = maeztro.data_tier
}

Because these are defined in *.mz files, they do not interfere at all with Terraform; they can coexist in the same directory, and Terraform will ignore the MZ. It is not necessary to have a maeztro extend block for your Terraform resources; they are automatically inferred based on Terraform code and/or state. You can specify a Terraform resource as a parent of other Terraform resources or other Maeztro resources.

Where a Terraform resource is described with a count or foreach attribute, Maeztro creates an entity for the definition and entities for each discovered and/or expected instance, indexed as per Terraform; these “indexed instances” are automatically parented by the “instance index definition”. Currently, Maeztro is only able to extend the parent.

The list of blocks and attributes permitted in a resource maeztro or maeztro extends block is described in the reference guide.

Lifecycle

With some resources defined, Maeztro or Terraform or both, you can create a new project with:

mz init

This logs in to the server, assuming the CLI is setup, creates a project, and uploads the files.

It will also upload Terraform state. If there is Terraform state without any Maeztro resources, Maeztro will detect that the application is already deployed; otherwise, to have Maeztro use the model you have created, run:

mz apply

You can subsequently make changes to the code, in files locally or in the UI, and transfer between your computer and the server using:

mz sync

Unapplied changes can be previewed, and when ready to apply, run mz apply again.

It is up to you whether terraform is run automatically as part of an apply and/or whether you run it manually; during the init process, if Terraform is detected, you will be prompted for how to run it. A shared Terraform backend, such as Terraform Cloud, permits the most flexible arrangements because terraform can be invoked on either end without needing to take care about synchronizing state.