foober_iter.yaml

# Foobernetes is an imaginary cloud provider used to illustrate and test the capabilities of Lyra.
#
# This file defines a workflow called "foober_iter" (named after the file that it resides in).
# The workflow contains a set of interrelated steps and Lyra will determine the correct order in
# which to execute them based on the parameters and returns of each. In this example we are
# deploying a (fictional) 3-tier application consisting of a database, two application servers and
# two web servers, with a load balancer in front. The fictional real-world resources are written to
# a file called "deployment.json" allowing you to see the changes made by Lyra.
#
# Try the following:
# 1. Use Lyra to apply the workflow:
#    "lyra apply --debug foober_iter"
# 2. Look at the debug output and compare with the newly-created "deployment.json"
#    file to see what Lyra has done.
# 3. Run Lyra a second time and note that no changes are made - all resources are
#    already in the desired state.
# 4. Edit the workflow then run Lyra again to see what happens.
# 5. Finally, use Lyra to delete all deployed resources:
#    "lyra delete --debug foober_iter"
#
# This example is written in yaml. See the yaml documentation here: docs/workflow-yaml.md

# The workflow expects a single parameter named "load_balancer_policy" and is used in the
# "loadbalancers" collect step below.
# The value itself comes from the "data.yaml" file at runtime based on the
# "lookup" key specified here: in this case a key called "lb_policy" nested in
# the "foober_iter" section. All top-level workflow parameters must be specified in
# the "data.yaml" file at runtime.
parameters:
  policies:
    type: Hash[String, String]
    lookup: foobernetes.policies

# The workflow returns a two element array containing the IDs produced by the
# "loadBalancers" collect step. All top-level returns must be returns of
# steps within this workflow.
returns: loadbalancers

# Steps are the main body of the workflow and define its behavior. The
# ordering of the steps is not important - Lyra will infer the correct
# order in which to execute the steps based on their parameters and returns.
#
# The steps in this workflow are all declarative "stateful steps",
# meaning they define the desired states of real-world resources. For each type
# of stateful step, there is a "state handler" that takes responsibility for
# ensuring the real-world resource matches the desired state. It does this by
# creating, reading, updating or deleting those resources in response to
# workflow changes. The types and state handlers for this workflow are defined
# in Go and can be found in the "go-foobernetes" plugin.
#
# Although Lyra support imperative "stateless steps", it is not possible to
# specify these in yaml.
#
# In yaml, step parameters are usually implicit (though can be made explicit if
# desired) and any field value that starts with a dollar sign ($) is assumed to
# be a parameter e.g. $databaseID. Step returns are always explicit. A step
# can only be executed when all parameters are available. Those parameters must
# come from either the top-level workflow parameters or the returns of other
# steps. Parameters and returns are correlated by name and so must be unique
# within a workflow.
steps:

  # This step defines an collect step called "webServers" which will
  # create two identical webserver resources.
  #
  # Since this is an collect step, it will always return a list where each entry is a value
  # returned by the contained step. The returned list is named after step by default but can
  # be changed using an 'into' property.
  # The parameters are implicit and can be identified by
  # the use of a dollar sign ($) i.e. appServers.
  webServers:
    times: 2
    step:
      # This step defines a Foobernetes::Webserver resource.
      returns: webServerID
      resource: Foobernetes::Webserver
      value:
        port: 8080
        appServers: $appServers

  # This collect step iterates over an array of 3 element arrays. Each iteration
  # assigns the 3 values to their corresponding variables $role, $ip, and $replica which
  # are then used when declaring each loadbalancer's state.
  loadbalancers:
    each:
      - [primary, '10.0.0.1', false]
      - [secondary, '10.0.0.2', true]
    as:
      - role
      - ip
      - replica
    step:
      returns: loadBalancerID
      resource: Foobernetes::Loadbalancer
      value:
        loadBalancerIP: $ip
        location: eu1
        policy: $policies.lb_policy
        replica: $replica
        webServerIDs: $webServers
        tags:
          team: "lyra team"
          role: $role

  # The state section of a step is keyed by a valid type name and can be arbitrarily nested as shown in the
  # "config" section.
  appServers:
    each:
      - app-server1
      - app-server2
    as: name
    step:
      returns: instanceID
      resource: Foobernetes::Instance
      value:
        location: eu2
        image: "lyra::application"
        config:
          name: $name
          databaseID: $databaseID
        cpus: 4
        memory: 8G

  database:
    returns:
      databaseID: instanceID
    resource: Foobernetes::Instance
    value:
      location: eu1
      image: "lyra::database"
      cpus: 16
      memory: 64G