I’m very new, so sorry if this is a silly question but every time I see Ansible referred to it seems to be on a single ad-hoc command line run, which is great for building but I was wondering how (or indeed if) daemonized ansible works for managing configuration.
I don’t want to use ansible-pull as I want to keep things nice, clean and agentless, so do you have to cron an ansible job or is there some form of daemon? If so, how do you configure that daemon (say… run every 30 mins or every 10 mns etc)
Tower is a very expensive product, although it’s an excellent option if you manage hundreds of servers and need to schedules dozens of jobs across different parts of your organization. If you’re environment is more simple or you’re working on a budget, you really have to rely on cron to schedule playbook runs.
But if you think about it, you don’t have to apply a system’s entire catalog, to use a Puppet term, every 30 or 60 minutes. Ansible makes it very easy to chop up your systems’ profiles into multiple playbooks. So the trick is to figure out which change sets need to be applied once, occasionally, or on a schedule.
you can also run ansible from cron, jenkins or any other scheduler if
you want that. If you want a 'agent' you can put ansible-pull on
eachmachine and invoke from cron there.
I’d suggest avoiding Tower as it is not Free Software. Instead, use a scheduler like RunDeck or Jenkins. You could use cron but the schedulers I’ve mentioned offer much more functionality (reporting, git webhooks, etc). Personally, I like the idea of setting up 2 jobs:
Scheduled:
This job should run once or twice a day depending on your needs. The job should always run at the same time(s). Its only purpose in life is to ensure your entire ecosystem is configured as designed. This assumes your playbooks are designed accordingly (I use a single site.yml).
On Demand:
The idea here is to trigger a playbook run based off a pull or push notification of your VCS repo. The difference between pull vs. push is left for you to decide based upon your time requirements and/or other determining factors related to your network and/or ACLs. Either way, these runs should be triggered based upon activity associated with your VCS. The scheduled job runs once or twice a day as a failback for those periods when there is no commit activity to your VCS. The idea here is to manage your systems and ensure they meet your requirements in the event some admin goes rouge and makes a change outside of the “config management” workflow.