There's a lot here, @Deanna
- It adds the new ansible-navigator tool that provides an integrated development experience combining a lot of existing tools such as ansible-playbook, ansible-config, ansible-inventory, and ansible-doc and adds new capabilities to them for debugging runs and so on. It is really cool.
- Execution environments. With upstream Ansible distributing many of its modules into Ansible Content Collections, execution environments provide a way to package up the content collections you need and their dependencies into a container-based environment that's independent of your control node. There are at least three reasons this is awesome:
1) Red Hat provides multiple supported execution environments: right now there's one for Ansible 2.9, a second for ansible-core 2.11 with just the ansible.builtin collection, and a third for ansible-core 2.11 with a large number of supported content collections (and their associated modules, filters, and plug-ins). This means that you can match an execution environment to a playbook. Have an old playbook that you want to keep on 2.9? Use that execution environment when running it.
2) This also means that if you're writing a playbook on your laptop that you plan to use in automation controller (the new name for Ansible Tower), you're much more likely to just be able to migrate it to Tower without changes, because the execution environment that runs the playbook can be the same container image, whether you're developing with ansible-navigator or running in production with automation controller.
3) This also does away with the need to create Python venvs on Ansible Tower in order to provide custom dependencies needed by your playbook. Those can be packaged up in your own custom execution environment instead, along with your own content collections, and stored in a container registry that automation controller can pull the image from. There's a neat tool called ansible-builder to help you make these. Automation controller then can run your playbook with your chosen execution environment. This also means that the folks setting up the project in the UI can manage the containerized execution environment through the UI without having to make software changes on the automation controller itself.
- The tools generally work like you'd expect. You can use ansible-navigator run with the options you're used to using with ansible-playbook and things will mainly work like you expect. There's a -m stdout option to get output that looks like the old tools, and some really interesting new interactive capabilities.
- This may be container-based, but you don't need Kubernetes or OpenShift or anything fancy, either for ansible-navigator or automation controller.
- Private automation hub is nice, and provides a way for you to provide local distribution of content collections and container images (assuming you don't have some other container registry for that part).
- It's still Ansible. If you know how to write Ansible 2.9 playbooks, you know how to write ansible-core 2.11 playbooks. There are a few details that might be different as far as implementation is concerned, but on the whole you know how to do this.
We're still learning a lot about it in Training, but there's good stuff here.
