General question about ansible CI/CD strategy

Archives Ansible Project
1

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.

2

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.