| 1 |
On 11/01/2015 09:46, Tomas Mozes wrote: |
| 2 |
> On 2015-01-10 23:11, Alan McKinnon wrote: |
| 3 |
>> On 10/01/2015 21:40, Tomas Mozes wrote: |
| 4 |
>> |
| 5 |
>> |
| 6 |
>>> Ansible is a not a backup solution. You don't need to download your /etc |
| 7 |
>>> from the machines because you deploy your /etc to machines via ansible. |
| 8 |
>>> |
| 9 |
>>> I was also thinking about putting /etc in git and then deploying it but: |
| 10 |
>>> - on updates, will you update all configurations in all /etc repos? |
| 11 |
>>> - do you really want to keep all the information in git, is it |
| 12 |
>>> necessary? |
| 13 |
>> |
| 14 |
>> The set of fileS in /etc/ managed by ansible is always a strict subset |
| 15 |
>> of everything in /etc |
| 16 |
>> |
| 17 |
>> For that reason alone, it's a good idea to back up /etc anyway, |
| 18 |
>> regardless of having a CM system in place. The smallest benefit is |
| 19 |
>> knowing when things changed, by the cm SYSTEM or otherwise |
| 20 |
> |
| 21 |
> For what reason? |
| 22 |
|
| 23 |
For the simple reason that ansible is not the only system that can make |
| 24 |
changes in /etc |
| 25 |
|
| 26 |
> And how does a workflow look like then? You commit changes to your git |
| 27 |
> repo of ansible. Then you deploy via ansible and check the /etc of each |
| 28 |
> machine and commit a message that you changed something via ansible? |
| 29 |
|
| 30 |
|
| 31 |
When you commit to the ansible repo, you are committing and tracking |
| 32 |
changes to the *ansible* config. You are not tracking changes to /etc on |
| 33 |
the actual destination host, that is a separate problem altogether and |
| 34 |
not directly related to the fact that ansible logs in and does various |
| 35 |
stuff. |
| 36 |
|
| 37 |
You can make your workflow whatever makes sense to you. |
| 38 |
|
| 39 |
The reason I'm recommending to keep all of /etc in it's own repo is that |
| 40 |
it's the simplest way to do it. /etc/ is a large mixture of |
| 41 |
ansible-controlled files, sysadmin-controlled files, and other arbitrary |
| 42 |
files installed by the package manager. It's also not very big, around |
| 43 |
10M or so typically. So you *could* manually add to a repo every file |
| 44 |
you change manually, but that is error-prone and easy to forget. Simpler |
| 45 |
to just commit everything in /etc which gives you an independant record |
| 46 |
of all changes over time. Have you ever dealt with a compliance auditor? |
| 47 |
An independant change record that is separate from the CM itself is a |
| 48 |
feature that those fellows really like a lot. |
| 49 |
|
| 50 |
|
| 51 |
|
| 52 |
|
| 53 |
-- |
| 54 |
Alan McKinnon |
| 55 |
alan.mckinnon@×××××.com |
Archives