Un peu de DevOps, avec une méthode de migration i-Parapheur qui marche…
Souvent, un environnement applicatif a besoin d’être existant en plusieurs exemplaires :
- Nominal (de production): évidemment, pour le service actif
- Test: pour reproduire des anomalies au calme, ou tester des versions non qualifiées
- … et autres selon les besoins: formation, pré-prod… selon la politique d’exploitation « devops » en vigueur
…Avec cette démultiplication d’applications identiques, et des contextes d’usages différents, mais des besoins voisins!
Par exemple, une configuration validée en environnement de test cherchera à être dupliquée vers la production. Ou inversement, on aimera être capable de vérifier si une nouvelle version d’application fonctionne toujours avec le contexte de production: donc dupliquer le contexte production vers l’environnement de test.
Recensement des éléments variables
Ici, je prends l’exemple de l’application i-Parapheur 4.4 (c’est un peu mon bébé). Elle s’appuie sur un socle « Alfresco Community en version 3.4 ». Donc les principes présentés ici sont applicables à un processus de migration d’entrepôt Alfresco.
Dans le scénario qui suit, on imagine automatiser la migration i-Parapheur (1 fois par semaine par exemple).
Éléments de paramétrage contextuels
Ils ne sont pas assujettis à la migration:
- Frontal HTTPS: configuration du Apache ou NginX
- Configuration: alfresco-global.properties , iparapheur-global.properties, et plus généralement ce qui se passe dans tomcat/shared/classes/alfresco
Éléments sujets à la migration i-Parapheur
Il s’agit de l’entrepôt, soit:
- Contenu de la base de données « alfresco », hébergée sur service MySQL.
- + Données filesystem: arborescence « alf_data »
Ainsi , nous sommes en définitive dans un processus de backup / restauration, mais sur serveur distant.
Préparation des données sur le serveur source
Il faut faire une sauvegarde cohérente des données d’entrepôt, afin de pouvoir les réutiliser sans souci.
Par conséquent, enchaîner les opérations suivantes :
- Arrêter l’application pour éviter toute désynchronisation filesystem vs.mysql
- Dump de la base de données dans un fichier SQL
- Création d’une archive (tar.gz) du ‘dir.root’ (répertoire alf_data)
- A l’issue de ces opérations, on peut re-démarrer l’application.
De préférence, cette sauvegarde est faite de nuit, à intervalle régulier, et mise en place par du personnel qualifié.
Mise à jour du serveur destination
Ensuite, la restauration consiste à enchaîner les opérations suivantes :
- Arrêter l’application
- Remplacer le contenu de alf_data par le contenu de l’archive tar.gz provenant du serveur source
- Idem pour la base de données: purger la base ‘alfresco’, et injecter le contenu du fichier SQL provenant du serveur source.
- Modifier temporairement le fichier alfresco-global.properties, et positionner la directive
index.recovery.mode=FULL
- Se mettre en situation de réindexation LUCENE:
- supprimer le répertoire alf_data/lucene-indexes
- supprimer le répertoire alf_data/backup-lucene-indexes
- Re-démarrer l’application
- Une fois l’application démarrée, remettre le paramètre dans alfresco-global.properties.
index.recovery.mode=AUTO
Facile non ? Maintenant, scriptez-moi tout ça. 🙂