dev-lxc 3.2.0 → 3.3.0

Sign up to get free protection for your applications and to get access to all the features.
data/README.md CHANGED
@@ -1,233 +1,235 @@
1
-
2
- ## dev-lxc
3
-
4
- dev-lxc builds and manages clusters of LXC containers and includes the ability to install and configure Chef products.
5
-
6
- Cluster management includes the ability to manage snapshots of the containers which makes dev-lxc well suited as a tool for support related work, customized cluster builds for demo purposes, as well as general experimentation and exploration.
7
-
8
- ### Features
9
-
10
- 1. LXC Containers - Resource efficient servers with fast start/stop times and standard init
11
- 2. Btrfs - Efficient, persistent storage backend provides fast, lightweight container snapshots
12
- 3. Dnsmasq - DHCP networking and DNS resolution
13
- 4. Base Containers - Containers that are built to resemble a traditional server
14
- 5. ruby-lxc - Ruby bindings for liblxc
15
- 6. YAML - Simple, flexible definition of clusters
16
- 7. Build process closely follows online installation documentation
17
- 8. Snapshots - Snapshots are created during the cluster's build process which makes rebuilding
18
- a cluster very fast.
19
- 9. mixlib-install library - Automatically manages a cache of Chef products
20
-
21
- Its containers, standard init, networking and build process are designed to be similar
22
- to what you would build if you follow the online installation documentation so the end
23
- result is a cluster that is relatively similar to a more traditionally built cluster.
24
-
25
- The Btrfs backed snapshots provide a quick clean slate which is helpful especially for
26
- experimenting and troubleshooting. Or it can be used to build a customized cluster
27
- for demo purposes and be able to bring it up quickly and reliably.
28
-
29
- If you aren't familiar with using containers you might be interested in this introduction.
30
-
31
- [LXC 1.0 Introduction](https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/)
32
-
33
- Additional dev-lxc related documentation can be found in the [docs folder](docs) in this repository.
34
-
35
- ## Build dev-lxc-platform instance
36
-
37
- The dev-lxc tool is used in a system that has been configured by the dev-lxc-platform cookbook.
38
-
39
- The easiest way to build a dev-lxc-platform system is to download the dev-lxc-platform repository
40
- and use Test Kitchen to build an AWS EC2 instance or a VirtualBox Vagrant instance.
41
-
42
- Follow the instructions in the [dev-lxc-platform README](https://github.com/jeremiahsnapp/dev-lxc-platform) to build
43
- a dev-lxc-platform instance. It takes about 7 minutes to build the dev-lxc-platform instance.
44
-
45
- ## Login to the dev-lxc-platform instance
46
-
47
- Login to the dev-lxc-platform instance and switch to the root user to use the dev-lxc tool.
48
-
49
- ```
50
- cd dev-lxc-platform
51
- kitchen login <ec2 or vagrant>
52
- sudo -i
53
- ```
54
-
55
- When you are logged in as the root user you should automatically enter a [byobu session](http://byobu.co/).
56
-
57
- See [byobu keybindings](docs/byobu_keybindings.md) to learn some byobu basics.
58
-
59
- ## Update dev-lxc gem
60
-
61
- Run the following command as the instance's root user if you ever need to upgrade the dev-lxc gem inside the dev-lxc-platform instance.
62
-
63
- ```
64
- cd dev-lxc-platform
65
- kitchen login <ec2 or vagrant>
66
- sudo -i
67
- chef gem update dev-lxc
68
- ```
69
-
70
- ## dl Command and Subcommands
71
-
72
- `dl` is the dev-lxc command line tool.
73
-
74
- `dl` subcommands and some options can be auto-completed by pressing the `Tab` key.
75
-
76
- You only have to type enough of a `dl` subcommand to make it unique.
77
-
78
- For example, the following commands are equivalent:
79
-
80
- ```
81
- dl help
82
- dl he
83
- ```
84
-
85
- ## Display dev-lxc help
86
-
87
- ```
88
- dl help
89
-
90
- dl help <subcommand>
91
- ```
92
-
93
- ## Demo: Build Chef Automate Cluster
94
-
95
- ### Create Base Container
96
-
97
- Create an Ubuntu 14.04 base container for the cluster's containers.
98
-
99
- ```
100
- dl create b-ubuntu-1404
101
- ```
102
-
103
- ### Create Config File
104
-
105
- Create a directory to hold the dev-lxc.yml file.
106
-
107
- ```
108
- mkdir -p /root/clusters/automate
109
- ```
110
-
111
- The following command creates a dev-lxc.yml file that defines a standalone Chef Server, Supermarket server, Compliance server,
112
- Chef Automate server a Job Dispatch Runner and an infrastructure node and removes the "reporting" product from the generated configuration.
113
-
114
- ```
115
- dl init --chef --compliance --supermarket --automate --runners --nodes --product-versions reporting:none > /root/clusters/automate/dev-lxc.yml
116
- ```
117
-
118
- Copy your delivery.license file to the `/root/clusters` directory.
119
-
120
- ### cluster-view
121
-
122
- Run the `cluster-view` command to create a Byobu session specifically for this cluster.
123
-
124
- ```
125
- cluster-view /root/clusters/automate
126
- ```
127
-
128
- The session's first window is named "cluster".
129
-
130
- The left pane is useful for running dev-lxc commands.
131
-
132
- The right pane updates every 0.5 seconds with the cluster's status provided by `dl status`.
133
-
134
- The session's second window is named "shell". It opens in the same directory as the
135
- cluster's `dev-lxc.yml` file and is useful for attaching to a server to perform system administration tasks.
136
-
137
- See the [usage docs](docs/usage.md) for more information about how to close/kill Byobu sessions.
138
-
139
- ### Build the Cluster
140
-
141
- ```
142
- dl up
143
- ```
144
-
145
- ### Use the Servers
146
-
147
- At this point all of the cluster's servers should be running.
148
-
149
- Since the cluster has a Chef Server and an infrastructure node dev-lxc made sure it configured the node's chef-client for the Chef Server so it is easy to converge the node.
150
-
151
- You can use the `attach` subcommand to login to a server as the root user.
152
-
153
- For example, the following commands should attach to node-1.lxc, start a chef-client run and exit the node.
154
-
155
- ```
156
- dl attach node
157
- chef-client
158
- exit
159
- ```
160
-
161
- Since the cluster has a Chef Server you can use the `chef-repo` subcommand to create a `.chef` directory in the host instance that contains a knife.rb and all of the keys for the users and org validator clients that are defined in dev-lxc.yml. This makes it very easy to use tools such as knife or berkshelf.
162
-
163
- ```
164
- dl chef-repo
165
- # set `username` to `mary-admin` and `orgname` to `demo` in `.chef/knife.rb`
166
- knife client list
167
- ```
168
-
169
- Since the cluster has a Chef Automate server you can use the `print-automate-credentials` subcommand to see the login credentials.
170
-
171
- ```
172
- dl print
173
- ```
174
-
175
- If you enabled local port forwarding for port 8888 in your workstation's SSH config file and configured your web browser to use `127.0.0.1:8888` for HTTP and HTTPS proxies as described in the [dev-lxc-platform README.md](https://github.com/jeremiahsnapp/dev-lxc-platform#accessing-the-containers-using-a-web-proxy) then you should be able to browse from your workstation to any server that has a web interface using its FQDN.
176
-
177
- For example, browse to https://automate.lxc and login with the credentials provided by `dl print-automate-credentials`.
178
-
179
- ### Manage the Cluster
180
-
181
- Let's stop the servers before restoring and creating snapshots.
182
-
183
- ```
184
- dl halt
185
- ```
186
-
187
- You can restore a specific snapshot by name if you desire.
188
-
189
- For example, the following command restores the Chef Automate server to the state right after its package was installed but before it was configured.
190
-
191
- ```
192
- dl snapshot automate -r snap0
193
- ```
194
-
195
- You can restore the most recent snapshot of all the servers.
196
-
197
- ```
198
- dl snapshot -r
199
- ```
200
-
201
- You can create snapshots with or without a comment.
202
-
203
- ```
204
- dl snapshot -c 'Demo snapshot'
205
- ```
206
-
207
- You can destroy snapshots.
208
-
209
- ```
210
- dl snapshot -d snap2
211
- ```
212
-
213
- Generally speaking, a cluster can be reused for a long time especially since snapshots easily allow you to restore the cluster to its initial build state. However, if you really want to destroy the servers and their snapshots you can use the `destroy` subcommand.
214
-
215
- ```
216
- dl destroy
217
- ```
218
-
219
- ## More Documentation
220
-
221
- For more in-depth documentation please see the pages in the [docs folder](docs).
222
-
223
- ## Example dev-lxc.yml files
224
-
225
- See the files in [example-clusters](example-clusters).
226
-
227
- ## Contributing
228
-
229
- 1. Fork it
230
- 2. Create your feature branch (`git checkout -b my-new-feature`)
231
- 3. Commit your changes (`git commit -am 'Add some feature'`)
232
- 4. Push to the branch (`git push origin my-new-feature`)
233
- 5. Create new Pull Request
1
+
2
+ ## dev-lxc
3
+
4
+ dev-lxc builds and manages clusters of LXC containers and includes the ability to install and configure Chef products.
5
+
6
+ Cluster management includes the ability to manage snapshots of the containers which makes dev-lxc well suited as a tool for support related work, customized cluster builds for demo purposes, as well as general experimentation and exploration.
7
+
8
+ ### Features
9
+
10
+ 1. LXC Containers - Resource efficient servers with fast start/stop times and standard init
11
+ 2. Btrfs - Efficient, persistent storage backend provides fast, lightweight container snapshots
12
+ 3. Dnsmasq - DHCP networking and DNS resolution
13
+ 4. Base Containers - Containers that are built to resemble a traditional server
14
+ 5. ruby-lxc - Ruby bindings for liblxc
15
+ 6. YAML - Simple, flexible definition of clusters
16
+ 7. Build process closely follows online installation documentation
17
+ 8. Snapshots - Snapshots are created during the cluster's build process which makes rebuilding
18
+ a cluster very fast.
19
+ 9. mixlib-install library - Automatically manages a cache of Chef products
20
+
21
+ Its containers, standard init, networking and build process are designed to be similar
22
+ to what you would build if you follow the online installation documentation so the end
23
+ result is a cluster that is relatively similar to a more traditionally built cluster.
24
+
25
+ The Btrfs backed snapshots provide a quick clean slate which is helpful especially for
26
+ experimenting and troubleshooting. Or it can be used to build a customized cluster
27
+ for demo purposes and be able to bring it up quickly and reliably.
28
+
29
+ If you aren't familiar with using containers you might be interested in this introduction.
30
+
31
+ [LXC 1.0 Introduction](https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/)
32
+
33
+ Additional dev-lxc related documentation can be found in the [docs folder](docs) in this repository.
34
+
35
+ ## Build dev-lxc-platform instance
36
+
37
+ The dev-lxc tool is used in a system that has been configured by the dev-lxc-platform cookbook.
38
+
39
+ The easiest way to build a dev-lxc-platform system is to download the dev-lxc-platform repository
40
+ and use Test Kitchen to build an AWS EC2 instance or a VirtualBox Vagrant instance.
41
+
42
+ Follow the instructions in the [dev-lxc-platform README](https://github.com/jeremiahsnapp/dev-lxc-platform) to build
43
+ a dev-lxc-platform instance. It takes about 7 minutes to build the dev-lxc-platform instance.
44
+
45
+ ## Login to the dev-lxc-platform instance
46
+
47
+ Login to the dev-lxc-platform instance and switch to the root user to use the dev-lxc tool.
48
+
49
+ ```
50
+ cd dev-lxc-platform
51
+ kitchen login <ec2 or vagrant>
52
+ sudo -i
53
+ ```
54
+
55
+ When you are logged in as the root user you should automatically enter a [byobu session](http://byobu.co/).
56
+
57
+ See [byobu keybindings](docs/byobu_keybindings.md) to learn some byobu basics.
58
+
59
+ ## Update dev-lxc gem
60
+
61
+ Run the following command as the instance's root user if you ever need to upgrade the dev-lxc gem inside the dev-lxc-platform instance.
62
+
63
+ ```
64
+ cd dev-lxc-platform
65
+ kitchen login <ec2 or vagrant>
66
+ sudo -i
67
+ chef gem update dev-lxc
68
+ ```
69
+
70
+ ## dl Command and Subcommands
71
+
72
+ `dl` is the dev-lxc command line tool.
73
+
74
+ `dl` subcommands and some options can be auto-completed by pressing the `Tab` key.
75
+
76
+ You only have to type enough of a `dl` subcommand to make it unique.
77
+
78
+ For example, the following commands are equivalent:
79
+
80
+ ```
81
+ dl help
82
+ dl he
83
+ ```
84
+
85
+ ## Display dev-lxc help
86
+
87
+ ```
88
+ dl help
89
+
90
+ dl help <subcommand>
91
+ ```
92
+
93
+ ## Demo: Build Chef Automate Cluster
94
+
95
+ Cluster build time: 19 minutes
96
+
97
+ ### Create Base Container
98
+
99
+ Create an Ubuntu 14.04 base container for the cluster's containers.
100
+
101
+ ```
102
+ dl create b-ubuntu-1404
103
+ ```
104
+
105
+ ### Create Config File
106
+
107
+ Create a directory to hold the dev-lxc.yml file.
108
+
109
+ ```
110
+ mkdir -p /root/clusters/automate
111
+ ```
112
+
113
+ The following command creates a dev-lxc.yml file that defines a standalone Chef Server, Supermarket server, Compliance server,
114
+ Chef Automate server a Job Dispatch Runner and an infrastructure node and removes the "reporting" product from the generated configuration.
115
+
116
+ ```
117
+ dl init --chef --compliance --supermarket --automate --runners --nodes --product-versions reporting:none > /root/clusters/automate/dev-lxc.yml
118
+ ```
119
+
120
+ Copy your delivery.license file to the `/root/clusters` directory.
121
+
122
+ ### cluster-view
123
+
124
+ Run the `cluster-view` command to create a Byobu session specifically for this cluster.
125
+
126
+ ```
127
+ cluster-view /root/clusters/automate
128
+ ```
129
+
130
+ The session's first window is named "cluster".
131
+
132
+ The left pane is useful for running dev-lxc commands.
133
+
134
+ The right pane updates every 0.5 seconds with the cluster's status provided by `dl status`.
135
+
136
+ The session's second window is named "shell". It opens in the same directory as the
137
+ cluster's `dev-lxc.yml` file and is useful for attaching to a server to perform system administration tasks.
138
+
139
+ See the [usage docs](docs/usage.md) for more information about how to close/kill Byobu sessions.
140
+
141
+ ### Build the Cluster
142
+
143
+ ```
144
+ dl up
145
+ ```
146
+
147
+ ### Use the Servers
148
+
149
+ At this point all of the cluster's servers should be running.
150
+
151
+ Since the cluster has a Chef Server and an infrastructure node dev-lxc made sure it configured the node's chef-client for the Chef Server so it is easy to converge the node.
152
+
153
+ You can use the `attach` subcommand to login to a server as the root user.
154
+
155
+ For example, the following commands should attach to node-1.lxc, start a chef-client run and exit the node.
156
+
157
+ ```
158
+ dl attach node
159
+ chef-client
160
+ exit
161
+ ```
162
+
163
+ Since the cluster has a Chef Server you can use the `chef-repo` subcommand to create a `.chef` directory in the host instance that contains a knife.rb and all of the keys for the users and org validator clients that are defined in dev-lxc.yml. This makes it very easy to use tools such as knife or berkshelf.
164
+
165
+ ```
166
+ dl chef-repo
167
+ # set `username` to `mary-admin` and `orgname` to `demo` in `.chef/knife.rb`
168
+ knife client list
169
+ ```
170
+
171
+ Since the cluster has a Chef Automate server you can use the `print-automate-credentials` subcommand to see the login credentials.
172
+
173
+ ```
174
+ dl print
175
+ ```
176
+
177
+ If you enabled local port forwarding for port 8888 in your workstation's SSH config file and configured your web browser to use `127.0.0.1:8888` for HTTP and HTTPS proxies as described in the [dev-lxc-platform README.md](https://github.com/jeremiahsnapp/dev-lxc-platform#accessing-the-containers-using-a-web-proxy) then you should be able to browse from your workstation to any server that has a web interface using its FQDN.
178
+
179
+ For example, browse to https://automate.lxc and login with the credentials provided by `dl print-automate-credentials`.
180
+
181
+ ### Manage the Cluster
182
+
183
+ Let's stop the servers before restoring and creating snapshots.
184
+
185
+ ```
186
+ dl halt
187
+ ```
188
+
189
+ You can restore a specific snapshot by name if you desire.
190
+
191
+ For example, the following command restores the Chef Automate server to the state right after its package was installed but before it was configured.
192
+
193
+ ```
194
+ dl snapshot automate -r snap0
195
+ ```
196
+
197
+ You can restore the most recent snapshot of all the servers.
198
+
199
+ ```
200
+ dl snapshot -r
201
+ ```
202
+
203
+ You can create snapshots with or without a comment.
204
+
205
+ ```
206
+ dl snapshot -c 'Demo snapshot'
207
+ ```
208
+
209
+ You can destroy snapshots.
210
+
211
+ ```
212
+ dl snapshot -d snap2
213
+ ```
214
+
215
+ Generally speaking, a cluster can be reused for a long time especially since snapshots easily allow you to restore the cluster to its initial build state. However, if you really want to destroy the servers and their snapshots you can use the `destroy` subcommand.
216
+
217
+ ```
218
+ dl destroy
219
+ ```
220
+
221
+ ## Example dev-lxc.yml files
222
+
223
+ See the files in [example-clusters](example-clusters).
224
+
225
+ ## More Documentation
226
+
227
+ For more in-depth documentation please see the pages in the [docs folder](docs).
228
+
229
+ ## Contributing
230
+
231
+ 1. Fork it
232
+ 2. Create your feature branch (`git checkout -b my-new-feature`)
233
+ 3. Commit your changes (`git commit -am 'Add some feature'`)
234
+ 4. Push to the branch (`git push origin my-new-feature`)
235
+ 5. Create new Pull Request
data/Rakefile CHANGED
@@ -1 +1 @@
1
- require "bundler/gem_tasks"
1
+ require "bundler/gem_tasks"
data/bin/dl CHANGED
@@ -1,9 +1,9 @@
1
- #!/usr/bin/env ruby
2
- require 'dev-lxc/cli'
3
-
4
- unless Process.uid == 0
5
- puts "ERROR: Must run as root"
6
- exit 1
7
- end
8
-
9
- DevLXC::CLI::DevLXC.start
1
+ #!/usr/bin/env ruby
2
+ require 'dev-lxc/cli'
3
+
4
+ unless Process.uid == 0
5
+ puts "ERROR: Must run as root"
6
+ exit 1
7
+ end
8
+
9
+ DevLXC::CLI::DevLXC.start
data/dev-lxc.gemspec CHANGED
@@ -1,26 +1,26 @@
1
- # coding: utf-8
2
- lib = File.expand_path('../lib', __FILE__)
3
- $LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
4
- require 'dev-lxc/version'
5
-
6
- Gem::Specification.new do |spec|
7
- spec.name = "dev-lxc"
8
- spec.version = DevLXC::VERSION
9
- spec.authors = ["Jeremiah Snapp"]
10
- spec.email = ["jeremiah@getchef.com"]
11
- spec.description = %q{A tool for building Chef server clusters using LXC containers}
12
- spec.summary = spec.description
13
- spec.licenses = "Apache2"
14
- spec.homepage = "https://github.com/jeremiahsnapp/dev-lxc"
15
-
16
- spec.files = `git ls-files`.split($/)
17
- spec.executables = spec.files.grep(%r{^bin/}) { |f| File.basename(f) }
18
- spec.test_files = spec.files.grep(%r{^(test|spec|features)/})
19
- spec.require_paths = ["lib"]
20
-
21
- spec.add_development_dependency "bundler", "~> 1.3"
22
- spec.add_development_dependency "rake", "~> 0"
23
- spec.add_runtime_dependency "mixlib-install"
24
- spec.add_runtime_dependency "thor", "~> 0"
25
- spec.add_runtime_dependency "ruby-lxc", "~> 1.2.0"
26
- end
1
+ # coding: utf-8
2
+ lib = File.expand_path('../lib', __FILE__)
3
+ $LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
4
+ require 'dev-lxc/version'
5
+
6
+ Gem::Specification.new do |spec|
7
+ spec.name = "dev-lxc"
8
+ spec.version = DevLXC::VERSION
9
+ spec.authors = ["Jeremiah Snapp"]
10
+ spec.email = ["jeremiah@getchef.com"]
11
+ spec.description = %q{A tool for building Chef server clusters using LXC containers}
12
+ spec.summary = spec.description
13
+ spec.licenses = "Apache2"
14
+ spec.homepage = "https://github.com/jeremiahsnapp/dev-lxc"
15
+
16
+ spec.files = `git ls-files`.split($/)
17
+ spec.executables = spec.files.grep(%r{^bin/}) { |f| File.basename(f) }
18
+ spec.test_files = spec.files.grep(%r{^(test|spec|features)/})
19
+ spec.require_paths = ["lib"]
20
+
21
+ spec.add_development_dependency "bundler", "~> 1.3"
22
+ spec.add_development_dependency "rake", "~> 0"
23
+ spec.add_runtime_dependency "mixlib-install"
24
+ spec.add_runtime_dependency "thor", "~> 0"
25
+ spec.add_runtime_dependency "ruby-lxc", "~> 1.2.0"
26
+ end
@@ -1,20 +1,17 @@
1
- ### Adhoc Clusters
2
-
3
- dev-lxc can also manage an adhoc cluster of servers.
4
-
5
- An adhoc cluster is just a set of managed servers cloned from the specified base
6
- container. The servers have SSH server running, a "dev-lxc" user with "dev-lxc" password and
7
- passwordless sudo access.
8
-
9
- This is particularly useful when you want to use something else, such as chef-provisioning,
10
- to configure the servers.
11
-
12
- The number of servers, their names and their IP addresses can be changed to fit your
13
- particular requirements.
14
-
15
- ```
16
- mkdir -p /root/clusters/adhoc
17
- dl init --adhoc > /root/clusters/adhoc/dev-lxc.yml
18
- cluster-view /root/clusters/adhoc
19
- dl up
20
- ```
1
+ ### Adhoc Clusters
2
+
3
+ dev-lxc can also manage an adhoc cluster of servers.
4
+
5
+ An adhoc cluster is just a set of managed servers cloned from the specified base
6
+ container. The servers have SSH server running, a "dev-lxc" user with "dev-lxc" password and
7
+ passwordless sudo access.
8
+
9
+ The number of servers, their names and their IP addresses can be changed to fit your
10
+ particular requirements.
11
+
12
+ ```
13
+ mkdir -p /root/clusters/adhoc
14
+ dl init --adhoc > /root/clusters/adhoc/dev-lxc.yml
15
+ cluster-view /root/clusters/adhoc
16
+ dl up
17
+ ```