1 |
On 09/01/2015 11:25, Stefan G. Weichinger wrote: |
2 |
> Am 08.01.2015 um 19:29 schrieb Alan McKinnon: |
3 |
> |
4 |
>> The directory layout in the best practice page is indeed way more than |
5 |
>> you need, it lists most of the directories in common use across a wide |
6 |
>> array of deployments. In reality you create just the directories you need. |
7 |
>> |
8 |
>> Global stuff goes in the top level (like inventory). |
9 |
>> Variables for groups and individual hosts go into suitably named files |
10 |
>> inside group_vars and host_vars. |
11 |
>> Roles have a definite structure, in practice you'll use tasks/ and |
12 |
>> templates/ a lot, everything else only when you need them. |
13 |
>> |
14 |
>> This is a good design I feel. If a file describes variables, you don't |
15 |
>> have to tag it as such or explicitly include it anywhere. Instead, files |
16 |
>> inside a *vars/ directory contain variables, the system knows when to |
17 |
>> use them based on the name of the file. It's really stunningly obvious |
18 |
>> once you train your brain to stop thinking in terms of complexity :-) |
19 |
> |
20 |
> Thanks a lot ... I spent some time with it already and learn to like it ;) |
21 |
> |
22 |
> I am nearly done with setting up an inventory file for all the customer |
23 |
> boxes I am responsible for. Just using the ad-hoc-commands is very |
24 |
> useful already! |
25 |
> |
26 |
> For example I could store the output of the "setup" module for local |
27 |
> reference ... this gives me loads of basic information. |
28 |
> |
29 |
> I know it is not a backup program but I think I could also use it to |
30 |
> rsync all the /etc directories to my ansible host? Or trigger a "git |
31 |
> push" on the remote machines to let them push their configs up to some |
32 |
> central git-repo I provide here (having /etc and the @world-file is |
33 |
> quite a good start here and then ... ). |
34 |
|
35 |
|
36 |
I think that is a perfectly valid approach, I just think of it slightly |
37 |
differently: I don't use it as a backup program, rather I think of it as |
38 |
a way to safely run the same command on multiple hosts. Whether you need |
39 |
to use git, trigger backups or add an arbitrary user doesn't matter, |
40 |
they are valid commands and ansible gives you a framework to run them |
41 |
safely on multiple hosts in parallel[1] |
42 |
|
43 |
And when you find yourself running the same ad-hoc command quite often, |
44 |
you can always fold it into a playbook proper |
45 |
|
46 |
> |
47 |
> It is also great to be able to check for let's say |
48 |
> shellshock-vulnerability by adding a playbook and running it to all/some |
49 |
> of the servers out there ... I am really starting to come up with lots |
50 |
> of ideas! |
51 |
> |
52 |
> My current use case will be more of an inventory to track all the boxes |
53 |
> ... deploying stuff out to them seems not so easy in my slightly |
54 |
> heterogeneous "zoo". But this can lead to a more standardized setup, sure. |
55 |
|
56 |
Indeed. it encourages a "cattle not pets" (google it) way of thinking. |
57 |
So your hosts may all be different, and you may end up with 10% more |
58 |
packages than you really need, but you do get a model you can keep in |
59 |
your head and be much more productive. And bill more hours :-) |
60 |
|
61 |
> |
62 |
> One question: |
63 |
> |
64 |
> As far as I see the hostname in the inventory does not have to be |
65 |
> unique? I have some firewalls out there without a proper FQDN, so there |
66 |
> are several "pfsense" lines in various groups (I have now groups in |
67 |
> there with the name of the [customer] and some of them have child groups |
68 |
> like [customer-sambas] ...). |
69 |
|
70 |
An inventory is just an .ini file, so duplicate entries don't really |
71 |
matter. IIRC later dupes just overwrite earlier ones. Internally, the |
72 |
inventory is treated as a bunch of key-value pairs and it's the key that |
73 |
ansible uses to name hosts it works with. The values tell it how to |
74 |
contact the host. |
75 |
|
76 |
What I do is list all my hosts at the top level of the inventory in some |
77 |
sensible order, and just list the names in groups below that (see the |
78 |
example below). If you don't explicitly provide an FQDN for a host, then |
79 |
ansible uses the name you gave it and tries to ssh to that name. The |
80 |
name can be something that resolves in DNS, something in /etc/hosts, or |
81 |
an IP address, just like using ssh (as it really is ssh doing the hard |
82 |
work under the hood) |
83 |
|
84 |
|
85 |
> I would like to be able to also access all the ipfires or sambas in |
86 |
> another group ... so I would have to list them again in that group |
87 |
> [ipfires] ? |
88 |
|
89 |
Yes. If the playbook says to run the play against a group, then you list |
90 |
each host in the group. You can also make groups of groups so it's quite |
91 |
easy to come up with a scheme that suits your setup. |
92 |
|
93 |
Here's a piece of my inventory to illustrate: |
94 |
|
95 |
|
96 |
# List all workstations here, including the ansible_* variables |
97 |
# Assign each host to the relevant groups below |
98 |
aadil-wks ansible_ssh_host=192.168.1.84 |
99 |
brandon-wks ansible_ssh_host=192.168.1.100 |
100 |
carmen-wks ansible_ssh_host=192.168.1.146 |
101 |
|
102 |
# List all servers here, including the ansible_* variables |
103 |
# Assign each host to the relevant groups below |
104 |
ppm-db-0 ansible_ssh_host=192.168.0.16 |
105 |
ppm-mail-0 ansible_ssh_host=192.168.0.14 |
106 |
ppm-preprod-0 ansible_ssh_host=192.168.0.12 |
107 |
ppm-www-0 ansible_ssh_host=192.168.0.20 |
108 |
|
109 |
[accounts-workstations] |
110 |
aadil-wks |
111 |
carmen-wks |
112 |
|
113 |
[support-workstations] |
114 |
brandon-wks |
115 |
|
116 |
[web-servers] |
117 |
ppm-www-0 |
118 |
|
119 |
[mysql-servers] |
120 |
ppm-db-0 |
121 |
|
122 |
[workstations:children] |
123 |
accounts-workstations |
124 |
support-workstations |
125 |
|
126 |
[servers:children] |
127 |
web-servers |
128 |
mysql-servers |
129 |
|
130 |
|
131 |
|
132 |
|
133 |
|
134 |
|
135 |
Basically, you call each host by any name that makes sense and group |
136 |
them how you want. It's the ansible_ssh_host attribute that tell ssh how |
137 |
to connect |
138 |
|
139 |
|
140 |
|
141 |
|
142 |
|
143 |
|
144 |
|
145 |
|
146 |
|
147 |
|
148 |
|
149 |
|
150 |
|
151 |
|
152 |
> |
153 |
> Thanks for the great hint to ansible, looking great so far! |
154 |
> Stefan |
155 |
|
156 |
|
157 |
|
158 |
[1] I used to use clusterssh for this, but I'm gradually shifting my |
159 |
headspace over to ansible ad-hoc commands. cssh is always impressive |
160 |
(fire off 30 xterms across 3 HD monitors, all thee newbies are terrified |
161 |
and your reputation in intact...) but ansible does remove a lot of noise |
162 |
from your vision |
163 |
|
164 |
|
165 |
-- |
166 |
Alan McKinnon |
167 |
alan.mckinnon@×××××.com |