Red Hat Satellite 6.4 Ansible Plugin vs. Ansible Tower

The Big Question Mark

Why should I be using Ansible Tower (AWX) when there is Ansible already integrated starting with Red Hat Satellite 6.4?

The Main Difference

The main difference for now is that the Ansible Plugin in Red Hat Satellite can not be managed in a Lifecycle Environment. Whenever you make use of that plugin you will use one previously imported version of an Ansible Role for all your managed hosts in all your Lifecycle Environments with no capability of specifying an exact Ansible Role version per Lifecycle Environment.

Pro Ansible Plugin in Satellite

If you are not going to use Lifecycle Environments at all or only one or you do not want to do versioning of your Ansible Configuration Management, you are perfectly good to go without Ansible Tower and use the provided Ansible Plugin of Satellite. Also if you have only a handful of managed hosts. But be aware that this comes with a great cost of inflexibility and if your environment is about to grow and your Configuration Management becomes more complex you might want to move to Ansible Tower.

Pro Ansible Tower

As with Ansible Tower you can create a dedicated Project and a Job Template per Lifecycle Environment. In the Project you can provide a requirements.yml file in the roles/ directory. For further reading see here and here. This way we are able to control which version of an Ansible Role is applied to any specific Lifecycle Environment. Also we are flexible in where to place the code of the Ansible Roles, for example in one or better multiple source code management repositories. Allowing a bigger organization to collaborate on the Configuration Management development in specific Lifecycle Environments.

Epilogue

I am working on another in depth post about a Standard Operating Environment setup with Satellite and Ansible Tower. Explaining the settings to make for Satellite and Ansible Tower to work in harmony.