ANSIBLE 2.0 UP CLOSE WE LIVE TO OPTIMIZE TECHNOLOGY AND HELP DRIVE - - PowerPoint PPT Presentation

ANSIBLE 2.0

UP CLOSE

WE LIVE TO OPTIMIZE TECHNOLOGY AND HELP DRIVE INNOVATION WE ARE PASSIONATE ABOUT HOW IT CAN TRANSFORM BUSINESS

YOUR PRESENTERS

MIKE SANTANGELO

▸ Over two decades of public sector infrastructure work ▸ Specialties: Ansible, Ansible Tower, Red Hat Linux

administration, Red Hat Network Satellite, Red Hat Clustering Suite, *nix troubleshooting, Shell scripting with awk, sed, grep, and various other tools

▸ email: mike@oteemo.com

YOUR PRESENTERS

ARKA CHAUDHURI

▸ Over two decades in IT and infrastructure services for

broadcast and streaming media, biotech and telecom

▸ Specialties: Cloud and hybrid infrastructure, Linux

administration, VoIP, streaming media, broadcast IT, hardware design

▸ arka@oteemo.com

PROLOGUE

WHY 2.0?

1.X WAS GETTING DIFFICULT TO:

▸ MAINTAIN:

▸ 3+ years of organic growth = unwieldy codebase. ▸ Increasingly difficult to fix bugs

▸ MODIFY:

▸ adding on features to core, ▸ delays in reviewing PRs ▸ Difficult to unit test

▸ EXTEND:

▸ task grouping and error handling, among other things

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

BLOCKS

▸ Attributes like become,

conditionals and tags are inherited by tasks in the block

▸ Try-catch for rollbacks at

block level

▸ Variable scope in blocks ▸ Blocks can be nested

• block:
• block:
• name: install (Debian)

apt: name: apache2 state: present update_cache: yes cache_valid_time: 3600 when: ansible_os_family == "Debian"

• block:
• name: install (Red Hat)

yum: name: httpd state: present when: ansible_os_family == "RedHat" tags: package

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

BLOCKS

▸ Attributes like become,

conditionals and tags are inherited by tasks in the block

▸ Try-catch for rollbacks at

block level

▸ Variable scope in blocks ▸ Blocks can be nested

• hosts: web

tasks:

• block:
• debug: msg="Hello World"
• command: /bin/false

rescue:

• debug: msg=“Rolling back!"
• command: /bin/false

when: ansible_os_family == "Debian"

• debug: msg="I handled an error"

always:

• - debug: msg="This always executes"

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

BLOCKS

▸ Attributes like become,

conditionals and tags are inherited by tasks in the block

▸ Try-catch for rollbacks at

block level

▸ Variable scope in blocks ▸ Blocks can be nested

• hosts: localhost

vars: example1: meow tasks:

• block:
• debug: var=example1
• debug: var=example2

vars: example2: woof

• debug: var=example2

“example1”:”meow” “example2”:”woof” “example2”:”VARIABLE IS NOT DEFINED!”

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

BETTER ERROR MESSAGES

More descriptive errors that point out the location of the error and possible solutions.

ERROR! Syntax Error while loading YAML. The error appears to have been in '/path/to/test.yml': line 6, column 15, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be:

• debug:

msg: {{ ansible_default_ipv4.address }} ^ here We could be wrong, but this one looks like it might be an issue with missing

• quotes. Always quote template expression brackets when they start a value. For

instance: with_items:

• {{ foo }}

Should be written as: with_items:

• "{{ foo }}"

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

EXECUTION STRATEGY PLUGINS

LINEAR

Classic Ansible. Wait for all hosts to complete a task before continuing to the next task.

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

EXECUTION STRATEGY PLUGINS

FREE

allows each host to process tasks as fast as possible without waiting for other hosts “Imma let you finish…”

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

EXECUTION STRATEGY PLUGINS

FREE

allows each host to process tasks as fast as possible without waiting for other hosts

• hosts: web

strategy: free tasks:

• debug:

msg: "{{ inventory_hostname }} is starting."

• name: "Sleep?"

command: sleep 10 when: ansible_os_family == "Debian"

• debug:

msg: "{{ inventory_hostname }} is complete.”

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

EXECUTION STRATEGY PLUGINS

ROLL YOUR OWN

Formulate your own execution strategy with a custom strategy plugin.

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

RUNTIME EVALUATION OF INCLUDES

Earlier, includes were evaluated before run, so loops, facts and variables set during execution time could not be used with includes. Now they can!

# This would fail before v2

• include: users.yml

vars: user: “{{ item }}” with_items:

• Tim
• John
• Jethro

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

RUNTIME EVALUATION OF INCLUDES

Now pull facts in at runtime like never before.

# Before v2

• include: RedHat.yml

when: ansible_os_family == "RedHat"

• include: Debian.yml

when: ansible_os_family == "Debian" # With v2

• include: "{{ ansible_os_family }}".yml

ANSIBLE AWESOMENESS: 2.0 IN DEPTH

IMPROVED VARIABLE MANAGEMENT

▸ Centralized processing and management of all variables

from all sources

▸ Predictable order to avoid premature flattening of data

structures

▸ One shot variable resolution, instead of piecemeal as

before.

ANSIBLE AWESOMENESS: 2.0 IN DEPTH

IMPROVED VARIABLE MANAGEMENT

Variable precedence in 1.x:

• 1. extra vars
• 2. vars, vars_files, etc. aka

“everything else in a playbook”

• 3. inventory vars — host_vars

then group_vars

• 4. facts
• 5. role defaults

Variable precedence in 2.x:

• 1. extra vars
• 2. task vars (only for the

task)

• 3. block vars (only for

tasks in block)

• 4. role and include vars
• 5. play vars_files
• 6. play vars_prompt
• 7. play vars
• 8. set_facts
• 9. registered vars

10.host facts 11.playbook host_vars 12.playbook group_vars 13.inventory host_vars 14.inventory group_vars 15.inventory vars 16.role defaults

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

NEW AND IMPROVED MODULES AND PLUGINS

▸ Over 200 new modules and countless improvements

existing ones -- EC2, VMWare, OpenStack and Windows (still beta) amongst many others

▸ Dozens of new inventory scripts, callbacks, lookups and

• ther plugins

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

PACKAGE MODULE: DISTRO INDEPENDENCE AT LAST?

YUM? OR APT?

Using conditionals and facts to decide what package manager to call? The new package module will use the package manager of the underlying OS. Just say: package: name=<packagename> state=latest Remember, a package may not have the same name across distributions.

* If automatic detection doesn’t work for some reason, add use=<specific-package-manager>.

ANSIBLE AWESOMENESS: 2.0 IN DETAIL

…AND NOT TO FORGET:

▸ meta: refresh_inventory to force re-reading the inventory

in a play. This re-executes inventory scripts, but does not force them to ignore any cache they might use.

▸ unarchive now includes the ability to set src to a download

url; no separate get_url required (unless you want to be backward compatible, that is)

▸ First introduced in 1.9, become is recommended to

replace sudo for privilege escalation.

WHAT WILL BREAK IN 2.0

YOU THOUGHT IT’S ALL GOOD NEWS?

CHANGES IN 2.0

DYNAMIC INCLUDE GOTCHAS

Since includes are now evaluated at runtime, there’s no way to know about:

▸ Tags inside includes: — list-tags may not show all tags, and

there are no explicit warnings if a tag is undefined

▸ Handlers inside includes: for pretty much the same

reasons as above, calling an undefined handler may not raise an error.

▸ Loops inside included files using a loop: don’t even ask.

CHANGES IN 2.0

PLAYBOOK, ROLES AND MODULE COMPATIBILITY

▸ 100% backward compatibility is intended for playbooks

and modules (with reasonable allowances for errors from dynamic includes)

▸ Watch your variable precedence. ▸ Idiomatic declarations like this may break:


with_items: fubar # is fubar a variable or a string???

▸ Empty variables and variables set to null in YAML will no

longer be converted to empty strings

CHANGES IN 2.0

PLAYBOOK, ROLES AND MODULE COMPATIBILITY

▸ Template code now retains types for booleans and

numbers instead of turning them into strings.

▸ Minor change in YAML trailing line handling ▸ Porting Guide (includes workarounds for playbooks):

http://docs.ansible.com/ansible/porting_guide_2.0.html

CHANGES IN 2.0

IMPORTANT: API CHANGES

If you use Ansible API, please pay attention.

• Callback, connection, cache and lookup plugin APIs have

changed, and will require modification to existing plugins

• Integrating directly with Ansible's API (not plugins) will

encounter breaking changes

• Callbacks need to be whitelisted in ansible.cfg. Being in

the callback plugins path is not enough as in previous versions

THANKS FOR THE AWESOMENESS

A DEBT OF GRATITUDE

▸ Ansible NOVA User Group, Immix Group and Fierce Software ▸ James Cammarata, Senior Principal Software Engineer, Ansible,

author of the “Ansible 2.0 and Beyond” presentation

▸ Justin Nemmers, Product Owner — Ansible, Red Hat ▸ The wonderful folks at Red Hat and Ansible that help our

community reach new frontiers in automation each and every day

▸ You guys, for taking the time on a weekday evening to be with us.

Thank you from the core of our being.

STAY IN TOUCH MIKE@OTEEMO.COM ARKA@OTEEMO.COM