4.3.9. Notes et procédures spécifiques V8.0¶

Prudence

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: V6 -> V7.0 -> V7.1 -> V8.0

4.3.9.1. Adaptation des sources de déploiement ansible¶

4.3.9.1.1. Configuration des jobs d’audit¶

Il est maintenant possible de configurer les jobs d’audit d’intégrité et d’existence par tenant, et par conséquent la définition des jobs d’audit a changé.

L’ancienne configuration définissait la fréquence d’exécution et les paramètres des jobs dans le fichier deployment/environments/group_vars/all/advanced/vitam_vars.yml :

vitam_timers:

functional_administration:: frequency_integrity_audit: « 0 0 0 1 JAN ? 2020 » frequency_existence_audit: « 0 0 0 1 JAN ? 2020 »

scheduler:

job_parameters:

integrity_audit:: operations_delay_in_minutes: 1440
existence_audit:: operations_delay_in_minutes: 1440

La nouvelle configuration n’utilise plus les valeurs de vitam_timers.functional_administration.frequency_integrity_audit et vitam_timers.functional_administration.frequency_existence_audit, et prend la forme suivante :

scheduler:

job_parameters:

integrity_audit:

key: SYSTEM selected_tenants: [1] operations_delay_in_minutes: 1440 frequency: « 0 0 2 ? * * * » # Every day at 2am
key: TENANT2 selected_tenants: [2] operations_delay_in_minutes: 1440 frequency: « 0 0 4 ? * * * » # Every day at 4am

existence_audit:

key: SYSTEM selected_tenants: [1,2] operations_delay_in_minutes: 1440 frequency: « 0 0 6 ? * * * » # Every day at 6am

Pour integrity_audit et existence_audit, il conviendra de définir une entrée par tenant ou groupe de tenant devant s’exécuter à la même fréquence. Les différents champs sont décrits ci-dessous :

Le paramètre key doit être unique et sera ajouté au nom du job. Il doit donc être de forme alphanumérique, sans espaces.

Le paramètre selected_tenants liste les identifiants de tenants auquel la fréquence s’applique. S’il est vide ou non renseigné, la fréquence s’appliquera à tous les tenants.

Le paramètre operations_delay_in_minutes correspond au paramètre de la version précédente.

Le paramètre frequency correspond aux fréquences précédemment définies dans les paramètres vitam_timers.functional_administration.frequency_integrity_audit et vitam_timers.functional_administration.frequency_existence_audit.

4.3.9.1.2. Déploiement des exporters pour VitamUI¶

Si vous utilisez VitamUI et que vous souhaitez déployer les exporters permettant de mettre en place la remontée de métriques dans Prometheus, vous devrez ajouter les groupes suivants au fichier d’inventaire (cf. inventaire d’exemple: environments/hosts.example):

[hosts:children] hosts_vitamui

4.3.9.1.2.1. # ZONE VITAMUI¶

[hosts_vitamui] # optional: To deploy exporters on VitamUI

[hosts_vitamui:children] hosts_vitamui_mongod

[hosts_vitamui_mongod] # optional: To deploy mongodb-exporter on VitamUI

Pour permettre de déployer l’exporter mongodb, vous devrez ajouter au fichier environments/group_vars/all/main/vault-vitam.yml les paramètres associés à la BDD mongo-vitamui:

mongodb:

mongo-vitamui:: mongod_port: 27017 admin:

user: vitamdb-admin password: admin1234

Avant de pouvoir exécuter le playbook de configuration des exporters pour VitamUI, il faudra au préalable récupérer les host_vars à l’aide du playbook ansible-vitam-exploitation/generate_hostvars_for_2_network_interfaces.yml ou ansible-vitam-exploitation/generate_hostvars_for_1_network_interface.yml.

Ensuite, ces exporters seront déployés à l’aide du playbook: ansible-vitam-extra/vitamui_prometheus.yml.

4.3.9.2. Procédures à exécuter AVANT la montée de version¶

4.3.9.2.1. Mise à jour des dépôts (YUM/APT)¶

Prudence

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/main/repositories.yml afin de renseigner les dépôts à la version cible.

Pour le dépôt vitam-external, vous devez renseigner la version adaptée à votre système d’exploitation (par exemple pour la version 8.0.0):

Puis exécutez le playbook suivant sur tous les sites :

ansible-playbook -i environments/<inventaire> ansible-vitam-extra/bootstrap.yml --ask-vault-pass

4.3.9.2.2. Arrêt complet de Vitam¶

Prudence

Cette opération doit être effectuée AVANT la montée de version vers la V8.0

Prudence

Cette opération doit être effectuée avec les sources de déploiements de l’ancienne version.

Vitam doit être arrêté sur tous les sites :

ansible-playbook -i environments/<inventaire> ansible-vitam-exploitation/stop_vitam.yml --ask-vault-pass

4.3.9.3. Application de la montée de version¶

Prudence

L’application de la montée de version s’effectue d’abord sur les sites secondaires puis sur le site primaire.

4.3.9.3.1. Lancement du master playbook vitam¶

ansible-playbook -i environments/<inventaire> ansible-vitam/vitam.yml --ask-vault-pass

4.3.9.3.2. Lancement du master playbook extra¶

ansible-playbook -i environments/<inventaire> ansible-vitam-extra/extra.yml --ask-vault-pass

4.3.9.4. Procédures à exécuter APRÈS la montée de version¶

4.3.9.4.1. Migration des mappings elasticsearch pour les métadonnées¶

Cette migration de données consiste à mettre à jour le modèle d’indexation des métadonnées sur elasticsearch-data.

Elle est réalisée en exécutant la procédure suivante sur tous les sites (primaire et secondaire(s)) :

ansible-playbook -i environments/<inventaire> ansible-vitam-migration/migration_elasticsearch_mapping.yml --ask-vault-pass

4.3.9.4.2. Migration des profiles¶

Prudence

Cette migration est à effectuer APRÈS la montée de version vers Vitam V8.0 et uniquement sur site primaire.

Ce playbook de migration a pour but de mettre à jour les notices en y intégrant la notion de SedaVersion.

Le script effectue les actions suivantes : - Définit par défaut la version SEDA 2.3 pour les AUP (Archive Unit Profile). - Si un fichier est présent pour les AP (Archive Profile), il tente de déterminer la version à partir de celui-ci. Dans le cas contraire, la version par défaut sera appliquée.

Pour lancer ce playbook, utilisez la commande suivante :

ansible-playbook -i environments/<inventaire> ansible-vitam-migration/migrate_profiles_v7.1_to_v8.0.yml --ask-vault-pass

4.3.9.4.3. Migration unités archivistiques avec demande de transfert non complétée¶

Cette migration permet de corriger des erreurs de sécurisation ou d’audit sur des unités archivistiques pour lesquelles une demande de transfert a été initiée, mais dont le transfert effectif n’a pas été finalisée.

Prudence

Cette procédure doit être exécutée uniquement en cas de migration majeure vers Vitam V8.0+ depuis : - Une version 7.1.1 ou inférieure - Une version 7.0.1 ou inférieure - Une version 6.3-1 ou inférieure

Prudence

Cette migration est à effectuer APRES l’installation et uniquement sur le site primaire.

Prudence

Dans le cas où un tenant comporte un très grand nombre d’unités archivistiques dont la demande de transfert a été initiée pour un tenant donné (plus de 100 000 unités archivistiques), la migration ne pourra alors s’opérer. Le support Vitam devra alors être contacté.

Pour lancer la migration, le playbook suivant doit être exécuté :

ansible-playbook -i environments/<inventaire> ansible-vitam-migration/migration_metadata_transfer_request_traceability.yml --ask-vault-pass