Developer Guide

Welcome to the Ansible Developer Guide!

Who should use this guide?

If you want to extend Ansible by using a custom module or plugin locally, creating a module or plugin, adding functionality to an existing module, or expanding test coverage, this guide is for you. We’ve included detailed information for developers on how to test and document modules, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository.

Find the task that best describes what you want to do:

• I’m looking for a way to address a use case:

  • I want to add a custom plugin or module locally.

  • I want to figure out if developing a module is the right approach for my use case.

  • I want to develop a collection.

• I’ve read the info above, and I’m sure I want to develop a module:

  • What do I need to know before I start coding?

  • I want to set up my Python development environment.

  • I want to get started writing a module.

  • I want to write a specific kind of module:

    • a network module

    • a Windows module.

    • an Amazon module.

    • an OpenStack module.

    • an oVirt/RHV module.

    • a VMware module.

  • I want to write a series of related modules that integrate Ansible with a new product (for example, a database, cloud provider, network platform, etc.).

• I want to refine my code:

  • I want to debug my module code.

  • I want to add tests.

  • I want to document my module.

  • I want to document my set of modules for a network platform.

  • I want to follow conventions and tips for clean, usable module code.

  • I want to make sure my code runs on Python 2 and Python 3.

• I want to work on other development projects:

  • I want to write a plugin.

  • I want to connect Ansible to a new source of inventory.

  • I want to deprecate an outdated module.

• I want to contribute back to the Ansible project:

  • I want to understand how to contribute to Ansible.

  • I want to contribute my module or plugin.

  • I want to understand the license agreement for contributions to Ansible.

If you prefer to read the entire guide, here’s a list of the pages in order.

• Adding modules and plugins locally
  • Modules and plugins: what’s the difference?
  • Adding a module locally
  • Adding a plugin locally
• Should you develop a module?
• Ansible module development: getting started
  • Environment setup
  • Starting a new module
  • Exercising your module code
  • Testing basics
  • Contributing back to Ansible
  • Communication and development support
  • Credit
• Contributing your module to Ansible
  • Contributing to Ansible: objective requirements
  • Contributing to Ansible: subjective requirements
  • Other checklists
• Conventions, tips, and pitfalls
  • Scoping your module(s)
  • Designing module interfaces
  • General guidelines & tips
  • Functions and Methods
  • Python tips
  • Importing and using shared code
  • Handling module failures
  • Handling exceptions (bugs) gracefully
  • Creating correct and informative module output
  • Following Ansible conventions
  • Module Security
• Ansible and Python 3
  • Minimum version of Python 3.x and Python 2.x
  • Developing Ansible code that supports Python 2 and Python 3
  • Testing modules on Python 3
• Debugging modules
  • Debugging (local)
  • Debugging (remote)
  • Debugging AnsibleModule-based modules
• Module format and documentation
  • Python shebang & UTF-8 coding
  • Copyright and license
  • ANSIBLE_METADATA block
  • DOCUMENTATION block
  • EXAMPLES block
  • RETURN block
  • Python imports
  • Testing module documentation
• Developing Cisco ACI modules
  • Introduction
  • ACI module structure
  • Testing ACI library functions
• Guidelines for Ansible Amazon AWS module development
  • Maintaining existing modules
  • Creating new AWS modules
  • Connecting to AWS
  • Handling exceptions
  • API throttling (rate limiting) and pagination
  • Returning Values
  • Dealing with IAM JSON policy
  • Dealing with tags
  • Helper functions
  • Integration Tests for AWS Modules
• OpenStack Ansible Modules
  • Naming
  • Interface
  • Interoperability
  • Libraries
  • Testing
• oVirt Ansible Modules
  • Naming
  • Interface
  • Interoperability
  • Libraries
  • New module development
  • Testing
• Guidelines for VMware module development
  • Testing with govcsim
  • Testing with your own infrastructure
  • Unit-test
  • Code style and best practice
  • Typographic convention
• Information for submitting a group of modules
  • Submitting a group of modules
  • Before you start coding
  • Naming convention
  • Speak to us
  • Where to get support
  • Your first pull request
  • Subsequent PRs
  • Maintaining your modules
  • New to git or GitHub
• Testing Ansible
  • Why test your Ansible contributions?
  • Types of tests
  • Testing within GitHub & Shippable
  • How to test a PR
  • Want to know more about testing?
• The lifecycle of an Ansible module
  • Deprecating modules
  • Changing a module name
• Developing plugins
  • Writing plugins in Python
  • Raising errors
  • String encoding
  • Plugin configuration & documentation standards
  • Developing particular plugin types
• Developing dynamic inventory
  • Inventory sources
  • Inventory plugins
  • Inventory scripts
• Developing the Ansible Core Engine
  • Ansible module architecture
• Ansible module architecture
  • Types of modules
  • How modules are executed
• Python API
  • Python API example
• Rebasing a pull request
  • Configuring your remotes
  • Rebasing your branch
  • Updating your pull request
  • Getting help rebasing
• Using and Developing Module Utilities
  • Naming and finding module utilities
  • Standard module utilities
• Developing collections
  • Collection structure
  • Creating collections
  • Migrating Ansible content to a collection
• Collection Galaxy metadata structure
  • Structure
  • Examples
• Ansible architecture
  • Modules
  • Module utilities
  • Plugins
  • Inventory
  • Playbooks
  • The Ansible search path