Who am I?

Office of Technology

Zuul

Ansible

Who am I?

Technical Committee

Developer Infrastructure Core Team

Former Foundation Board of Directors

PTL of shade project

Ansible

Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.

Why Ansible is Great

• simple declarative YAML syntax
• list of tasks to perform - easy to debug
• agentless - don't infect machines under management
• Open Source - thousands of contributors worldwide

Ansible Overview

• task - an action to perform
• module - code that exposes a type of action
• role - reusable collection of tasks to acomplish a goal
• play - tasks and roles run on a specific host or hosts
• inventory - list of locations available to run plays on
• playbook - file containing one or more plays

Ansible Simple Example

simple.yaml

- hosts: all
  tasks:
  - name: Print hostname of server
    command: hostname
      

A playbook containing a play that will run against all hosts in the inventory. It has one task that uses the command module to run the "hostname" command.

Ansible Longer Example

longer.yaml

- hosts: git
  roles:
    - create-mirror-locations
- hosts: code-review.example.com
  roles:
    - create-repositories
      

A playboook containing two plays. The first runs a role called "create-mirror-locations" against a group of hosts from the inventory called "git". Then it runs a role called "create-repositories" against a host from the inventory called "code-review.example.com".

Ansible Modules

• Usually written in Python
• Can do anything, not limited to executing commands on a server
• Manipulate Network Switch Config (ansible-network)
• Build Containers (ansible-container)
• Interact with REST APIs

Ansible OpenStack Modules

• http://docs.ansible.com/ansible/list_of_cloud_modules.html#openstack
• Focused on consuming OpenStack APIs
• Some are end-user focused
• Some are deployer focused

Interop - Work on All OpenStack Clouds

• Ansible's OpenStack modules work the same on every OpenStack cloud

Don't let the existence of Rackspace modules confuse you. The OpenStack modules work just great on Rackspace

Work Around Deployer Differences ... To a Point

• Herculean effort is made to hide a giant amount of differences
• Even so - some bugs are EWONTFIX

A provider decided to redefine the OpenStack Availability Zone concept complete with incompatible API changes. That is unsupportable.

PS. Don't do that

Based on shade library

• OpenStack python library to abstract deployment differences
• designed for multi-cloud
• simple to use
• massive scale
  • optional advanced features to handle >20k servers a day
• Initial logic/design extracted from OpenStack Infra's nodepool
• Turned in to library for re-use in Ansible

Integration Testing

• Every shade patch is integration tested in OpenStack Infra
• Every shade patch tests the ansible modules in OpenStack Infra
• Support coming very soon to test PRs to ansible modules in OpenStack Infra

Let's Take a Few Steps Back

OpenStack in Ansible and Multi-cloud Operations are easy...

but you need to know a few things.

• Module structure
• Terminology
• Config

Module Structure

• All modules start with os_
• End-user oriented modules are named for the resource
  • os_image
  • os_sever
• Operator oriented modules are named for the service
  • os_nova_flavor
  • os_keystone_domain
• If it could go both ways, we prefer user orientation
  • os_user
  • os_group
• If more than one service provides a resource, they DTRT
  • os_security_group
  • os_floating_ip

OpenStack Dynamic Inventory Script

• github.com/ansible/ansible/contrib/inventory/openstack.py
• Uses all hosts in all clouds as one inventory
• Excludes hosts without IPs
• Makes a bunch of auto-groups (flavor, image, az, region, cloud)
• Makes groups for metadata['groups']

New inventory plugin coming in Ansible 2.4

Modules for All OpenStack Resources are Welcome Upstream

• If there is a thing you want to manage that doesn't have a module, add one
• We're very welcoming/accepting
• Same goes for features to existing modules

To Serve All Users, We Have to be Strict

• Modules that touch OpenStack APIs must do so via shade library
• In user modules, vendor differences should be hidden
• In operator modules, exposing them is ok

clouds.yaml

• Information about the clouds you want to connect to is stored in a file called clouds.yaml.
• In OpenStack Pike release, Horizon provides downloadable clouds.yaml
• Both yaml and yml are acceptable.
• clouds.yaml can be in your homedir: ~/.config/openstack/clouds.yaml or system-wide: /etc/openstack/clouds.yaml.
• Information in your homedir, if it exists, takes precedence.
• Full docs on clouds.yaml are at https://docs.openstack.org/developer/os-client-config/

What about Mac and Windows?

USER_CONFIG_DIR is different on Linux, OSX and Windows.

• Linux: ~/.config/openstack
• OSX: ~/Library/Application Support/openstack
• Windows: C:\\Users\\USERNAME\\AppData\\Local\\OpenStack\\openstack

SITE_CONFIG_DIR is different on Linux, OSX and Windows.

• Linux: /etc/openstack
• OSX: /Library/Application Support/openstack
• Windows: C:\\ProgramData\\OpenStack\\openstack

Config Terminology

For multi-cloud, think of two types:

• profile - Facts about the cloud that are true for everyone
• cloud - Information specific to a given user

Remember your Execution Context!

• ansible executes code on remote systems
• clouds.yaml needs to be on the host where the modules run
• auth information can be passed to modules directly
• other config (currently) MUST go in clouds.yaml
• Ability to pass entire cloud config to module coming soon

basic clouds.yaml for the example code

Simple example of a clouds.yaml

• Config for a named cloud "my-citycloud"
• Reference a well-known "named" profile: citycloud
• os-client-config has a built-in list of profiles at https://docs.openstack.org/developer/os-client-config/vendor-support.html
• Vendor profiles contain various advanced config
• cloud name can match profile name (using different names for clarity)

clouds:
  my-citycloud:
    profile: citycloud
    auth:
      username: mordred
      project_id: 65222a4d09ea4c68934fa1028c77f394
      user_domain_id: d0919bd5e8d74e49adf0e145807ffc38
      project_domain_id: d0919bd5e8d74e49adf0e145807ffc38
      

Where's the password?

secure.yaml

• Optional additional file just like clouds.yaml
• Values overlaid on clouds.yaml
• Useful if you want to protect secrets more stringently

Example secure.yaml

• No, my password isn't XXXXXXXX
• cloud name should match clouds.yaml
• Optional - I actually keep mine in my clouds.yaml

clouds:
  my-citycloud:
    auth:
      password: XXXXXXXX
      

more clouds.yaml

More information can be provided.

• Use v3 of the identity API - even if others are present
• Use https://image-ca-ymq-1.vexxhost.net/v2 for image API instead of what's in the catalog

my-vexxhost:
  identity_api_version: 3
  image_endpoint_override: https://image-ca-ymq-1.vexxhost.net/v2
  profile: vexxhost
  auth:
    user_domain_id: default
    project_domain_id: default
    project_name: d8af8a8f-a573-48e6-898a-af333b970a2d
    username: 0b8c435b-cc4d-4e05-8a47-a2ada0539af1
      

Much more complex clouds.yaml example

• Not using a profile - all settings included
• In the ams01 region there are two networks with undiscoverable qualities
• Each one are labeled here so choices can be made
• Any of the settings can be specific to a region if needed
• region settings override cloud settings
• cloud does not support floating-ips

Extra Variables to Control Inventory Behavior

• expand_hostvars

  whether to make extra API calls to fill out additional information about each server

• use_hostnames

  changes the behavior from registering every host with its UUID and making a group of its hostname to only doing this if the hostname in question has more than one server

• fail_on_errors

  causes the inventory to fail and return no hosts if one cloud has failed

ansible:
  use_hostnames: False
  expand_hostvars: True
  fail_on_errors: True

Test Your Config

---
- hosts: localhost
  tasks:
  - os_auth:
      cloud: "{{ item.cloud }}"
      region_name: "{{ item.region }}"
    with_items:
    - cloud: my-vexxhost
      region: ca-ymq-1
    - cloud: my-citycloud
      region: Buf1
    - cloud: my-internap
      region: ams01
      

More Interesting

- hosts: localhost
  tasks:
  - os_server:
      name: "my-server"
      cloud: "{{ item.cloud }}"
      region_name: "{{ item.region }}"
      image: "{{ item.image }}"
      flavor: "{{ item.flavor }}"
      auto_ip: true
    with_items:
    - cloud: my-vexxhost
      region: ca-ymq-1
      image: Ubuntu 16.04.1 LTS [2017-03-03]
      flavor: v1-standard-4
    - cloud: my-citycloud
      region: Buf1
      image: Ubuntu 16.04 Xenial Xerus
      flavor: 4C-4GB-100GB
    - cloud: my-internap
      region: ams01
      image: Ubuntu 16.04 LTS (Xenial Xerus)
      flavor: A1.4

Check That There is an Inventory

python ~/src/github.com/ansible/ansible/contrib/inventory/openstack.py --list

Cleanup After Ourselves

- hosts: localhost
  tasks:
  - os_server:
      cloud: "{{ item.cloud }}"
      region_name: "{{ item.region }}"
      name: my-server
      state: absent
    with_items:
    - cloud: my-vexxhost
      region: ca-ymq-1
    - cloud: my-citycloud
      region: Buf1
    - cloud: my-internap
      region: ams01
      

Check out Ansible Cloud Launcher

https://git.openstack.org/cgit/openstack/ansible-role-cloud-launcher

• Role for launching resources on an OpenStack Cloud

Check out Linch-pin

http://linch-pin.readthedocs.io/en/develop/

• From our friends in CentOS

Linch-pin provides a collection of Ansible playbooks for provisioning, decommissioning, and managing resources across multiple infrastructures. The main goal of linch-pin is to facilitate provisioning and orchestration of resources in a multi-cloud environment through a topology file.