Questo contenuto non è disponibile nella lingua selezionata.

Chapter 29. Best practices for automation controller


The following describes best practice for the use of 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

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

If you have an external source of truth for your infrastructure, whether it is a cloud provider or a local CMDB, it is best to define an inventory sync process and use the support for dynamic inventory (including cloud inventory sources). This ensures your inventory is always 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

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 as long as 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

For a Continuous Integration system, such as Jenkins, to spawn 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. For configuration and use instructions, see Installation in the Ansible documentation.

Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat