Search

Chapter 2. Installing Red Hat Ansible Automation Platform from GCP Marketplace

download PDF

2.1. Prerequisites

Before you can install and register Ansible Automation Platform, you must be familiar with GCP including how services operate, how data is stored, and any privacy implications that may exist by using these services. You must also set up an account with Google Cloud Platform (GCP).

You must have a working knowledge of the following aspects of Google Cloud Platform:

  • Deploying solutions from the GCP Marketplace
  • Compute engine Virtual machine (VM) instances
  • Cloud SQL for PostgreSQL
  • Filestore
  • GPC Virtual Private Clouds (VPCs)

    • Subnets
    • Route Tables
    • Load Balancers
  • Network Design

    • Hub-and-spoke networking designs
    • VPC Peering
    • Class Inter-Domain Routing (CIDR) blocks
    • Transit routing
  • GCP Cloud monitoring

    • GCP Ops agent
  • SSH

For more information about Google Cloud Platform and terminology, see the GCP product documentation.

2.2. Permissions

Your GCP account must have the following permissions to successfully create an Ansible Automation Platform deployment on Google Cloud Platform.

  • Cloud SQL Permissions

    • cloudsql.databases.create
    • cloudsql.databases.delete
    • cloudsql.databases.get
    • cloudsql.databases.list
    • cloudsql.instances.connect
    • cloudsql.instances.create
    • cloudsql.instances.delete
    • cloudsql.instances.get
    • cloudsql.instances.list
    • cloudsql.instances.login
  • Compute Permissions

    • compute.addresses.create
    • compute.addresses.get
    • compute.addresses.list
    • compute.addresses.use
    • compute.forwardingRules.create
    • compute.forwardingRules.get
    • compute.globalAddresses.get
    • compute.globalOperations.get
    • compute.instances.delete
    • compute.instances.get
    • compute.instances.getGuestAttributes
    • compute.instances.list
    • compute.projects.get
    • compute.projects.setCommonInstanceMetadata
    • compute.regionBackendServices.create
    • compute.regionBackendServices.get
    • compute.regionBackendServices.update
    • compute.regionBackendServices.use
    • compute.regionHealthChecks.create
    • compute.regionHealthChecks.get
    • compute.regionHealthChecks.useReadOnly
    • compute.regionOperations.get
    • compute.regionTargetHttpProxies.create
    • compute.regionTargetHttpProxies.get
    • compute.regionTargetHttpProxies.use
    • compute.regionUrlMaps.create
    • compute.regionUrlMaps.get
    • compute.regionUrlMaps.use
    • compute.regions.list
    • compute.zoneOperations.get
  • Deployment Manager Permissions

    • deploymentmanager.deployments.create
    • deploymentmanager.deployments.delete
    • deploymentmanager.deployments.get
    • deploymentmanager.deployments.list
    • deploymentmanager.manifests.get
    • deploymentmanager.operations.get
    • deploymentmanager.resources.list
  • IAM Permissions

    • iam.serviceAccounts.actAs
  • Logging Permissions:

    • logging.logEntries.create
  • Monitoring Permissions:

    • monitoring.metricDescriptors.get
    • monitoring.timeSeries.create
  • Resource Manager Permissions

    • resourcemanager.projects.get
  • Runtime Configurator Permissions

    • runtimeconfig.configs.list
    • runtimeconfig.variables.create
    • runtimeconfig.variables.get
    • runtimeconfig.variables.list
    • runtimeconfig.variables.update
  • Secret Manager Permissions

    • secretmanager.secrets.create
    • secretmanager.secrets.delete
    • secretmanager.secrets.get
    • secretmanager.secrets.list
    • secretmanager.versions.access
    • secretmanager.versions.add
    • secretmanager.versions.destroy
    • secretmanager.versions.disable
    • secretmanager.versions.get
    • secretmanager.versions.list
  • Service Networking Permissions

    • servicenetworking.operations.get
    • servicenetworking.services.addPeering
  • Service Usage Permissions

    • serviceusage.services.list

2.3. Create a project

To install Ansible Automation Platform, you must create a project in your Google Cloud Platform account to host the application if you do not already have one. See Creating and managing projects in the GCP documentation.

2.3.1. Required APIs

Your Google Cloud Platform (GCP) project requires access to several API services to complete Ansible Automation Platform installation. On marketplace deployment, the process automatically attempts to enable the following APIs.

If you prefer, you can enable the APIs ahead of time to ensure they are permitted by your organization.

API ServiceConsole service name

Compute Engine API

compute.googleapis.com

Google Cloud APIs

cloudapis.googleapis.com

Identity and Access Management (IAM) API

iam.googleapis.com

Cloud SQL Admin API

sql-component.googleapis.com

Cloud Logging API

logging.googleapis.com

See Monitoring and logging

Cloud Monitoring API

monitoring.googleapis.com

See Monitoring and logging

Cloud Resource Manager API

cloudresourcemanager.googleapis.com

Cloud Identity-Aware Proxy API

iap.googleapis.com

Secret Manager API

secretmanager.googleapis.com

Service Networking API

servicenetworking.googleapis.com

Service Usage API

serviceusage.googleapis.com

OS Config API

osconfig.googleapis.com

Cloud Runtime Configuration API

runtimeconfig.googleapis.com

Cloud Filestore API

file.googleapis.com

2.3.2. Your service account

You must have a service account to set up Ansible Automation Platform from GCP Marketplace. This account is used to install and configure the application and remains associated with the Ansible Automation Platform virtual machines. You can use an existing service account with the required roles, or the Ansible Automation Platform deployment can create one with the required roles on your behalf. If you use an existing account, or create a service account in advance, it must have the following roles:

  • Editor
  • Logs Writer
  • Cloud SQL Client
  • Cloud SQL Instance User
  • Secret Manager Secret Accessor
  • Compute Network Admin

See Grant a single role for steps to add the required roles to your existing service account.

The Compute Network Administrator role is only required at the time of deployment to configure the application properly. When installation and configuration are complete, this role can be removed from the service account, which remains configured on the Ansible Automation Platform Virtual Machines.

Note

The secrets created during the deployment must be able to use the automatic replication policy. The user specified replication policy is not supported and must be disabled during deployment, backup or upgrade.

2.4. Application deployment

To launch your offer on the Google Cloud Console, navigate to the marketplace and search for Red Hat Ansible Automation Platform 2 - Up to 100 Managed Nodes. After selecting this offer click Launch.

There are four virtual machines included in this product listing. Three n2-standard-2 virtual machines make up the permanent compute components of the solution. Additionally, a single ephemeral e2-medium instance is used to run Red Hat Ansible Automation Platform and Google Cloud deployment workloads. This virtual machine is only used during deployment and then is permanently removed from the solution. The infrastructure cost for the ephemeral VM is charged at the hourly rate during the period that the VM exists, usually less than an hour.

Important

A temporary yet necessary constraint has been placed on the length of deployment names. This is due to GCP’s naming scheme for internal components that make up an Ansible Automation Platform deployment. Component names based on this naming scheme can get too long and often break naming constraints imposed by other services, creating deployment errors.

The length of the name of your deployment, plus the length of your GCP project name must be less than 35 characters and the length of the deployment name must be less than 30 characters.

The calculation below will help you find the maximum length of the name of an Ansible Automation Platform deployment in your project.

length of deployment name < = (minimum between 30 and 35) - length(gcp project name)

There are two methods for deploying the application:

2.4.1. Deploying an application with a new VPC

Note

The process of deploying the application using a new VPC has been deprecated, and the functionality will be removed from Ansible Automation Platform from GCP Marketplace in a future release.

This procedure creates a new VPC network and deploys the application in the created VPC.

Procedure

  1. In the Deployment page, select the Service Usage API link below the Confirm Service Usage API is enabled checkbox.
  2. In the API/Service Details tab, ensure that the API is enabled, then return to the Deployment page.
  3. Check the Confirm Service Usage API is enabled checkbox.
  4. Select or create a Service Account. For further information see Your service account.
  5. In the Region field, select the region where you want the application deployed.
  6. In the Zone field, select the zone where you want the Filestore deployed. The zone must be in the Region you selected.
  7. In the Observability section, you can enable logging and metrics to be sent to Cloud Logging and Cloud Monitoring. See Operations Suite Pricing for the financial cost of enabling these services. See See Monitoring and logging for more information on configuring this feature.
  8. In the Network Selection section, select New network. The Networking section provides defaults for all of the network ranges used in the deployment. If you want to modify these values, see Networking Options.
  9. Click DEPLOY.
  10. The Deployment Manager displays the running deployment.
  11. The application begins provisioning. It can take some time for the infrastructure and application to fully provision.
Note

You will see a warning on the deployment

This deployment has resources from the Runtime Configurator service, which is in Beta

This warning is expected and is not a cause for concern.

2.4.2. Deploying an application with an existing VPC

The following procedure uses an existing VPC network to deploy an application.

Note

The existing proxy subnet must be of type Regional Managed Proxy, which is the reserved proxy-only subnet for load balancing.

Procedure

  1. In the Deployment page, select the Service Usage API link below the Confirm Service Usage API is enabled checkbox.
  2. In the API/Service Details tab, ensure that the API is enabled, then return to the Deployment page.
  3. Check the Confirm Service Usage API is enabled checkbox.
  4. Select or create a Service Account. For further information, see Your service account.
  5. In the Region field, select the region where you want the application deployed.
  6. In the Zone field, select the zone where you want the Filestore deployed. The zone must be in the Region you selected.
  7. In the Observability section, you can enable logging and metrics to be sent to Cloud Logging and Cloud Monitoring. See Operations Suite Pricing for the financial cost of enabling these services. See Monitoring and logging for more information on configuring this feature.
  8. In the Network Selection section, select Existing network.
  9. In the Existing Network section, provide your existing VPC network name, existing subnet name and existing proxy subnet name. Select cloud NAT router to create a NAT router in your VPC network.
  10. The Networking section provides defaults for all of the network ranges used in the deployment. Provide these values based on your existing network configuration. If you want to modify these values, see Networking Options
  11. Click DEPLOY.
  12. The Deployment Manager displays the running deployment.
  13. The application begins provisioning. It can take some time for the infrastructure and application to fully provision.

    Note

    You will see a warning on the deployment.

    This deployment has resources from the Runtime Configurator service, which is in Beta.

    This warning is expected and is not a cause for concern.

2.4.3. Retrieving the administration password

Use the following procedure to retrieve the administration password.

Procedure

  1. In the GCP UI, select the main menu from the top left.
  2. Select Security. If you do not see Security, select View All Products.
  3. Select Secret Manager.
  4. Filter with the name of the deployment. The secret name format is <DeploymentName>-aap-admin.
  5. Click on the secret name of the deployment
  6. Click the More Actions icon *⋮ on the line of the deployment.
  7. Select View secret value. The administration password is displayed

2.4.4. Retrieving the controller and hub load balancer IP address

Use the following procedure to retrieve the controller and hub IP address.

Procedure

  1. In the GCP UI, select the main menu from the top left.
  2. Select Deployment Manager.
  3. Select Deployment.
  4. Select the deployment name.
  5. Select View Details.
  6. In the right pane, under Deployment properties, find the Layout line
  7. Select View. The outputs: section shows the finalValue for the name controllerIp and hubIp.

2.5. Deploying an extension node

You configure extension nodes after you have purchased and launched an extension from the public or private offer.

Procedure

  1. In the Deployment name field, enter a sufficiently short name as described in Application deployment.
  2. For the Service Account, select the service account used with your Red Hat Ansible Automation Platform with up to 100 Managed Nodes deployment.
  3. In the Region field, select the region where you want the application deployed.
  4. In the Zone field, select a zone in the Region you selected when deploying your foundational offer. This field is only used to filter the Network list.
  5. In the Main Deployment Name field, enter the foundation deployment name for which you are deploying an extension.
  6. In the Networking section, expand the default option.
  7. In the Network field, select the existing foundation network ending with -aap-net.
  8. In the Subnetwork field, select the existing foundation subnetwork ending with -aap-subnet.

    Important

    Do not select the subnet ending with -aap-prxy-subnet.

  9. Ensure Extend Ansible Automation Platform deployment in selected VPC is checked.
  10. Click DEPLOY.
  11. The Deployment Manager displays the running deployment.

The extension begins provisioning.

It can take some time for the infrastructure and extension to fully provision.

2.6. Networking options

The network topology of Ansible Automation Platform from GCP Marketplace includes several configurable network segments that can be changed to fit into your organization’s network requirements.

The deployment creates a new VPC and subnet that are not accessible from the public internet, or by using an existing VPC network. You must provide access to the application as described in Networking and Application Access.

Consider your existing network configurations when specifying the following network ranges below. Ensure that each range does not overlap with any other specified here, and does not overlap with existing ranges in your network. Each range should exist within a private network class.

Application Subnet Range

The network CIDR defining the subnet range used by the custom VPC deployed by the offering. Must be a minimum /24 segment and must be in the private network range (192.168 or 10.0).

Default: 192.168.240.0/24

Cloud SQL Peering Network Range

The network CIDR defines the network segment used to peer the GCP CloudSQL network with the application subnet deployed by the offering. Must be a /24 segment. The /24 segment range is a requirement of GCP CloudSQL network peering configuration.

Default: 192.168.241.0/24

Filestore Peering Network Range

Ansible Automation Platform from GCP Marketplace uses GCP Filestore service to share configuration files between multiple automation controller and automation hub VMs provisioned as part of the deployment. This network CIDR range defines the peer network that is used by the offering to peer between the GCP Filestore network and the custom VPC application subnet of the offering. Must be a minimum /29 segment.

Default: 192.168.243.0/29

Load Balancer Proxy Subnet Range

Ansible Automation Platform from GCP Marketplace is deployed using GCP’s native cloud capabilities to provide a scalable and reliable installation. As part of the Ansible Automation Platform from GCP Marketplace deployment topology two load balancers are deployed in front of the automation hub and automation controller VMs. All traffic is directed at these load balancers and is proxied to the available backend VMs. The deployment takes advantage of GCP’s native load balancing support enabling the customer to add additional ports (https) to the load balancers to capture and forward requests onto the backend VMs. This also provides request balancing and session tracking for better reliability. As part of the load balancer deployment, GCP requires creation of a special proxy network where GCP natively handles the redirection of requests to the backend VMs. This special proxy network is not used within Ansible Automation Platform from GCP Marketplace for any other purpose than GCP’s load balancer’s proxy network requirement. A /24 segment is required.

Default: 192.168.242.0/24

Controller Internal Load Balancer IP Address

This is the static IP Address assigned to the automation controller Load Balancer. This address must be within the Application Subnet Range segment.

Default: 192.168.240.20

Hub Internal Load Balancer IP Address

This is the static IP Address assigned to the automation hub Load Balancer. This address must be within the Application Subnet Range segment.

Default: 192.168.240.21

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.