Red Hat Ansible Automation Platform from GCP Marketplace is installed into infrastructure resources running within your GCP account.

Ansible Automation Platform from GCP Marketplace is designed to be private, with no public access allowed by default.

This requires customers to expose the deployed Internal Load Balancers (ILBs) themselves pursuant to their own network requirements and security practices. Some potential ways to expose the ILBs include VPC Peering, Transit Gateway, VPN, External Load Balancers, amongst others.

All cloud infrastructure components are deployed in a Virtual Private Cloud (VPC).

Customers can choose between deploying into an existing VPC, or to have the product deploy a new VPC for them. All VM instances and Cloud infrastructure have private IP addresses (allocation determined by the VPC and subnetworks specified at deployment time) by default.

All internal traffic is encrypted using self-signed certificates generated at deployment time (external traffic can also be encrypted by deploying your own certificate on the Internal Load Balancers deployed by the product).

The Ansible Automation Platform software runs as containers on the deployed VM instances.

Managed instance groups (MIGs) manage VM instance lifecycles and monitor the health of each service running on the VM instances, automatically cycling the VM instances down and replacing them with new VM instances if the health check fails to respond, ensuring that the Ansible Automation Platform services stays up and available to process requests.

The VM instances run a customized RedHat Enterprise Linux (RHEL) Google Cloud Machine Image as their base image. This Google Cloud Machine Image is preloaded with all the required container images and packages to run the Ansible Automation Platform (automation hub, automation controller, and Execution Node components).

A shared Google File Store (GFS) volume is mounted into each VM instance provisioned by the product and is used for shared access to common files and resources.

A Google Cloud SQL Service is provisioned by the product at deployment time and contains databases for both the automation controller and automation hub.

The Foundation product includes two Execution Nodes running on the same VM instances as the automation controller components (this is called a Hybrid Node configuration in Ansible Automation Platform). Additional Execution Node offerings can be purchased to increase the scale (total number of managed nodes) the Ansible Automation Platform deployment is licensed to automate. When deploying the Execution Node offerings into an existing Ansible Automation Platform Foundation deployment, additional Execution Node VM instances can be deployed and automatically connected to the automation controller of the Foundation deployment where they immediately begin processing automation tasks.

Ansible Automation Platform components are run as containers using the Podman container runtime on the VM instances. The Podman runtime configuration is managed as a system service using systemd to ensure uptime and availability, and restarting any failed containers automatically.

SELinux is enabled on the VM instances and is supported down to the container level.

Additional operational automations are provided by the offering, available as a separate docker container for download from registry.redhat.io. These additional operational automations include backup, restore, and upgrade.

Any Common Vulnerabilities and Exposures (CVEs) found in the RHEL OS base image, the Ansible Automation Platform containers, or any included packages are addressed during upgrade of the Ansible Automation Platform offering by swapping out the base RHEL Google Cloud Machine Image with a newer version including all required software, packages, and containers.

This is done automatically for you through the use of the included upgrade automation.

Customers can take advantage of these operational automations to simplify the operational readiness of Ansible Automation Platform within their own corporate standards freeing themselves up to focus on developing Ansible Automation to manage their own infrastructure and applications rather than spending time developing automations to manage Ansible Automation Platform.

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:

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

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.

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

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 two methods for deploying the application:

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

After deploying Ansible Automation Platform, use the following procedures to retrieve information about your deployment.

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

The extension begins provisioning.

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

The following table lists the offer types and the corresponding GCP instance types. Depending on the workload needs, you can choose a more suitable offer type for the extension nodes.

Extension node offers can be mixed and matched together to scale the Ansible Automation Platform deployment up.

Your GCP account must have the following Identity and Access Management (IAM) permissions to successfully create and manage extension nodes on Ansible Automation Platform.

Your GCP account must also be licensed to deploy extension node offers for Ansible Automation Platform from GCP Marketplace.

Minimum Permissions -

Cloud SQL Client
Cloud SQL Instance User
Editor
Logs Writer
Secret Manager Secret Accessor
IAP-secured Tunnel User

Pull the Docker image for the Ansible on Clouds operational container with the same tag as the version you are deploying to.

$ docker login registry.redhat.io

For example, if your foundation deployment version is 2.4.20230630-00, you must pull the operational image with tag 2.4.20230630 to deploy extension nodes to the foundation deployment.

Use the following commands:

$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630
$ docker pull $IMAGE --platform=linux/amd64

The following commands generate the required data file. These commands create a directory, and an empty data template that, when populated, is used during the deployment of the extension nodes.

You must populate the data file before triggering the operation. The variables listed in the data file are defined below.

Pull the Docker image for the Ansible on Clouds operational container with the same tag as your foundation deployment.

$ docker login registry.redhat.io

For example, if your foundation deployment version is 2.4.20230630-00, you must pull the operational image with tag 2.4.20230630 to deploy extension nodes to the foundation deployment.

Use the following commands:

$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630
$ docker pull $IMAGE --platform=linux/amd64

The following commands generate the required data file. These commands create a directory, and an empty data template that, when populated, is used during the upgrade.

When you have run these commands, a command_generator_data/extra_vars.yml template file is created. This template file resembles the following:

gcp_add_extension_nodes:
  cloud_credentials_path:
  deployment_name:
  extra_vars:
    gcp_compute_region:
    gcp_instance_group_name:
    gcp_instance_template_name:

You must populate the data file before triggering the operation. The variables listed in the data file are defined below.

If there are no errors, the extension node is removed successfully.

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.

Default: 192.168.240.0/24

Default: 192.168.241.0/24

Default: 192.168.243.0/29

Default: 192.168.242.0/24

Default: 192.168.240.20

Default: 192.168.240.21

Many networking configurations to access the platform are possible, but the following configurations have been validated to work with Ansible Automation Platform from GCP Marketplace.

VPC Peering is required for Ansible Automation Platform to access resources that reside on private VPCs or where transit routing between Google Cloud Platform and your on-premises network(s) exists. It offers the ability to directly connect different networks within your GCP infrastructure. VPCs are individually connected to one another with no other routing hops between them. VPC deployments omit access from the public internet by default.

This is also the deployment model for the GCP architecture used by Ansible Automation Platform from GCP Marketplace.

This is a simple peering model and is useful when connecting several networks.

Complex peering can be configured, but routing can become more complex over time.

When VPC peering and routing are configured, you can access Ansible Automation Platform through a VM on a connected VPC subnet, or directly if your organization has a transit routing setup between GCP and your local networks.

When two or more networks are peered, Google performs automated actions to assist with routing, but can perform routable updates to enable traffic flow within your GCP infrastructure.

Configure VPC peering with Ansible Automation Platform with the following procedure.

For additional information on routing tables, firewalls and other networking components regarding VPC Peering, see the GCP documentation.

It is possible to expose Ansible automation controller and Ansible private automation hub to the public internet if you want users to have access to the platform from any internet connected machine.

This is not recommended as a best practice for security reasons.

However this implementation can be secured with different GCP tools. This section describes how to connect a load balancer that faces the public internet, but it does not include steps to harden access through Google’s security products. Only use this approach if you intend to protect the public endpoints with Google Cloud Armor or similar product(s).

At this point you should have accesss to the Ansible Automation Platform automation controller UI. You can log in after you retrieve the administration password.

Repeat the same process for private automation hub. The process is identical except for selecting the instance group -aap-hub-igm during backend configuration.

The default administrator password for Ansible Automation Platform is generated randomly when Ansible Automation Platform from GCP Marketplace is deployed. Follow these steps to change the administrator password for both automation controller and automation hub.

By default, VM instances are secured with a self-signed SSL/TLS certificate with a validity period of ten years. When the certificate expires or you want VM instances to use your own certificate, you are required to replace the SSL/TLS certificate and key.

Ansible Automation Platform from GCP Marketplace is deployed with two internal application load balancers, one each in front of the hub and controller instances. These internal load balancers must be configured with SSL certificates after deployment completes.

To modify both the automation controller and automation hub load balancers, which have the name format <DEPLOYMENT_NAME>-aap-<cntrlr/hub>-int-lb.

To configure Red Hat Single Sign-On with an identity provider that can enable Multi factor Authentication (MFA), follow the steps here for connecting enterprise authentication to Ansible Automation Platform.

Securing infrastructure services is an important step in any cloud deployment. Follow the implementation and security suggestions from GCP documentation for services used as part of an Ansible Automation Platform from GCP Marketplace deployment.

Pull the Docker image for the Ansible on Clouds operational container with the same tag version as your deployment.

$ docker login registry.redhat.io

For example, if your foundation deployment version is 2.4.20230630-00, you must pull the operational image with tag 2.4.20230630.

Use the following commands:

$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630
$ docker pull $IMAGE --platform=linux/amd64

Some, but not all of the playbooks are described in this document. Here, those which are used either to retrieve information from the Ansible on Clouds deployment or to check it are described. These playbooks do not modify the deployment.

gcp_aap_health_check

This playbook checks if the Ansible application is healthy.

$ docker run --rm $IMAGE command_generator_vars gcp_aap_health_check

Which generates the following output:

===============================================
Playbook: gcp_aap_health_check
Description: This playbook checks if the deployment is healthy using the Ansible health service.
-----------------------------------------------
The health check consists of checking the Ansible Automation Platform from GCP Marketplace environemnt to verify it is healthy.

-----------------------------------------------
Command generator template:

docker run --rm $IMAGE command_generator gcp_aap_health_check [--ansible-config ansible_config_path>] -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone>'
===============================================

Launching this command by replacing the parameters generates a new command to launch and outputs:

...
PLAY RECAP *********************************************************************
localhost                  : ok=29   changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

A failed not equal zero indicates an issue with Ansible on Cloud deployment.

gcp_add_labels

This playbook adds labels to the deployment.

$ docker run --rm $IMAGE command_generator_vars gcp_add_labels

Which generates the following output:

===============================================
Playbook: gcp_add_labels
Description: This playbook adds labels to the deployment.
-----------------------------------------------
Add labels to the Ansible Automation Platform from GCP Marketplace deployment.

-----------------------------------------------
Command generator template:

docker run --rm $IMAGE command_generator gcp_add_labels -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone> gcp_labels=<gcp_labels>'
===============================================

The parameter gcp_labels is a comma separated list of key=value pairs to add or update. For example: key1=value1,key2=value2

Launching this command by replacing the parameters generates a new command to launch and outputs:

...
PLAY RECAP *********************************************************************
localhost                  : ok=22   changed=2    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

gcp_remove_labels

This playbook removes labels from the deployment.

$ docker run --rm $IMAGE command_generator_vars gcp_remove_labels

Which generates the following output:

===============================================
Playbook: gcp_remove_labels
Description: This playbook removes labels from the deployment.
-----------------------------------------------
Remove labels from the Ansible Automation Platform from GCP Marketplace deployment.

-----------------------------------------------
Command generator template:

docker run --rm $IMAGE command_generator gcp_remove_labels -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone> gcp_labels=<gcp_labels>'
===============================================

The parameter gcp_labels is a comma separated list of keys to remove. For example: key1,key2

Launching this command by replacing the parameters generates a new command to launch and outputs:

...
PLAY RECAP *********************************************************************
localhost                  : ok=22   changed=2    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

gcp_check_aoc_version

This playbook checks if the Ansible on Cloud version is the same as the command generator container. The check is done each time a playbook is called.

$ docker run --rm $IMAGE command_generator_vars gcp_check_aoc_version

Which generates the following output:

===============================================
Playbook: gcp_check_aoc_version
Description: Check the operational container version matches the Ansible on Clouds version.
-----------------------------------------------
Check the operational container version matches the Ansible on Clouds version.

-----------------------------------------------
Command generator template:

docker run --rm $IMAGE command_generator gcp_check_aoc_version [--ansible-config ansible_config_path>] -c <cloud_credentials_path> -d <deployment_name>
===============================================

Launching this command by replacing the parameters generates a new command to launch and outputs:

...
TASK [redhat.ansible_on_clouds.standalone_check_aoc_version : Verify operational playbook and Ansible on Clouds deployment versions] ***
ok: [localhost] => {
    "changed": false,
    "msg": "This operation playbook version and the Ansible on Clouds deployment version are identical: 2.4.20230606-00"
}

PLAY RECAP *********************************************************************
localhost                  : ok=8    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

A failed not equal zero means the Ansible on Clouds deployment version does not match the command_generator container and a different version is required for the command generator to manage that deployment.

gcp_get_aoc_version

This playbook retrieves the version of the Ansible on Clouds deployment.

$ docker run --rm $IMAGE command_generator_vars gcp_get_aoc_version

Which generates the following output:

===============================================
Playbook: gcp_get_aoc_version
Description: Get the current Ansible on Clouds version.
-----------------------------------------------
Get the current Ansible on Clouds version.

-----------------------------------------------
Command generator template:

docker run --rm $IMAGE command_generator gcp_get_aoc_version [--ansible-config ansible_config_path>] -c <cloud_credentials_path> -d <deployment_name>
===============================================

Launching this command by replacing the parameters generates a new command to launch and outputs:

...
TASK [Print version] ***********************************************************
ok: [localhost] => {
    "msg": "The AOC version is 2.4.20230606-00"
}

PLAY RECAP *********************************************************************
localhost                  : ok=5    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

gcp_health_check

This playbook checks if the nodes and Ansible application are healthy.

$ docker run --rm $IMAGE command_generator_vars gcp_health_check

Which generates the following output:

===============================================
Playbook: gcp_health_check
Description: This playbook checks if the Ansible Automation Platform from GCP Marketplace deployment is healthy.
-----------------------------------------------
The health check consists of checking the Ansible Automation Platform from GCP Marketplace heatlh checks
and the health of the monitoring exporter.

-----------------------------------------------
Command generator template:

docker run --rm $IMAGE command_generator gcp_health_check [--ansible-config ansible_config_path>] -c <cloud_credentials_path> -d <deployment_name> --extra-vars 'gcp_compute_region=<gcp_compute_region> gcp_compute_zone=<gcp_compute_zone>'
===============================================

Launching this command by replacing the parameters will generate a new command to launch and will output:

...
PLAY RECAP *********************************************************************
localhost                  : ok=47   changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

A failed not equal zero indicates an issue with nodes or the Ansible on Cloud deployment.

gcp_list_deployments

This playbook list the deployments, the region and zone are optional.

$ docker run --rm $IMAGE command_generator_vars gcp_list_deployments

Which generates the following output:

===============================================
Playbook: gcp_list_deployments
Description: This playbook generates a list of available Ansible Automation Platform from GCP Marketplace deployments.
-----------------------------------------------
This playbook is used to generate a list of available Ansible Automation Platform from GCP Marketplace deployments.

-----------------------------------------------
Command generator template:

docker run --rm $IMAGE command_generator gcp_list_deployments -c <cloud_credentials_path> --extra-vars '[gcp_compute_region=<gcp_compute_region>] [gcp_compute_zone=<gcp_compute_zone>]'
===============================================

Launching this command by replacing the parameters generates a new command to launch and outputs:

...
TASK [Show deployment list] ****************************************************
ok: [localhost] => {
    "msg": [
        "Deployment list: ['dep1', 'dep2', 'dep3']"
    ]
}

PLAY RECAP *********************************************************************
localhost                  : ok=7    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

gcp_nodes_health_check

This playbook checks if the nodes are healthy.

$ docker run --rm $IMAGE command_generator_vars gcp_nodes_health_check

Which generates the following output:

===============================================
Playbook: gcp_nodes_health_check
Description: This role runs a health check on a group of nodes in the Ansible Automation Platform from GCP Marketplace deployment
-----------------------------------------------
The playbook checks if the Ansible Automation Platform from GCP Marketplace monitoring exporter is up and running.

-----------------------------------------------
Command generator template:

docker run --rm $IMAGE command_generator gcp_nodes_health_check [--ansible-config ansible_config_path>] -d <deployment_name> -c <cloud_credentials_path> --extra-vars 'check_monitoring=True'
===============================================

Launching this command by replacing the parameters generates a new command to launch and outputs:

...
PLAY RECAP *********************************************************************
localhost                  : ok=47   changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

A failed not equal zero indicates an issue with nodes in the deployment.

Automating against your licensed managed node allocation in the offer is provided with the following operational expectations. Automating outside of the boundaries of these criteria is not supported, but can still function depending on your automation.

If you want to scale your deployment beyond the initial number of supported managed nodes, Ansible Automation Platform from GCP Marketplace can be manually scaled using separately sold extension nodes.

Extension nodes are additional compute instances that can be deployed to scale-up or scale-out depending on the immediate scaling requirements. If your requirements are for higher parallel automation operations you can select compute shapes that scale-up, while if you have a requirement to automate more nodes over time you can select compute shapes that scale out.

Extension nodes are the supported way of extending the capabilities of Ansible Automation Platform from GCP Marketplace.

You can start or stop the logging and monitoring after the deployment by using the gcp_setup_logging_monitoring playbook available from registry.redhat.com.

required-roles:

Service Account User
Compute Instance Admin (v1)

required-permissions:

cloudsql.instances.connect
cloudsql.instances.get
cloudsql.instances.login
cloudsql.users.update
compute.addresses.get
compute.addresses.list
compute.instances.delete
compute.instances.get
compute.instances.list
compute.instances.setLabels
compute.zoneOperations.get
deploymentmanager.deployments.list
deploymentmanager.manifests.get
deploymentmanager.manifests.list
file.instances.get
file.instances.list
file.instances.update
file.operations.get
iap.tunnelInstances.accessViaIAP
logging.logEntries.create
monitoring.timeSeries.create
resourcemanager.projects.get
runtimeconfig.variables.create
runtimeconfig.variables.get
runtimeconfig.variables.list
runtimeconfig.variables.update
secretmanager.secrets.create
secretmanager.secrets.delete
secretmanager.secrets.get
secretmanager.versions.add
secretmanager.versions.get
secretmanager.versions.list
servicenetworking.operations.get
servicenetworking.services.addPeering
serviceusage.services.list

$ docker login registry.redhat.io

$ export IMAGE=registry.redhat.io/ansible-on-clouds/ansible-on-clouds-ops-rhel9:2.4.20230630
$ docker pull $IMAGE --platform=linux/amd64

gcp_setup_logging_monitoring:
  cloud_credentials_path: ~/secrets/GCP-secrets.json
  deployment_name: AnsibleAutomationPlatform
  extra_vars:

docker run --rm -v $(pwd)/command_generator_data:/data $IMAGE command_generator gcp_setup_logging_monitoring \
--data-file /data/logging-monitoring.yml

docker run --rm --env PLATFORM=GCP -v </path/to/gcp/service-account.json>:/home/runner/.gcp/credentials:ro \
--env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=<deployment_name> --env GENERATE_INVENTORY=true  \
$IMAGE redhat.ansible_on_clouds.gcp_setup_logging_monitoring -e 'gcp_deployment_name=<deployment_name> \
gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials  monitoring_enabled=<monitoring_enabled> \
logging_enabled=<logging_enabled> default_collector_interval=<interval>'

$ docker run --rm --env PLATFORM=GCP -v /path/to/credentials:/home/runner/.gcp/credentials:ro \
--env ANSIBLE_CONFIG=../gcp-ansible.cfg --env DEPLOYMENT_NAME=mu-deployment \
--env GENERATE_INVENTORY=true  $IMAGE redhat.ansible_on_clouds.gcp_setup_logging_monitoring \
-e 'gcp_deployment_name=mu-deployment \
gcp_service_account_credentials_json_path=/home/runner/.gcp/credentials  components=["hubs","controllers"]\
monitoring_enabled=True logging_enabled=True default_collector_interval=60s'

TASK [redhat.ansible_on_clouds.setup_logging_monitoring : Update runtime variable logging_enabled] ***
changed: [<user_name> -> localhost]

TASK [redhat.ansible_on_clouds.setup_logging_monitoring : Update runtime variable monitoring_enabled] ***
changed: [<user_name> -> localhost]

PLAY RECAP *********************************************************************
<user_name>     : ok=20   changed=6    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0

Metrics are provided by Ansible, Podman and Google Ops Agent. The Google Ops Agent and Podman are installed on automation controller and automation hub VM instances, however Ansible metrics are only installed on automation hub instances.

A configurable process (collector) runs on each automation controller VM instance and automation hub VM instance to export the collected Ansible and Podman metrics to Google Cloud Platform Monitoring. As the Google Ops Agent is part of the Google Cloud solution, it has its own configuration file.

The Google Ops Agent is also responsible for the logging configuration.

The service APIs monitoring.googleapis.com and logging.googleapis.com must be respectively enabled for the monitoring and logging capabilities.

# This value will be set at deployment time.
# Set to zero if monitoringEnabled is false otherwise 59s
# The collection interval for each collector will be the minimum
# between the defaultCollectorInterval and all send Interval
# of a given collector
# NB: The awx exported should not run on controllers as
# it duplicates the number of records sent to GCP Monitoring

defaultCollectorInterval: $DEFAULT_COLLECTOR_INTERVAL
collectors:
- name: podman
 endpoint: http://localhost:9882/podman/metrics
 enabled: true

# list of metrics to exclude
# excludedMetrics:
# - podman_container_created_seconds

 metrics:
 - name: podman_container_exit_code
   # interval on which the metric must be pushed to gcp
   sendInterval: 59s

# This value will be set at deployment time.
# Set to zero if monitoringEnabled is false otherwise 59s
# The collection interval for each collector will be the minimum
# between the defaultCollectorInterval and all sendInterval
# of a given collector
# NB: The awx exporter should not run on controllers as
# it duplicates the number of records sent to GCP Monitoring

defaultCollectorInterval: 59s
collectors:
- name: awx
 userName: admin
 endpoint: http://<Controller_LB_IP>/api/v2/metrics/
 enabled: true
 metrics:
 - name: awx_inventories_total
   # interval on which the metric must be pushed to gcp
   sendInterval: 59s
- name: podman
 endpoint: http://localhost:9882/podman/metrics
 enabled: true

# list of metrics to exclude
#  excludedMetrics:
#  - podman_container_created_seconds

 metrics:
 - name: podman_container_exit_code
   # interval on which the metric must be pushed to gcp
   sendInterval: 59s

A backup enables you to backup your environment by saving the database and the shared file system. A new environment is created during the restore using the saved shared file system. When the new environment is in place, the process restores the database.

The backup and restore process must use the same version. If you performed the backup with an earlier version, you must use the restore process of that version. Then, if required, you can run an upgrade.

You must also make a backup before an upgrade. For further information, read Upgrading your deployment

The backup process involves taking a backup of the Cloud SQL database and filestore instances at a given point in time. The backup playbook requires an active Ansible Automation Platform from GCP Marketplace foundation deployment to be running.

A bucket needs to be created in your project as restore information will be stored in that bucket.

The bucket can contain multiple backups from the same deployment or different ones. A backup will generate a directory named <prefix>-<deployment_name>-<timestamp> and a file named <prefix>-<deployment_name>-<timestamp>.json. The directory contains the awx and pulp databases backup, the deployment configuration and the secrets. The json file contains information for the restore procedure.

Playbooks are provided through the CLI to list and delete backups.

The following procedures describe how to backup the Ansible Automation Platform from GCP Marketplace deployment.

required-roles:

Service Account User
Compute Instance Admin (v1)
required-permissions:

compute.instances.list
deploymentmanager.deployments.get
deploymentmanager.manifests.get
deploymentmanager.manifests.list
deploymentmanager.resources.list
file.backups.create
file.operations.get
iap.tunnelInstances.accessViaIAP
storage.objects.create
storage.objects.list

The restore process creates a new deployment, and restores the filestore and SQL database instance to the specified backup.

The following procedures describe how to restore the Ansible Automation Platform from GCP Marketplace deployment.

required-roles:

Cloud SQL Client
Cloud SQL Instance User
Compute Instance Admin (v1)
Compute Network Admin
Editor
Logs Writer
Secret Manager Secret Accessor
Service Account User
required-permissions:

compute.instances.list
compute.networks.create
deploymentmanager.deployments.create
deploymentmanager.deployments.get
deploymentmanager.operations.get
file.instances.create
file.operations.get
iap.tunnelInstances.accessViaIAP
secretmanager.secrets.create
secretmanager.secrets.delete
secretmanager.secrets.get
secretmanager.secrets.update
secretmanager.versions.add
secretmanager.versions.list
storage.objects.get
storage.objects.list

TASK [redhat.ansible_on_clouds.standalone_gcp_restore : [restore_deployment] Restore awx db] *
fatal: [localhost -> dvernier-restore1-aap-cntrlr-x2c6]: FAILED!

If you would like to restore the earlier version of your Ansible Automation Platform environment to the state it was in before the upgrade, follow the Ansible on Clouds 2.3 restore instructions.

Extension nodes are created as deployments in GCP Deployment Mananger. As such, the process to delete an Ansible Automation Platform extension node is the same as the process to delete the main Ansible Automation Platform deployment.

The extension node is deleted.

It can take some time to complete the deletion.

The following procedures describes how to delete any resources left behind after an upgrade.

The following procedures describe how to delete any resources left behind when uninstalling your Ansible Automation Platform deployment, after having run a backup on it.

The following procedures describes how to delete any resources left behind when uninstalling your Ansible Automation Platform deployment.

To ensure a successful upgrade, logging and monitoring must be disabled before running the upgrade. Follow these instructions to toggle off monitoring and logging for your current version before beginning the upgrade. when the upgrade has completed, logging and monitoring can be reenabled by following these instructions.

On Linux, any file or directory created by the command generator is owned by root:root by default. To change the ownership of the files and directories, you can run the sudo chmod command after the files are created:

# Change the owner of the command_generator_data directory recursively
$ sudo chown -R $USER:$USER command_generator_data/

# Check the permissions
$ ls -la command_generator_data/

The command generator currently expects to use the Docker CLI in the daemon mode. The default Docker installation does not have User namespace mapping for Discretionary access control (DAC). So, for any file created by root from the container will also be owned by root on the host if the file is located in a shared volume.

You can learn more about the Linux namespaces, including the User namespace at the article The 7 most used Linux namespaces.

Upgrading Ansible Automation Platform to 2.4.20230630 updates the protocol of its internal load balancers from HTTP to HTTPs. If additional networking configurations were added, they can also be updated to ensure connectivity. When the upgrade has succeeded, you must revalidate any additional added networking configurations.

API endpoints for Controller must contain a trailing slash in order for requests to go through. Automatic trailing slash redirects are not supported in this current offering of Ansible Automation Platform from GCP Marketplace. For example a request such as <controller_base_url>/api/v2/metrics times out while <controller_base_url>/api/v2/metrics/ goes through.

When removing extension node using the Ansible-on-Clouds ops playbook, ensure you have provided correct instance group name and instance template name. Incorrect instance group name and instance template name results in some orphan resources.

When you update any secrets in the GCP secret manager, ensure that the latest secret version is enabled. For example, if you have two secret versions for a <deployment-name>-aap-admin secret, secret version 2 must be enabled, where <deployment-name> is the name of your foundation deployment.

Red Hat supports changes to the following options:

Ansible Automation Platform from GCP Marketplace is delivered through virtual machines that are based on a VM image produced by the Red Hat Ansible team. This image contains packages from Red Hat and Google in order to properly function on Google Cloud Platform and run Red Hat Ansible Automation Platform. The image contains the following Google packages and containers: