Simplifying Automation with Organized Collections
Ansible Content Collections revolutionize automation content management by offering a simplified, consistent, and portable way to deliver modules, roles, and playbooks. Their versioning and reusability enable better collaboration and seamless integration into various workflows.
But where should you store your Ansible Collections? The answer depends on your specific use case. Let’s explore the options.
Ansible Content Collections bundle automation content like modules, roles, and playbooks into portable, reusable, and versioned packages. These Collections:
Execution Environments (EEs) are container images that package all dependencies, including Ansible Collections, plugins, and Python libraries, into a consistent runtime.
To create or customize an EE, use the ansible-builder
tool to define the necessary dependencies and build the container image. Collections included in the EE are automatically available wherever the container runs.
This is the most robust method, especially for environments managed via the Red Hat Ansible Automation Platform.
You can store Collections in a directory on the system and configure the ansible.cfg
file to point to it.
Example ansible.cfg
:
COLLECTIONS_PATHS = ./collections:~/.ansible/collections:/usr/share/ansible/collections
Caution: This approach is less suited for multi-node setups, such as Red Hat Ansible Automation Platform, as mounting local directories across multiple execution nodes is challenging.
Collections can also reside alongside the playbook in a dedicated collections
directory.
Steps:
collections
directory in the same folder as your playbook.ansible.cfg
file:...
COLLECTIONS_PATHS = ./collections:~/.ansible/collections:/usr/share/ansible/collections
...
This approach ensures collections travel with your playbook, simplifying portability and reducing dependency concerns.
requirements.yml
For larger or distributed setups, define Collections in a requirements.yml
file and let Ansible fetch them from a source such as:
Example requirements.yml
:
collections:
- name: https://github.com/iamgini/ansible-collections-in-git-demo.git#/azure-azcollection-1.18.1/
type: git
- name: https://github.com/iamgini/ansible-collections-in-git-demo.git#/community-general-7.4.0/
type: git
- name: cisco.ios
version: 5.2.0
source: https://galaxy.ansible.com
- name: amazon.aws
version: 6.5.0
source: https://aap.example.local/api/galaxy/content/rh-certified/
The requirements.yml
method is highly recommended for automation environments as it integrates seamlessly with automation controllers.
It’s possible to combine methods to suit your needs. For instance:
Ensure the COLLECTIONS_PATHS
variable is updated to reflect your hybrid setup.
Choosing the right location for your Ansible Collections depends on your workflow and infrastructure. Whether you use Execution Environments for streamlined containerized automation or manage Collections alongside your playbooks for portability, proper organization ensures a smoother automation experience.
Where do you keep your Ansible Collections? Let us know in the comments!
Disclaimer:
The views expressed and the content shared in all published articles on this website are solely those of the respective authors, and they do not necessarily reflect the views of the author’s employer or the techbeatly platform. We strive to ensure the accuracy and validity of the content published on our website. However, we cannot guarantee the absolute correctness or completeness of the information provided. It is the responsibility of the readers and users of this website to verify the accuracy and appropriateness of any information or opinions expressed within the articles. If you come across any content that you believe to be incorrect or invalid, please contact us immediately so that we can address the issue promptly.
Tags: Ansible · ansible automation platform · Ansible best practices · ansible collections · Ansible Content Collections · ansible galaxy · Ansible Tips · ansible-builder · Automation · Automation Workflow · Collections Management · Configuration Management · Devops · Execution Environments · IT Automation · Playbook Directory · Portable Automation · Private Automation Hub · Requirements File · Reusable Automation · System Path
Gineesh Madapparambath
Gineesh Madapparambath is the founder of techbeatly and he is the co-author of The Kubernetes Bible, Second Edition. and the author of 𝗔𝗻𝘀𝗶𝗯𝗹𝗲 𝗳𝗼𝗿 𝗥𝗲𝗮𝗹-𝗟𝗶𝗳𝗲 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻.
He has worked as a Systems Engineer, Automation Specialist, and content author. His primary focus is on Ansible Automation, Containerisation (OpenShift & Kubernetes), and Infrastructure as Code (Terraform).
(aka Gini Gangadharan - iamgini.com)
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Leave a Reply