{"id":721,"date":"2021-02-11T20:22:08","date_gmt":"2021-02-12T01:22:08","guid":{"rendered":"https:\/\/crossan007.dev\/blog\/?p=721"},"modified":"2021-02-11T20:31:57","modified_gmt":"2021-02-12T01:31:57","slug":"a-better-ansible_managed-tag","status":"publish","type":"post","link":"https:\/\/crossan007.dev\/blog\/ci-cd-tools\/a-better-ansible_managed-tag\/","title":{"rendered":"A Better ansible_managed Tag"},"content":{"rendered":"\n
Tweet<\/a><\/div>\n\n

If you’re using Ansible to manage configuration files on your servers, you’re probably familiar with the <\/code>{{ ansible_managed }}<\/code> tag <\/a>. <\/p>\n\n\n\n

This tag is well behaved from an idempotentcy perspective, but in the nitty-gritty of managing servers where there’s a chance of interaction by humans, this built-in tag leaves a lot to be desired.<\/p>\n\n\n\n

Enter Ansible filter plugins<\/a>, and a little bit of magic in group_vars<\/a>.<\/p>\n\n\n\n

This filter plugin will obtain (according to git pretty-formats<\/a>) the commit hash, author, and date of the last commit to the file provided by the filter plugin structure:<\/p>\n\n\n

\n#!\/usr\/bin\/python\n# this should be saved to .\/filter_plugins\/get_last_commit_to_file.py\n\nclass FilterModule(object):\n  def filters(self):\n    return {\n      'get_last_commit_to_file': self.get_last_commit_to_file\n    }\n\n  def get_last_commit_to_file(self, file_path):\n    import os\n    try:  # py3\n      from shlex import quote\n    except ImportError:  # py2\n      from pipes import quote\n    stream = os.popen('git log -n 1 --pretty=format:\\'%h by %an at %aD\\' -- ' + quote(file_path))\n    output = stream.read()\n    return output\n<\/pre><\/div>\n\n\n
So, now we can define two new variables in our group_vars\/all.yml<\/code> file: ansible_workspace_git_url<\/code> and ansible_managed_custom<\/code>.    <\/p>\n\n\n\n
Notice the use of our custom filter plugin  – we can pipe the variable template_path variable (which Ansible gives to us for free)<\/a> into our filter plugin to obtain a string about the git history of our file!<\/p>\n\n\n
\nansible_workspace_git_url: "https:\/\/github.com\/myrepo"\n\nansible_managed_custom: "\nAnsible Managed for {{ inventory_hostname }} ({{ansible_system_vendor}}::{{ansible_product_name}}::{{ansible_product_serial}}) \\n\nAnsible Git Repository URL: {{ ansible_workspace_git_url }}\\n\nInventory File: {{ inventory_file|replace(inventory_dir,'') }}@{{ inventory_file | get_last_commit_to_file }}\\n\nTemplate file: {{ template_path|replace(inventory_dir,'') }}@{{ template_path | get_last_commit_to_file }}\\n\nRole Context: {{ role_name | default('None') }}\\n\nRendered Template Target: {{ template_destpath }}"\n<\/pre><\/div>\n\n\n
We now have available for use inside any template a nicely formatted (but not necessarily idempotent) header which gives any readers DETAILED information including:<\/p>\n\n\n\n
  • The hostname and BIOS serial number of the host to which this file was rendered<\/li>
  • The git repository of the playbook responsible for this template<\/li>
  • The filename of the template used to render this file <\/li>
  • The hash of the last commit which affected the template used to render this file<\/li>
  • The filename of the inventory supplying variables to render this template<\/li>
  • The hash of the last commit which affected the inventory supplying variables to render this template<\/li>
  • The target path on the target server to where this file was rendered<\/li><\/ul>\n\n\n\n
    Now, anytime I’m templating out a file (well, at least any file that supports multiline comments), I can just include our new ansible_managed_custom<\/code> variable:<\/p>\n\n\n
    \n<!--\n  {{ ansible_managed_custom }}\n--> \n<\/pre><\/div>\n\n\n
    By switching to this header format, I was able to better assist my teammates with identifying why a template was rendered in a particular fashion, as well as provide them details about how to fix any problems they may find.    This template format also helps answer questions about whether the rendered file was _copied_ from one server to another (possibly in a migration) and whether the file is likely to still be under Ansible management. <\/p>\n","protected":false},"excerpt":{"rendered":"
    We now have available for use inside any template a nicely formatted (but not necessarily idempotent) header which gives any readers DETAILED information<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[229],"tags":[287,157,25,288],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\t\n