-
Notifications
You must be signed in to change notification settings - Fork 37
/
foober_iter.yaml
132 lines (125 loc) · 5.17 KB
/
foober_iter.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
# 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