opskeleton 0.6.5 → 0.6.6
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/README.md +9 -128
- data/chef.md +136 -0
- data/lib/opskeleton/generate_puppet.rb +1 -1
- data/lib/opskeleton/version.rb +1 -1
- data/puppet.md +125 -0
- data/templates/chef/gemfile +1 -1
- data/templates/chef/vagrant.erb +1 -1
- data/templates/{gemfile → puppet/gemfile} +1 -1
- data/templates/puppet/opsk.yaml +2 -0
- metadata +5 -3
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 010f9793ae61094386bd62cbcb6057adc43fe3cf
|
4
|
+
data.tar.gz: ef76043ada71b082876516f259ff04c33421920d
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 0bf99b01016136f1bbc83e619f0732d970e4705c3f4a6189e201cfbfb26469f8f376a2a6331a977cd91f234529408822f2fdf211dbf6af662afac2eef4f89068
|
7
|
+
data.tar.gz: 32d147a5964d0718b00c618fc6873845f973f5c55d628c55db27151ef11befa4ff22581d1916b7c5ba6ea48448bff1829d35be7c44760e5d2bcf2c3b2e089a13
|
data/README.md
CHANGED
@@ -4,24 +4,27 @@
|
|
4
4
|
|
5
5
|
Opskelaton is an opinionated bootstrap tool for local Sandbox projects.
|
6
6
|
|
7
|
-
|
7
|
+
Opskeleton aims to solve the following common issues:
|
8
8
|
* Devops develop Puppet modules on master machines which results with 'It works on my (machine) master' approach.
|
9
9
|
* Implicit/Missing dependencies, like ruby version used, operating system, gems, third party puppet module
|
10
10
|
* Manual steps in setting up puppet modules and local sandboxes (like installing third party code).
|
11
11
|
* Non standard layout, projects missing README and LICENSE files, no clear separation between developed and dependant code.
|
12
12
|
* No clear development guidelines, for example extracting general modules and exporting them.
|
13
13
|
|
14
|
+
Opskeleton comes to solve these issues by introducing a decentralized development workflow with pre-defined layout, packaging and dependency management.
|
14
15
|
|
15
16
|
See it in action [here](https://www.youtube.com/watch?v=LNlHC54Ej8c).
|
16
17
|
|
17
18
|
[![Build Status](https://travis-ci.org/opskeleton/opskeleton.png)](https://travis-ci.org/opskeleton/opskeleton)
|
18
19
|
|
19
|
-
|
20
|
-
|
20
|
+
|
21
|
+
# Usage
|
22
|
+
|
23
|
+
## Installation
|
21
24
|
|
22
25
|
Perquisites (on Ubuntu):
|
23
26
|
|
24
|
-
* Vagrant 1.
|
27
|
+
* Vagrant 1.6.x
|
25
28
|
* RVM
|
26
29
|
* Ruby 1.9.x
|
27
30
|
|
@@ -30,131 +33,9 @@ Perquisites (on Ubuntu):
|
|
30
33
|
$ sudo gem install opskeleton
|
31
34
|
```
|
32
35
|
|
33
|
-
|
34
|
-
|
35
|
-
```bash
|
36
|
-
$ rvm use system
|
37
|
-
# parameters include name vagrant-box
|
38
|
-
$ opsk generate_puppet redis ubuntu-13.10
|
39
|
-
$ cd redis-sandbox
|
40
|
-
$ bundle install
|
41
|
-
$ librarian-puppet install
|
42
|
-
$ vagrant up
|
43
|
-
```
|
44
|
-
|
45
|
-
## Layout
|
46
|
-
|
47
|
-
Opskelaton creates the complete folder structure fine tuned to match best practices:
|
48
|
-
|
49
|
-
Folder layout:
|
50
|
-
|
51
|
-
<img src="https://raw.github.com/narkisr/vagrant-sketching-board/master/images/opsk-folders.png" width='30%' hight='50%' alt="" />
|
52
|
-
|
53
|
-
|
54
|
-
## Module lifecycle
|
55
|
-
|
56
|
-
Opskelaton defines a simple module life cycle:
|
57
|
-
|
58
|
-
1. Internal non reusable modules (usually specific to a client site) go under static-modules
|
59
|
-
2. If we create a general reusable module which is ready for prime time we pull out to a new git repository.
|
60
|
-
3. The extracted module is added back as a third party (using [librarian-puppet](https://github.com/rodjek/librarian-puppet) module which resides under modules folder.
|
61
|
-
|
62
|
-
Life cycle scheme:
|
63
|
-
|
64
|
-
<img src="https://raw.github.com/narkisr/vagrant-sketching-board/master/images/module-lifecycle-black.png" width='30%' hight='50%' alt="" />
|
65
|
-
|
66
|
-
Creating new (static) modules is easy as:
|
67
|
-
|
68
|
-
```bash
|
69
|
-
$ opsk module foo
|
70
|
-
```
|
71
|
-
|
72
|
-
Each generated module will contain puppet-rspec with matching Rakefile (see [testing](https://github.com/opskeleton/opskeleton#testing)).
|
73
|
-
|
74
|
-
## Testing
|
75
|
-
|
76
|
-
Opskelaton supports two levels of testing:
|
77
|
-
|
78
|
-
* Static module testing that includes rspec and linting.
|
79
|
-
* Integration testing using [serverspec](http://serverspec.org/) and Vagrant.
|
80
|
-
|
81
|
-
```bash
|
82
|
-
# linting all static modules
|
83
|
-
$ rake lint
|
84
|
-
# rspecing
|
85
|
-
$ rake modspec
|
86
|
-
# running serverspec
|
87
|
-
$ rake spec
|
88
|
-
```
|
89
|
-
|
90
|
-
## Packaging
|
91
|
-
Opskelaton fully supports deployment and portable execution of sandboxes on non Vagrant environments:
|
92
|
-
|
93
|
-
```bash
|
94
|
-
$ opsk generate_puppet foo ubuntu-13.10
|
95
|
-
$ cd foo-sandbox
|
96
|
-
# The package version file
|
97
|
-
$ cat opsk.yaml
|
98
|
-
---
|
99
|
-
version: '0.0.1'
|
100
|
-
name: foo
|
101
|
-
|
102
|
-
# post bundle and gem install ..
|
103
|
-
$ opsk package
|
104
|
-
create pkg/foo-sandbox-0.0.1
|
105
|
-
create pkg/foo-sandbox-0.0.1/scripts
|
106
|
-
create pkg/foo-sandbox-0.0.1/scripts/lookup.rb
|
107
|
-
chmod pkg/foo-sandbox-0.0.1/scripts/lookup.rb
|
108
|
-
create pkg/foo-sandbox-0.0.1/scripts/run.sh
|
109
|
-
chmod pkg/foo-sandbox-0.0.1/scripts/run.sh
|
110
|
-
create pkg/foo-sandbox-0.0.1/manifests/site.pp
|
111
|
-
exist pkg
|
112
|
-
$ ls pkg
|
113
|
-
foo-sandbox-0.0.1 foo-sandbox-0.0.1.tar.gz
|
114
|
-
```
|
115
|
-
The packaging process creates a portable tar file that can be run on any machine with puppet installed via the bundled run.sh:
|
116
|
-
|
117
|
-
```bash
|
118
|
-
$ tar -xvzf foo-sandbox-0.0.1.tar.gz
|
119
|
-
$ cd foo-sandbox-0.0.1
|
120
|
-
$ sudo ./run.sh
|
121
|
-
```
|
122
|
-
|
123
|
-
An external node classifier based runner is also available under scripts/run.sh, this runner expects to get a <hostname>.yaml input file with the required node classes.
|
124
|
-
|
125
|
-
|
126
|
-
## Deployment
|
127
|
-
|
128
|
-
The packaged tar files can be consumed using any tool and protocol however http is recommended, opsk has built in support for deploying public sandboxes into bintray:
|
129
|
-
|
130
|
-
```bash
|
131
|
-
$ opsk package
|
132
|
-
$ opsk deploy <bintray-repo>
|
133
|
-
deployed foo-sandbox-0.0.1.tar.gz to http://dl.bintray.com/narkisr/<bintray-repo>/foo-sandbox-0.0.1.tar.gz
|
134
|
-
```
|
135
|
-
|
136
|
-
Make sure to [configure](https://github.com/narkisr/bintray-deploy#usage) configure the bintray API key.
|
137
|
-
|
138
|
-
## Updating
|
139
|
-
Keeping you box up to date with latest opsk version is easy, just re-generate it again and resolve conflicts by answering y/n:
|
140
|
-
```bash
|
141
|
-
# Moving to latest opsk
|
142
|
-
$ gem update opskeleton
|
143
|
-
# foo box already exists
|
144
|
-
$ opsk generate foo <vagrant-box>
|
145
|
-
exist foo-sandbox
|
146
|
-
conflict foo-sandbox/Vagrantfile
|
147
|
-
Overwrite /home/ronen/code/foo-sandbox/Vagrantfile? (enter "h" for help) [Ynaqdh]
|
148
|
-
```
|
149
|
-
|
150
|
-
## Vagrant
|
151
|
-
Opskeleton generates a Vagrant file with couple of enhancements:
|
152
|
-
|
153
|
-
* VAGRANT_BRIDGE (default eth0) for setting up public bridge on the go.
|
154
|
-
* PUPPET_ENV (default dev) for setting puppet environment.
|
155
|
-
* Puppet options preset to match modules and hiera folders.
|
36
|
+
Now Follow either [Chef](chef.md) or [Puppet](puppet.md).
|
156
37
|
|
157
|
-
|
38
|
+
# Boxes
|
158
39
|
Opskeleton recommends the use of [box-cutter](https://github.com/box-cutter) in order to create Vagrant boxes in a consistent manner (as no free hosting solution currently exist):
|
159
40
|
```bash
|
160
41
|
# make sure to have latest packer
|
data/chef.md
ADDED
@@ -0,0 +1,136 @@
|
|
1
|
+
# Intro
|
2
|
+
|
3
|
+
Opskelaton fully supports chef based sandboxes with the same lifecycle semantics
|
4
|
+
|
5
|
+
it offers similar features to the Puppet based sandboxes with additional support for roles, environments and cookbooks.
|
6
|
+
|
7
|
+
# Usage
|
8
|
+
|
9
|
+
Creating out first sandbox
|
10
|
+
|
11
|
+
```bash
|
12
|
+
$ opsk generate_chef redis ubuntu-14.04
|
13
|
+
$ cd redis-sandbox
|
14
|
+
```
|
15
|
+
|
16
|
+
## Layout
|
17
|
+
|
18
|
+
Opskelaton creates the complete folder structure fine tuned to match best practices:
|
19
|
+
|
20
|
+
Folder layout:
|
21
|
+
|
22
|
+
<!-- <img src="https://raw.github.com/narkisr/vagrant-sketching-board/master/images/opsk-folders.png" width='30%' hight='50%' alt="" /> -->
|
23
|
+
|
24
|
+
|
25
|
+
## Cookbook lifecycle
|
26
|
+
|
27
|
+
Opskelaton defines a simple cookbook life cycle:
|
28
|
+
|
29
|
+
1. Internal non reusable cookbooks (usually specific to a client site) go under static-cookbooks
|
30
|
+
2. If we create a general reusable cookbook which is ready for prime time we pull out to a new git repository.
|
31
|
+
3. The extracted cookbook is added back as a third party (using [librarian-chef](https://github.com/applicationsonline/librarian-chef) cookbook which resides under modules folder.
|
32
|
+
|
33
|
+
Life cycle scheme:
|
34
|
+
|
35
|
+
<img src="https://raw.github.com/narkisr/vagrant-sketching-board/master/images/module-lifecycle-black.png" width='30%' hight='50%' alt="" />
|
36
|
+
|
37
|
+
Creating new (cookbooks) modules is easy as:
|
38
|
+
|
39
|
+
```bash
|
40
|
+
$ opsk cookbook foo
|
41
|
+
```
|
42
|
+
|
43
|
+
## Testing
|
44
|
+
|
45
|
+
Opskelaton supports testing/linting:
|
46
|
+
|
47
|
+
* Static cookbook testing that includes rspec and food-critic. (TBD)
|
48
|
+
* Integration testing using [serverspec](http://serverspec.org/) and Vagrant.
|
49
|
+
|
50
|
+
```bash
|
51
|
+
# running serverspec
|
52
|
+
$ rake spec
|
53
|
+
```
|
54
|
+
|
55
|
+
## Packaging
|
56
|
+
Opskelaton fully supports deployment and portable execution of sandboxes on non Vagrant environments:
|
57
|
+
|
58
|
+
```bash
|
59
|
+
$ opsk generate_chef foo ubuntu-14.04.
|
60
|
+
$ cd foo-sandbox
|
61
|
+
# The package version file
|
62
|
+
$ cat opsk.yaml
|
63
|
+
|
64
|
+
---
|
65
|
+
version: '0.0.1'
|
66
|
+
name: redis
|
67
|
+
includes:
|
68
|
+
- Cheffile
|
69
|
+
- cookbooks
|
70
|
+
- static-cookbooks
|
71
|
+
- dna.json
|
72
|
+
- environments
|
73
|
+
- Gemfile
|
74
|
+
- Gemfile.lock
|
75
|
+
- opsk.yaml
|
76
|
+
- roles
|
77
|
+
- LICENSE-2.0.txt
|
78
|
+
- run.sh
|
79
|
+
- boot.sh
|
80
|
+
- solo.rb
|
81
|
+
|
82
|
+
# post bundle and gem install ..
|
83
|
+
$ opsk package
|
84
|
+
create pkg/foo-sandbox-0.0.1
|
85
|
+
create pkg/foo-sandbox-0.0.1/scripts
|
86
|
+
create pkg/foo-sandbox-0.0.1/scripts/lookup.rb
|
87
|
+
chmod pkg/foo-sandbox-0.0.1/scripts/lookup.rb
|
88
|
+
create pkg/foo-sandbox-0.0.1/scripts/run.sh
|
89
|
+
chmod pkg/foo-sandbox-0.0.1/scripts/run.sh
|
90
|
+
exist pkg
|
91
|
+
$ ls pkg
|
92
|
+
foo-sandbox-0.0.1 foo-sandbox-0.0.1.tar.gz
|
93
|
+
```
|
94
|
+
The packaging process creates a portable tar file that can be run on any machine with chef-solo installed via the bundled run.sh:
|
95
|
+
|
96
|
+
```bash
|
97
|
+
$ tar -xvzf foo-sandbox-0.0.1.tar.gz
|
98
|
+
$ cd foo-sandbox-0.0.1
|
99
|
+
# expects to get the chef environment
|
100
|
+
$ sudo ./run.sh dev
|
101
|
+
```
|
102
|
+
|
103
|
+
|
104
|
+
## Deployment
|
105
|
+
|
106
|
+
The packaged tar files can be consumed using any tool and protocol however http is recommended, opsk has built in support for deploying public sandboxes into bintray:
|
107
|
+
|
108
|
+
```bash
|
109
|
+
$ opsk package
|
110
|
+
$ opsk deploy <bintray-repo>
|
111
|
+
deployed foo-sandbox-0.0.1.tar.gz to http://dl.bintray.com/narkisr/<bintray-repo>/foo-sandbox-0.0.1.tar.gz
|
112
|
+
```
|
113
|
+
|
114
|
+
Make sure to [configure](https://github.com/narkisr/bintray-deploy#usage) configure the bintray API key.
|
115
|
+
|
116
|
+
## Updating
|
117
|
+
|
118
|
+
Keeping you box up to date with latest opsk version is easy, just re-generate it again and resolve conflicts by answering y/n:
|
119
|
+
```bash
|
120
|
+
# Moving to latest opsk
|
121
|
+
$ gem update opskeleton
|
122
|
+
# foo box already exists
|
123
|
+
$ opsk generate_chef foo <vagrant-box>
|
124
|
+
exist foo-sandbox
|
125
|
+
conflict foo-sandbox/Vagrantfile
|
126
|
+
Overwrite /home/ronen/code/foo-sandbox/Vagrantfile? (enter "h" for help) [Ynaqdh]
|
127
|
+
```
|
128
|
+
|
129
|
+
## Vagrant
|
130
|
+
Opskeleton generates a Vagrant file with couple of enhancements:
|
131
|
+
|
132
|
+
* CHEF_ENV (default dev) for setting chef environment.
|
133
|
+
* Default role (sandbox name) created under roles/{type}.rb
|
134
|
+
* static-cookbooks/cookbooks roles/environments folders are set.
|
135
|
+
|
136
|
+
|
data/lib/opskeleton/version.rb
CHANGED
data/puppet.md
ADDED
@@ -0,0 +1,125 @@
|
|
1
|
+
# Intro
|
2
|
+
|
3
|
+
Opskelaton fully supports Puppet based sandboxes with the same lifecycle semantics as Chef.
|
4
|
+
|
5
|
+
# Usage
|
6
|
+
|
7
|
+
Creating out first sandbox
|
8
|
+
|
9
|
+
```bash
|
10
|
+
$ opsk generate_puppet redis ubuntu-14.04
|
11
|
+
$ cd redis-sandbox
|
12
|
+
```
|
13
|
+
|
14
|
+
## Layout
|
15
|
+
|
16
|
+
Opskelaton creates the complete folder structure fine tuned to match best practices:
|
17
|
+
|
18
|
+
Folder layout:
|
19
|
+
|
20
|
+
<img src="https://raw.github.com/narkisr/vagrant-sketching-board/master/images/opsk-folders.png" width='30%' hight='50%' alt="" />
|
21
|
+
|
22
|
+
|
23
|
+
## Module lifecycle
|
24
|
+
|
25
|
+
Opskelaton defines a simple module life cycle:
|
26
|
+
|
27
|
+
1. Internal non reusable modules (usually specific to a client site) go under static-modules
|
28
|
+
2. If we create a general reusable module which is ready for prime time we pull out to a new git repository.
|
29
|
+
3. The extracted module is added back as a third party (using [librarian-puppet](https://github.com/rodjek/librarian-puppet) module which resides under modules folder.
|
30
|
+
|
31
|
+
Life cycle scheme:
|
32
|
+
|
33
|
+
<img src="https://raw.github.com/narkisr/vagrant-sketching-board/master/images/module-lifecycle-black.png" width='30%' hight='50%' alt="" />
|
34
|
+
|
35
|
+
Creating new (static) modules is easy as:
|
36
|
+
|
37
|
+
```bash
|
38
|
+
$ opsk module foo
|
39
|
+
```
|
40
|
+
|
41
|
+
Each generated module will contain puppet-rspec with matching Rakefile (see [testing](https://github.com/opskeleton/opskeleton#testing)).
|
42
|
+
|
43
|
+
## Testing
|
44
|
+
|
45
|
+
Opskelaton supports two levels of testing:
|
46
|
+
|
47
|
+
* Static module testing that includes rspec and linting.
|
48
|
+
* Integration testing using [serverspec](http://serverspec.org/) and Vagrant.
|
49
|
+
|
50
|
+
```bash
|
51
|
+
# linting all static modules
|
52
|
+
$ rake lint
|
53
|
+
# rspecing
|
54
|
+
$ rake modspec
|
55
|
+
# running serverspec
|
56
|
+
$ rake spec
|
57
|
+
```
|
58
|
+
|
59
|
+
## Packaging
|
60
|
+
Opskelaton fully supports deployment and portable execution of sandboxes on non Vagrant environments:
|
61
|
+
|
62
|
+
```bash
|
63
|
+
$ opsk generate_puppet foo ubuntu-13.10
|
64
|
+
$ cd foo-sandbox
|
65
|
+
# The package version file
|
66
|
+
$ cat opsk.yaml
|
67
|
+
---
|
68
|
+
version: '0.0.1'
|
69
|
+
name: foo
|
70
|
+
|
71
|
+
# post bundle and gem install ..
|
72
|
+
$ opsk package
|
73
|
+
create pkg/foo-sandbox-0.0.1
|
74
|
+
create pkg/foo-sandbox-0.0.1/scripts
|
75
|
+
create pkg/foo-sandbox-0.0.1/scripts/lookup.rb
|
76
|
+
chmod pkg/foo-sandbox-0.0.1/scripts/lookup.rb
|
77
|
+
create pkg/foo-sandbox-0.0.1/scripts/run.sh
|
78
|
+
chmod pkg/foo-sandbox-0.0.1/scripts/run.sh
|
79
|
+
create pkg/foo-sandbox-0.0.1/manifests/site.pp
|
80
|
+
exist pkg
|
81
|
+
$ ls pkg
|
82
|
+
foo-sandbox-0.0.1 foo-sandbox-0.0.1.tar.gz
|
83
|
+
```
|
84
|
+
The packaging process creates a portable tar file that can be run on any machine with puppet installed via the bundled run.sh:
|
85
|
+
|
86
|
+
```bash
|
87
|
+
$ tar -xvzf foo-sandbox-0.0.1.tar.gz
|
88
|
+
$ cd foo-sandbox-0.0.1
|
89
|
+
$ sudo ./run.sh
|
90
|
+
```
|
91
|
+
|
92
|
+
An external node classifier based runner is also available under scripts/run.sh, this runner expects to get a <hostname>.yaml input file with the required node classes.
|
93
|
+
|
94
|
+
|
95
|
+
## Deployment
|
96
|
+
|
97
|
+
The packaged tar files can be consumed using any tool and protocol however http is recommended, opsk has built in support for deploying public sandboxes into bintray:
|
98
|
+
|
99
|
+
```bash
|
100
|
+
$ opsk package
|
101
|
+
$ opsk deploy <bintray-repo>
|
102
|
+
deployed foo-sandbox-0.0.1.tar.gz to http://dl.bintray.com/narkisr/<bintray-repo>/foo-sandbox-0.0.1.tar.gz
|
103
|
+
```
|
104
|
+
|
105
|
+
Make sure to [configure](https://github.com/narkisr/bintray-deploy#usage) configure the bintray API key.
|
106
|
+
|
107
|
+
## Updating
|
108
|
+
Keeping you box up to date with latest opsk version is easy, just re-generate it again and resolve conflicts by answering y/n:
|
109
|
+
```bash
|
110
|
+
# Moving to latest opsk
|
111
|
+
$ gem update opskeleton
|
112
|
+
# foo box already exists
|
113
|
+
$ opsk generate foo <vagrant-box>
|
114
|
+
exist foo-sandbox
|
115
|
+
conflict foo-sandbox/Vagrantfile
|
116
|
+
Overwrite /home/ronen/code/foo-sandbox/Vagrantfile? (enter "h" for help) [Ynaqdh]
|
117
|
+
```
|
118
|
+
|
119
|
+
## Vagrant
|
120
|
+
Opskeleton generates a Vagrant file with couple of enhancements:
|
121
|
+
|
122
|
+
* VAGRANT_BRIDGE (default eth0) for setting up public bridge on the go.
|
123
|
+
* PUPPET_ENV (default dev) for setting puppet environment.
|
124
|
+
* Puppet options preset to match modules and hiera folders.
|
125
|
+
|
data/templates/chef/gemfile
CHANGED
data/templates/chef/vagrant.erb
CHANGED
data/templates/puppet/opsk.yaml
CHANGED
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: opskeleton
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.6.
|
4
|
+
version: 0.6.6
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- narkisr
|
8
8
|
autorequire:
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
|
-
date: 2014-08-
|
11
|
+
date: 2014-08-30 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: thor
|
@@ -130,6 +130,7 @@ files:
|
|
130
130
|
- TODOS
|
131
131
|
- autocomplete/opsk_bash_completion
|
132
132
|
- bin/opsk
|
133
|
+
- chef.md
|
133
134
|
- lib/opskeleton.rb
|
134
135
|
- lib/opskeleton/bump.rb
|
135
136
|
- lib/opskeleton/clean.rb
|
@@ -142,6 +143,7 @@ files:
|
|
142
143
|
- lib/opskeleton/thorable.rb
|
143
144
|
- lib/opskeleton/version.rb
|
144
145
|
- opskeleton.gemspec
|
146
|
+
- puppet.md
|
145
147
|
- templates/LICENSE-2.0.txt
|
146
148
|
- templates/README.erb
|
147
149
|
- templates/chef/Cheffile
|
@@ -158,7 +160,6 @@ files:
|
|
158
160
|
- templates/chef/ubuntu_docker.erb
|
159
161
|
- templates/chef/vagrant.erb
|
160
162
|
- templates/clean.yaml
|
161
|
-
- templates/gemfile
|
162
163
|
- templates/gitignore
|
163
164
|
- templates/hiera.yaml
|
164
165
|
- templates/hiera_vagrant.yaml
|
@@ -170,6 +171,7 @@ files:
|
|
170
171
|
- templates/puppet/Rakefile
|
171
172
|
- templates/puppet/boot.sh
|
172
173
|
- templates/puppet/default.erb
|
174
|
+
- templates/puppet/gemfile
|
173
175
|
- templates/puppet/opsk.yaml
|
174
176
|
- templates/puppet/run.sh
|
175
177
|
- templates/puppet/scripts/lookup.rb
|