A environment management tool for Ansible content development that provides isolated workspaces for development. ansible-dev-environment (ade) manages virtual environments, collection installation and removal, and Python dependency resolution to ensure consistent, reproducible development environments.
Overview
ansible-dev-environment (ade) provides comprehensive collection development environment management by:
- Creating isolated virtual environments
- Installing and removing collections with full dependency tracking
- Resolving and installing collection Python dependencies from requirements.txt and test-requirements.txt
- Installing collections in editable mode with symlinks for active development
- Managing development dependencies like ansible-dev-tools
- Providing configurable workspace isolation
While ansible-galaxy efficiently manages collection installation and dependencies, it does not handle Python package dependencies that collections may require. ade complements this by ensuring all Python requirements are properly managed within isolated environments.
Collections are installed into Python's site-packages directory, making them discoverable by both Ansible and Python tooling including pytest.
Expand your automation to a virtually unlimited set of use cases.
Ansible Lint is a command-line tool for linting playbooks, roles and collections aimed towards any Ansible users. Its main goal is to promote proven practices, patterns and behaviors while avoiding common pitfalls that can easily lead to bugs or make code harder to maintain.
Ansible lint is also supposed to help users upgrade their code to work with newer versions of Ansible. Due to this reason we recommend using it with the newest version of Ansible, even if the version used in production may be older.
As any other linter, it is opinionated. Still, its rules are the result of community contributions and they can always be disabled based individually or by category by each user.
Ansible Galaxy project makes use of this linter in order to compute quality scores for Galaxy Hub contributed content. This does not mean this tool is aimed only to those that want to share their code. Files like galaxy.yml, or sections like galaxy_info inside meta.yml help with documentation and maintenance, even for unpublished roles or collections.
The project was originally started by @willthames, and has since been adopted by the Ansible Community team. Its development is purely community driven, while keeping permanent communications with other Ansible teams.
It’s vital to test new technology before rolling it out into your production environment. I like to use Python virtual environments provided by the venv module for developing and testing Ansible playbooks and features. Instead of using the default Python and Ansible commands installed on your system, you can easily set up multiple Python environments and test different versions of Ansible and its component libraries.
Virtual environments are like a virtual machine or Linux chroot, but they create an isolated structure of lightweight directories separated from actual Python system directories. That means you can have different sets of Python environments, each with different versions of modules, files, or configurations.
Ansible is based on Python and leverages many Python modules and plugins. When you test something new, it could require you to update a module that your Ansible installation depends on. Upgrading a component that your production environment depends on defeats the purpose of testing. Still, you can have different versions of Ansible and other important Python modules in a dedicated test directory with a virtual environment.
Ansible Tower 3.0 and later uses virtualenv. Virtualenv creates isolated Python environments to avoid problems caused by conflicting dependencies and differing versions. Virtualenv works by simply creating a folder which contains all of the necessary executables and dependencies for a specific version of Python. Ansible Tower creates two virtualenvs during installation–one is used to run Tower, while the other is used to run Ansible. This allows Tower to run in a stable environment, while allowing you to add or update modules to your Ansible Python environment as necessary to run your playbooks. For more information on virtualenv, see the Python Guide to Virtual Environments and the Python virtualenv project itself.
By default, the virtualenv is located at /var/lib/awx/venv/ansible on the file system but starting with Ansible Tower 3.5, you can create your own custom directories and use them in inventory imports. This allows you to choose how you run your inventory imports, as inventory sources use custom virtual environments.
Tower also pre-installs a variety of third-party library/SDK support into this virtualenv for its integration points with a variety of cloud providers (such as EC2, OpenStack, Azure, etc.) Periodically, you may want to add additional SDK support into this virtualenv, which is described in further detail below.
This repo hosts the openstack.cloud Ansible Collection.
The collection includes the Openstack modules and plugins supported by Openstack community to help the management of Openstack infrastructure.
Ansible modules contain documentation in form of YAML blocks documenting the parameters, examples and return values of the module. The Ansible documentation site is built using Sphinx from reStructuredText. As the modules don't contain reStructuredText, Ansible hashad a tool to generate it from the documentation YAML: build-ansible.py document-plugins. The tool and the accompanying libraries are not part of the Ansible distribution - they just live in the hacking directory. To run them we need a git checkout of Ansible and source hacking/env-setup to set PYTHONPATH and a few other variables correctly for Ansible to run directly from that checkout.