Ansible Runner as a Service

Ansible Runner is a device and Python library that helps when interfacing with Ansible immediately or as a part of one other system. Ansible Runner works as a standalone device, a container picture interface, or a Python module that may be imported. The purpose is to offer a secure and constant interface abstraction to Ansible.

The Ansible Runner as a Service (ARaaS) wraps the ansible runner interface inside a REST API enabling Ansible playbooks to be executed and queried from different platforms.
Guarantee your code delivers the expertise and performance the enterprise expects by optimizing efficiency throughout take a look at, pre-production, and manufacturing environments with AppDynamics.

The inducement for that is to:

• Present Ansible integration to non-python initiatives.
• Present a method of programmatically working playbooks the place the Ansible engine is working on a separate host or in a separate container.

ARaaS Options

• HTTPS assist (HTTP not supported)
  • manufacturing model:
    • makes use of TLS mutual authentication. (<misc/nginx> folder gives a container for use in manufacturing)
    • Legitimate shopper and server certificates should be used to entry the API (See documentation in <misc/nginx> folder)
  • take a look at model:
    • makes use of self-signed if current crt/key recordsdata are usually not current (<misc/docker> gives a container for use in take a look at methods)
    • if not current, generates self-signed on the primary startup
• creates or reuses ssh pub/non-public keys for communication with goal hosts

• /metrics endpoint gives key metrics for monitoring the occasion with Prometheus
• a pattern Grafana dashboard is supplied within the misc/dashboards listing to trace exercise

• exposes playbooks by identify discovered throughout the mission folder
• helps Ansible environments that use non-public libraries (i.e. the library listing is saved throughout the mission folder)
• playbooks might be run with tags to alter execution habits
• playbooks can use limits to limit actions to a selected host
• playbooks can use the examine parameter to run the ansible-runner in examine mode
• working playbooks could also be canceled
• helps execution of concurrent playbooks

• playbook state and output might be queried throughout and after execution
• playbook state exhibits total standing, with the at the moment lively process identify
• the caller can request all occasions related to present or previous playbook runs
• occasions could also be filtered for particular output e.g. ?process=RSEULTS to indicate occasions with a process identify of RESULTS
• playbook state is cached to enhance API response instances

• hosts and ansible teams are managed via the API /teams and /hosts endpoints
• Earlier than a bunch might be added to the stock, it’s checked for DNS and passwordless ssh
• lacking public keys on ‘candidate’ hosts, consequence within the occasion’s public key being returned to the caller. The requester can then organize for this key to be put in on the candidate host.
• host and group vars supported both contained in the ‘hosts’ file or within the host_vars/group_vars sub-directories

• easy to make use of REST API permitting playbooks to be run, and outcomes/state queried
• gives an API endpoint describing every endpoint
• API content material is robotically generated and has no exterior dependencies
• every description contains an curl command instance, along with output

• helps docker – Dockerfile and README included
• cross platform assist (docker picture makes use of CentOS7 base, construct course of executes towards Ubuntu)
• might be packaged as an rpm or run as a container
• designed to supply core ansible performance, supplemented by a customers set of playbooks/roles/library
• helps configuration choices via a selected /and so on listing
• configuration choices could also be overridden on the command line for diagnostics
• all related exercise is logged

ARaaS Conditions

Up to now, testing has been primarily towards Fedora (28) and CentOS7 for the docker picture. Bundle Dependencies:

• Python 3.6
• pyOpenSSL (python3-pyOpenSSL on Fedora, CentOS pyOpenSSL)
• ansible_runner 1.1.1 or above

ARaaS Set up

Assuming you might have an surroundings that meets the python3 dependencies, merely unzip the archive and run the next command.

python3 ansible_runner_service.py

Once you run from any listing exterior of /usr, the script regards this as ‘dev’ mode. On this mode, all recordsdata and paths are relative to the trail that you simply’ve unzipped the mission into.

For ‘prod’ mode, a setup.py is supplied. As soon as the package deal is put in and known as from /usr/*/bin, the script will count on config and output recordsdata to be present in all the conventional ‘manufacturing’ places.

sudo python3 setup.py set up --record installed_files --single-version-externally-managed

As soon as that is put in, you might begin the service.

python3 ansible_runner_service.py 

ARaaS API Endpoints

As soon as the service is working, you may level your browser to https://localhost:5001/api to indicate which endpoints can be found.

Every endpoint is described together with a curl instance displaying invocation and output.

Chances are you’ll click on on any row to broaden the outline of the API route and present the curl instance.

The app makes use of a self-signed certificates, so all examples use the -k parameter (insecure mode).

ARaaS API Endpoints ‘cheat sheet’

API Routes and descriptions
/api — Present accessible API endpoints (this data)
/api/v1/teams  — Record all of the outlined teams within the stock
/api/v1/teams/<group_name> — Handle teams throughout the stock
/ /v1/groupvars/<group_name> — Handle group variables
/api/v1/hosts — Return an inventory of hosts from the stock
/api/v1/hosts/<host_name> — Present group membership for a given host
/api/v1/hosts/<host_name>/teams/<group_name> — Handle ansible management of a given host
/api/v1/hostvars/<host_name>/teams/<group_name> — Handle host variables for a selected group throughout the stock
/api/v1/jobs/<play_uuid>/occasions — Return an inventory of occasions inside a given playbook run (job)
/api/v1/jobs/<play_uuid>/occasions/<event_uuid> — Return the output of a selected process inside a playbook
/api/v1/playbooks — Return the names of all accessible playbooks
/api/v1/playbooks/<play_uuid> — Question the state or cancel a playbook run (by uuid)
/api/v1/playbooks/<playbook_name> — Begin a playbook by identify, returning the play’s uuid
/api/v1/playbooks/<playbook_name>/tags/ — Begin a playbook utilizing tags to manage which duties run
/metrics — Present Prometheus appropriate statistics which describe playbook exercise

ARaaS Instance

Get the checklist of accessible playbooks

curl -k -i https://localhost:5001/api/v1/playbooks -X GET

Run the playbook.yml playbook, passing the time_delay parameter (30 secs ought to be sufficient)

curl -k -i -H "Content material-Sort: software/json" --data '{"time_delay": 30}' https://localhost:5001/api/v1/playbooks/playbook.yml -X POST

Get an inventory of all of the occasions in a playbook. The return checklist consists of all of the job occasion ID’s

curl -k -i https://localhost:5001/api/v1/jobs/de264512-32f1-11ec-aaf5-005056a854a6/occasions -X GET

To get particular output from a job occasion, you may question the job occasion

curl -k -i https://localhost:5001/api/v1/jobs/de264512-32f1-11ec-aaf5-005056a854a6/occasions/16-b853adec-9978-4499-8e6d-d2aecc34e108​​​​​​​ -X GET

Clearly, you’ll want to alter the playbook UUID and job UUIDs in your run.

ARaaS and AppD Usecase

• Buyer with plain/CLI Ansible playbooks to configure the ACI material.
• The shopper would really like to combine AppD with the present Ansible playbooks.
• Challenges:
  • The buyer just isn’t utilizing Ansible Tower or AWX so we are able to’t leverage their APIs.
  • AppD integration is out there utilizing HTTP (i.e., REST) requests.

What are you able to do?… 🤔

…Yep, you bought it proper! 👏

• We will deploy an ARaaS VM/container and configure the AppD HTTP request template with the playbook URI.
• That can allow our prospects to supplement AppD capabilities by leveraging current Ansible playbooks for:
  • Remediation
  • Provisioning
  • Configuration administration
  • Utility deployment (through IaC)

Remaining thought

That’s cool, proper? Wrapping a plain/CLI Ansible playbook inside a REST API name! Consider the (AppD/Others?) integration prospects… 💡

Associated assets

This text goals to cowl the fundamental performance of Ansible Runner as a Service. Listed here are some useful hyperlinks to be taught extra:

We’d love to listen to what you suppose. Ask a query or go away a remark under.
And keep linked with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Fb | YouTube Channel

Share: