Ideas #

Ways to improve the book

• What if you want to use existing Ansible code in your extension?
• Is there a good way to combine multiple Ansible actions together into a single, reusable action?
• Some kind of coherent explanation about the fucking directory layout
• Add a section on external data stores
  • Answer the question “what should you do if you need to store data somewhere but the inventory isn’t a good place for it?”
  • If you’re doing this, you may want to write a lookup plugin (link) to retrieve that data
• Organize the book by types of problems to solve
  • I might have a “How does Ansible think about extensions?” section that describes the differences between plugins and modules or whatever
  • But the more important content is “here’s how to add an action” or “here’s how to get inventory information from an external source”, so those sections should come first
• Is it valuable to talk about custom facts and inventory scripts?
  • These are fairly well documented in the actual Ansible documentation
  • Maybe worth a little show and tell but not spending too much time
• Examples with Active Directory
  • Inventory from AD?
  • Host vars from AD?
  • Querying AD with a lookup plugin
• Show what you can write in languages other than Python
  • Non-Python programmers might appreciate knowing the bounds of what’s possible
  • Relatively ignored in the Ansible documentation
  • https://github.com/pmarkham/writing-ansible-modules-in-bash/blob/master/ansible_bash_modules.md
  • Huh. Some discussion of Powershell https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general_windows.html
  • https://dmilind.github.io/Custom-Ansible-Module-In-Golang/
• Link to other examples of Ansible plugins
  • https://rndmh3ro.github.io/
• Learn more about, and add prose for, Ansible Galaxy.
• Some interesting things in the lookup plugins list that don’t get surfaced very loudly. For instance, you can get the string of an inflated template file, and you can lookup keys/values in ini files.
• Add a chapter on custom facts. Useful for caching previous actions - e.g. configuring a service account, and caching that it exists. I think I want to do this with some of tagasaw.
• Talk about minimizing round trips
  • Write a single module for all your custom facts. Downside: centralizes them. Updside: one round trip.
  • Optimize Ansible loops — one round trip per loop item — into shell scripts that run remotely
    • Seriously, can you believe that Ansible runs the loop on the controller, and invokes the task separately for each item? Misery
  • Or optimize them further into a custom action module written in Python
  • AI changes the calculus on when this type of optimization is worth it — much more often now
  • Talk about profiling options