Mettre à jour Cloud Exchange conteneurisé - Documentation technique de Netskope

Utilisez ces étapes pour mettre à jour un déploiement conteneurisé de Cloud Exchange, autonome ou HA, vers la dernière version. Pour les chemins de mise à jour pris en charge et les autres types de déploiement, reportez-vous à la section Mettre à jour Cloud Exchange.

Important

Contactez votre SE/AM si vous avez des questions concernant l'installation, le déploiement, la configuration et la mise à jour de Cloud Exchange.

Avant de commencer la mise à niveau, assurez-vous que votre instance respecte les exigences système de Cloud Exchange.

Conditions préalables

Allez dans le répertoire d’installation Cloud Exchange : ta_cloud_exchange
Exécutez ces commandes pour télécharger le script de vérification de la mise à jour/migration et pour rendre le script exécutable :
```
curl -fsSL -O https://raw.githubusercontent.com/netskopeoss/ta_cloud_exchange/main/ce_healthcheck
chmod +x ce_healthcheck
```
Exécutez le script de vérification de mise à jour/migration. Pour plus de détails sur sa sortie, reportez-vous à Comprendre les résultats.
```
sudo python3 ./ce_healthcheck
```
- Pour les nœuds secondaires, exécutez la commande donnée ci-dessous. Ceci s’applique uniquement aux déploiements en HA.
```
sudo python3 ./ce_healthcheck --deployment HA
```
  Note
  
  Si l’une des vérifications échoue, veuillez les traiter avant de passer à l’étape suivante.
Désactivez tous les plugins source dans tous les modules et attendez que les tâches en file d'attente se terminent :
1. Attendez 20 à 30 minutes après avoir désactivé les plugins sources.
2. Accédez à Settings > Logging, cliquez sur Filter Query, entrez ce filtre dans le champ Filtres, puis cliquez sur Load.
```
message Like "Ingested " || message Like "Stored " || message Like "task(s)" || message Like "Completed storing"
```
3. Surveillez les logs filtrés. Lorsque plus aucun New log n’apparaît, poursuivez avec la mise à niveau.
4. Une fois la mise à niveau terminée, activez les plugins source que vous avez désactivés.
Gardez le mot de passe de maintenance à portée de main. Vous en aurez besoin pour effectuer certaines étapes.

Important

Si vous perdez le mot de passe de maintenance, vos données existantes ne pourront pas être conservées.

La migration des données RabbitMQ n'est pas prise en charge, car le type de file d'attente est passé de Classique à Quorum.

Déploiement autonome

De la v5.1.1 à la v7.0.0, v5.1.2, v6.0.0, v6.0.1, v6.1.0 Déploiement autonome

Avant de commencer, mettez à jour tous vos tenants Netskope avec un jeton V2 ayant accès à tous les points de terminaison d’exportation de données.

Avant de commencer, remplissez les Conditions préalables et effectuez une sauvegarde. Pour plus de détails, consultez Sauvegarder Cloud Exchange.

Accédez au répertoire ta_cloud_exchange existant contenant le fichier docker-compose.yml et arrêtez les conteneurs Cloud Exchange :
```
sudo ./stop
```
Si la sortie est ./stop: No such file or directory, exécutez plutôt cette commande :
```
sudo docker compose down -v
```
Si vous avez effectué des modifications locales sur le fichier docker-compose.yml, réinitialisez-les. Vous pourriez avoir besoin de sudo.
```
sudo git reset --hard
```
Extrayez les dernières modifications :
```
sudo git pull
```
Copiez l’exemple de fichier de configuration et ouvrez-le pour le modifier :
```
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
```
Dans cloudexchange.config, définissez la valeur du mot de passe de maintenance. Configurez également les champs facultatifs que vous utilisez ou personnalisez, tels que la configuration du proxy et le port de l’interface utilisateur.
```
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
```
Exécutez le script de configuration :
```
sudo python3 ./setup
```
Démarrez le Cloud Exchange :
```
sudo ./start
```
Fermez toutes vos fenêtres de navigateur Cloud Exchange. Videz ensuite le cache du navigateur ou connectez-vous à nouveau dans une fenêtre de navigation privée. L’interface utilisateur de Cloud Exchange est disponible à l’adresse http(s)://<ip>.

Les plugins CLS qui utilisent l’authentification TLS doivent être mis à jour vers une version compatible CE 7.0.0 avant de pouvoir être configurés ou utilisés sur CE 7.0.0. Consultez la base de connaissances pour connaître les plugins concernés.

Déploiement HA

De la v5.1.1 à la v7.0.0, v5.1.2, v6.0.0, v6.0.1, v6.1.0 Déploiement autonome

Avant de commencer, complétez les Conditions préalables et effectuez une sauvegarde. Pour plus de détails, reportez-vous à Sauvegarder Cloud Exchange.

Le nœud autonome existant devient le nœud principal du cluster HA. Pour plus de détails sur les paramètres HA et sur la configuration du cluster, reportez-vous à la section Haute disponibilité de Cloud Exchange.

Une fois que vous êtes passé en haute disponibilité (HA), Cloud Exchange peut répondre lentement pendant les premières minutes pendant que les données sont répliquées sur tous les nœuds.

Sur le nœud autonome (New nœud primaire)

Arrêtez le déploiement autonome :
```
sudo ./stop
```

Accédez au répertoire des données et créez un fichier zip des données :

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

Si vous utilisez des plug-ins personnalisés, ajoutez-les au fichier zip :
```
sudo zip -r ce_backup.zip custom_plugins
```
Revenez au répertoire ta_cloud_exchange et récupérez les dernières modifications :
```
cd ..
sudo git pull
```
Si git pull échoue, réinitialisez les modifications locales et effectuez à nouveau une extraction :
```
sudo git reset --hard
sudo git pull
```
Copiez l’exemple de fichier de configuration et ouvrez-le pour le modifier :
```
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
```
Dans cloudexchange.config, définissez les valeurs de ces champs. Définissez également les champs facultatifs que vous utilisez ou personnalisez, tels que la configuration du proxy et le port de l’interface utilisateur.
```
MAINTENANCE_PASSWORD=<old cloud exchange maintenance password>
JWT_SECRET=<old cloud exchange JWT secret>
```
JWT_SECRET est optionnel. Si vous le laissez vide, le script d’installation génère un New secret JWT.
Supprimer le fichier .env :
```
sudo rm -rf .env
```
Exécutez le script de configuration :
```
sudo python3 ./setup
```
Démarrez le Cloud Exchange :
```
sudo ./start
```
Ouvrez l’interface utilisateur du nœud principal dans votre navigateur à l’adresse https://<ip> et connectez-vous avec vos identifiants Cloud Exchange existants.
Accédez à Settings > General Settings > Node Configurations et activez le commutateur Enable HA. Dans la fenêtre contextuelle Confirmer l’action, saisissez l’adresse IP ou le FQDN de Cloud Exchange uniquement si vous devez les modifier, puis cliquez sur Enable HA.

Important

Pendant que la HA est activée, Cloud Exchange est temporairement indisponible et peut redémarrer plusieurs fois.

Sur les nœuds secondaires

Effectuez les étapes 1 à 6 sur chaque nœud secondaire. Ajoutez ensuite les nœuds secondaires à partir de l'interface utilisateur du nœud primaire.

Accédez au répertoire ta_cloud_exchange qui contient la dernière version de Cloud Exchange :
```
cd <ta_cloud_exchange-dir>
```

Sur le nœud principal, copiez le contenu du fichier de clé CA :

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

Sur le nœud secondaire, créez le fichier de clé d’autorité de certification, collez la clé que vous avez copiée et enregistrez le fichier. La clé d’autorité de certification correspondante permet au nœud secondaire de communiquer avec le cluster HA.
```
sudo vi data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
```
Copiez l’exemple de fichier de configuration et ouvrez-le pour le modifier :
```
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
```
Dans cloudexchange.config, définissez les valeurs de ces champs :

Important

Le secret JWT et la clé CA d'un nœud secondaire doivent correspondre à ceux du nœud principal. S'ils diffèrent, l'ajout du nœud secondaire au cluster HA échouera avec une erreur d'authentification. Si vous ne connaissez pas le secret JWT du nœud principal, générez-en un New et appliquez-le. Pour les étapes, reportez-vous à la section Dépannage de Cloud Exchange.
```
JWT_SECRET=<JWT_SECRET value of the primary node>
MAINTENANCE_PASSWORD=<old maintenance password>
```
Exécutez le script de configuration :
```
sudo python3 ./setup
```
Dans l’interface utilisateur du nœud principal, accédez à Settings > General Settings > Node Configurations et ajoutez les nœuds secondaires un par un.

Il n’est pas nécessaire d’exécuter le script de démarrage sur les nœuds secondaires. Il s’exécute automatiquement lorsque vous ajoutez un nœud secondaire depuis l’interface utilisateur du nœud principal.

Vers la version 7.0.0 à partir de la version 5.1.1, version 5.1.2, version 6.0.0, version 6.0.1, version 6.1.0 Déploiement HA

Avant de commencer, complétez les Conditions préalables et effectuez une sauvegarde. Pour plus de détails, reportez-vous à Sauvegarder Cloud Exchange.

Sur tous les nœuds

Arrêtez d'abord les nœuds secondaires, puis le nœud primaire, afin que les conteneurs s'arrêtent correctement :
```
sudo ./stop
```
Extrayez les dernières modifications :
```
sudo git pull
```
Si git pull échoue, réinitialisez les modifications locales et effectuez à nouveau une extraction :
```
sudo git reset --hard
sudo git pull
```

Sur le nœud principal

Copiez l’exemple de fichier de configuration et ouvrez-le pour le modifier :
```
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
```
Dans cloudexchange.config, définissez les valeurs de ces champs. Définissez également les champs facultatifs que vous utilisez ou personnalisez, tels que la configuration du proxy et le port de l’interface utilisateur.
```
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 est optionnel. Si vous le laissez vide, le script d’installation génère un New secret JWT.
Supprimer le fichier .env :
```
sudo rm -rf .env
```
Exécutez le script de configuration :
```
sudo python3 ./setup
```
Démarrez le Cloud Exchange :
```
sudo ./start
```

Sur les nœuds secondaires

Effectuez les étapes 1 à 7 sur chaque nœud secondaire. Ajoutez ensuite les nœuds secondaires à partir de l’interface utilisateur du nœud primaire.

Accédez au répertoire ta_cloud_exchange :
```
cd <ta_cloud_exchange-dir>
```

Sur le nœud principal, copiez le contenu du fichier de clé CA :

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

Sur le nœud secondaire, créez le fichier de clé d’autorité de certification, collez la clé que vous avez copiée et enregistrez le fichier. La clé d’autorité de certification correspondante permet au nœud secondaire de communiquer avec le cluster HA.
```
sudo vi data/ssl_certs/mongodb_rabbitmq_certs/tls_cert_ca.key
```
Supprimer le fichier .env :
```
sudo rm -rf .env
```
Copiez l’exemple de fichier de configuration et ouvrez-le pour le modifier :
```
cp cloudexchange.config.example cloudexchange.config
vi cloudexchange.config
```
Dans cloudexchange.config, définissez les valeurs de ces champs :

Important

Le secret JWT et la clé CA d'un nœud secondaire doivent correspondre à ceux du nœud principal. S'ils diffèrent, l'ajout du nœud secondaire au cluster HA échouera avec une erreur d'authentification. Si vous ne connaissez pas le secret JWT du nœud principal, générez-en un New et appliquez-le. Pour les étapes, reportez-vous à la section Dépannage de Cloud Exchange.
```
JWT_SECRET=<JWT_SECRET value of the primary node>
MAINTENANCE_PASSWORD=<old maintenance password>
```
Exécutez le script de configuration :
```
sudo python3 ./setup
```
Dans l’interface utilisateur du nœud principal, accédez à Settings > General Settings > Node Configurations et ajoutez les nœuds secondaires un par un.

Il n’est pas nécessaire d’exécuter le script de démarrage sur les nœuds secondaires. Il s’exécute automatiquement lorsque vous ajoutez un nœud secondaire depuis l’interface utilisateur du nœud principal.