dev-lxc 2.0.3 → 2.1.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/CHANGELOG.md +12 -0
- data/README.md +99 -363
- data/docs/adhoc_clusters.md +22 -0
- data/docs/base_containers.md +44 -0
- data/docs/configuration.md +182 -0
- data/docs/dev-lxc_version_2.md +10 -0
- data/docs/manage_multiple_clusters.md +30 -0
- data/docs/prerequisites.md +75 -0
- data/docs/usage.md +187 -0
- data/lib/dev-lxc/cli.rb +74 -0
- data/lib/dev-lxc/cluster.rb +371 -206
- data/lib/dev-lxc/version.rb +1 -1
- metadata +10 -3
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: f871a43dea58908ab84c21ed956c63585749b86c
|
4
|
+
data.tar.gz: 106896247fff4158856d8b7e7b68d855b53f856b
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 06f0045440c5d62985634e90dec1b55cf693afb51e9a3c6ed2320dd0d553d85dfdb4973e11cdaab392ba53f2acc89e334fe48cb5430eaaa32204a38b82a29eb2
|
7
|
+
data.tar.gz: 0474c7ad48397b3015cb5086260c587006d9aed88ea9abe3ee1f6bf0d5063ceceb168f268880ccf02cbdd0e51741fe1908b51b8de1d8a935d86d3d0045b25d1e
|
data/CHANGELOG.md
CHANGED
@@ -1,5 +1,17 @@
|
|
1
1
|
# dev-lxc Change Log
|
2
2
|
|
3
|
+
## 2.1.0 (2016-07-19)
|
4
|
+
|
5
|
+
* Provide ability to define Chef org for node's chef-client config
|
6
|
+
* Enable node chef-client configuration at server_type level
|
7
|
+
* Add show-config subcommand
|
8
|
+
* Enable setting mounts, ssh_keys and base_container for each server
|
9
|
+
* Add print-automate-credentials subcommand
|
10
|
+
* Add prepare-product-cache subcommand
|
11
|
+
* Add build-nodes
|
12
|
+
* Add Automate server
|
13
|
+
* Define Chef Server orgs and users to be created
|
14
|
+
|
3
15
|
## 2.0.3 (2016-06-27)
|
4
16
|
|
5
17
|
* Use "stable" package channel for chef-backend since Chef HA 2.0 has been GA released
|
data/README.md
CHANGED
@@ -1,40 +1,22 @@
|
|
1
|
-
# dev-lxc 2.0 is Available
|
2
1
|
|
3
|
-
|
2
|
+
## dev-lxc
|
4
3
|
|
5
|
-
|
6
|
-
* Genuine container snapshot management (make as many snapshots as you want)
|
7
|
-
* New "nodes" server type which auto configures nodes for a Chef Server in the same cluster
|
8
|
-
* Removed all xc-... bash functions because the new "nodes" server type replaces this functionality
|
9
|
-
* Able to build Chef Server HA 2.0 cluster using chef-backend
|
10
|
-
* Updated and simplified READMEs
|
4
|
+
dev-lxc builds and manages clusters of LXC containers and includes the ability to install and configure Chef products.
|
11
5
|
|
12
|
-
|
13
|
-
|
14
|
-
A tool for building Chef Server clusters and Chef Analytics clusters using LXC containers.
|
15
|
-
|
16
|
-
Using [ruby-lxc](https://github.com/lxc/ruby-lxc) it builds servers and optionally installs and
|
17
|
-
configures many Chef products including a standalone Chef Server or tier Chef Server cluster
|
18
|
-
composed of a backend and multiple frontends with round-robin DNS resolution.
|
19
|
-
|
20
|
-
dev-lxc also has commands to manipulate Chef node containers. For example, dev-lxc can bootstrap a
|
21
|
-
container by installing Chef Client, configuring it for a Chef Server and running a specified run_list.
|
22
|
-
|
23
|
-
The dev-lxc tool is well suited as a tool for support related work, customized cluster builds
|
24
|
-
for demo purposes, as well as general experimentation and exploration of Chef products
|
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.
|
25
7
|
|
26
8
|
### Features
|
27
9
|
|
28
10
|
1. LXC 2.0 Containers - Resource efficient servers with fast start/stop times and standard init
|
29
|
-
2. Btrfs - Efficient, persistent storage backend provides fast, lightweight container
|
11
|
+
2. Btrfs - Efficient, persistent storage backend provides fast, lightweight container snapshots
|
30
12
|
3. Dnsmasq - DHCP networking and DNS resolution
|
31
13
|
4. Base Containers - Containers that are built to resemble a traditional server
|
32
14
|
5. ruby-lxc - Ruby bindings for liblxc
|
33
|
-
6. YAML - Simple,
|
15
|
+
6. YAML - Simple, flexible definition of clusters
|
34
16
|
7. Build process closely follows online installation documentation
|
35
17
|
8. Snapshots - Snapshots are created during the cluster's build process which makes rebuilding
|
36
18
|
a cluster very fast.
|
37
|
-
9. mixlib-install library
|
19
|
+
9. mixlib-install library - Automatically manages a cache of Chef products
|
38
20
|
|
39
21
|
Its containers, standard init, networking and build process are designed to be similar
|
40
22
|
to what you would build if you follow the online installation documentation so the end
|
@@ -48,26 +30,27 @@ If you aren't familiar with using containers please read this introduction.
|
|
48
30
|
|
49
31
|
[LXC 1.0 Introduction](https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/)
|
50
32
|
|
51
|
-
|
33
|
+
### Requirements
|
52
34
|
|
53
|
-
*
|
35
|
+
* Please follow the [Prerequisite Instructions](docs/prerequisites.md)
|
54
36
|
|
55
|
-
|
56
|
-
[dev-lxc-platform](https://github.com/jeremiahsnapp/dev-lxc-platform).
|
37
|
+
When you are done with the prerequisites you should be able to log into the dev-lxc-platform VM and start using it.
|
57
38
|
|
58
|
-
|
39
|
+
You must login to the root user to use the dev-lxc command.
|
59
40
|
|
60
|
-
|
61
|
-
|
62
|
-
|
63
|
-
|
64
|
-
|
41
|
+
```
|
42
|
+
cd dev-lxc-platform
|
43
|
+
vagrant ssh
|
44
|
+
sudo -i
|
45
|
+
```
|
65
46
|
|
66
|
-
|
47
|
+
### Update dev-lxc gem
|
67
48
|
|
68
|
-
Run
|
49
|
+
Run the following command if you ever need to upgrade the dev-lxc gem inside the dev-lxc-platform VM.
|
69
50
|
|
70
|
-
|
51
|
+
```
|
52
|
+
chef gem update dev-lxc
|
53
|
+
```
|
71
54
|
|
72
55
|
### Display Help
|
73
56
|
|
@@ -77,10 +60,9 @@ dev-lxc help
|
|
77
60
|
dev-lxc help <subcommand>
|
78
61
|
```
|
79
62
|
|
80
|
-
###
|
63
|
+
### dev-lxc Alias and Subcommands
|
81
64
|
|
82
|
-
The dev-lxc
|
83
|
-
for most instructions this README will use `dev-lxc` for clarity.
|
65
|
+
The dev-lxc command has a `dl` alias for ease of use.
|
84
66
|
|
85
67
|
You only have to type enough of a `dev-lxc` subcommand to make it unique.
|
86
68
|
|
@@ -96,428 +78,182 @@ dev-lxc snapshot
|
|
96
78
|
dl sn
|
97
79
|
```
|
98
80
|
|
99
|
-
###
|
100
|
-
|
101
|
-
The container that is used as the base container for a cluster's containers must exist before
|
102
|
-
the cluster can be built. The cluster's containers are cloned from the base container using
|
103
|
-
the btrfs filesystem to very quickly provide a lightweight duplicate of the container.
|
104
|
-
|
105
|
-
This container provides the chosen OS platform and version (e.g. b-ubuntu-1404).
|
106
|
-
|
107
|
-
A typical LXC container has minimal packages installed so `dev-lxc` makes sure that the
|
108
|
-
same packages used in Chef's [bento boxes](https://github.com/opscode/bento) are
|
109
|
-
installed to provide a more typical server environment.
|
110
|
-
A few additional packages are also installed.
|
111
|
-
|
112
|
-
Base containers have openssh-server installed and running with unique SSH Host Keys.
|
113
|
-
|
114
|
-
Base containers have a "dev-lxc" user with "dev-lxc" password and passwordless sudo.
|
115
|
-
|
116
|
-
*Once this base container is created there is rarely a need to delete it.*
|
117
|
-
|
118
|
-
### Create a dev-lxc Base Container
|
119
|
-
|
120
|
-
dev-lxc is able to create base containers that have openssh-server installed and running with unique SSH Host Keys.
|
121
|
-
|
122
|
-
dev-lxc base containers have a "dev-lxc" user with "dev-lxc" password and passwordless sudo.
|
123
|
-
|
124
|
-
You can see a menu of base containers that `dev-lxc` can create by using the following command.
|
125
|
-
|
126
|
-
```
|
127
|
-
dev-lxc create-base-container
|
128
|
-
```
|
129
|
-
|
130
|
-
The initial creation of base containers can take awhile so let's go ahead and start creating
|
131
|
-
an Ubuntu 14.04 container now.
|
132
|
-
|
133
|
-
```
|
134
|
-
dev-lxc create-base-container b-ubuntu-1404
|
135
|
-
```
|
136
|
-
|
137
|
-
Note: It is possible to pass additional arguments to the underlying LXC create command.
|
138
|
-
For example:
|
139
|
-
|
140
|
-
```
|
141
|
-
dev-lxc create-base-container b-ubuntu-1404 -o -- '--no-validate --keyserver http://my.key.server.com'
|
142
|
-
```
|
143
|
-
|
144
|
-
### dev-lxc.yml Config Files
|
145
|
-
|
146
|
-
dev-lxc uses a YAML configuration file named `dev-lxc.yml` to define a cluster.
|
147
|
-
|
148
|
-
The `init` command generates sample config files for various server types.
|
149
|
-
|
150
|
-
Let's generate a config for a Chef Server tier topology with one backend and one frontend
|
151
|
-
along with an Analytics Server, Supermarket Server and a node server.
|
152
|
-
|
153
|
-
```
|
154
|
-
dev-lxc init --chef-tier --analytics --supermarket --nodes > dev-lxc.yml
|
155
|
-
```
|
156
|
-
|
157
|
-
The contents of `dev-lxc.yml` should look like this.
|
158
|
-
|
159
|
-
```
|
160
|
-
# base_container must be the name of an existing container
|
161
|
-
base_container: b-ubuntu-1404
|
162
|
-
|
163
|
-
# list any host directories you want mounted into the servers
|
164
|
-
#mounts:
|
165
|
-
# - /root/dev root/dev
|
166
|
-
|
167
|
-
# list any SSH public keys you want added to /home/dev-lxc/.ssh/authorized_keys
|
168
|
-
#ssh-keys:
|
169
|
-
# - /root/dev/clusters/id_rsa.pub
|
170
|
-
|
171
|
-
# DHCP reserved (static) IPs must be selected from the IP range 10.0.3.150 - 254
|
172
|
-
|
173
|
-
chef-server:
|
174
|
-
servers:
|
175
|
-
chef.lxc:
|
176
|
-
ipaddress: 10.0.3.203
|
177
|
-
products:
|
178
|
-
chef-server:
|
179
|
-
manage:
|
180
|
-
push-jobs-server:
|
181
|
-
reporting:
|
182
|
-
|
183
|
-
analytics:
|
184
|
-
servers:
|
185
|
-
analytics.lxc:
|
186
|
-
ipaddress: 10.0.3.204
|
187
|
-
products:
|
188
|
-
analytics:
|
189
|
-
|
190
|
-
supermarket:
|
191
|
-
servers:
|
192
|
-
supermarket.lxc:
|
193
|
-
ipaddress: 10.0.3.206
|
194
|
-
products:
|
195
|
-
supermarket:
|
196
|
-
|
197
|
-
nodes:
|
198
|
-
servers:
|
199
|
-
node-1.lxc:
|
200
|
-
products:
|
201
|
-
chef:
|
202
|
-
```
|
203
|
-
|
204
|
-
The dev-lxc.yml config file is very customizable. You can add or remove mounts, products or servers,
|
205
|
-
change ip addresses, server names, the base_container and more.
|
206
|
-
|
207
|
-
As you can see there are four server types represented by five servers.
|
208
|
-
|
209
|
-
1. chef-server - chef.lxc
|
210
|
-
2. analytics - analytics.lxc
|
211
|
-
3. supermarket - supermarket.lxc
|
212
|
-
4. nodes - node-1.lxc
|
81
|
+
### Demo: Build Chef Automate Cluster
|
213
82
|
|
214
|
-
|
215
|
-
|
216
|
-
The global settings used by each of the server types are the `base_container`, a list of `mounts` and
|
217
|
-
a list of `ssh-keys`. These settings are described in the config comments.
|
218
|
-
|
219
|
-
Be sure to set `base_container` in the `dev-lxc.yml` to an existing container's name.
|
220
|
-
This container will be cloned to create each container in the cluster.
|
221
|
-
If you don't already have a container to use as a `base_container` then you can follow the instructions in the
|
222
|
-
[Create a dev-lxc Base Container section](https://github.com/jeremiahsnapp/dev-lxc#create-a-dev-lxc-base-container) to create one.
|
223
|
-
|
224
|
-
#### Server Specific Settings
|
225
|
-
|
226
|
-
It is possible to define different values for `base_container`, `mounts` or `ssh-keys` for a particular server type as
|
227
|
-
you can see in the following snippet.
|
83
|
+
Log into the dev-lxc-platform VM's root user.
|
228
84
|
|
229
85
|
```
|
230
|
-
|
231
|
-
|
232
|
-
|
233
|
-
|
86
|
+
cd dev-lxc-platform
|
87
|
+
vagrant up # if the VM is not already running
|
88
|
+
vagrant ssh
|
89
|
+
sudo -i
|
234
90
|
```
|
235
91
|
|
236
|
-
|
237
|
-
is not specified then a dynamic IP address is assigned when the server starts.
|
92
|
+
When you are logged in as the root user you should automatically enter a [byobu session](http://byobu.co/).
|
238
93
|
|
239
|
-
|
94
|
+
Byobu makes it easy to manage multiple terminal windows and panes. You can press `fn-F1` to get help which includes a [list of keybindings](http://manpages.ubuntu.com/manpages/wily/en/man1/byobu.1.html#contenttoc8).
|
240
95
|
|
241
|
-
|
242
|
-
to a cache in `/var/dev-lxc` in the host VM. This cache is automatically mounted into each server when it starts.
|
96
|
+
Some of the keys that will be most useful to you are:
|
243
97
|
|
244
|
-
|
245
|
-
|
98
|
+
* `option-Up`, `option-Down` to switch between Byobu sessions
|
99
|
+
* `option-Left`, `option-Right` to switch between windows in a session
|
100
|
+
* `shift-Left`, `shift-Right`, `shift-Up`, `shift-Down` to switch between panes in a window
|
246
101
|
|
247
|
-
|
102
|
+
#### Create Base Container
|
248
103
|
|
249
|
-
|
250
|
-
Version can be `latest` or a version number with `latest` as the default.
|
251
|
-
|
252
|
-
For example, the following specifies the `current` channel and version `0.16.1` of the `chefdk` product.
|
104
|
+
The [base container](docs/base_containers.md) used for the cluster's containers must be created first. Let's use Ubuntu 14.04 for the base container.
|
253
105
|
|
254
106
|
```
|
255
|
-
|
256
|
-
servers:
|
257
|
-
node-1.lxc:
|
258
|
-
products:
|
259
|
-
chefdk:
|
260
|
-
channel: current
|
261
|
-
version: 0.16.1
|
107
|
+
dl create b-ubuntu-1404
|
262
108
|
```
|
263
109
|
|
264
|
-
|
110
|
+
#### Create Config File
|
265
111
|
|
266
|
-
|
267
|
-
nodes:
|
268
|
-
servers:
|
269
|
-
node-1.lxc:
|
270
|
-
products:
|
271
|
-
chefdk:
|
272
|
-
package_source: /root/chefdk_0.16.1-1_amd64.deb
|
273
|
-
```
|
112
|
+
Create the [dev-lxc.yml config file](docs/configuration.md) for the cluster.
|
274
113
|
|
275
|
-
|
276
|
-
|
277
|
-
dev-lxc knows how to automatically configure Chef Server standalone, Chef Server tier topology,
|
278
|
-
Chef Server HA 2.0 as well as Chef Client, Analytics, Compliance and Supermarket.
|
279
|
-
|
280
|
-
If an Analytics server or Supermarket server is defined in the same config file as
|
281
|
-
a Chef Server then each server will automatically be integrated with that Chef Server.
|
282
|
-
|
283
|
-
If a node server with Chef Client or Chef DK installed is defined in the same config file as
|
284
|
-
a Chef Server then the Chef Client will automatically be configured to use that Chef Server.
|
285
|
-
|
286
|
-
Alternatively, values for `chef_server_url`, `validation_client_name` and `validation_key` can
|
287
|
-
be set in the config file.
|
114
|
+
First, create an arbitrary directory to hold the dev-lxc.yml file.
|
288
115
|
|
289
116
|
```
|
290
|
-
|
291
|
-
servers:
|
292
|
-
node-1.lxc:
|
293
|
-
chef_server_url: https://api.chef.io/organizations/demo
|
294
|
-
validation_client_name: demo-validator
|
295
|
-
validation_key: /hosted-chef/chef-repo/.chef/demo-validator.pem
|
296
|
-
products:
|
297
|
-
chef:
|
117
|
+
mkdir -p /root/dev/clusters/automate
|
298
118
|
```
|
299
119
|
|
300
|
-
|
120
|
+
Then use the `init` subcommand to generate a sample configuration using the available options. Run `dl help init` to see what options are available.
|
301
121
|
|
302
|
-
|
122
|
+
The following command configures a standalone Chef Server, a Chef Automate server and a build node.
|
303
123
|
|
304
124
|
```
|
305
|
-
dev-lxc
|
125
|
+
dl init --chef --automate --build-nodes -f /root/dev/clusters/automate/dev-lxc.yml
|
306
126
|
```
|
307
127
|
|
308
|
-
|
128
|
+
We can easily append additional configurations to this file. For example, the following command appends an infrastructure node.
|
309
129
|
|
310
130
|
```
|
311
|
-
|
312
|
-
|
313
|
-
analytics.lxc NOT_CREATED
|
314
|
-
|
315
|
-
supermarket.lxc NOT_CREATED
|
316
|
-
|
317
|
-
node-1.lxc NOT_CREATED
|
131
|
+
dl init --nodes -a -f /root/dev/clusters/automate/dev-lxc.yml
|
318
132
|
```
|
319
133
|
|
320
|
-
|
134
|
+
Edit the dev-lxc.yml file:
|
321
135
|
|
322
|
-
|
323
|
-
|
136
|
+
* Delete the `reporting` product from the Chef Server config since we will be using Chef Automate's Visibility.
|
137
|
+
* Set the Automate server's `license_path` value to the location of your license file.
|
138
|
+
* (Optionally) Modify the server names to make them [unique from other clusters](docs/manage_multiple_clusters.md) you may define.
|
324
139
|
|
325
|
-
|
326
|
-
creates a tmux/byobu session with the same name as the cluster's directory.
|
140
|
+
#### cluster-view
|
327
141
|
|
328
|
-
`cluster-view`
|
329
|
-
as the first argument and `cluster-view` will change to that directory before
|
330
|
-
creating the tmux/byobu session.
|
142
|
+
Run the `cluster-view` command to create a Byobu session specifically for this cluster.
|
331
143
|
|
332
144
|
The session's first window is named "cluster".
|
333
145
|
|
334
|
-
The left
|
146
|
+
The left pane is useful for running dev-lxc commands.
|
335
147
|
|
336
|
-
The right
|
148
|
+
The right pane updates every 0.5 seconds with the cluster's status provided by `dev-lxc status`.
|
337
149
|
|
338
150
|
The session's second window is named "shell". It opens in the same directory as the
|
339
|
-
cluster's `dev-lxc.yml` file.
|
151
|
+
cluster's `dev-lxc.yml` file and is useful for attaching to a server to perform system administration tasks.
|
340
152
|
|
341
|
-
|
153
|
+
See the [Usage docs](docs/usage.md) for more information about how to close/kill Byobu sessions.
|
342
154
|
|
343
|
-
|
344
|
-
|
345
|
-
|
346
|
-
`tks` is an alias for `tmux kill-session -t` and is used to kill tmux/byobu sessions.
|
347
|
-
When specifying the session to be killed you only need as many characters of the session
|
348
|
-
name that are required to make the name unique among the list of running sessions.
|
155
|
+
```
|
156
|
+
cluster-view /root/dev/clusters/automate
|
157
|
+
```
|
349
158
|
|
350
|
-
|
351
|
-
tmux/byobu session. Otherwise you will need to reattach to the remaining tmux/byobu session.
|
352
|
-
Use the keyboard shortcuts Alt-Up/Down to easily switch between tmux/byobu sessions.
|
159
|
+
#### Specifying a Subset of Servers
|
353
160
|
|
354
|
-
|
161
|
+
Many dev-lxc subcommands can act on a subset of the cluster's servers by specifying a regular expression that matches the desired server names.
|
355
162
|
|
356
|
-
|
163
|
+
For example, the following command will show the status of the build node and the infrastructure node.
|
357
164
|
|
358
165
|
```
|
359
|
-
|
166
|
+
dl status node
|
360
167
|
```
|
361
168
|
|
362
|
-
|
363
|
-
the bootstrap backend server in `/root/chef-repo/.chef` for testing purposes.
|
364
|
-
|
365
|
-
The `knife-opc` plugin is installed in the embedded ruby environment of the
|
366
|
-
Private Chef and Enterprise Chef server to facilitate the creation of the test
|
367
|
-
org and user.
|
368
|
-
|
369
|
-
### Create chef-repo
|
169
|
+
#### Build the Cluster
|
370
170
|
|
371
|
-
|
171
|
+
dev-lxc knows to build the servers in an appropriate order.
|
372
172
|
|
373
|
-
|
173
|
+
It downloads the product packages to a cache location and installs the packages in each server.
|
374
174
|
|
375
|
-
|
175
|
+
It configures each product and creates necessary things such as Chef organizations and users as needed.
|
376
176
|
|
377
177
|
```
|
378
|
-
|
178
|
+
dl up
|
379
179
|
```
|
380
180
|
|
381
|
-
|
181
|
+
Note: You also have the option of running the `prepare-product-cache` subcommand which downloads required product packages to the cache.
|
182
|
+
This can be helpful when you don't want to start building the cluster yet but you want the package cache ready when you build the cluster later.
|
382
183
|
|
383
|
-
|
384
|
-
cd chef-repo
|
385
|
-
knife client list
|
386
|
-
```
|
184
|
+
#### Use the Servers
|
387
185
|
|
388
|
-
|
186
|
+
At this point all of the cluster's servers should be running.
|
389
187
|
|
390
|
-
|
391
|
-
dev-lxc halt
|
392
|
-
dev-lxc up
|
393
|
-
```
|
188
|
+
If you setup the workstation's networking correctly as described in the prerequisites you should be able to ping any server from your workstation using it's FQDN. You can also browse to any server that has a web interface.
|
394
189
|
|
395
|
-
|
190
|
+
Since the cluster has a Chef Server you can use the `chef-repo` subcommand to create a chef-repo directory in the VM 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.
|
396
191
|
|
397
192
|
```
|
398
|
-
|
193
|
+
dl chef
|
194
|
+
cd chef-repo
|
195
|
+
knife client list
|
196
|
+
cd ..
|
399
197
|
```
|
400
198
|
|
401
|
-
|
402
|
-
|
403
|
-
Attach the terminal to a server in the cluster that matches the REGEX pattern given.
|
199
|
+
Since the cluster has a Chef Automate server you can use the `print-automate-credentials` subcommand to see what the login credentials.
|
404
200
|
|
405
201
|
```
|
406
|
-
|
202
|
+
dl print
|
407
203
|
```
|
408
204
|
|
409
|
-
|
205
|
+
You can use the `attach` subcommand to login to the root user of a server.
|
410
206
|
|
411
|
-
|
207
|
+
For example, the following command should attach to the Chef Server.
|
412
208
|
|
413
209
|
```
|
414
|
-
|
415
|
-
dev-lxc snapshot -c 'this is a snapshot comment'
|
210
|
+
dl at chef
|
416
211
|
```
|
417
212
|
|
418
|
-
|
419
|
-
|
420
|
-
```
|
421
|
-
dev-lxc snapshot -l
|
422
|
-
```
|
213
|
+
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.
|
423
214
|
|
424
|
-
|
215
|
+
#### Manage the Cluster
|
425
216
|
|
426
|
-
|
217
|
+
The right pane of the "cluster" window should show `dev-lxc status` output. This shows the status of each server including any existing snapshots.
|
427
218
|
|
428
|
-
|
219
|
+
It is recommended that you stop the servers before restoring or creating snapshots.
|
429
220
|
|
430
221
|
```
|
431
|
-
|
432
|
-
dev-lxc up
|
222
|
+
dl halt
|
433
223
|
```
|
434
224
|
|
435
|
-
|
436
|
-
|
437
|
-
Destroy snapshots by name or destroy all snapshots by specifying `ALL`.
|
438
|
-
|
439
|
-
Leave out the snapshot name or specify `LAST` to destroy the most recent snapshots.
|
225
|
+
You can restore the most recent snapshot of all the servers.
|
440
226
|
|
441
227
|
```
|
442
|
-
|
228
|
+
dl sn -r
|
443
229
|
```
|
444
230
|
|
445
|
-
|
231
|
+
You could also restore a specific snapshot by name if you desire.
|
446
232
|
|
447
|
-
|
233
|
+
For example, you could restore the Chef Automate server to the state right after its package was installed but before it was configured.
|
448
234
|
|
449
235
|
```
|
450
|
-
|
236
|
+
dl sn automate -r snap0
|
451
237
|
```
|
452
238
|
|
453
|
-
|
454
|
-
You can also run most of these commands against a set of servers by specifying a regular expression
|
455
|
-
that matches a set of server names.
|
239
|
+
You can create snapshots with or without a comment.
|
456
240
|
|
457
241
|
```
|
458
|
-
|
242
|
+
dl sn -c 'Demo snapshot'
|
459
243
|
```
|
460
244
|
|
461
|
-
|
245
|
+
You can destroy snapshots.
|
462
246
|
|
463
247
|
```
|
464
|
-
|
248
|
+
dl sn -d snap2
|
465
249
|
```
|
466
250
|
|
467
|
-
|
468
|
-
|
469
|
-
dev-lxc can also manage an adhoc cluster of servers.
|
470
|
-
|
471
|
-
An adhoc cluster is just a set of managed servers cloned from the specified base
|
472
|
-
container. The servers have SSH server running, a "dev-lxc" user with "dev-lxc" password and
|
473
|
-
passwordless sudo access.
|
474
|
-
|
475
|
-
This is particularly useful when you want to use something else, such as chef-provisioning,
|
476
|
-
to configure the servers.
|
477
|
-
|
478
|
-
The number of servers, their names and their IP addresses can be changed to fit your
|
479
|
-
particular requirements.
|
251
|
+
And finally you can destroy the servers and there snapshots.
|
480
252
|
|
481
253
|
```
|
482
|
-
|
483
|
-
cd /root/dev/clusters/delivery
|
484
|
-
dev-lxc init --adhoc > dev-lxc.yml
|
485
|
-
# edit dev-lxc.yml to have enough adhoc servers for a delivery cluster
|
486
|
-
cluster-view
|
487
|
-
dl up
|
254
|
+
dl d
|
488
255
|
```
|
489
256
|
|
490
|
-
### Maintain Uniqueness Across Multiple Clusters
|
491
|
-
|
492
|
-
The default cluster configs are already designed to be unique from each other but as you build
|
493
|
-
more clusters you have to maintain uniqueness across the YAML config files for the following items.
|
494
|
-
|
495
|
-
* Server names, `api_fqdn` and `analytics_fqdn`
|
496
|
-
|
497
|
-
Server names should really be unique across all clusters.
|
498
|
-
|
499
|
-
Even when cluster A is shutdown, if cluster B uses the same server names when it is created it
|
500
|
-
will use the already existing servers from cluster A.
|
501
|
-
|
502
|
-
`api_fqdn` and `analytics_fqdn` uniqueness only matters when clusters with the same `api_fqdn`
|
503
|
-
and `analytics_fqdn` are running.
|
504
|
-
|
505
|
-
If cluster B is started with the same `api_fqdn` or `analytics_fqdn` as an already running cluster A,
|
506
|
-
then cluster B will overwrite cluster A's DNS resolution of `api_fqdn` or `analytics_fqdn`.
|
507
|
-
|
508
|
-
* IP Addresses
|
509
|
-
|
510
|
-
IP addresses uniqueness only matters when clusters with the same IP's are running.
|
511
|
-
|
512
|
-
If cluster B is started with the same IP's as an already running cluster A, then cluster B
|
513
|
-
will overwrite cluster A's DHCP reservation of the IP's but dnsmasq will still refuse to
|
514
|
-
assign the IP's to cluster B because they already in use by cluster A. dnsmasq then assigns
|
515
|
-
random IP's from the DHCP pool to cluster B leaving it in an unexpected state.
|
516
|
-
|
517
|
-
The `dev-lxc-platform` creates the IP range 10.0.3.150 - 254 for DHCP reserved IP's.
|
518
|
-
|
519
|
-
Use unique IP's from that range when configuring clusters.
|
520
|
-
|
521
257
|
## Contributing
|
522
258
|
|
523
259
|
1. Fork it
|
@@ -0,0 +1,22 @@
|
|
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/dev/clusters/delivery
|
17
|
+
cd /root/dev/clusters/delivery
|
18
|
+
dev-lxc init --adhoc > dev-lxc.yml
|
19
|
+
# edit dev-lxc.yml to have enough adhoc servers for a delivery cluster
|
20
|
+
cluster-view
|
21
|
+
dl up
|
22
|
+
```
|