Ansible Features I Missed

Well, ok some of these aren't particularly new, but I've only just become aware of them. Even after years of Ansible experience, there's always something to learn!

Module Defaults

It's been around since at least 2.7 and the docs are here.

If you frequently call the same module with the same arguments, it can be useful to define default arguments for that particular module using the module_defaults attribute.

If I've got a simple playbook, where I'm calling the same thing over and passing the same information a lot, this is really useful to cut down on duplication and error possibilities.

Where will I be using this mostly though? For spinning up all things public cloud.

The Module defaults group lets you define a whole load of commonly called variables, for AWS, Azure, VMware, k8s and others.

The docs example of setting the AWS region, is a good one. Each AWS module is going to mandate a region as an option, so set it only once so it can be used throughout those modules:

# example_play.yml

- hosts: localhost

  module_defaults:
    group/aws:
      region: us-west-2

  tasks:

  - name: Get info
    aws_s3_bucket_info:


  # now the region is shared between both info modules


  - name: Get info
    ec2_ami_info:
      filters:
        name: 'RHEL*7.5*'

That is useful and will cut down on YAML lines!

Anchors & Aliases

Jury's out for me on this one to be to honest!

But I think the java options example in the docs is a useful one.

...
vars:
    app1:
        jvm: &jvm_opts
            opts: '-Xms1G -Xmx2G'
            port: 1000
            path: /usr/lib/app1
    app2:
        jvm:
            <<: *jvm_opts
            
            path: /usr/lib/app2



This looks complicated on the face of it, but it's easy enough to understand -

&jvm_opts is the anchor, or "remember these values"

We can then re-use them for another app definition, using the *jvm_opts alias.

The outcome is that app1 and app2 share the same opts and port definitions, and the path value is merged using <<

For the more complex set of variable structures, this little trick could be useful!


Joel Figov

Sr Cloud Engineer and product owner at Aviva

4 年

Nice one Phil, shame that module defaults can't be used universally across a load of modules eg. Files or copy! Would save a lot of lines of YAML in some of my playbooks!

回复
Sorin Sbarnea

Principal Software Engineer at Ansible by Red Hat

4 年

I used YAML anchors and aliases to avoid repeating configuration for years and I do recommend them. The issue with module_defaults is that it makes impossible to make use of JSON Schema to validate playbooks/tasks, as you can no longer know which required fields are optional or not (those defined in in defaults will be missing from the call). Alternative is to mark even mandatory arguments as optional in order to avoid false-positive failures for users that make use of module_defaults. As it can easily be seen that is no joy for https://github.com/ansible-community/schemas On the other hand, YAML native features are not affected by this. Still they cannot be used outside a single file and I do expect that ansible module_defaults to effects to be set for the entire playbook, with included tasks and roles.

回复
Florian Moss

Head of Automation & Infrastructure - Financial Services

4 年

Sweet, wasn’t aware of the defaults!

回复

要查看或添加评论,请登录

Phil Griffiths的更多文章

  • Still using vi for Ansible? No problem!

    Still using vi for Ansible? No problem!

    Having grown up using vi as a main editor on UN*X systems, I still love it and often fire it up for quick demos etc. I…

    3 条评论
  • Calling the Ansible Automation Platform API Using 'Friendly' Job Template Names

    Calling the Ansible Automation Platform API Using 'Friendly' Job Template Names

    Have you ever wanted to call the AAP/Tower API to launch a Job Template? The REST API allows you to do that, fast and…

    1 条评论
  • Creating a custom EE for AWX

    Creating a custom EE for AWX

    This is a quick and rough guide to creating and consuming a custom execution environment (EE) in AWX. What You'll Need…

    29 条评论
  • Ansible Execution Environments

    Ansible Execution Environments

    Introduction Ansible as a automation platform offering is evolving further, making customer automation runtimes easier…

    15 条评论
  • AWX 18.0.0 with Containerised Execution Environments

    AWX 18.0.0 with Containerised Execution Environments

    The upstream of Ansible Automation Platform, AWX has just landed with a new exciting release. Thought I'd give it a try…

    4 条评论
  • Tuning RHEL Using Ansible System Roles

    Tuning RHEL Using Ansible System Roles

    Take the pain out of some performance tuning using RHEL's tuned functionality. Take even more pain out setting it up…

    1 条评论
  • Oh Molecule You've Come A Long Way

    Oh Molecule You've Come A Long Way

    I often get asked about Ansible testing, best practices and related topics. If there's one tool I'd have in the kit bag…

    4 条评论
  • Holy crap batman! sudo's bust!

    Holy crap batman! sudo's bust!

    As we all know, software has bugs, no one escapes! How you respond and fix those bugs is what's important. If you ever…

    1 条评论
  • RHEL OS Image Builder (part two)

    RHEL OS Image Builder (part two)

    This is part 2 of the blog series. Part one is here.

    1 条评论
  • RHEL8 OS Image Builder (part one)

    RHEL8 OS Image Builder (part one)

    Following on from this post for setting up a quick RHEL VM with minimal fuss, this is what I really wanted it for!…

社区洞察

其他会员也浏览了