Chapter 6. Creating content
Use the guidelines in this section of the Creator Guide to learn more about the developing the content you will use in Red Hat Ansible Automation Platform.
6.1. Creating playbooks
Playbooks contain one or more plays. A basic play contains the following sections:
- Name: a brief description of the overall function of the playbook, which assists in keeping it readable and organized for all users.
- Hosts: identifies the target(s) for Ansible to run against.
-
Become statements: this optional statement can be set to
true/yesto enable privilege escalation using a become plugin (such assudo,su,pfexec,doas,pbrun,dzdo,ksu). - Tasks: this is the list actions that get executed against each host in the play.
Example playbook
- name: Set Up a Project and Job Template
hosts: host.name.ip
become: true
tasks:
- name: Create a Project
ansible.controller.project:
name: Job Template Test Project
state: present
scm_type: git
scm_url: https://github.com/ansible/ansible-tower-samples.git
- name: Create a Job Template
ansible.controller.job_template:
name: my-job-1
project: Job Template Test Project
inventory: Demo Inventory
playbook: hello_world.yml
job_type: run
state: present
6.2. Creating collections
You can create your own Collections locally with the Ansible Galaxy CLI tool. You can use the collection subcommand to activate the Collection-specific commands.
Prerequisites
- You have Ansible-core version 2.15 or newer installed in your development environment.
Procedure
- In your terminal, go to where you want your namespace root directory to be. For simplicity, this should be a path in COLLECTIONS_PATH but that is not required.
Run the following command, replacing
my_namespaceandmy_collection_namewith your own values:$ ansible-galaxy collection init <my_namespace>.<my_collection_name>
NoteMake sure you have the proper permissions to upload to a namespace by checking under the My Content tab on galaxy.ansible.com or console.redhat.com/ansible/automation-hub
The earlier command will create a directory named from the namespace argument (if one does not already exist) and then create a directory under that with the Collection name. Inside of that directory will be the default or "skeleton" Collection. This is where you can add your roles or plugins and start working on developing your own Collection.
In relation to execution environments, Collection developers can declare requirements for their content by providing the appropriate metadata in Ansible Builder.
Requirements from a Collection can be recognized in these ways:
-
A file
meta/execution-environment.yml, which references the Python orbindeprequirements files. -
A file named
requirements.txt, which includes information about the Python dependencies, and is sometimes found at the root level of the Collection. -
A file named
bindep.txt, which includes system-level dependencies, and is sometimes found at the root level of the Collection. -
If any of these files are in the
build_ignoreof the Collection, Ansible Builder will not pick up on these. Thebuild_ignoresection filters any files or directories that should not be included in the build artifact.
Collection maintainers can verify that ansible-builder recognizes the requirements they expect by using the introspect command:
$ ansible-builder introspect --sanitize ~/.ansible/collections/
Additional resources
- For more information about creating collections, see Creating collections in the Ansible Developer Guide.
6.3. Creating roles
You can create roles by using the Ansible Galaxy CLI tool. You can access Role-specific commands from the roles subcommand.
ansible-galaxy role init <role_name>
Standalone roles outside of Collections are still supported, but create new roles inside of a Collection to take advantage of all the features Ansible Automation Platform has to offer.
Procedure
-
In your terminal, go to the
rolesdirectory inside a collection. Create a role called
role_nameinside the collection:$ ansible-galaxy role init my_role
The collection now includes a role named
my_roleinside therolesdirectory:~/.ansible/collections/ansible_collections/<my_namespace>/<my_collection_name> ... └── roles/ └── my_role/ ├── .travis.yml ├── README.md ├── defaults/ │ └── main.yml ├── files/ ├── handlers/ │ └── main.yml ├── meta/ │ └── main.yml ├── tasks/ │ └── main.yml ├── templates/ ├── tests/ │ ├── inventory │ └── test.yml └── vars/ └── main.ymlA custom role skeleton directory can be supplied by using the
--role-skeletonargument. This allows organizations to create standardized templates for new roles to suit their needs.ansible-galaxy role init my_role --role-skeleton ~/role_skeleton
This will create a role named my_role by copying the contents of ~/role_skeleton into my_role. The contents of role_skeleton can be any files or folders that are valid inside a role directory.
Additional resources
- For more information about creating roles, see Creating roles in the Ansible Galaxy documentation.
6.4. Creating automation execution environments
- An automation execution environments definition file will specify
- An Ansible version
- A Python version (defaults to system Python)
- A set of required Python libraries
- Zero or more Content Collections (optional)
- Python dependencies for those specific Collections
The concept of specifying a set of Collections for an environment is to resolve and install their dependencies. The Collections themselves are not required to be installed on the machine that you are generating the automation execution environments on.
An automation execution environments is built from this definition, and results in a container image. Please read the Ansible Builder documentation to learn the steps involved in creating these images.
