Why do you you need to run constant playbook runs? are you looking to enforce OS state with Ansible? (I.E: CIS standards or is this more an application question?)
CICD strategies are for pushing out updates only when there is an update to your code. This is great for applications, but will almost never happen to your CIS setting because they will probably never change. Ultimately, you should be writing your playbooks and tasks to be idempotent. Then, whenever you run your playbooks, they don't do anything unless there is an update to be made. You could run Ansible as many times as you like and it wouldn't matter. Regarding affected hosts, you can control that with dynamic inventories. Most large companies have change tickets for production anyway (and some lower environments) so you probably wouldn't be able to just push new code out which would stop you just running arbitrary code (so you couldn't do CD, but you could do CI - then push out the updated code once you have change approval) There are may ways to do it. Just look at what would accomplish what you need to accomplish and do that. I use a simplified roles and profiles method which I coded here: https://github.com/dmccuk/vm_customisation The playbooks are broken down into all the common stuff that everything gets, and then it passes to a specific role(s) for the server or role specific code to be deployed. It make like a lot easier if you can fit your code deployment into something like this. On Tuesday, 20 December 2022 at 23:40:30 UTC [email protected] wrote: > Hi team, > > I'm having a question about the CI/CD strategy for ansible managed > resources. From my understanding, there are basically two ways: > > 1. Having a periodic deployment triggered per playbook with customized > running frequency. > 2. Trigger ansible playbook based on the code change merged. > > The first strategy is the most straight forward one, but there could be > many unnecessary runs if there is actually no code change involved. The > second strategy is more efficient and event-driven, but I'm having > difficulty completing the picture due to the following concerns: > > 1. If we have a nested roles defined and a relatively complex playbook > dependencies, it is hard to get the impact of the code change, especially > when some of the tasks running conditions depending on some runtime > collected attributes. > > 2. Sometimes we just reformat the playbook, which does not have any > functional change. However, if we could detect the change somehow, the > affected hosts by a code change could be many, and it is not fair to waste > many resources to trigger all those playbooks just for some no-op > operations. > > 3. Similar to the item #2, but the the conern is on the blasting radius > part. If there is a real change needs to be performed, the impacted hosts > could be huge with many different playbooks, how to coordinate on those > deployments could also be challenging. > > Looking forward to any insights or discussion on this. > > Thanks. > Jianan. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/ca87e607-f9ce-4469-8d40-bb5f59038597n%40googlegroups.com.
