sparkle-guides 0.1.10 → 0.1.12
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- 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
|