Manually install the Console agent in Google Cloud
To manually install the Console agent on your own Linux host, you need to review host requirements, set up your networking, prepare Google Cloud permissions, enable Google Cloud APIs, install the Console, and then provide the permissions that you prepared.
-
You should have an understanding of Console agents.
-
You should review Console agent limitations.
Step 1: Review host requirements
The Console agent software must run on a host that meets specific operating system requirements, RAM requirements, port requirements, and so on.
|
The Console agent reserves the UID and GID range of 19000 to 19200. This range is fixed and cannot be modified. If any third-party software on your host is using UIDs or GIDs within this range, the agent installation will fail. NetApp recommends using a host that is free of third-party software to avoid conflicts. |
- Dedicated host
-
The Console agent is not supported on a host that is shared with other applications. The host must be a dedicated host. The host can be of any architecture that meets the following size requirements:
-
CPU: 8 cores or 8 vCPUs
-
RAM: 32 GB
-
Disk space: 165 GB is recommended for the host, with the following partition requirements:
-
/opt
: 120 GiB of space must be availableThe agent uses
/opt
to install the/opt/application/netapp
directory and its contents. -
/var
: 40 GiB of space must be availableThe Console agent requires this space in
/var
because Docker or Podman are architected to create the containers within this directory. Specifically, they will create containers in the/var/lib/containers/storage
directory. External mounts or symlinks do not work for this space.
-
-
- Hypervisor
-
A bare metal or hosted hypervisor that is certified to run a supported operating system is required.
- Operating system and container requirements
-
The Console agent is supported with the following operating systems when using the Console in standard mode or restricted mode. A container orchestration tool is required before you install the agent.
Operating system Supported OS versions Supported agent versions Required container tool SELinux
aRed Hat Enterprise Linux
9.1 to 9.4
8.6 to 8.10
-
English language versions only.
-
The host must be registered with Red Hat Subscription Management. If it's not registered, the host can't access repositories to update required 3rd-party software during agent installation.
3.9.50 or later with the Console in standard mode or restricted mode
Podman version 4.6.1 or 4.9.4
Supported in enforcing mode or permissive mode
-
Management of Cloud Volumes ONTAP systems is NOT supported by agents that have SELinux enabled on the operating system.
Ubuntu
24.04 LTS
3.9.45 or later with the NetApp Console in standard mode or restricted mode
Docker Engine 23.06 to 28.0.0.
Not supported
22.04 LTS
3.9.50 or later
Docker Engine 23.0.6 to 28.0.0.
Not supported
-
- Google Cloud machine type
-
An instance type that meets the CPU and RAM requirements above. We recommend n2-standard-8.
The Console agent is supported in Google Cloud on a VM instance with an OS that supports Shielded VM features
- Disk space in /opt
-
100 GiB of space must be available
The agent uses
/opt
to install the/opt/application/netapp
directory and its contents. - Disk space in /var
-
20 GiB of space must be available
The Console agent requires this space in
/var
because Docker or Podman are architected to create the containers within this directory. Specifically, they will create containers in the/var/lib/containers/storage
directory. External mounts or symlinks do not work for this space.
Step 2: Install Podman or Docker Engine
Depending on your operating system, either Podman or Docker Engine is required before installing the agent.
-
Podman is required for Red Hat Enterprise Linux 8 and 9.
-
Docker Engine is required for Ubuntu.
Follow these steps to install and configure Podman:
-
Enable and start the podman.socket service
-
Install python3
-
Install the podman-compose package version 1.0.6
-
Add podman-compose to the PATH environment variable
-
If using Red Hat Enterprise Linux 8, verify that your Podman version is using Aardvark DNS instead of CNI
|
Adjust the aardvark-dns port (default: 53) after installing the agent to avoid DNS port conflicts. Follow the instructions to configure the port. |
-
Remove the podman-docker package if it's installed on the host.
dnf remove podman-docker rm /var/run/docker.sock
-
Install Podman.
You can obtain Podman from official Red Hat Enterprise Linux repositories.
For Red Hat Enterprise Linux 9:
sudo dnf install podman-2:<version>
Where <version> is the supported version of Podman that you're installing. View the supported Podman versions.
For Red Hat Enterprise Linux 8:
sudo dnf install podman-3:<version>
Where <version> is the supported version of Podman that you're installing. View the supported Podman versions.
-
Enable and start the podman.socket service.
sudo systemctl enable --now podman.socket
-
Install python3.
sudo dnf install python3
-
Install the EPEL repository package if it's not already available on your system.
-
If using Red Hat Enterprise:
This step is required because podman-compose is available from the Extra Packages for Enterprise Linux (EPEL) repository.
For Red Hat Enterprise Linux 9:
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
For Red Hat Enterprise Linux 8:
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
-
Install podman-compose package 1.0.6.
sudo dnf install podman-compose-1.0.6
Using the dnf install
command meets the requirement for adding podman-compose to the PATH environment variable. The installation command adds podman-compose to /usr/bin, which is already included in thesecure_path
option on the host. -
If using Red Hat Enterprise Linux 8, verify that your Podman version is using NetAvark with Aardvark DNS instead of CNI.
-
Check to see if your networkBackend is set to CNI by running the following command:
podman info | grep networkBackend
-
If the networkBackend is set to
CNI
, you'll need to change it tonetavark
. -
Install
netavark
andaardvark-dns
using the following command:dnf install aardvark-dns netavark
-
Open the
/etc/containers/containers.conf
file and modify the network_backend option to use "netavark" instead of "cni".
If
/etc/containers/containers.conf
doesn't exist, make the configuration changes to/usr/share/containers/containers.conf
. -
-
Restart podman.
systemctl restart podman
-
Confirm networkBackend is now changed to "netavark" using the following command:
podman info | grep networkBackend
Follow the documentation from Docker to install Docker Engine.
-
View installation instructions from Docker
Follow the steps to install a supported Docker Engine version. Do not install the latest version, as it is unsupported by the Console.
-
Verify that Docker is enabled and running.
sudo systemctl enable docker && sudo systemctl start docker
Step 3: Set up networking
Set up your networking so the Console agent can manage resources and processes within your hybrid cloud environment. For example, you need to ensure that connections are available to target networks and that outbound internet access is available.
- Connections to target networks
-
The Console agent requires a network connection to the location where you're planning to create and manage systems. For example, the network where you plan to create Cloud Volumes ONTAP systems or a storage system in your on-premises environment.
- Outbound internet access
-
The network location where you deploy the Console agent must have an outbound internet connection to contact specific endpoints.
- Endpoints contacted from computers when using the web-based NetApp Console
-
Computers that access the Console from a web browser must have the ability to contact several endpoints. You'll need to use the Console to set up the Console agent and for day-to-day use of the Console.
- Endpoints contacted from the Console agent
-
The Console agent requires outbound internet access to contact the following endpoints to manage resources and processes within your public cloud environment for day-to-day operations.
The endpoints listed below are all CNAME entries.
Endpoints Purpose https://www.googleapis.com/compute/v1/
https://compute.googleapis.com/compute/v1
https://cloudresourcemanager.googleapis.com/v1/projects
https://www.googleapis.com/compute/beta
https://storage.googleapis.com/storage/v1
https://www.googleapis.com/storage/v1
https://iam.googleapis.com/v1
https://cloudkms.googleapis.com/v1
https://www.googleapis.com/deploymentmanager/v2/projectsTo manage resources in Google Cloud.
https://mysupport.netapp.com
To obtain licensing information and to send AutoSupport messages to NetApp support.
https://signin.b2c.netapp.com
To update NetApp Support Site (NSS) credentials or to add new NSS credentials to the NetApp Console.
https://api.bluexp.netapp.com
https://netapp-cloud-account.auth0.com
https://netapp-cloud-account.us.auth0.com
https://console.netapp.com
https://components.console.bluexp.netapp.com
https://cdn.auth0.comTo provide features and services within the NetApp Console.
https://bluexpinfraprod.eastus2.data.azurecr.io
https://bluexpinfraprod.azurecr.ioTo obtain images for Console agent upgrades.
-
When you deploy a new agent, the validation check tests connectivity to current endpoints. If you use previous endpoints, the validation check fails. To avoid this failure, skip the validation check.
Although the previous endpoints are still supported, NetApp recommends updating your firewall rules to the current endpoints as soon as possible. Learn how to update your endpoint list.
-
When you update to the current endpoints in your firewall, your existing agents will continue to work.
-
- Proxy server
-
NetApp supports both explicit and transparent proxy configurations. If you are using a transparent proxy, you only need to provide the certificate for the proxy server. If you are using an explicit proxy, you'll also need the IP address and credentials.
-
IP address
-
Credentials
-
HTTPS certificate
-
- Ports
-
There's no incoming traffic to the Console agent, unless you initiate it or if it is used as a proxy to send AutoSupport messages from Cloud Volumes ONTAP to NetApp Support.
-
HTTP (80) and HTTPS (443) provide access to the local UI, which you'll use in rare circumstances.
-
SSH (22) is only needed if you need to connect to the host for troubleshooting.
-
Inbound connections over port 3128 are required if you deploy Cloud Volumes ONTAP systems in a subnet where an outbound internet connection isn't available.
If Cloud Volumes ONTAP systems don't have an outbound internet connection to send AutoSupport messages, the Console automatically configures those systems to use a proxy server that's included with the Console agent. The only requirement is to ensure that the Console agent's security group allows inbound connections over port 3128. You'll need to open this port after you deploy the Console agent.
-
- Enable NTP
-
If you're planning to use NetApp Data Classification to scan your corporate data sources, you should enable a Network Time Protocol (NTP) service on both the Console agent and the NetApp Data Classification system so that the time is synchronized between the systems. Learn more about NetApp Data classification
Step 4: Set up permissions for the Console agent
A Google Cloud service account is required to provide the Console agent with the permissions that the Console needs to manage resources in Google Cloud. When you create the Console agent, you'll need to associate this service account with the Console agent VM.
It's your responsibility to update the custom role as new permissions are added in subsequent releases. If new permissions are required, they will be listed in the release notes.
-
Create a custom role in Google Cloud:
-
Create a YAML file that includes the contents of the service account permissions for the Console agent.
-
From Google Cloud, activate cloud shell.
-
Upload the YAML file that includes the required permissions.
-
Create a custom role by using the
gcloud iam roles create
command.The following example creates a role named "connector" at the project level:
gcloud iam roles create connector --project=myproject --file=connector.yaml
-
-
Create a service account in Google Cloud and assign the role to the service account:
-
From the IAM & Admin service, select Service Accounts > Create Service Account.
-
Enter service account details and select Create and Continue.
-
Select the role that you just created.
-
Finish the remaining steps to create the role.
-
-
If you plan to deploy Cloud Volumes ONTAP systems in different projects than the project where the Console agent resides, then you'll need to provide the Console agent's service account with access to those projects.
For example, let's say the Console agent is in project 1 and you want to create Cloud Volumes ONTAP systems in project 2. You'll need to grant access to the service account in project 2.
-
From the IAM & Admin service, select the Google Cloud project where you want to create Cloud Volumes ONTAP systems.
-
On the IAM page, select Grant Access and provide the required details.
-
Enter the email of the Console agent's service account.
-
Select the Console agent's custom role.
-
Select Save.
-
For more details, refer to Google Cloud documentation
-
Step 5: Set up shared VPC permissions
If you are using a shared VPC to deploy resources into a service project, then you'll need to prepare your permissions.
This table is for reference and your environment should reflect the permissions table when IAM configuration is complete.
View shared VPC permissions
Identity | Creator | Hosted in | Service project permissions | Host project permissions | Purpose |
---|---|---|---|---|---|
Google account to deploy the agent |
Custom |
Service Project |
compute.networkUser |
Deploying the agent in the service project |
|
agent service account |
Custom |
Service project |
compute.networkUser |
Deploying and maintaining Cloud Volumes ONTAP and services in the service project |
|
Cloud Volumes ONTAP service account |
Custom |
Service project |
storage.admin |
N/A |
(Optional) For NetApp Cloud Tiering and NetApp Backup and Recovery |
Google APIs service agent |
Google Cloud |
Service project |
(Default) Editor |
compute.networkUser |
Interacts with Google Cloud APIs on behalf of deployment. Allows the Console to use the shared network. |
Google Compute Engine default service account |
Google Cloud |
Service project |
(Default) Editor |
compute.networkUser |
Deploys Google Cloud instances and compute infrastructure on behalf of deployment. Allows the Console to use the shared network. |
Notes:
-
deploymentmanager.editor is only required at the host project if you are not passing firewall rules to the deployment and are choosing to let the Console create them for you. The NetApp Console creates a deployment in the host project which contains the VPC0 firewall rule if no rule is specified.
-
firewall.create and firewall.delete are only required if you are not passing firewall rules to the deployment and are choosing to let the Console create them for you. These permissions reside in the Console account .yaml file. If you are deploying an HA pair using a shared VPC, these permissions will be used to create the firewall rules for VPC1, 2 and 3. For all other deployments, these permissions will also be used to create rules for VPC0.
-
For Cloud Tiering, the tiering service account must have the serviceAccount.user role on the service account, not just at the project level. Currently if you assign serviceAccount.user at the project level, the permissions don't show when you query the service account with getIAMPolicy.
Step 6: Enable Google Cloud APIs
Several Google Cloud APIs must be enabled before you can deploy Cloud Volumes ONTAP systems in Google Cloud.
-
Enable the following Google Cloud APIs in your project:
-
Cloud Deployment Manager V2 API
-
Cloud Logging API
-
Cloud Resource Manager API
-
Compute Engine API
-
Identity and Access Management (IAM) API
-
Cloud Key Management Service (KMS) API
(Required only if you are planning to use NetApp Backup and Recovery with customer-managed encryption keys (CMEK))
-
Step 7: Install the Console agent
After the pre-requisites are complete, you can manually install the software on your own Linux host.
You should have the following:
-
Root privileges to install the Console agent.
-
Details about a proxy server, if a proxy is required for internet access from the Console agent.
You have the option to configure a proxy server after installation but doing so requires restarting the Console agent.
-
A CA-signed certificate, if the proxy server uses HTTPS or if the proxy is an intercepting proxy.
|
You cannot set a certificate for a transparent proxy server when manually installing the Console agent. If you need to set a certificate for a transparent proxy server, you must use the Maintenance Console after installation. Learn more about the Agent Maintenance Console. |
The installer that is available on the NetApp Support Site might be an earlier version. After installation, the Console agent automatically updates itself if a new version is available.
-
If the http_proxy or https_proxy system variables are set on the host, remove them:
unset http_proxy unset https_proxy
If you don't remove these system variables, the installation fails.
-
Download the Console agent software from the NetApp Support Site, and then copy it to the Linux host.
You should download the "online" agent installer that's meant for use in your network or in the cloud.
-
Assign permissions to run the script.
chmod +x NetApp_Console_Agent_Cloud_<version>
Where <version> is the version of the Console agent that you downloaded.
-
If installing in a Government Cloud environment, disable the configuration checks. Learn how to disable configuration checks for manual installations.
-
Run the installation script.
./NetApp_Console_Agent_Cloud_<version> --proxy <HTTP or HTTPS proxy server> --cacert <path and file name of a CA-signed certificate>
You'll need to add proxy information if your network requires a proxy for internet access. You can add either a transparent or explicit proxy. The --proxy and --cacert parameters are optional and you won't be prompted to add them. If you have a proxy server, you will need to enter the parameters as shown.
Here is an example configuring an explicit proxy server with a CA-signed certificate:
./NetApp_Console_Agent_Cloud_v4.0.0--proxy https://user:password@10.0.0.30:8080/ --cacert /tmp/cacert/certificate.cer
--proxy
configures the Console agent to use an HTTP or HTTPS proxy server using one of the following formats:-
http://address:port
-
http://user-name:password@address:port
-
http://domain-name%92user-name:password@address:port
-
https://address:port
-
https://user-name:password@address:port
-
https://domain-name%92user-name:password@address:port
Note the following:
-
The user can be a local user or domain user.
-
For a domain user, you must use the ASCII code for a \ as shown above.
-
The Console agent doesn't support user names or passwords that include the @ character.
-
If the password includes any of the following special characters, you must escape that special character by prepending it with a backslash: & or !
For example:
http://bxpproxyuser:netapp1\!@address:3128
-
-
--cacert
specifies a CA-signed certificate to use for HTTPS access between Console agent and the proxy server. This parameter is required for HTTPS proxy servers, intercepting proxy servers, and transparent proxy servers.
+
Here is an example configuring a transparent proxy server. When you configure a transparent proxy, you don't need to define the proxy server. You only add a CA-signed certificate to your Console agent host:
+
./NetApp_Console_Agent_Cloud_v4.0.0 --cacert /tmp/cacert/certificate.cer
-
If you used Podman, you'll need to adjust the aardvark-dns port.
-
SSH to the Console agent virtual machine.
-
Open podman /usr/share/containers/containers.conf file and modify the chosen port for Aardvark DNS service. For example, change it to 54.
vi /usr/share/containers/containers.conf ... # Port to use for dns forwarding daemon with netavark in rootful bridge # mode and dns enabled. # Using an alternate port might be useful if other DNS services should # run on the machine. # dns_bind_port = 54 ... Esc:wq
-
Reboot the Console agent virtual machine.
-
-
Wait for the installation to complete.
At the end of the installation, the Console agent service (occm) restarts twice if you specified a proxy server.
|
If the installation fails, you can view the installation report and logs to help you fix the issues. Learn how to troubleshoot installation issues. |
-
Open a web browser from a host that has a connection to the Console agent virtual machine and enter the following URL:
https://ipaddress
-
After you log in, set up the Console agent:
-
Specify the organization to associate with the Console agent.
-
Enter a name for the system.
-
Under Are you running in a secured environment? keep restricted mode disabled.
You should keep restricted mode disabled because these steps describe how to use the Console in standard mode. You should enable restricted mode only if you have a secure environment and want to disconnect this account from backend services. If that's the case, follow steps to get started with the NetApp Console in restricted mode.
-
Select Let's start.
If the installation fails, you can view logs and a report to help you troubleshoot. Learn how to troubleshoot installation issues. -
If you have Google Cloud Storage buckets in the same Google Cloud account where you created the Console agent, you'll see a Google Cloud Storage system appear on the Systems page automatically. Learn how to manage Google Cloud Storage from the NetApp Console
Step 8: Provide permissions to Console agent
You need to provide the Console agent with the Google Cloud permissions that you previously set up. Providing the permissions enables the Console agent to manage your data and storage infrastructure in Google Cloud.
-
Go to the Google Cloud portal and assign the service account to the Console agent VM instance.
-
If you want to manage resources in other Google Cloud projects, grant access by adding the service account with the Console agent role to that project. You'll need to repeat this step for each project.