1 |
On 11/01/2015 19:41, Tomas Mozes wrote: |
2 |
> On 2015-01-11 09:22, Alan McKinnon wrote: |
3 |
>> On 11/01/2015 09:46, Tomas Mozes wrote: |
4 |
>>> On 2015-01-10 23:11, Alan McKinnon wrote: |
5 |
>>>> On 10/01/2015 21:40, Tomas Mozes wrote: |
6 |
>>>> |
7 |
>>>> |
8 |
>>>>> Ansible is a not a backup solution. You don't need to download your |
9 |
>>>>> /etc |
10 |
>>>>> from the machines because you deploy your /etc to machines via |
11 |
>>>>> ansible. |
12 |
>>>>> |
13 |
>>>>> I was also thinking about putting /etc in git and then deploying it |
14 |
>>>>> but: |
15 |
>>>>> - on updates, will you update all configurations in all /etc repos? |
16 |
>>>>> - do you really want to keep all the information in git, is it |
17 |
>>>>> necessary? |
18 |
>>>> |
19 |
>>>> The set of fileS in /etc/ managed by ansible is always a strict subset |
20 |
>>>> of everything in /etc |
21 |
>>>> |
22 |
>>>> For that reason alone, it's a good idea to back up /etc anyway, |
23 |
>>>> regardless of having a CM system in place. The smallest benefit is |
24 |
>>>> knowing when things changed, by the cm SYSTEM or otherwise |
25 |
>>> |
26 |
>>> For what reason? |
27 |
>> |
28 |
>> For the simple reason that ansible is not the only system that can make |
29 |
>> changes in /etc |
30 |
>> |
31 |
>>> And how does a workflow look like then? You commit changes to your git |
32 |
>>> repo of ansible. Then you deploy via ansible and check the /etc of each |
33 |
>>> machine and commit a message that you changed something via ansible? |
34 |
>> |
35 |
>> |
36 |
>> When you commit to the ansible repo, you are committing and tracking |
37 |
>> changes to the *ansible* config. You are not tracking changes to /etc on |
38 |
>> the actual destination host, that is a separate problem altogether and |
39 |
>> not directly related to the fact that ansible logs in and does various |
40 |
>> s |
41 |
>> |
42 |
>> You can make your workflow whatever makes sense to you. |
43 |
>> |
44 |
>> The reason I'm recommending to keep all of /etc in it's own repo is that |
45 |
>> it's the simplest way to do it. /etc/ is a large mixture of |
46 |
>> ansible-controlled files, sysadmin-controlled files, and other arbitrary |
47 |
>> files installed by the package manager. It's also not very big, around |
48 |
>> 10M or so typically. So you *could* manually add to a repo every file |
49 |
>> you change manually, but that is error-prone and easy to forget. Simpler |
50 |
>> to just commit everything in /etc which gives you an independant record |
51 |
>> of all changes over time. Have you ever dealt with a compliance auditor? |
52 |
>> An independant change record that is separate from the CM itself is a |
53 |
>> feature that those fellows really like a lot. |
54 |
> |
55 |
> Out of curiosity, "ansible-controlled files, sysadmin-controlled files" |
56 |
> means that something is managed via ansible and something is done manually? |
57 |
|
58 |
|
59 |
Yes |
60 |
|
61 |
|
62 |
> And then, /etc is not the only directory with changing files, what about |
63 |
> other directories? |
64 |
|
65 |
Do with them whatever you want, just like /etc |
66 |
|
67 |
/etc is the canonical example of something you might want to track in |
68 |
git, as a) it changes and b) it's hard to recreate. |
69 |
|
70 |
Maybe you have other directories and locations you feel the same about, |
71 |
so if you think they need tracking in git by all means go ahead and |
72 |
track them. It's your choice after all, you can do with your servers |
73 |
whatever you wish |
74 |
|
75 |
|
76 |
|
77 |
> Regarding the workflow with /etc in git vs ansible in git I was asking |
78 |
> about your concrete workflow so we can learn from it and maybe apply |
79 |
> some good practices on our servers as well. |
80 |
|
81 |
|
82 |
There isn't any workflow. |
83 |
|
84 |
Ansible does it's thing and sometimes changes stuff. |
85 |
Changes get committed to a repo however and whenever works best for you. |
86 |
Maybe it's a regular cron job, maybe it's something you remember to do |
87 |
every time you quit vi, maybe it's an ansible handler that runs at the |
88 |
end of every play. |
89 |
|
90 |
It will be almost impossible to give advice to someone else on this. |
91 |
|
92 |
|
93 |
-- |
94 |
Alan McKinnon |
95 |
alan.mckinnon@×××××.com |