5. Procédure de Montée de version VitamUI V7.1
Attention: Veuillez appliquer les procédures spécifiques à chacune des versions précédentes en fonction de la version de départ selon la suite suivante: V5 -> V6RC -> V6 -> V7.0.
5.1. Adaptation des sources de déploiement ansible
5.1.1. Mise à jour du fichier d’inventaire
De nouveaux groupes et paramètres ont fait leur apparition dans le fichier d’inventaire.
Veuillez vous référer à l’inventaire de référence: environments/hosts-ui.example.
Ajout du nouveau groupe
[hosts_vitamui_api_gateway]au sein de la zone[zone_vitamui_app:children]: Obligatoire pour permettre de déployer ce nouveau composant.Ajout du nouveau groupe
[hosts_logstash]au sein de la zone[vitam:children]: Obligatoire si le groupe[hosts_vitamui_logstash]n’est pas défini et quesyslog.name: filebeat(par défaut).Ajout du nouveau groupe
[reverse]au sein de la zone[vitam:children]: Optionnel, uniquement dans le cas d’un déploiement des extra VitamUI (non recommandé en production).Ajout de la variable
vitamui_reverse_external_dns: Obligatoire pour définir l’url d’accès à VitamUI.
5.1.2. Mise à jour des certificats
5.1.2.1. Recharting des applications frontend
Suite au recharting des webapps front, leurs ressources sont maintenant hébergées sur un serveur nginx.
Ainsi, il peut-être opportun de redispatcher les composants des groupes [hosts_ui_*] sur les même machines que celles du groupe [hosts_vitamui_reverseproxy] afin de mutualiser l’utilisation des ressources.
Si vous modifiez la répartition des services UI dans votre inventaire, vous devrez regénérer les certificats pour ces composants et ainsi supprimer les précédents via la commande suivante:
find environments/certs/server/hosts/ -name ui-* -type f -delete
5.1.2.2. Nouveau composant applicatif API Gateway
À partir de la V7.1, le nouveau composant applicatif api-gateway a été introduit et nécessite un certificat.
De plus, si vous avez modifié la répartition des services UI, ces commandes seront aussi nécessaires.
Générer les nouveaux certificats
./pki/scripts/generate_certs.sh environments/<inventaire>Regénérer les stores
./generate_stores.sh true
5.1.3. Nouvelle variable vitamui_reverse_external_dns
L’objectif est de différencier le nom du domaine VitamUI de celui de Vitam car ils peuvent être hébergés sur des reverses distincts.
Cette distinction permet notamment d’appliquer le rôle merge_index sur le groupe [reverse] afin de fournir les liens d’accès à mongo-express-mongo-vitamui et aux browsers si ils sont déployés.
Attention, à ne pas déployer en production !
Il est maintenant indispensable de rajouter à votre fichier d’inventaire la variable vitamui_reverse_external_dns pointant vers le nom de domaine externe d’appel à VitamUI.
5.1.4. Modification de la durée de rétention des logs par défaut
Par défaut on conserve maintenant 365j de logs (accesslogs & applicatif) dans une limite de 5GB (par composant). De plus, nous avons réduit la quantité de logs gc de 32*64m=2048m à 8*32m=256m.
Il est toujours possible de personnaliser ce paramétrage par défaut via les variables suivantes:
Pour les gc:
vitamui_defaults.jvm_opts.gcou par composant en utilisant la variablevitamui.<composant>.jvm_opts.gc.
Pour les accesslogs:
vitamui_defaults.services.access_retention_days: 365ou par composant en utilisant la variablevitamui.<composant>.access_retention_days: 365.vitamui_defaults.services.access_total_size_cap: 5GBou par composant en utilisant la variablevitamui.<composant>.access_total_size_cap: 5GB.
Pour les logs applicatifs:
vitamui_defaults.services.log.logback_max_history: 365ou par composant en utilisant la variablevitamui.<composant>.log.logback_max_history: 365.vitamui_defaults.services.log.logback_total_size_cap: 5GBou par composant en utilisant la variablevitam.<composant>.log.logback_total_size_cap: 5GB.
5.1.5. Modification de la méthodologie de concentration des logs
Un nouveau composant applicatif (Filebeat) permettant de collecter les logs dans le cluster elasticsearch-log a été ajouté.
La méthode de collecte via rsyslog et syslog-ng sera donc dépréciée dans les futures releases.
Vous pouvez continuer à utiliser les précédentes méthodes de concentation de logs via la configuration du paramètre syslog.name: filebeat (rsyslog, syslog-ng).
5.1.6. Nouveau mode de déploiement en container (beta)
Attention, à ne pas utiliser en production.
Pour permettre le déploiement en mode conteneur de VitamUI, vous devez configurer les valeurs suivantes:
Dans le fichier de configuration des repositories environments/group_vars/all/main/repositories.yml
install_mode: container # Default to legacy
container_repository:
registry_url:
username:
password:
5.1.7. Configuration des jetons de communication interne CAS
Cette opération doit être effectuée en cas de mise à jour majeure depuis une version v7.0.x vers une version v7.1.3+ (version 7.1.3 ou supérieure).
Une nouvelle clé vitamui.cas_server.secret_token doit être éditée dans le fichier de configuration environments/group_vars/all/vault-vitamui.yml. Elle permet de sécuriser les appels d’API entre le CAS Server et IAM.
ansible-vault edit --vault-password-file vault_pass.txt environments/group_vars/all/vault-vitamui.yml
Attention, la clé devrait être configurée avec une clé alphanumérique longue et sans caractères spéciaux.
5.2. Procédures à exécuter AVANT la montée de version
5.2.1. Mise à jour des dépôts (YUM/APT)
Cette opération doit être effectuée AVANT la montée de version
Afin de pouvoir déployer la nouvelle version, vous devez mettre à jour la variable vitam_repositories sous environments/group_vars/all/repositories.yml afin de renseigner les dépôts à la version cible.
Puis exécutez le playbook suivant :
ansible-playbook -i environments/<inventaire> ansible-vitamui-extra/bootstrap.yml --ask-vault-pass
5.2.2. Montée de version vers mongo 6.0
Attention: Cette montée de version doit être effectuée AVANT la montée de version V7.1 de VitamUI. Cette opération doit être effectuée après avoir mis à jour les dépôts Vitam en V7.1. Il est recommandé d’effectuer un backup de la base de données à l’aide de mongodump avant de poursuivre.
Exécutez le playbook suivant à partir de l’ansiblerie de la V7.1 :
ansible-playbook -i environments/<inventaire> ansible-vitamui-migration/migration_mongodb_60.yml --ask-vault-pass
5.2.3. Montée de version vers mongo 7.0
Attention: Cette montée de version doit être effectuée AVANT la montée de version V7.1 de VitamUI et après la montée de version de MongoDB 6.0 ci-dessus. Cette opération doit être effectuée après avoir mis à jour les dépôts Vitam en V7.1.
Exécutez le playbook suivant à partir de l’ansiblerie de la V7.1 :
ansible-playbook -i environments/<inventaire> ansible-vitamui-migration/migration_mongodb_70.yml --ask-vault-pass
5.2.4. Arrêt complet de VitamUI
Cette opération doit être effectuée AVANT la montée de version vers la V7.1. Cette opération doit être effectuée avec les sources de déploiement de l’ancienne version.
VitamUI doit être arrêté :
ansible-playbook -i environments/<inventaire> ansible-vitamui-exploitation/stop_vitamui.yml --ask-vault-pass
5.2.5. Playbook de migration vers la V7.1
Cette opération doit être effectuée AVANT la montée de version vers la V7.1. Cette opération doit être effectuée avec les sources de déploiement de la V7.1 avec l’inventaire de l’ancienne version (si vous avez modifié la répartition des composants des groupes
[hosts_ui_*]ou[hosts_vitamui_reverseproxy]), sinon vous pouvez utiliser votre inventaire V7.1.
Exécutez le script de migration pour supprimer les anciens services UI Java, supprimer les anciens éléments du reverse et de vitamui-logstash.
Les éléments de configuration du reverse sur les machines
[hosts_vitamui_reverseproxy]sera supprimé, n’oubliez pas de backuper vos configurations en cas de besoin.
ansible-playbook -i environments/<inventaire-version-precedente> ansible-vitamui-migration/migration_vitamui_71.yml --ask-vault-pass
5.3. Application de la montée de version
5.3.1. Lancement du master playbook vitamui
Cette opération doit être effectuée avec les sources de déploiement de la V7.1.
ansible-playbook -i environments/<inventaire> ansible-vitamui/vitamui.yml --ask-vault-pass
5.4. Procédures à exécuter APRÈS la montée de version
N/A