Upgrade Containerized Cloud Exchange - Netskope Technical Documentation

Use these steps to upgrade a containerized Cloud Exchange deployment, standalone or HA, to the latest version. For the supported upgrade paths and the other deployment type, refer to Upgrade Cloud Exchange.

Important

Contact your SE/AM if you have questions regarding Cloud Exchange installation, deployment, configuration, and upgrade.

Prerequisites

Before you start the upgrade, make sure your instance meets the Cloud Exchange System Requirements.
Disable all source plugins in all modules, and wait for the queued tasks to finish:
1. Wait 20 to 30 minutes after you disable the source plugins.
2. Go to Settings > Logging, click Filter Query, enter this filter in the Filters field, and click Load.
```
message Like "Ingested " || message Like "Stored " || message Like "task(s)" || message Like "Completed storing"
```
3. Monitor the filtered logs. When no new logs appear, continue with the upgrade.
4. After the upgrade is complete, enable the source plugins that you disabled.
Keep the maintenance password ready. You need it to complete some of the steps.

Important

If you lose the maintenance password, your existing data cannot be retained.

RabbitMQ data migration is not supported, because the queue type changed from Classic to Quorum.

Standalone Deployment

To v7.0.0 from v5.1.1, v5.1.2, v6.0.0, v6.0.1, v6.1.0 Standalone Deployment

Before you start, update all your Netskope tenants with a V2 token that has access to all the Data Export endpoints.

Before you start, complete the Prerequisites and makeake a backup. For details, refer to Backup Cloud Exchange.

Go to the existing ta_cloud_exchange directory that has the docker-compose.yml file, and stop the Cloud Exchange containers:
```
sudo ./stop
```
If the output is ./stop: No such file or directory, run this command instead:
```
sudo docker compose down -v
```
If you made local changes to the docker-compose.yml file, reset them. You might need sudo.
```
sudo git reset --hard
```
Pull the latest changes:
```
sudo git pull
```

Copy the example configuration file, and open it for editing:

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

In cloudexchange.config, set the value of the maintenance password. Also set any optional fields that you use or customized, such as the proxy configuration and UI port.

MAINTENANCE_PASSWORD=<old maintenance password>
JWT_SECRET=<old cloud exchange JWT secret>

JWT_SECRET is optional. If you leave it empty, the setup script generates a new JWT secret

Run the setup script:
```
sudo python3 ./setup
```
Start Cloud Exchange:
```
sudo ./start
```
Close all your Cloud Exchange browser windows. Then clear the browser cache, or log in again in an incognito window. The Cloud Exchange UI is available at http(s)://<ip>.

HA Deployment

To v7.0.0 from v5.1.1, v5.1.2, v6.0.0, v6.0.1, v6.1.0 Standalone Deployment

Before you start, complete the Prerequisites and make a backup. For details, refer to Backup Cloud Exchange.

The existing standalone node becomes the primary node of the HA cluster. For details about the HA parameters and how to set up the cluster, refer to Cloud Exchange High Availability.

After you move to HA, Cloud Exchange may respond slowly for the first few minutes while the data is replicated to all the nodes.

On the Standalone Node (New Primary Node)

Stop the standalone deployment:
```
sudo ./stop
```

Go to the data directory, and create a zip file of the data:

cd ta_cloud_exchange/data
sudo zip -r ce_backup.zip mongo-data/ repos/ plugins/

If you use custom plugins, add them to the zip file:
```
sudo zip -r ce_backup.zip custom_plugins
```
Go back to the ta_cloud_exchange directory, and pull the latest changes:
```
cd ..
sudo git pull
```
If git pull fails, reset the local changes and pull again:
```
sudo git reset --hard
sudo git pull
```

Copy the example configuration file, and open it for editing:

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

In cloudexchange.config, set the values of these fields. Also set any optional fields that you use or customized, such as the proxy configuration and UI port.
```
MAINTENANCE_PASSWORD=<old cloud exchange maintenance password>
JWT_SECRET=<old cloud exchange JWT secret>
```
JWT_SECRET is optional. If you leave it empty, the setup script generates a new JWT secret.
Remove the .env file:
```
sudo rm -rf .env
```
Run the setup script:
```
sudo python3 ./setup
```
Start Cloud Exchange:
```
sudo ./start
```
Open the UI of the primary node in your browser at https://<ip>, and log in with your existing Cloud Exchange credentials.
Go to Settings > General Settings > Node Configurations and enable the Enable HA toggle. In the Confirm Action pop-up, enter the Cloud Exchange IP address or FQDN only if you need to change it, and click Enable HA.

Important

While HA is being enabled, Cloud Exchange is temporarily unavailable and may restart several times.

On the Secondary Nodes

Complete steps 1 to 6 on each secondary node. Then add the secondary nodes from the UI of the primary node.

Go to the ta_cloud_exchange directory that has the latest Cloud Exchange version:
```
cd <ta_cloud_exchange-dir>
```

On the primary node, copy the contents of the CA key file:

<ta_cloud_exchange-dir>/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key

On the secondary node, create the CA key file, paste the key that you copied, and save the file. The matching CA key lets the secondary node communicate with the HA cluster.
```
sudo vi data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
```

Copy the example configuration file, and open it for editing:

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

In cloudexchange.config, set the values of these fields:

Important

The JWT secret and the CA key of a secondary node must match the primary node. If they differ, adding the secondary node to the HA cluster fails with an authentication error. If you don’t know the JWT secret of the primary node, generate and apply a new one. For the steps, refer to Cloud Exchange Troubleshooting.
```
JWT_SECRET=<JWT_SECRET value of the primary node>
MAINTENANCE_PASSWORD=<old maintenance password>
```
Run the setup script:
```
sudo python3 ./setup
```
In the UI of the primary node, go to Settings > General Settings > Node Configurations and add the secondary nodes one at a time.

You don’t need to run the start script on the secondary nodes. It runs automatically when you add a secondary node from the UI of the primary node.

To v7.0.0 from v5.1.1, v5.1.2, v6.0.0, v6.0.1, v6.1.0 HA Deployment

Before you start, complete the Prerequisites and make a backup. For details, refer to Backup Cloud Exchange.

On All Nodes

Stop the secondary nodes first, and then the primary node, so that the containers shut down properly:
```
sudo ./stop
```
Pull the latest changes:
```
sudo git pull
```
If git pull fails, reset the local changes and pull again:
```
sudo git reset --hard
sudo git pull
```

On the Primary Node

Copy the example configuration file, and open it for editing:

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

In cloudexchange.config, set the values of these fields. Also set any optional fields that you use or customized, such as the proxy configuration and UI port.
```
HA_ENABLED=True
HA_CURRENT_NODE=<current node ip>
HA_PRIMARY_NODE_IP=<current node ip>
HA_IP_LIST=<current node ip>
MAINTENANCE_PASSWORD=<old maintenance password>
JWT_SECRET=<old cloud exchange JWT secret>
```
JWT_SECRET is optional. If you leave it empty, the setup script generates a new JWT secret.
Remove the .env file:
```
sudo rm -rf .env
```
Run the setup script:
```
sudo python3 ./setup
```
Start Cloud Exchange:
```
sudo ./start
```

On the Secondary Nodes

Complete steps 1 to 7 on each secondary node. Then add the secondary nodes from the UI of the primary node.

Go to the ta_cloud_exchange directory:
```
cd <ta_cloud_exchange-dir>
```

On the primary node, copy the contents of the CA key file:

<ta_cloud_exchange-dir>/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key

On the secondary node, create the CA key file, paste the key that you copied, and save the file. The matching CA key lets the secondary node communicate with the HA cluster.
```
sudo vi data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
```
Remove the .env file:
```
sudo rm -rf .env
```

Copy the example configuration file, and open it for editing:

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

In cloudexchange.config, set the values of these fields:

Important

The JWT secret and the CA key of a secondary node must match the primary node. If they differ, adding the secondary node to the HA cluster fails with an authentication error. If you don’t know the JWT secret of the primary node, generate and apply a new one. For the steps, refer to Cloud Exchange Troubleshooting.
```
JWT_SECRET=<JWT_SECRET value of the primary node>
MAINTENANCE_PASSWORD=<old maintenance password>
```
Run the setup script:
```
sudo python3 ./setup
```
In the UI of the primary node, go to Settings > General Settings > Node Configurations and add the secondary nodes one at a time.

You don’t need to run the start script on the secondary nodes. It runs automatically when you add a secondary node from the UI of the primary node.

Prerequisites

Before you start the upgrade, make sure your instance meets the Cloud Exchange System Requirements.

Disable all source plugins in all modules, and wait for the queued tasks to finish:

Wait 20 to 30 minutes after you disable the source plugins.

Go to Settings > Logging, click Filter Query, enter this filter in the Filters field, and click Load.

message Like "Ingested " || message Like "Stored " || message Like "task(s)" || message Like "Completed storing"

Monitor the filtered logs. When no new logs appear, continue with the upgrade.
After the upgrade is complete, enable the source plugins that you disabled.

Keep the maintenance password ready. You need it to complete some of the steps.

Important

If you lose the maintenance password, your existing data cannot be retained.

RabbitMQ data migration is not supported, because the queue type changed from Classic to Quorum.

Standalone Deployment

To v7.0.0 from v5.1.1, v5.1.2, v6.0.0, v6.0.1, v6.1.0 Standalone Deployment

Before you start, update all your Netskope tenants with a V2 token that has access to all the Data Export endpoints.

Before you start, complete the Prerequisites and makeake a backup. For details, refer to Backup Cloud Exchange.

Go to the existing ta_cloud_exchange directory that has the docker-compose.yml file, and stop the Cloud Exchange containers:
```
sudo ./stop
```
If the output is ./stop: No such file or directory, run this command instead:
```
sudo docker compose down -v
```
If you made local changes to the docker-compose.yml file, reset them. You might need sudo.
```
sudo git reset --hard
```
Pull the latest changes:
```
sudo git pull
```

Copy the example configuration file, and open it for editing:

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

In cloudexchange.config, set the value of the maintenance password. Also set any optional fields that you use or customized, such as the proxy configuration and UI port.

MAINTENANCE_PASSWORD=<old maintenance password>
JWT_SECRET=<old cloud exchange JWT secret>

JWT_SECRET is optional. If you leave it empty, the setup script generates a new JWT secret

Run the setup script:
```
sudo python3 ./setup
```
Start Cloud Exchange:
```
sudo ./start
```
Close all your Cloud Exchange browser windows. Then clear the browser cache, or log in again in an incognito window. The Cloud Exchange UI is available at http(s)://<ip>.

HA Deployment

To v7.0.0 from v5.1.1, v5.1.2, v6.0.0, v6.0.1, v6.1.0 Standalone Deployment

Before you start, complete the Prerequisites and make a backup. For details, refer to Backup Cloud Exchange.

The existing standalone node becomes the primary node of the HA cluster. For details about the HA parameters and how to set up the cluster, refer to Cloud Exchange High Availability.

After you move to HA, Cloud Exchange may respond slowly for the first few minutes while the data is replicated to all the nodes.

On the Standalone Node (New Primary Node)

Stop the standalone deployment:
```
sudo ./stop
```

Go to the data directory, and create a zip file of the data:

cd ta_cloud_exchange/data
sudo zip -r ce_backup.zip mongo-data/ repos/ plugins/

If you use custom plugins, add them to the zip file:
```
sudo zip -r ce_backup.zip custom_plugins
```
Go back to the ta_cloud_exchange directory, and pull the latest changes:
```
cd ..
sudo git pull
```
If git pull fails, reset the local changes and pull again:
```
sudo git reset --hard
sudo git pull
```

Copy the example configuration file, and open it for editing:

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

In cloudexchange.config, set the values of these fields. Also set any optional fields that you use or customized, such as the proxy configuration and UI port.
```
MAINTENANCE_PASSWORD=<old cloud exchange maintenance password>
JWT_SECRET=<old cloud exchange JWT secret>
```
JWT_SECRET is optional. If you leave it empty, the setup script generates a new JWT secret.
Remove the .env file:
```
sudo rm -rf .env
```
Run the setup script:
```
sudo python3 ./setup
```
Start Cloud Exchange:
```
sudo ./start
```
Open the UI of the primary node in your browser at https://<ip>, and log in with your existing Cloud Exchange credentials.
Go to Settings > General Settings > Node Configurations and enable the Enable HA toggle. In the Confirm Action pop-up, enter the Cloud Exchange IP address or FQDN only if you need to change it, and click Enable HA.

Important

While HA is being enabled, Cloud Exchange is temporarily unavailable and may restart several times.

On the Secondary Nodes

Complete steps 1 to 6 on each secondary node. Then add the secondary nodes from the UI of the primary node.

Go to the ta_cloud_exchange directory that has the latest Cloud Exchange version:
```
cd <ta_cloud_exchange-dir>
```

On the primary node, copy the contents of the CA key file:

<ta_cloud_exchange-dir>/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key

On the secondary node, create the CA key file, paste the key that you copied, and save the file. The matching CA key lets the secondary node communicate with the HA cluster.
```
sudo vi data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
```

Copy the example configuration file, and open it for editing:

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

In cloudexchange.config, set the values of these fields:

Important

The JWT secret and the CA key of a secondary node must match the primary node. If they differ, adding the secondary node to the HA cluster fails with an authentication error. If you don’t know the JWT secret of the primary node, generate and apply a new one. For the steps, refer to Cloud Exchange Troubleshooting.
```
JWT_SECRET=<JWT_SECRET value of the primary node>
MAINTENANCE_PASSWORD=<old maintenance password>
```
Run the setup script:
```
sudo python3 ./setup
```
In the UI of the primary node, go to Settings > General Settings > Node Configurations and add the secondary nodes one at a time.

You don’t need to run the start script on the secondary nodes. It runs automatically when you add a secondary node from the UI of the primary node.

To v7.0.0 from v5.1.1, v5.1.2, v6.0.0, v6.0.1, v6.1.0 HA Deployment

Before you start, complete the Prerequisites and make a backup. For details, refer to Backup Cloud Exchange.

On All Nodes

Stop the secondary nodes first, and then the primary node, so that the containers shut down properly:
```
sudo ./stop
```
Pull the latest changes:
```
sudo git pull
```
If git pull fails, reset the local changes and pull again:
```
sudo git reset --hard
sudo git pull
```

On the Primary Node

Copy the example configuration file, and open it for editing:

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

In cloudexchange.config, set the values of these fields. Also set any optional fields that you use or customized, such as the proxy configuration and UI port.
```
HA_ENABLED=True
HA_CURRENT_NODE=<current node ip>
HA_PRIMARY_NODE_IP=<current node ip>
HA_IP_LIST=<current node ip>
MAINTENANCE_PASSWORD=<old maintenance password>
JWT_SECRET=<old cloud exchange JWT secret>
```
JWT_SECRET is optional. If you leave it empty, the setup script generates a new JWT secret.
Remove the .env file:
```
sudo rm -rf .env
```
Run the setup script:
```
sudo python3 ./setup
```
Start Cloud Exchange:
```
sudo ./start
```

On the Secondary Nodes

Complete steps 1 to 7 on each secondary node. Then add the secondary nodes from the UI of the primary node.

Go to the ta_cloud_exchange directory:
```
cd <ta_cloud_exchange-dir>
```

On the primary node, copy the contents of the CA key file:

<ta_cloud_exchange-dir>/data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key

On the secondary node, create the CA key file, paste the key that you copied, and save the file. The matching CA key lets the secondary node communicate with the HA cluster.
```
sudo vi data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
```
Remove the .env file:
```
sudo rm -rf .env
```

Copy the example configuration file, and open it for editing:

cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config

In cloudexchange.config, set the values of these fields:

Important

The JWT secret and the CA key of a secondary node must match the primary node. If they differ, adding the secondary node to the HA cluster fails with an authentication error. If you don’t know the JWT secret of the primary node, generate and apply a new one. For the steps, refer to Cloud Exchange Troubleshooting.
```
JWT_SECRET=<JWT_SECRET value of the primary node>
MAINTENANCE_PASSWORD=<old maintenance password>
```
Run the setup script:
```
sudo python3 ./setup
```
In the UI of the primary node, go to Settings > General Settings > Node Configurations and add the secondary nodes one at a time.

You don’t need to run the start script on the secondary nodes. It runs automatically when you add a secondary node from the UI of the primary node.