Python Zip App for Ansible

--- tags: ansible, proposal --- # Python Zip App for Ansible ## Summary Ansible Execution Environments provide a convenient method for packaging Ansible content in a portable format. The current implementation uses a container image for distributing this content. While this has a number of benefits, it also presents a number of challenges for embedded environments. ## Problems With Container Images 1. A container runtime may not be available in the embedded environment. 1. Container images contain an entire operating system worth of code and can be quite large. 1. Managing the host running the container from within the container is difficult since containers were designed to prevent this. ## Proposed Solution ### Overview [PEP 441] allows Python to execute ZIP archives directly. Ansible Core uses this feature for module execution internally. Ansible Builder could be enhanced to create an executable ZIP archive containing collection content and, optionally, Python libraries required by the collections. A number of tools have expanded on the capabilities of PEP441. Two examples are [`pex`] and [`shiv`]. Ansible Builder could leverage either of the above tools to generate a ZIP archive and then insert the Ansible content into the generated ZIP archive. A custom entry point script inside the ZIP archive would call `ansible-runner` to execute the play. ### Challenges The main challenge beyond the work of actual implementation would be the reliance on a Python interpreter on the managed system. A container image brings along its own Python, but a ZIPP archive does not. The ZIP archive would only contain Ansible content, a custom entry point script, and optionally third party Python libraries. For embedded systems, the control node and the managed node are the same. The control node Python requirements for Ansible are much higher than for the managed node. As of Ansible Core 2.12, the minimum supported Python version is 3.8. This will limit the hosts that can run the ZIP archive. ### Benefits The two primary benefits are no container runtime is necessary and the embedded host will not require a listening SSH connection in order for Ansible to manage it. The entry point script provides a useful abstraction between the command being run and the underlying Ansible content. At a minimum, this could provide a much simpler interface to running Ansible content than constructing an `ansible-playbook` command or creating an environment to pass to `ansible-runner`. This could also provide an excellent mechanism for creating executables that leverage Ansible content but provide a different interface. For example, examining role argument specs and mapping those values to command line options. Or changing the displayed output from the underlying `ansible-playbook` run. Within the ZIP archive, Ansible collections could be placed inside the Python `site-packages` directory. This would leverage the existing capability of Ansible Core to find collections in the system `site-pacckages` directory. An added benefit of this is it makes collections available for the invocation from within the ZIP archive but does not make them globally available on the system. [PEP 441]: https://www.python.org/dev/peps/pep-0441/ [`pex`]: https://pypi.org/project/pex/ [`shiv`]: https://pypi.org/project/shiv/