Installing Red Hat Ansible Automation Platform (AAP) in environments which are fully disconnected from the internet is fairly straightforward with some planning and preparation. The following checklist will help prepare you for a virtual machine-based installation of AAP on a disconnected network. Running AAP on an OpenShift cluster in a disconnected environment is also a supported option, but is out of scope for this checklist.
A minimal production architecture for AAP consists of three to five virtual machines: an optional (but preferred) dedicated installation host, a single automation controller, a single private automation hub, a dedicated installer-managed database, and optionally an Event-Driven Ansible (EDA) controller. This architecture provides the basic requirements for running AAP, while providing the flexibility to scale the platform in the future as needed.
This checklist covers the high-level steps needed to prepare for a disconnected install. Links to the relevant documentation in the Disconnected Installation section of the AAP Installation Guide and the AAP Hardening Guide are included which can be followed for more detailed information.
✅ Ensure all AAP servers meet the system requirements for compute and storage, operating system, and system software. RHEL 9 is the recommended OS.
✅ Ensure each AAP server has been added to DNS on the disconnected network. The FQDN of each server will be used in the installation inventory file.
✅ Ensure all AAP servers have access to the RHEL BaseOS and AppStream package repositories. This may be accomplished in one of the following ways (only one is required):
- Each server may be subscribed to a Red Hat Satellite server on the disconnected network which provides the BaseOS and AppStream repos. This is the preferred method.
- Each server may be configured to use a yum repository which mirrors content from the BaseOS and AppStream repos.
- Where a Satellite server or yum repo mirror are not available, the repos can be accessed from a locally mounted RHEL DVD image.
✅ Ensure all AAP servers are not configured to use the EPEL repository. EPEL contains versions of python packages which conflict with the requirements for AAP.
✅ If the RHEL STIG or similar compliance profile must be applied to the AAP servers, apply all of the controls before attempting to install AAP. Then review the STIG considerations section of the AAP Hardening Guide for guidance on disabling certain compliance controls that are known to be blockers for installation and operation. Applying security controls to AAP servers after installation can make compliance-related issues more difficult to troubleshoot.
✅ Ensure that the network ports and protocols requirements are met for each AAP server, and that the servers can communicate between themselves.
- If any network or host-based firewalls exist between any of the AAP servers, ensure the proper network ports are open between the AAP servers.
- If any cloud instance security groups are applied to any of the AAP servers, ensure the proper security group rules are added to permit required traffic.
✅ Plan to run the installer from a dedicated installation host where possible. If a dedicated installation host cannot be used, run the installer from the controller.
✅ If you have user-provided certificates for the AAP services, copy the certificates and keys to the setup bundle directory on the dedicated installation host (or controller) and add the relevant variables to the installation inventory.
✅ Follow the steps to download and install AAP on a disconnected network. The setup bundle is required for disconnected installation.
- Sensitive variables in the installation inventory file can be kept in an encrypted vault file to limit exposure.
- If passwordless sudo is not configured in the environment, the sudo password can be passed to the installer at runtime.