"My thoughts would be that you set up hostX as a backup client with a backup role and backup everything...(maybe excluding certain temporary directories)... Why do you want something explicitly different for web servers/web sites?"
Agree. I'd configure your backup tool to indicate what paths should be backed up. Even if doing something as basic as rsync, rsync is very good at determining what files it needs to move. Otherwise you are backing up only the things that ansible has known it changed, which doesn't include things that the software could have changed by itself (databases) or users logging in. Thus the backup process should probably be independent of the ansible playbook process -- ansible will set up the backup to core, or cause it, but I'd venture it shouldn't make decisions on what needs to be backed up conditionally based on what it changed, as that could miss things you might want to back up. On Tue, May 27, 2014 at 8:54 PM, Brice Burgess <briceb...@gmail.com> wrote: > > On Tuesday, May 27, 2014 5:33:38 PM UTC-5, Adam Morris wrote: >> >> >> I'm curious why you would do this (not because there is anything >> inherently wrong with it, but I'm wondering what your thinking is here). >> > > In short -- I am trying to avoid running 88 non-changing tasks to execute > 2 changing ones. For instance; when I'm applying sites to a server, I don't > want to also apply apache, and whatever else apache depends on, and so > forth -- just to apply the sites. Here's an example playbook; > > https://github.com/iceburg-net/ansible-pcd/blob/master/iceburg-sites.yml > > Apache was setup in a playbook I previously executed (as a dependency of > the php role); > > https://github.com/iceburg-net/ansible-pcd/blob/master/webservers.yml > > > ... so, for instance, when I'm applying sites via the apache-site role, > it's really useful to know where to put SSL certificates. I define where to > put ssl certificates in an upstream role (httpd) as `httpd_ssl_dir`. > `httpd_ssl_dir` best belongs in the httpd role and not the apache_sites > roles because OTHER ROLES may want to use it; and it's the natural spot to > look for it. > > I know my organizational process differs from Michael and it's made it > very inefficient to me to work with ansible; but none-the-less it's my > favorite infrastructure automation tool && I believe my struggles have > always been failure to clearly communicate my ideas. I think I'm closer now > && I hope that I've created something respectable. > > I believe elegance and simplicity are one in the same, and, in fact, > dependent upon eachother. > > ~ Brice > > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ansible-project+unsubscr...@googlegroups.com. > To post to this group, send email to ansible-project@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/3658e1c3-c30e-4451-baa8-afb1d255b0b4%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/3658e1c3-c30e-4451-baa8-afb1d255b0b4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwJWC5U1cboSxjKR9B_HxFEoqMpSfeB9q1AtkX5gBXy1A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
