On 11/01/2015 19:41, Tomas Mozes wrote: > On 2015-01-11 09:22, Alan McKinnon wrote: >> On 11/01/2015 09:46, Tomas Mozes wrote: >>> On 2015-01-10 23:11, Alan McKinnon wrote: >>>> On 10/01/2015 21:40, Tomas Mozes wrote: >>>> >>>> >>>>> Ansible is a not a backup solution. You don't need to download your >>>>> /etc >>>>> from the machines because you deploy your /etc to machines via >>>>> ansible. >>>>> >>>>> I was also thinking about putting /etc in git and then deploying it >>>>> but: >>>>> - on updates, will you update all configurations in all /etc repos? >>>>> - do you really want to keep all the information in git, is it >>>>> necessary? >>>> >>>> The set of fileS in /etc/ managed by ansible is always a strict subset >>>> of everything in /etc >>>> >>>> For that reason alone, it's a good idea to back up /etc anyway, >>>> regardless of having a CM system in place. The smallest benefit is >>>> knowing when things changed, by the cm SYSTEM or otherwise >>> >>> For what reason? >> >> For the simple reason that ansible is not the only system that can make >> changes in /etc >> >>> And how does a workflow look like then? You commit changes to your git >>> repo of ansible. Then you deploy via ansible and check the /etc of each >>> machine and commit a message that you changed something via ansible? >> >> >> When you commit to the ansible repo, you are committing and tracking >> changes to the *ansible* config. You are not tracking changes to /etc on >> the actual destination host, that is a separate problem altogether and >> not directly related to the fact that ansible logs in and does various >> s >> >> You can make your workflow whatever makes sense to you. >> >> The reason I'm recommending to keep all of /etc in it's own repo is that >> it's the simplest way to do it. /etc/ is a large mixture of >> ansible-controlled files, sysadmin-controlled files, and other arbitrary >> files installed by the package manager. It's also not very big, around >> 10M or so typically. So you *could* manually add to a repo every file >> you change manually, but that is error-prone and easy to forget. Simpler >> to just commit everything in /etc which gives you an independant record >> of all changes over time. Have you ever dealt with a compliance auditor? >> An independant change record that is separate from the CM itself is a >> feature that those fellows really like a lot. > > Out of curiosity, "ansible-controlled files, sysadmin-controlled files" > means that something is managed via ansible and something is done manually?
Yes > And then, /etc is not the only directory with changing files, what about > other directories? Do with them whatever you want, just like /etc /etc is the canonical example of something you might want to track in git, as a) it changes and b) it's hard to recreate. Maybe you have other directories and locations you feel the same about, so if you think they need tracking in git by all means go ahead and track them. It's your choice after all, you can do with your servers whatever you wish > Regarding the workflow with /etc in git vs ansible in git I was asking > about your concrete workflow so we can learn from it and maybe apply > some good practices on our servers as well. There isn't any workflow. Ansible does it's thing and sometimes changes stuff. Changes get committed to a repo however and whenever works best for you. Maybe it's a regular cron job, maybe it's something you remember to do every time you quit vi, maybe it's an ansible handler that runs at the end of every play. It will be almost impossible to give advice to someone else on this. -- Alan McKinnon alan.mckin...@gmail.com
