Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 29. Best practices for automation controller


Adopt these best practices to help ensure scalable, maintainable, and highly efficient automation. This guidance focuses on using source control, dynamic inventories, and robust file structures within automation controller.

29.1. Use source control

Automation controller supports playbooks stored directly on the server. Therefore, you must store your playbooks, roles, and any associated details in source control.

This way you have an audit trail describing when and why you changed the rules that are automating your infrastructure. Additionally, it permits sharing of playbooks with other parts of your infrastructure or team.

29.2. Ansible file and directory structure

This section describes the recommended file and directory structure for Ansible projects used with Automation controller and execution environments. Ansible projects typically include playbooks, inventory files, variable files, and custom modules or plugins. A well-organized file and directory structure enhances maintainability, collaboration, and scalability of Ansible projects.

To ensure reliable and consistent automation, follow these best practices for managing your content:

  • Package reusable content, such as roles, modules, and plugins into Ansible Collections.
  • Reference all necessary Collections for a project in the project’s requirements.yml file. These dependencies are automatically installed into the execution environment (EE) at runtime, but only if they are not already present in the EE image.
  • Do not import content from other projects or common file-system locations, such as /opt, at runtime. All content must be explicitly defined within the EE.
  • Working directory: The playbook directory is used as the current working directory at runtime. However, always use the playbook_dir variable instead of relying on the current working directory path.
Warning

Automation controller does not support interactive features.

  • Avoid using the vars_prompt feature, as automation controller does not permit interactive questions. For user input, use Surveys in job templates.
  • Do not use the pause feature without a timeout. Automation controller does not permit canceling a pause interactively. If pause is necessary, you must set a timeout.

29.3. Use Dynamic Inventory Sources

Define an inventory synchronization process by using dynamic sources, such as a cloud provider or CMDB, to help ensure your infrastructure inventory in automation controller stays consistently up-to-date.

Note

Edits and additions to Inventory host variables persist beyond an inventory synchronization as long as --overwrite_vars is not set.

29.4. Variable Management for Inventory

Variables associated with hosts and groups in an inventory can be managed in several ways in automation controller.

Keep variable data with the hosts and groups definitions (see the inventory editor), rather than using group_vars/ and host_vars/. If you use dynamic inventory sources, automation controller can synchronize such variables with the database while the Overwrite Variables option is not set.

29.5. Autoscaling

Use the "callback" feature to permit newly booting instances to request configuration for auto-scaling scenarios or provisioning integration.

29.6. Larger Host Counts

Set "forks" on a job template to larger values to increase parallelism of execution runs.

29.7. Continuous integration / Continuous deployment

Continuous Integration (CI) and Continuous Deployment (CD) are development practices that require developers to integrate code into a shared repository several times a day.

Each integration can then be verified by an automated build and automated tests. CI/CD is a method to deliver applications to customers by introducing automation into the stages of app development.

The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment. Automation controller can be integrated with CI/CD systems to enable automated provisioning, configuration management, application deployment, and other IT tasks as part of the CI/CD pipeline.

For a Continuous Integration system, such as Jenkins, to create a job, it must make a curl request to a job template. The credentials to the job template must not require prompting for any particular passwords.

Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat