diff --git a/docs/execution_environments.rst b/docs/execution_environments.rst index a06cc4db5..c1e418e29 100644 --- a/docs/execution_environments.rst +++ b/docs/execution_environments.rst @@ -3,9 +3,9 @@ Using Runner with Execution Environmnets ======================================== -**Execution Environments** are meant to be a consistent, reproducable, portable, +**Execution Environments** are meant to be a consistent, reproducible, portable, and sharable method to run Ansible Automation jobs in the exact same way on -your laptop as they are executed in `Ansible AWX `_, or via `Red Hat Ansible Automation Platform `_ @@ -35,7 +35,7 @@ As previously mentioned, a primary goal of adding the Execution Environment CLI interface is to aid in the creation of Ansible Automation jobs and content. The approach here is to make it as similar as possible to the way **Ansible** users are accustomed to using Ansible today. There are two subcommands, ``adhoc`` and -``playbook`` that have been added to accomodate this. The ``adhoc`` subcommand +``playbook`` that have been added to accommodate this. The ``adhoc`` subcommand to ``ansible-runner`` is synonymous with ``ansible`` and the ``playbook`` subcommand to ``ansible-runner`` is synonymous with ``ansible-playbook``. Examples are below. @@ -45,9 +45,9 @@ Running Ansible adhoc An example invocation using the ``ping`` module and ``localhost`` as target:: - $ ansible-runner adhoc localhost -m ping + $ ansible-runner adhoc localhost -m ping -Something to note here is that implicit ``localhost`` in this context is a containerized instantiation of an Ansible Execution Environment and as such you will not get Ansible Facts about your system if using the ``setup`` module. +Something to note here is that implicit ``localhost`` in this context is a containerized instantiation of an Ansible Execution Environment and as such you will not get Ansible Facts about your system if using the ``setup`` module. Running Ansible ansible-playbook ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -58,18 +58,18 @@ An example invocation using the ``demo.yml`` playbook and ``inventory.ini`` inve Something to note here is that implicit ``localhost`` in this context is a containerized instantiation of an Ansible Execution Environment and as such you will not get Ansible Facts about your system if using ``gather_facts: true`` and targeting ``localhost`` in your playbook without explicit host definition in your inventory. -Notes an Considerations ------------------------ +Notes and Considerations +------------------------ -There are some differences between running Ansible directly from the command -that have to do with configuration, content locality, and secret data. +There are some differences between using Ansible Runner and running Ansible directly from the +command line that have to do with configuration, content locality, and secret data. Secrets ^^^^^^^ Typically with Ansible you are able to provide secret data via a series of -machanisms, many of which are pluggable and configurable. However when using -Ansible Runner certain considerations need to be made, these are analogous to +mechanisms, many of which are pluggable and configurable. When using +Ansible Runner, however, certain considerations need to be made; these are analogous to how Ansible AWX and Tower manage this information. See :ref:`inputdir` for more information @@ -82,23 +82,23 @@ which is also the name of the artifacts subfolder where results are saved to. When a container for job isolation is launched, it will be given a name of ``ansible_runner_``. Some characters from the job identifier may be replaced with underscores for compatibility with -names that podman and docker allow. +names that Podman and Docker allow. This name is used internally if a command needs to be ran against the container -at a later time, for instance, to stop the container when the job is canceled. +at a later time (e.g., to stop the container when the job is canceled). ~/.ssh/ symlinks ^^^^^^^^^^^^^^^^ In order to make the ``adhoc`` and ``playbook`` container execution of Ansible -easier, Ansible Runner will automatically bind mount your local ssh agent +easier, Ansible Runner will automatically bind mount your local ssh agent UNIX-domain socket (``SSH_AUTH_SOCK``) into the container runtime. However, this -does not work if files in your ``~/.ssh/`` directory happen to be symlink'd to +does not work if files in your ``~/.ssh/`` directory happen to be symlinked to another directory that is also not mounted into the container runtime. Ansible Runner ``adhoc`` and ``playbook`` subcommands provide the ``--container-volume-mount`` option to address this, among other things. -Here is an example of a ssh config file that is a symlink: +Here is an example of an ssh config file that is a symlink: ::