Hello all, I am in a project with Ansible and F5 and I was checking this article about best practices for structure and groups → https://support.f5.com/csp/article/K35276063
I was hoping they would have best practices for inlife changes, any ideas ?
Hi Renato, how do you mean inlife changes?
The modules can be used to manage many of the most common features of
the devices in the same way that you would manage configuration of
general operating systems, or applications running on those operating
systems. Is there a specific thing you want to do?
-tim
Hello Tim,
Thank you for your reply.
I was asking regarding “inlife changes” because their examples are all the initial config I think. I wanted to see how they use it for small changes to the config, updates, etc… not just one time tasks.
Makes sense?
Regards
RG
The guidance I would offer is similar to how I would structure other
Ansible things, with some important points to take note of.
In my own ops, I keep many different playbooks to address many
different scenarios. It may be that you have a playbook for
on-boarding, and others for different scenarios within your
environment. For instance, playbook for adding new virtuals and their
component parts such as pools, members and monitors. Playbook for
doing software upgrades of the devices. Playbook for rotating
certificates across a range of vips. etc etc.
This is how I structure my work and it may not be conducive to your environment.
The points to keep in mind specifically about the F5 modules is that
they delegate to Ansible primitives many of the things that would
otherwise have to be done in the module code. For example. Where it
might be reasonable (to you) that a module take a list of items,
instead, the module takes a single item and delegates the list
behavior to Ansible's loop construct, or with_* constructs.
While some folks disagree with this approach, it was done
intentionally (I would know...I wrote them). In cases where a module
takes a list, and you are no expected to loop (for instance it stomps
the list in place), the guidance would be to assemble the list from
facts queried via bigip_device_facts first...then provide that list to
the module in question.
Another note to keep in mind is that the F5 module's `state` parameter
is nearly always defaulted to "present". This can catch you off-guard
if you disable a pool member, then follow up that action with another
action on the pool member where you are not specifying the `state`
param explicitly. In this scenario, the pool member state will default
to present and it would re-enable itself. Scenarios like this are
arguably bugs, but in the event that they do not change on your
timelines, be aware that they are there so you don't goof up your
configuration
Another thing to keep in mind is to be sure to periodically use
bigip_config and it's `save` param. The F5 modules change your
*running* config only. Therefore, when you reboot the device, certain
aspects of your config will disappear if they were not saved through
bigip_config. The reason for this is that the process of saving takes
100% more time than just changing the running config. We figured that
handlers could be used to address saving when changes occur.
Other than that, the act of managing an F5 is not much different than
managing anything in Ansible. I would break up my work by function,
put those functions in a series of playbooks, and use modules to
change things in place.
Hope that helps.
-tim