sparkle-guides 0.1.10 → 0.1.12
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +5 -5
- data/CHANGELOG.md +4 -0
- data/docs/apply-and-nested.md +44 -1
- data/docs/getting-started.md +3 -2
- data/docs/tips-and-tricks.md +128 -0
- data/sparkle-guides.gemspec +1 -1
- metadata +4 -4
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
|
-
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
2
|
+
SHA256:
|
3
|
+
metadata.gz: e2cf461c429c10b2156db909a0cb627c594bda1cc7c86532d6dd8b3920affceb
|
4
|
+
data.tar.gz: df4f1573c99d06439f0fe11b3d80bc238c56105dc35c5b42497a66c6b1455ff7
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: facf5eefbb559517c5a68a0d3b8b7abac016196ef6760e3cbdc8c483c668593358eaab39628a319e156cd4db3671e6538bfd3e2c373506f1d35ae64c35403b5f
|
7
|
+
data.tar.gz: 8c9b28db2eb1208c774fc6f9da95cdd43a187f5587b0184a1bbb4e455bdb055a63e64b871a9ffb8ce7669f446c28ecca095a64a82afb280a70c6d36c2f02f82b
|
data/CHANGELOG.md
CHANGED
data/docs/apply-and-nested.md
CHANGED
@@ -1,5 +1,5 @@
|
|
1
1
|
---
|
2
|
-
title: "Stack
|
2
|
+
title: "Stack Dependencies"
|
3
3
|
weight: 2
|
4
4
|
anchors:
|
5
5
|
- title: "Overview"
|
@@ -10,6 +10,8 @@ anchors:
|
|
10
10
|
url: "#nested-stack-implementation"
|
11
11
|
- title: "Apply nested stack"
|
12
12
|
url: "#apply-nested-stack"
|
13
|
+
- title: "Cross location"
|
14
|
+
url: "#cross-location"
|
13
15
|
---
|
14
16
|
|
15
17
|
## Overview
|
@@ -390,3 +392,44 @@ You can destroy the all the `infrastructure` related stacks with the command:
|
|
390
392
|
~~~
|
391
393
|
sfn destroy sparkle-guide-infrastructure
|
392
394
|
~~~
|
395
|
+
|
396
|
+
## Cross location
|
397
|
+
|
398
|
+
SparkleFormation supports accessing stacks in other locations when using the
|
399
|
+
apply stack functionality. This is done by configuring named locations within
|
400
|
+
the `.sfn` configuration file and then referencing the location when applying
|
401
|
+
the stack. Using this example `.sfn` configuration file:
|
402
|
+
|
403
|
+
~~~ruby
|
404
|
+
Configuration.new do
|
405
|
+
credentials do
|
406
|
+
provider :aws
|
407
|
+
aws_access_key_id 'KEY'
|
408
|
+
aws_secret_access_key 'SECRET'
|
409
|
+
aws_region 'us-east-1'
|
410
|
+
end
|
411
|
+
locations do
|
412
|
+
west_stacks do
|
413
|
+
provider :aws
|
414
|
+
aws_access_key_id 'KEY'
|
415
|
+
aws_secret_access_key 'SECRET'
|
416
|
+
aws_region 'us-west-2'
|
417
|
+
end
|
418
|
+
end
|
419
|
+
end
|
420
|
+
~~~
|
421
|
+
|
422
|
+
This configuration connects to the AWS API in us-east-1. It also includes configuration
|
423
|
+
for connecting to us-west-2 via a named location of `west_stacks`. This allows referencing
|
424
|
+
stacks located in us-west-2 when using the apply stack functionality. Assume a new stack
|
425
|
+
is being created in us-east-1 (my-stack) and the outputs from other-stack in us-west-2
|
426
|
+
should be applied. This can be accomplished with the following command:
|
427
|
+
|
428
|
+
~~~
|
429
|
+
sfn create my-stack --apply-stack west_stacks__my-stack
|
430
|
+
~~~
|
431
|
+
|
432
|
+
When the stack is created sfn will first connect to the us-west-2 API and gather the
|
433
|
+
outputs from other-stack, then it will connect to us-east-1 to create the new stack.
|
434
|
+
|
435
|
+
_NOTE: Custom locations are not required to have a common provider._
|
data/docs/getting-started.md
CHANGED
@@ -26,8 +26,7 @@ anchors:
|
|
26
26
|
|
27
27
|
## Requirements
|
28
28
|
|
29
|
-
* Ruby (Version `>=` 2.
|
30
|
-
* Bundler
|
29
|
+
* Ruby (Version `>=` 2.3)
|
31
30
|
* Provider Credentials
|
32
31
|
|
33
32
|
### Installing Ruby
|
@@ -53,8 +52,10 @@ the provider:
|
|
53
52
|
|
54
53
|
* [miasma-aws](https://github.com/miasma-rb/miasma-aws)
|
55
54
|
* [miasma-azure](https://github.com/miasma-rb/miasma-azure)
|
55
|
+
* [miasma-google](https://github.com/miasma-rb/miasma-google)
|
56
56
|
* [miasma-open-stack](https://github.com/miasma-rb/miasma-open-stack)
|
57
57
|
* [miasma-rackspace](https://github.com/miasma-rb/miasma-rackspace)
|
58
|
+
* [miasma-terraform](https://github.com/miasma-rb/miasma-terraform)
|
58
59
|
|
59
60
|
## Installation
|
60
61
|
|
@@ -0,0 +1,128 @@
|
|
1
|
+
---
|
2
|
+
title: "Tips and Tricks"
|
3
|
+
weight: 3
|
4
|
+
anchors:
|
5
|
+
- title: "Stubbing builtins"
|
6
|
+
url: "#stubbing-builtins"
|
7
|
+
- title: "Resource conflicts"
|
8
|
+
url: "#resource-conflicts"
|
9
|
+
---
|
10
|
+
|
11
|
+
## Stubbing builtins
|
12
|
+
|
13
|
+
SparkleFormation provides a number of builtin resources using the
|
14
|
+
`dynamic!` helper. These known resources are collected when SparkleFormation
|
15
|
+
is released. Because this is a static list of resource types it is
|
16
|
+
common for new resources to be introduced within a cloud provider
|
17
|
+
and not be available within SparkleFormation. Since the new resource
|
18
|
+
types will not be available within SparkleFormation until the next
|
19
|
+
release, stubbing the builtin will provide the same behavior as if
|
20
|
+
it were included within the builtin list.
|
21
|
+
|
22
|
+
For example, lets assume that AWS CloudFormation introduces a new
|
23
|
+
resource type named `AWS::JVM::Instance`. To stub this resource a
|
24
|
+
new dynamic can be created locally:
|
25
|
+
|
26
|
+
~~~ruby
|
27
|
+
SparkleFormation.dynamic(:jvm_instance) do |name|
|
28
|
+
resources.set!("#{name}_jvm_instance".to_sym) do
|
29
|
+
type "AWS::JVM::Instance"
|
30
|
+
end
|
31
|
+
end
|
32
|
+
~~~
|
33
|
+
|
34
|
+
With this dynamic defined it will behave the same as if it were
|
35
|
+
defined in the builtin list:
|
36
|
+
|
37
|
+
~~~ruby
|
38
|
+
SparkleFormation.new(:test) do
|
39
|
+
dynamic!(:jvm_instance, :test) do
|
40
|
+
properties.memory 512
|
41
|
+
end
|
42
|
+
end
|
43
|
+
~~~
|
44
|
+
|
45
|
+
which results in:
|
46
|
+
|
47
|
+
~~~json
|
48
|
+
{
|
49
|
+
"Resources": {
|
50
|
+
"TestJvmInstance": {
|
51
|
+
"Type": "AWS::JVM::Instance",
|
52
|
+
"Properties": {
|
53
|
+
"Memory": 512
|
54
|
+
}
|
55
|
+
}
|
56
|
+
}
|
57
|
+
}
|
58
|
+
~~~
|
59
|
+
|
60
|
+
Once the `AWS::JVM::Instance` becomes available in the builtin
|
61
|
+
list within SparkleFormation the custom stub dynamic can be deleted.
|
62
|
+
|
63
|
+
## Resource conflicts
|
64
|
+
|
65
|
+
Resource conflicts can occur when the same resource name is used
|
66
|
+
in multiple resource namespaces. If a template has created resources
|
67
|
+
using the `dynamic!` helper and not included the resource's namespace,
|
68
|
+
conflicts will occur when the new resource becomes available. An
|
69
|
+
example of this is the `AWS::ElasticLoadBalancing::LoadBalancer` resource.
|
70
|
+
|
71
|
+
Assume that the following template is in use:
|
72
|
+
|
73
|
+
~~~ruby
|
74
|
+
SparkleFormation.new(:lb) do
|
75
|
+
dynamic!(:load_balancer, :app)
|
76
|
+
end
|
77
|
+
~~~
|
78
|
+
|
79
|
+
and it generates:
|
80
|
+
|
81
|
+
~~~json
|
82
|
+
{
|
83
|
+
"Resources": {
|
84
|
+
"AppLoadBalancer": {
|
85
|
+
"Type": "AWS::ElasticLoadBalancing::LoadBalancer"
|
86
|
+
}
|
87
|
+
}
|
88
|
+
}
|
89
|
+
~~~
|
90
|
+
|
91
|
+
Now, AWS releases a new resource with a conflicting name
|
92
|
+
`AWS::ElasticLoadBalancingV2::LoadBalancer` and SparkleFormation's internal
|
93
|
+
resource list has been updated. When the template is run again, it returns
|
94
|
+
an error about conflicting resource names. One solution is to update the
|
95
|
+
`dynamic!` call to include the namespace:
|
96
|
+
|
97
|
+
~~~ruby
|
98
|
+
SparkleFormation.new(:lb) do
|
99
|
+
dynamic!(:elastic_load_balancing_load_balancer, :app)
|
100
|
+
end
|
101
|
+
~~~
|
102
|
+
|
103
|
+
and it will then generate:
|
104
|
+
|
105
|
+
~~~json
|
106
|
+
{
|
107
|
+
"Resources": {
|
108
|
+
"AppElasticLoadBalancingLoadBalancer": {
|
109
|
+
"Type": "AWS::ElasticLoadBalancing::LoadBalancer"
|
110
|
+
}
|
111
|
+
}
|
112
|
+
}
|
113
|
+
~~~
|
114
|
+
|
115
|
+
This resolves the conflict issue, yet in practice the modification of the
|
116
|
+
resource name will likely cause issues in complex templates where the
|
117
|
+
resource is being referenced in other locations. To allow templates to
|
118
|
+
remain unchanged, a new dynamic can be introduced which will force matching
|
119
|
+
of the `:load_balancer` name to the local dynamic:
|
120
|
+
|
121
|
+
~~~ruby
|
122
|
+
SparkleFormation.dynamic(:load_balancer) do |name|
|
123
|
+
dynamic!(:elastic_load_balancing_load_balancer, name, :resource_name_suffix => :load_balancer)
|
124
|
+
end
|
125
|
+
~~~
|
126
|
+
|
127
|
+
With this dynamic in place, all original templates will continue to behave
|
128
|
+
as expected without individual modifications.
|
data/sparkle-guides.gemspec
CHANGED
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: sparkle-guides
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.1.
|
4
|
+
version: 0.1.12
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Chris Roberts
|
8
8
|
autorequire:
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
|
-
date:
|
11
|
+
date: 2019-01-26 00:00:00.000000000 Z
|
12
12
|
dependencies: []
|
13
13
|
description: SparkleFormation Usage Guides
|
14
14
|
email: chrisroberts.code@gmail.com
|
@@ -20,6 +20,7 @@ files:
|
|
20
20
|
- README.md
|
21
21
|
- docs/apply-and-nested.md
|
22
22
|
- docs/getting-started.md
|
23
|
+
- docs/tips-and-tricks.md
|
23
24
|
- sparkle-guides.gemspec
|
24
25
|
homepage: http://github.com/sparkleformation/sparkle-guides
|
25
26
|
licenses:
|
@@ -40,8 +41,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
|
|
40
41
|
- !ruby/object:Gem::Version
|
41
42
|
version: '0'
|
42
43
|
requirements: []
|
43
|
-
|
44
|
-
rubygems_version: 2.4.8
|
44
|
+
rubygems_version: 3.0.1
|
45
45
|
signing_key:
|
46
46
|
specification_version: 4
|
47
47
|
summary: SparkleFormation Guides
|