Crafted by Megabyte Labs
This repository is the home of an Ansible role that provides a great, cross-platform starting point for developing an Ansible role. This repository contains the base structure for an Ansible role. It includes an extensive set of Molecule test options and build tools / configs useful for automating the repository update process
Looking to install Ansible Role without having to deal with Ansible? Simply run the following command that correlates to your operating system:
Linux/macOS:
curl -sS https://install.doctor/ansible-role | bashWindows:
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://install.doctor/ansible-role?os=win'))Important Note: Before running the commands above you should probably directly access the URL to make sure the code is legit. We already know it is safe but, before running any script on your computer, you should inspect it.
You can also check out Install Doctor. It is an app we created that can install any Ansible role with a one-liner. It has some other nifty features too like the ability to install binaries on-the-fly without requiring a password. However, if you would like to incorporate this role into an Ansible playbook (and customize settings) then please continue reading below.
The chart below shows the operating systems that we have tested this role on. It is automatically generated using the Ansible Molecule tests located in the molecule/ folder. There is CI logic in place to automatically handle the testing of Windows, macOS, Ubuntu, Fedora, CentOS, Debian, and Archlinux. If your operating system is not listed but is a variant of one of the systems we test (i.e. a Debian-flavored system or a RedHat-flavored system) then it is possible that the role will still work.
| OS Family | OS Version | Status | Idempotent | Tested On |
|---|
What does idempotent mean? Idempotent means that if you run this role twice in row then there will be no changes to the system the second time around.
We spent a lot of time perfecting our CI configurations and build tools. If you are interested in learning more about how we perfected our process then you might find our Ansible common files and Ansible documentation repositories interesting. See the CONTRIBUTING.md guide for more details.
Most of our roles rely on Ansible Galaxy collections. Some of our projects are also dependent on other roles and collections that are published on Ansible Galaxy. Before you run this role, you will need to install the collection and role dependencies, as well as the Python requirements, by running:
if type poetry &> /dev/null; then poetry install --no-root; else pip3 install -r .config/assets/requirements.txt; fi
ansible-galaxy install -r requirements.ymlAlternatively, you can simply run bash .config/scripts/start.sh if you are new to Ansible and do not mind the development requirements also being installed. This is the easy way of making sure that everything works properly.
Although the only tool necessary to run this play on a standard machine is Ansible (a Python package), we include several other Python dependencies that are required for specialized use cases and development. The table below details these packages:
| Package | Description | Required |
|---|---|---|
| ansible | A configuration management system that can remotely configure computers | ✔️ |
| docker | Enables the capability of provisioning Docker containers with Ansible | ✔️ |
| python-vagrant | Required for provisioning Vagrant VMs | ✔️ |
| pywinrm | Required for provisioning Windows machines that are using WinRM | ✔️ |
| ansible-lint | Linting tool for Ansible files | |
| ansibler | Custom tool used to generate advanced documentation (e.g. it generates the compatibility chart and some other charts) | |
| black | Python file auto-formatter included in case project utilizes Python test scripts | |
| blocklint | Linting tool that prevents certain words from entering the code base | |
| flake8 | Python linter that reports Python syntax and style errors | |
| mod-ansible-autodoc | Custom fork of ansible-autodoc which allows us to auto-generate documentation based on comments in the role's YAML files | |
| molecule | Test framework for Ansible | |
| molecule-docker | Molecule plugin for provisioning Docker containers | |
| molecule-vagrant | Molecule plugin for provisioning Vagrant VMs | |
| pre-commit-hooks | Suite of tools useful for linting | |
| proselint | Linter used to generate English-language improvements (used to improve documentation) | |
| yamllint | Linter for YAML files that ensures proper syntax and styling is used |
Although most of our roles do not have dependencies, there are some cases where another role has to be installed before the logic can continue. At the beginning of the play, the Ansible Galaxy role dependencies listed in meta/main.yml will run. These dependencies are configured to only run once per playbook. If you include more than one of our roles in your playbook that have dependencies in common then the dependency installation will be skipped after the first run. Some of our roles also utilize helper roles directly from the task files which helps keep our main playbook (Gas Station) DRY.
The requirements.yml file contains a full list of the Ansible Galaxy dependencies required by this role (i.e. meta/main.yml role dependencies, helper roles, collections, etc.). For your convenience, a list of the role dependencies along with quick descriptions is below:
role_dependencies
This role is dependent on multiple Ansible Galaxy collections. The collections along with a links to their source are listed below.
With the dependencies installed, all you have to do is add the role to your main playbook. The role handles the become behavior so you can simply add the role to your playbook without having to worry about commands that should not be run as root:
- hosts: all
roles:
- professormanhattan.ansible-role
If you are incorporating this role into a pre-existing playbook, then it might be prudent to copy the requirements outlined in pyproject.toml and requirements.yml to their corresponding files in the root of your playbook so you only have to worry about installing one set of requirements during future use. Note that the dependencies in pyproject.toml can be moved to the more traditional requirements.txt, if that is what you are currently using to track Python dependencies.
You can find an example of a playbook that incorporates this role in our main playbook (a.k.a. Gas Station). The playbook is an excellent example for someone learning how to use Ansible. It also incorporates a lot of well-thought out build tools that more advanced Ansible users can appreciate. And people who could care less about Ansible can also benefit from it because it allows you to more or less turn your computer (and network) into the ultimate development enivornment. The bottom line is that it is an awesome project that developers should know about!
Contributions, issues, and feature requests are welcome! Feel free to check the issues page. If you would like to contribute, please take a look at the contributing guide.
Sponsorship
Dear Awesome Person,
I create open source projects out of love. Although I have a job, shelter, and as much fast food as I can handle, it would still be pretty cool to be appreciated by the community for something I have spent a lot of time and money on. Please consider sponsoring me! Who knows? Maybe I will be able to quit my job and publish open source full time.
Sincerely,
Brian Zalewski
Below you will find a list of services we leverage that offer special incentives for signing up for their services through our special links:
Copyright © 2020-2021 Megabyte LLC. This project is MIT licensed.
